Add EIP: eth_sendRawTransactionSync Method #9890

SmoothBot · 2025-06-11T05:39:41Z

EIP: eth_sendRawTransactionSync RPC Method for Lower Latency Transaction Submission

This EIP proposes a new JSON-RPC method eth_sendRawTransactionSync which reduces the latency between transaction submission and user confirmation by blocking until the transaction has been included in a block or safely gossiped to peers. This method addresses the user experience gap in high-frequency applications by offering stronger delivery guarantees than eth_sendRawTransaction.

eth-bot · 2025-06-11T05:40:07Z

File `EIPS/eip-7966.md`

Requires 1 more reviewers from @g11tech, @lightclient, @SamWilsn

chore: update EIP-sync send method

bomanaps · 2025-06-16T06:28:50Z

EIPS/eip-sync_send_method.md

+- `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.


Avoid explaining "why" certain decisions were made.
"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." This explanation is behavioral context that's implementation-specific and not a strict part of the “what” — this belongs in a Rationale

Thank you, I have refined the description.

bomanaps · 2025-06-16T06:30:51Z

EIPS/eip-sync_send_method.md

+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.


in a specification. This should use precise language like (all-caps MUST, SHOULD, MAY, etc.) for example "MUST poll every X milliseconds"

Thank you, this has been addressed in 56a439 and a65994

bomanaps · 2025-06-16T06:35:09Z

EIPS/eip-sync_send_method.md

+- **On standard error**. 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.


Suggested change

Upon receiving an `eth_sendRawTransactionSync` request, the handler function performs the follow task.

Upon receiving an `eth_sendRawTransactionSync` request, the handler function performs the following tasks.

bomanaps · 2025-06-16T06:42:11Z

EIPS/eip-sync_send_method.md

+- align blockchain interactions closer to traditional Web2 request-response patterns;
+- maintain backward-compatibility and optionality, preserving existing RPC methods and semantics.
+
+## Specification


In here, we need to have consistent use of RFC 2119 keywords (MUST, SHOULD, etc.). For example, in places where we currently have phrases like "this should be", we need to revise them to use proper normative language, such as:

"The handler function MUST submit the signed transaction to the network."

"The implementation MUST poll for the receipt at an interval not greater than 100 milliseconds until the timeout elapses."

Thank you, this has been addressed in 56a439 and a65994

bomanaps · 2025-06-16T06:48:48Z

EIPS/eip-sync_send_method.md

+}
+```
+
+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:


Suggested change

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:

bomanaps · 2025-06-16T06:52:40Z

EIPS/eip-sync_send_method.md

+
+## 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.


Suggested change

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 receipt is found or a timeout occurs. Polling intervals and timeout values can be tuned by client implementations to optimize performance.

bomanaps · 2025-06-16T06:54:30Z

EIPS/eip-sync_send_method.md

+
+## 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`.


Suggested change

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`.

chore: address comments in ethereum#9890

github-actions · 2025-06-19T01:29:39Z

The commit 3f74e21 (as a parent of 7e408a0) contains errors.
Please inspect the Run Summary for details.

g11tech · 2025-06-23T06:34:20Z

@SmoothBot let us know when you have fixed the issues flagged by the bot and this PR is draft ready

LampardNguyen234 · 2025-06-23T07:56:19Z

@SmoothBot let us know when you have fixed the issues flagged by the bot and this PR is draft ready

Thank you @g11tech, all issues flagged by the bot have been resolved now.

wjmelements · 2025-06-23T23:07:39Z

EIPS/eip-7966.md

+
+- 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.


You mention the timeout is specified but not how it is specified. Should it be a parameter to this function or should it be configured by the node?

Hi @wjmelements, thank you for the comment. We have addressed the timeout issue in 316cf05.

g11tech · 2025-06-24T16:20:05Z

@SmoothBot seems like there are a few things more flagged by other technical reviewers which you might want to accomodate or respond to. let me know when you are done so we can consider it for merging this draft

SmoothBot · 2025-06-25T03:29:24Z

@SmoothBot seems like there are a few things more flagged by other technical reviewers which you might want to accomodate or respond to. let me know when you are done so we can consider it for merging this draft

Thanks, there are a few technical discussions happening still. We will ping you when it's ready 🙏

LampardNguyen234 · 2025-06-26T03:20:43Z

@SmoothBot seems like there are a few things more flagged by other technical reviewers which you might want to accomodate or respond to. let me know when you are done so we can consider it for merging this draft

Thank you @g11tech, these have been addressed.

drafting eth_sendRawTransactionSync eip

80db588

SmoothBot requested a review from eth-bot as a code owner June 11, 2025 05:39

Darkknight-web approved these changes Jun 11, 2025

View reviewed changes

fix: broken author format

54bdc19

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-interface labels Jun 11, 2025

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels Jun 11, 2025

github-actions bot added the w-ci Waiting on CI to pass label Jun 11, 2025

SmoothBot and others added 4 commits June 11, 2025 16:04

Correcting return payloads

2f14e75

chore: update EIP-sync send method

51ca25f

chore: change Reth to reth

036cc7b

Merge pull request #2 from SmoothBot/thanh/sync_send_method

5978a48

chore: update EIP-sync send method

eth-bot changed the title ~~Add EIP: eth_sendRawTransactionSync RPC Method for Lower Latency Transaction Submission~~ Add EIP: eth_sendRawTransactionSync Method Jun 12, 2025

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Jun 12, 2025

bomanaps reviewed Jun 16, 2025

View reviewed changes

SamWilsn added 2 commits June 16, 2025 11:45

Update and rename eip-sync_send_method.md to eip-7966.md

153b695

Rename sync-vs-async.png to sync-vs-async.png

914cca1

github-actions bot removed the w-ci Waiting on CI to pass label Jun 16, 2025

Rename sync-vs-async.png to sync-vs-async.png

e4dc00a

github-actions bot added the w-ci Waiting on CI to pass label Jun 16, 2025

LampardNguyen234 added 6 commits June 17, 2025 11:05

chore: change file names to match EIP number

4258ff1

chore: fix typos

0fe1425

chore: address comments

56a439a

Merge branch 'sync_send_method' into thanh/sync_send_method

43fe02b

chore: change to normative form

a659946

chore: fix typo

c04e491

LampardNguyen234 mentioned this pull request Jun 17, 2025

chore: address comments in #9890 SmoothBot/EIPs#3

Merged

SmoothBot and others added 2 commits June 19, 2025 08:20

Merge pull request #3 from SmoothBot/thanh/sync_send_method

774ae78

chore: address comments in ethereum#9890

chore: fix lint issues

3f74e21

LampardNguyen234 mentioned this pull request Jun 23, 2025

RPC Standards #7 | June 23rd, 2025 ethereum/pm#1585

Closed

LampardNguyen234 added 2 commits June 23, 2025 14:16

chore: fix lint issues

dc7a68c

chore: update discussions-to link

a51cd65

github-actions bot removed the w-ci Waiting on CI to pass label Jun 23, 2025

wjmelements reviewed Jun 23, 2025

View reviewed changes

poojaranjan mentioned this pull request Jun 24, 2025

EIP Editing Office Hour Meeting 63 (EIP Only) | June 24, 2025 ethereum/pm#1592

Closed

29 tasks

chore: update timeout specs

316cf05

MrsStiles840308 approved these changes Jun 26, 2025

View reviewed changes

	Upon receiving an `eth_sendRawTransactionSync` request, the handler function performs the follow task.
	Upon receiving an `eth_sendRawTransactionSync` request, the handler function performs the following tasks.

	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:


		## 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.


		## 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`.

Add EIP: eth_sendRawTransactionSync Method #9890

Are you sure you want to change the base?

Add EIP: eth_sendRawTransactionSync Method #9890

Conversation

SmoothBot commented Jun 11, 2025

EIP: eth_sendRawTransactionSync RPC Method for Lower Latency Transaction Submission

Uh oh!

eth-bot commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

File EIPS/eip-7966.md

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jun 19, 2025

Uh oh!

g11tech commented Jun 23, 2025

Uh oh!

LampardNguyen234 commented Jun 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

g11tech commented Jun 24, 2025

Uh oh!

SmoothBot commented Jun 25, 2025

Uh oh!

LampardNguyen234 commented Jun 26, 2025

Uh oh!

Uh oh!

eth-bot commented Jun 11, 2025 •

edited

Loading

File `EIPS/eip-7966.md`