Etherlink Gets 10x Faster with Instant Confirmations

Etherlink is now 10x faster. Learn how Instant Confirmations deliver sub-50ms transaction receipts and unlock real-time on-chain experiences.

10 minute read

Instant Confirmations

Blockchains have always competed on confirmation speed  -  how quickly users can be confident that a transaction has been accepted and is unlikely to be reverted. Layer 2 networks have made huge progress, bringing transaction confirmations down to under a second.

But even at sub-second latency, blockchain confirmation times still break real-time experiences in DeFi, payments, and gaming. For example, imagine a trading app where a market maker is offering to buy and sell tez at a given price. If the market price of tez changes suddenly, but it takes 500ms+ for their last trade to be confirmed, the market maker does not yet know whether their old price is still active. During that short delay, traders can trade against an outdated price, causing losses. To avoid this, market makers protect themselves by quoting wider spreads on the buy and sell prices. This makes trades more expensive and reduces liquidity for everyone.

When inclusion latency drops, that risk window also reduces drastically, allowing spreads to stay tight and markets to stay efficient.

Now with Instant Confirmations on Etherlink instead of waiting for the next block to be produced, users receive a transaction receipt as soon as the sequencer commits to including their transactions in the next block. This reduces confirmation latency by 10x, from ~500ms to under 50ms. This helps on-chain interactions feel instant and enables truly real-time experiences for both users and developers.

Instant Confirmations on Etherlink allow users to receive assurance that their transactions will be included in the next block — in under 50 milliseconds. Instead of waiting for a block to be produced, Etherlink nodes notify users as soon as the sequencer commits to including the transaction in the next block.

Visualising Instant Confirmations on Etherlink

Once the sequencer commits to including a transaction in the next block (within 50ms), Etherlink nodes execute the transaction and return a full transaction receipt (including gas used, logs, status, and transaction hash). Because the block has not yet been created, the block hash is not available. This is fine for most applications where inclusion confirmation is sufficient, while full block confirmation and finality can follow shortly after.

These transaction receipts can also be streamed (in near-real time), using new WebSocket subscriptions allowing applications to observe and react to Instant Confirmations across the chain as they happen.

decoration

Who are Instant Confirmations Built For? #

We built Instant Confirmations to expand what’s possible on-chain when the latency between execution and confirmation time is removed. They open new possibilities for applications where every millisecond matters.

DeFi Traders and Market Makers #

For market makers, sub-50ms confirmations enable tighter spreads and faster reactions to market movements. Beyond faster trade executions, Instant Confirmations also make it possible to observe transactions executing across the chain in near real time. This allows for increased arbitrage opportunities, quicker response to liquidity shifts and real-time changes to trading strategies — like adjusting off-chain limit orders based on live on-chain price action.

Real-Time Gaming & Application Developers #

Games and interactive applications need immediate feedback to feel responsive. When a player makes a move, trades an item, or completes an action, waiting 500ms+ for confirmation breaks immersion. Sub-50ms Instant Confirmations enable:

Agentic Payment Systems #

Instant Confirmations are a strong use case for agent-to-agent payments in modern payment systems. Sequencer commitments to include a transaction allow agentic and programmable payment flows to react immediately, without waiting for block-level confirmations.

This unlocks payment models like:

Developers and Blockchain Engineers #

Beyond end-users, Instant Confirmations dramatically improve the developer experience. You can now:

Instant Confirmations vs Base Flashblocks vs Other L2s #

Instant Confirmations on Etherlink differ fundamentally from fast confirmation approaches on other L2s. On OP Stack based L2s such as Base or Unichain, Flashblocks introduce pre-confirmation blocks that stream partial block execution every ~200ms based on the outcome of a gas auction (i.e. ordered following a gas auction based on the priority fee proposed by each transaction within the Flashblock). These pre-confirmed receipts give applications early visibility into transactions, but they are optimistic and derived from an in-progress block, meaning transactions can still be reordered within the Flashblock or changed before the final block is produced.

Etherlink’s Instant Confirmations take a different approach. Instead of creating a sub-block every X milliseconds, transactions are set for inclusion as soon as they arrive, on a strict first-come-first-served basis, subject to block capacity. Once included, a transaction is streamed to anyone interested in computing its receipt ahead of the block creation.

Unlike Flashblocks, Instant Confirmations don’t require the sequencer to compute additional metadata partway through creating a block, making them more efficient and allowing the sequencer to focus solely on ordering and inclusion commitment, while execution is handled by Etherlink nodes.

decoration Comparison of Etherlink’s Instant Confirmations vs Confirmation approaches on other L2s

Instant Confirmations provide a sequencer commitment, with transaction receipts available once execution has completed. For strict finality, applications can wait for Etherlink block confirmation (~500ms).

On traditional L2 networks today, developers must wait for block inclusion before receiving a transaction receipt. This introduces latency, forces polling, and complicates application logic for real-time use cases.

Security, Trust and Finality with Instant Confirmations #

While Instant Confirmations drastically reduce latency, they do not change the underlying finality model of Etherlink. As a rollup, finality on Etherlink happens when blocks are published and confirmed on Tezos L1.

In practice, users can treat transactions as irreversible much earlier than full L1 finality. When a transaction is submitted to an RPC node via eth_sendRawTransactionSync (with “pending”), Etherlink returns a transaction receipt (eth_getTransactionReceipt) as soon as the sequencer commits to including the transaction in the next block and the RPC node executes the transaction.

This makes transaction submission synchronous from the application’s perspective. Users wait and are notified immediately when the transaction has been executed. This is the fastest mode of confirmation and is enough for most real-time UX, but it assumes trust in the sequencer’s commitment.

Alternatively, users can wait for the sequencer to produce a block — which takes around 500ms on Etherlink, providing stronger assurance than execution confirmation while still staying sub-second.

If the sequencer is stopped after your transaction has been executed but before the block is finalised, your transaction will not be settled when the sequencer reboots and you will need to resubmit the transaction.

Getting Started With Instant Confirmations #

Instant Confirmations are currently an experimental feature, and we’re actively monitoring performance and reliability as we gather feedback from early adopters

Starting today, January 20th, you can opt in to use Instant Confirmations in your application by calling the eth_sendRawTransactionSync method from an RPC node. This method returns an instant confirmation from the sequencer which includes a transaction receipt that provides information about the completed transaction, such as the status, hash, gas used, and index of the transaction in the next block. The only information missing from the receipt is the hash of the next block, because it has not been created yet.

You can also send the transaction using the eth_sendRawTransactionSync method and pass the pending value like below

curl --request POST \
    --url https://node.shadownet.etherlink.com \
    --header 'accept: application/json' \
    --header 'content-type: application/json' \
    --data '
{
 "id": 1,
 "jsonrpc": "2.0",
 "params": [
   "0x88a747dbc7f84e8416dc4be31ddef0",
   "pending"
 ],
 "method": "eth_sendRawTransactionSync"
}

If you pass latest instead of pending, the sequencer waits until the transaction is in a block to send the confirmation.

Once the sequencer queues the transaction and commits to including the transaction in the next block, Etherlink nodes execute the transaction and return a full receipt for the transaction that includes information such as its gas price and gas cost. This receipt matches the specification for eth_getTransactionReceipt except that the blockHash field is always 0x000… because the block has not been created yet. You can take this response as a confirmation that the sequencer will put the transaction in the next block.

Read the Etherlink Instant Confirmation docs for more on using Instant Confirmations within your application.

Subscribing to Instant Confirmations #

You can also subscribe to WebSockets to receive Instant Confirmations, which are notices that a transaction will appear in the next block. Etherlink nodes provide two custom WebSocket events that you can subscribe to for notice of upcoming transactions: tez_newIncludedTransactions & tez_newPreconfirmedReceipts.

Read more detail on these new methods in the developer documentation.

Network Latency and Sequencer Co-location #

While the introduction of Instant Confirmations reduces the protocol-level latency on Etherlink, total end-to-end latency still depends on network distance to the sequencer. With the Etherlink sequencer now operating from Tokyo, co-locating application infrastructure closer to the sequencer can further reduce round-trip latency.

Latency-sensitive applications like trading bots, market makers, games or agentic payment systems, can benefit from this, achieving a lower end-to-end latency overall.

In practice, applications running in the same region as the sequencer can achieve near execution-time responsiveness, while applications running in infrastructure further away may experience additional network latency despite instant execution.

Wrapping Up #

Instant Confirmations mark a major shift in what’s possible on-chain. By cutting confirmation latency from ~500ms to under 50ms, Etherlink allows an entirely new category of applications to be built that were previously not feasible.

Whether you’re building high-frequency trading systems, real-time games, or next-generation payment infrastructure, we’re excited to see what you build with sub-50ms confirmations.

To see Instant Confirmations in action, Watch a Live Demo.

Learn more about Instant Confirmations.