Transaction confirmation shouldn't require complex polling loops. By supporting synchronous transaction submission (EIP-7966), Openfort allows developers to get immediate feedback on transaction status without the traditional wait.
See how wallet automations let you sign and execute transactions on behalf of users.
What is Synchronous SendTransaction (EIP-7966)?
Synchronous SendTransaction (EIP-7966) is a specialized protocol enhancement that introduces the eth_sendRawTransactionSync method. Traditionally, developers had to submit a transaction and then repeatedly poll the network until a receipt was generated. With EIP-7966, the initial RPC call itself waits for a result and returns either a full transaction receipt, a typed timeout (if the transaction is still pending), or a definitive error. This significantly reduces perceived latency—often by up to 50%—and eliminates the need for "glue code" like custom polling logic or background workers, providing a faster and more predictable experience for users and AI agents. The impact is most visible in trading and other DeFi flows, where confirmation latency is the product.
What 7966 is (and why it helps Openfort users)
Traditionally, apps submit a tx with eth_sendRawTransaction, then poll eth_getTransactionReceipt until confirmation. EIP-7966 introduces eth_sendRawTransactionSync—a single RPC that submits the signed tx and waits briefly (node-configured; the EIP recommends a small default, e.g. ~2s) to return the receipt, a timeout (meaning “not included yet”), or a clear error. This collapses round-trips and reduces submission-to-confirmation latency on low-latency chains.
Key point: 7966 is an Interface EIP in Draft and optional. Support varies by provider/chain; that’s why Openfort negotiates it per connection and falls back seamlessly.
How Openfort implements it
-
Auto-detect + route: If the connected RPC exposes
eth_sendRawTransactionSync, Openfort uses it; otherwise we use our hardened send-and-receipt path. No code changes needed in your app. -
Three explicit outcomes your UI can trust:
confirmed→ standard receipt object (same shape aseth_getTransactionReceipt)pending_timeout→ clearly “not yet included,” not a failureerror→ meaningful error (e.g., nonce/underpriced/revert)
-
Safer UX defaults: Treat
pending_timeoutas pending (no double-submit). Openfort will continue background tracking as usual if you choose.
What you should expect (performance & claims)
- Latency/throughput: The EIP’s goal is to reduce end-to-end latency by ~50% on suitable networks by removing the extra RPC round-trip. Real-world gains depend on the chain, sequencer, and your RPC’s implementation.
- Timeouts: The spec recommends a small node-configured default (≈2s); providers may choose different windows (some expose longer caps). Openfort forwards these semantics while letting you keep your own UI timers.
Why this matters for wallet UX, not just infra
- Instant, trustworthy feedback: Users see “confirmed” faster, “pending” when appropriate, and useful errors instead of ambiguity.
- Fewer “did it go through?” tickets: Cleaner states cut support load.
- Less glue code: Remove custom polling/retry utilities and race-condition bandaids—one code path across chains.
FAQs
Is 7966 replacing normal sends? No. It’s additive and optional. Nodes without it return “method not found,” and Openfort falls back to the standard flow automatically.
What timeout should I show users? Treat node timeouts as “still pending”, not a failure. Keep your UX timer small (e.g., spinner + “pending” badge) and let Openfort follow up in the background if you choose.
Which chains/providers support it?
Support is expanding. Some providers already expose eth_sendRawTransactionSync (often branded as “synchronous send”) on major L2s; Openfort will use it automatically when your endpoint has it.
