chore: address comments in #9890

EIPS/eip-7966.md

@@ -20,16 +20,16 @@ Currently, Ethereum clients submit signed transactions asynchronously using `eth
 
 This asynchronous approach is not efficient for high-frequency blockchains or Layer 2 solutions with fast block times and low latency, where rapid transaction throughput and quick confirmation feedback are critical. The need to separately poll for receipts results in increased network overhead, slower overall transaction confirmation feedback, and more complex client implementations.
 
-![Sync vs Async Transaction Sending](../assets/eip-sync_send_method/sync-vs-async.png)
-_In a low-latency blockchain, transaction receipts are often available right after the transactions land to the block producer’s mempool. Requiring an additional RPC call introduces unnecessary latency._
+![Sync vs Async Transaction Sending](../assets/eip-7966/sync-vs-async.png)
+_In a low-latency blockchain, transaction receipts are often available right after the transactions land in the block producer’s mempool. Requiring an additional RPC call introduces unnecessary latency._
 
-`eth_sendRawTransactionSync` addresses these issues by combining transaction submission and receipt retrieval into a single RPC call. This helps
+`eth_sendRawTransactionSync` addresses these issues by combining transaction submission and receipt retrieval into a single RPC call. This helps:
 
 - reduce total transaction submission and confirmation latency by approximately 50%;
 - simplify client implementations by eliminating the need for separate polling loops;
 - improve user experience by enabling more responsive dApps and wallets;
 - align blockchain interactions closer to traditional Web2 request-response patterns;
-- maintain backward-compatibility and optionality, preserving existing RPC methods and semantics.
+- maintain backward compatibility and optionality, preserving existing RPC methods and semantics.
 
 ## Specification
 
@@ -38,21 +38,22 @@ _In a low-latency blockchain, transaction receipts are often available right aft
 `eth_sendRawTransactionSync`
 
 ### Parameters
-The parameters of this method is identical to the `eth_sendRawTransaction` method which contain a signed transaction data.
+The parameters of this method MUST be identical to the `eth_sendRawTransaction` method, which contain a signed transaction data.
 - `DATA`. The signed transaction data.
 
 ### Returns
-- **On success**. Return the transaction receipt object as defined by the [`eth_getTransactionReceipt`](https://docs.metamask.io/services/reference/ethereum/json-rpc-methods/eth_gettransactionreceipt/) method. If the transaction is not yet included in a block, the fields blockHash will be populated but all other fields will be `null` or omitted depending on the client implementation.
-- **On timeout error**. Return an error code `-32002` with a timeout message.
-- **On standard error**. Return A JSON-RPC error object consistent with existing RPC error formats.
+- **On success**. Clients MUST return the transaction receipt object as defined by the [`eth_getTransactionReceipt`](https://docs.metamask.io/services/reference/ethereum/json-rpc-methods/eth_gettransactionreceipt/) method.
+- **On timeout error**. Clients MUST return an error code `-32002` with a timeout message.
+- **On standard error**. Clients MUST return a JSON-RPC error object consistent with existing RPC error formats.
 
 ### Behavior
-Upon receiving an `eth_sendRawTransactionSync` request, the handler function performs the follow task.
-- Submit the signed transaction to the network as per the existing `eth_sendRawTransaction` semantics.
-- Poll for the transaction receipt at short intervals (e.g., every 10 milliseconds).
-- If the receipt is found within the specified timeout, return it immediately.
-- If the timeout expires without obtaining a receipt, return an error message with a timeout message.
-- If the transaction submission fails (e.g., due to invalid transaction data), return an error immediately.
+Upon receiving an `eth_sendRawTransactionSync` request, the handler function performs the following tasks.
+- The handler function MUST submit the signed transaction to the network as per the existing `eth_sendRawTransaction` semantics.
+- The handler function MUST wait for the transaction receipt until the timeout elapses.
+- If the receipt is found within the specified timeout, the handler function MUST return it immediately.
+- If the timeout expires without obtaining a receipt, the handler function MUST return an error message with a timeout message.
+- If the transaction submission fails (e.g., due to invalid transaction data), the handler function MUST return an error immediately.
+
 
 ### Example Request
 ```json
@@ -130,11 +131,11 @@ The synchronous receipt retrieval reduces the complexity of client applications
 
 ## Backwards Compatibility
 
-This EIP introduces a new RPC method and does not modify or deprecate any existing methods. Clients and servers that do not implement this method will continue operating normally. Existing applications using `eth_sendRawTransaction` are unaffected. Clients not supporting the method will simply return `method not found`.
+This EIP introduces a new RPC method and does not modify or deprecate any existing methods. Clients and servers that do not implement this method will continue operating normally. Existing applications using `eth_sendRawTransaction` are unaffected. Clients that do not support the method will simply return `method not found`.
 
 ## Reference Implementation
 
-A minimal reference implementation can be realized by wrapping existing `eth_sendRawTransaction` submission with a polling loop that queries `eth_getTransactionReceipt` at short intervals until receipt is found or timeout occurs. Polling intervals and timeout values can be tuned by client implementations to optimize performance.
+A minimal reference implementation can be realized by wrapping existing `eth_sendRawTransaction` submission with a polling loop that queries `eth_getTransactionReceipt` at short intervals until a receipt is found or a timeout occurs. Polling intervals and timeout values can be tuned by client implementations to optimize performance.
 
 For example, in [reth](https://github.com/paradigmxyz/reth), we can implement the handler for `eth_sendRawTransactionSync` as follows.
 ```rust
@@ -162,7 +163,7 @@ async fn send_raw_transaction_sync(&self, tx: Bytes) -> RpcResult<OpTransactionR
 }
 ```
 
-Other implementations such as [`go-ethereum`](https://github.com/ethereum/go-ethereum) can utilize channel to signify receipt availability instead of polling. A prototype is being developed in reth:
+Other implementations such as [`go-ethereum`](https://github.com/ethereum/go-ethereum) can utilize a channel to signify receipt availability instead of polling. A prototype is being developed in reth:
 - [Issue](https://github.com/paradigmxyz/reth/issues/16674)
 - [Pull request](https://github.com/paradigmxyz/reth/pull/16683)