chore(fmt): build

EIP-SPEC.md

@@ -3,7 +3,7 @@ eip: 0000
 title:
 description:
 author: Sam Bacha (@sambacha) <Additional Contributors HERE>
-discussions-to: 
+discussions-to:
 status:
 type: Standards Track
 category: Interface
@@ -13,72 +13,48 @@ requires: 86, 155, 695, 1193
 
 # Abstract
 
-
-
 ## Motivation
 
-
 ## Rationale
 
-
-
 ## Specification
-  
+
 IETF: 4627, 2119, 3986
 
 ### Key Words
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
-"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
-[RFC-2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119](https://www.ietf.org/rfc/rfc2119.txt).
 
 ### ResourceURI (string)
 
-Uniform Resource Identifier as specified in RFC 3986, is used to identify and resolve endpoints. 
-Case sensitive and MUST be case normalized as per section 6.2.2.1 of RFC 3986, m
-eaning that the scheme and authority MUST be in lowercase.
+Uniform Resource Identifier as specified in RFC 3986, is used to identify and resolve endpoints. Case sensitive and MUST be case normalized as per section 6.2.2.1 of RFC 3986, m eaning that the scheme and authority MUST be in lowercase.
 
-### JSON-RPC 
+### JSON-RPC
 
-Since JSON-RPC utilizes JSON, it has the same type system (described in
-[RFC 4627](http://www.ietf.org/rfc/rfc4627.txt)). JSON can represent four primitive types (Strings,
-Numbers, Booleans, and Null) and two structured types (Objects and Arrays). The term "Primitive" in
-this specification references any of those four primitive JSON types. The term "Structured"
-references either of the structured JSON types. Whenever this document refers to any JSON type, the
-first letter is always capitalized: Object, Array, String, Number, Boolean, Null. True and False are
-also capitalized.
+Since JSON-RPC utilizes JSON, it has the same type system (described in [RFC 4627](http://www.ietf.org/rfc/rfc4627.txt)). JSON can represent four primitive types (Strings, Numbers, Booleans, and Null) and two structured types (Objects and Arrays). The term "Primitive" in this specification references any of those four primitive JSON types. The term "Structured" references either of the structured JSON types. Whenever this document refers to any JSON type, the first letter is always capitalized: Object, Array, String, Number, Boolean, Null. True and False are also capitalized.
 
-All member names exchanged between the Client and the Server that are considered for matching of any
-kind should be considered to be case-sensitive. The terms function, method, and procedure can be
-assumed to be interchangeable.
+All member names exchanged between the Client and the Server that are considered for matching of any kind should be considered to be case-sensitive. The terms function, method, and procedure can be assumed to be interchangeable.
 
-The Client is defined as the origin of Request objects and the handler of Response objects. The
-Server is defined as the origin of Response objects and the handler of Request objects.
+The Client is defined as the origin of Request objects and the handler of Response objects. The Server is defined as the origin of Response objects and the handler of Request objects.
 
 ### `wallet_switchNetworkRpcProvider`
 
 #### Parameters
 
 #### Parameters
 
-
-
 #### Returns
 
-
 ### Examples
 
-
 ## Backwards Compatibility
-  
-*Tentative*: Will Examine more thoroughly 
+
+_Tentative_: Will Examine more thoroughly
 
 Does not introduce backwards incompatibilities with existing `eth_` methods or EIP specifications
 
 ## Security Considerations
 
-
-
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

README.md

@@ -6,15 +6,12 @@ A specification for the new Ethereum JSON-RPC Method `eth_getTransactionBySender
 
 ## Overview
 
-Returns the transaction object for a given sender's address and nonce, if any. 
-This method provides a way for users to check which transaction is using a specific nonce for their address. It can be particularly useful in scenarios where users want to understand the status of a particular transaction or if they suspect that a nonce might have been used maliciously.
+Returns the transaction object for a given sender's address and nonce, if any. This method provides a way for users to check which transaction is using a specific nonce for their address. It can be particularly useful in scenarios where users want to understand the status of a particular transaction or if they suspect that a nonce might have been used maliciously.
 
 ## Specification
 
 [eth_getTransactionBySenderAndNonce](./eth_getTransactionBySenderAndNonce.md)
 
 ## Contributors
 
-Patricio Palladino
-Sam Bacha
-
+Patricio Palladino Sam Bacha

eth_getTransactionBySenderAndNonce.md

@@ -2,7 +2,7 @@
 title: Specification for eth_getTransactionBySenderAndNonce RPC Method
 description:
 version:
-author: 
+author:
 ---
 
 ## `eth_getTransactionBySenderAndNonce`
@@ -18,53 +18,53 @@ Returns the transaction object for a given sender's address and nonce, if any.
 
 `Object` - A transaction object, or `null` if no transaction matches the given sender and nonce. The transaction object has the following fields:
 
-- `hash`: `DATA`, 32 bytes - Hash of the transaction.
-- `nonce`: `QUANTITY` - The number of transactions made by the sender prior to this one.
-- `blockHash`: `DATA`, 32 bytes - Hash of the block where this transaction was in. `null` when its pending.
-- `blockNumber`: `QUANTITY` - Block number where this transaction was in. `null` when its pending.
-- `transactionIndex`: `QUANTITY` - Integer of the transactions index position in the block. `null` when its pending.
-- `from`: `DATA`, 20 bytes - Address of the sender.
-- `to`: `DATA`, 20 bytes - Address of the receiver. `null` when its a contract creation transaction.
-- `value`: `QUANTITY` - Value transferred in Wei.
-- `gasPrice`: `QUANTITY` - Gas price provided by the sender in Wei.
-- `gas`: `QUANTITY` - Gas provided by the sender.
-- `input`: `DATA` - The data sent along with the transaction.
+-   `hash`: `DATA`, 32 bytes - Hash of the transaction.
+-   `nonce`: `QUANTITY` - The number of transactions made by the sender prior to this one.
+-   `blockHash`: `DATA`, 32 bytes - Hash of the block where this transaction was in. `null` when its pending.
+-   `blockNumber`: `QUANTITY` - Block number where this transaction was in. `null` when its pending.
+-   `transactionIndex`: `QUANTITY` - Integer of the transactions index position in the block. `null` when its pending.
+-   `from`: `DATA`, 20 bytes - Address of the sender.
+-   `to`: `DATA`, 20 bytes - Address of the receiver. `null` when its a contract creation transaction.
+-   `value`: `QUANTITY` - Value transferred in Wei.
+-   `gasPrice`: `QUANTITY` - Gas price provided by the sender in Wei.
+-   `gas`: `QUANTITY` - Gas provided by the sender.
+-   `input`: `DATA` - The data sent along with the transaction.
 
 ### Example
 
 #### Request
 
 ```json
 {
-  "id": 1,
-  "jsonrpc": "2.0",
-  "method": "eth_getTransactionBySenderAndNonce",
-  "params": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "0x1"]
+	"id": 1,
+	"jsonrpc": "2.0",
+	"method": "eth_getTransactionBySenderAndNonce",
+	"params": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "0x1"]
 }
 ```
 
 #### Response
 
 ```json
 {
-  "id": 1,
-  "jsonrpc": "2.0",
-  "result": {
-    "hash": "0x9fc76417374aa880d4449a1f7f31ec597f00b1f6f3dd2d66f4c9c6c445836d8b",
-    "nonce": "0x1",
-    "blockHash": "0xef95f2f1ed3ca60b048b4bf67cde2195961e0bba6f70bcbea9a2c4e133e34b46",
-    "blockNumber": "0x6fd9e2a26ab",
-    "transactionIndex": "0x1",
-    "from": "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
-    "to": "0x85h43d8a49eeb85d32cf465507dd71d507100c2",
-    "value": "0x7f110",
-    "gasPrice": "0x09184e72a000",
-    "gas": "0x2710",
-    "input": "0x68656c6c6f21"
-  }
+	"id": 1,
+	"jsonrpc": "2.0",
+	"result": {
+		"hash": "0x9fc76417374aa880d4449a1f7f31ec597f00b1f6f3dd2d66f4c9c6c445836d8b",
+		"nonce": "0x1",
+		"blockHash": "0xef95f2f1ed3ca60b048b4bf67cde2195961e0bba6f70bcbea9a2c4e133e34b46",
+		"blockNumber": "0x6fd9e2a26ab",
+		"transactionIndex": "0x1",
+		"from": "0x407d73d8a49eeb85d32cf465507dd71d507100c1",
+		"to": "0x85h43d8a49eeb85d32cf465507dd71d507100c2",
+		"value": "0x7f110",
+		"gasPrice": "0x09184e72a000",
+		"gas": "0x2710",
+		"input": "0x68656c6c6f21"
+	}
 }
 ```
 
 ---
 
-This method provides a way for users to check which transaction is using a specific nonce for their address. It can be particularly useful in scenarios where users want to understand the status of a particular transaction or if they suspect that a nonce might have been used maliciously.
+This method provides a way for users to check which transaction is using a specific nonce for their address. It can be particularly useful in scenarios where users want to understand the status of a particular transaction or if they suspect that a nonce might have been used maliciously.

package.json

@@ -0,0 +1,15 @@
+{
+  "name": "eth-gettx",
+  "version": "1.0.0",
+  "description": "## Abstract",
+  "main": "prettier.config.js",
+  "scripts": {
+    "test": "echo \"Error: no test specified\" && exit 1"
+  },
+  "keywords": [],
+  "author": "",
+  "license": "ISC",
+  "devDependencies": {
+    "prettier": "^3.0.3"
+  }
+}