Synchronous Finality

Users don’t care about rollups. They care about whether their transaction worked.

On most L2s, “worked” is complicated. Your transaction might be included but not finalized. Confirmed on L2 but not settled on L1. Sequencer says yes, but the chain might reorg. You’re left checking explorers, waiting for confirmations, wondering if your assets actually moved.

Signet eliminates this ambiguity. Transactions either complete on both chains in the same block—or they don’t happen at all. No soft confirmations. No “probably final.” Just done.

The Confirmation Gap

Most rollups use “run-ahead” sequencers. The sequencer operates independently of Ethereum, producing blocks on its own schedule. This creates a gap:

• L2 block at T=0
• L1 inclusion at T=minutes (or hours)
• Final settlement at T=days (optimistic) or T=minutes (zk)

During that gap, things can go wrong. Reorgs. Failed proofs. State divergence. Users see “confirmed” but the transaction isn’t settled. “Confirmed on L2” and “settled on L1” are different states, and most apps don’t handle the distinction well. The gap creates UX friction and edge-case bugs that are hard to reason about.

One Clock

Signet takes a different approach. Every Signet block corresponds to exactly one Ethereum block, with identical timestamps:

Ethereum Block 19000000 (timestamp: 1704067200)
         ↓
Signet Block 19000000   (timestamp: 1704067200)

Signet and Ethereum share the same clock — no timing mismatch. Signet reorganizes if and only if Ethereum does. Cross-chain operations complete in one 12-second window.

When your transaction is included in a Signet block, it’s included in the corresponding Ethereum block. One confirmation, not two timelines to track. This means Signet can’t confirm faster than Ethereum’s 12-second cadence — run-ahead sequencers offer faster but weaker confirmations. Signet follows Ethereum’s fork-choice rule perfectly — see (Re)Based Rollups for the technical foundation.

All-or-Nothing Execution

Cross-chain transactions on Signet are conditional. They only execute if all required actions complete successfully—on both chains, in the same block.

Traditional cross-chain flow:

1. Lock assets on Chain A
2. Wait for confirmation
3. Mint/release on Chain B
4. Hope nothing fails in between

Signet’s flow:

1. Submit conditional transaction
2. Either: both sides execute atomically, OR nothing happens

There’s no intermediate state. No assets locked waiting for the other side. No “hand-off problem” where transactions get included but manipulated to fail.

How It Works

Signet’s EVM enforces a key invariant: if a transaction emits an Order event, it’s applied to state if and only if all outputs have corresponding Filled events.

L1 → Signet (via Passage/Transactor):

• Deposit on Ethereum → mint on Signet in the same block
• Call Transactor on Ethereum → execute on Signet in the same block

Signet → L1 (via Orders):

• Create Order on Signet specifying required L1 output
• Filler provides L1 output in the same block
• Both sides execute atomically, or neither does

The protocol enforces atomicity. Apps don’t need to handle partial states.

What Simplifies

Synchronous finality collapses the complexity that developers normally deal with. No separate L1/L2 confirmation states to track — one transaction, one result. No cleanup logic for partial executions — transactions succeed completely or fail completely. Testing becomes predictable: if it works in one block, it works.

We’ve integrated Permit2 to further reduce friction:

pub struct Permit2Batch {
    pub permit: PermitBatchTransferFrom,
    pub owner: Address,
    pub signature: Bytes,
}

Single-signature authorization for cross-chain operations. No separate approval transactions.

What This Enables

Synchronous finality enables applications that can’t exist with async settlement:

• Cross-chain flash loans: Borrow on Signet, use on Ethereum, repay atomically
• Atomic arbitrage: Execute on both chains in the same block
• Real-time oracle updates: React to L1 state changes instantly
• Payment gating: Require L1 payment before L2 execution

See Solidity Examples for implementation patterns.

Get Started

• Cross-chain transfers: How assets move between chains
• Orders documentation: Conditional transaction patterns
• Signet SDK: EVM extensions and tooling

Questions? Get in touch.