This writeup introduces synchronous composability via ULTRA TX by Gwyneth, explaining how they work together to make L1 and L2 blocks programmable and composable.

Written by Arixon and reviewed by Brecht.

• One fat L1 transaction (“ULTRA TX”) sits at the top of each L1 block (mostly, not enforced yet). Read more about ULTRA TX here.

• Inside it, a master builder bundles: L1 account‑abstracted txs, multiple L2 blocks, proofs/witnesses, and the outputs of any cross‑chain calls.

• Gwyneth is the execution stack that makes this possible: a modified REVM + block builder based on Reth + proposer + execution extension (ExEx) that can simulate L1 and L2 together and later replay the same effects onchain.

• Result: synchronous composability between L1 and many L2s with atomicity and single‑proof verification, without changing L1 rules.

Cross‑chain UX today is split across async messages and “hope it lands” flows:

• You can’t easily enforce invariants across transactions.

• L1→L2 calls that need a return value are clunky.

• L2s want to settle together (share blobs, aggregate proofs) every L1 block if possible.

Goal: Make a block feel like a programmable container where L1 and L2 work can run, talk to each other, and then be committed atomically.

• Custom REVM (“Gwyneth REVM”) — runs transactions across many chains in one process; records a detailed journal (reads/writes, call trees, modes).

• ULTRA Block Builder — picks/executes txs across L1+L2, enforces size/fee limits, collects witnesses, and prepares the ULTRA payload.

• Stateless Validator — turns execution traces into compact proofs/witness data so verifiers can re‑execute without full state.

• Block Proposer — packages everything into an EIP‑4844 blob and submits the ULTRA transaction to L1.

• Custom Execution Extension (ExEx) — watches L1, decodes ULTRA payloads, rebuilds L2 blocks via Engine API, updates forkchoice, and handles reorgs.

• SimpleMultiChainDB & Global Nodes Map — lightweight layer that gives the REVM read/write access to state across many chains within the same process.

1. Gather inputs. Pending L1 AA txs and many L2 txs sit in a shared pool. (Note: Non AA txs can still be executed after ULTRA TX in the L1 block)

2. Execute locally. The builder runs them through the Gwyneth REVM with a multi‑chain DB.

   • When a contract wants to “call another chain”, it tags the next call using a tiny precompile. REVM then either:

     • Simulates that cross‑chain segment (for build/prove), or

     • Marks it as L1‑Direct work that must actually run on L1 during proposal.

3. Record everything. The REVM keeps a journal: storage diffs, balances, code reads, and a full call tree (including cross‑chain hops). These become your witness.

4. Package. The builder stops once gas/blob/byte caps are met and constructs the ULTRA payload:

   • Per‑L2 transactions/state roots

   • L1 AA tx batch (if any)

   • Extension outputs (return data for off‑L1 functionality) to be provided to a simple onchain ExtensionOracle

   • Proof inputs / sidecars for stateless verification

1. Top of block. Ideally the ULTRA TX is placed first, so the latest L1 state is known to everything inside it. Although this is the preferred functionality, non top of block inclusion is also supported.

2. Replay & verify. The contract:

   • Checks the recorded pre-state (block hash, beacon root, timestamp, prevrandao, parent ULTRA hash) and blob commitments,

   • Verifies proofs (or performs the configured checks) up front,

   • Replays the recorded L1 work in order—prestate assertions, ExtensionOracle.setTap, smart-account calls, and applyStateDelta writes—reverting the whole ULTRA TX on any mismatch.

1. ExEx picks it up. ExEx watches L1, decodes the ULTRA payload, and for each L2:

   • Rebuilds the L2 block via Engine API using the included data/witnesses,

   • Advances the L2 head and pins finality to the finalized L1 block window,

   • Updates a global map from “which L1 block → which L2 heads”.

Result: every L2 gets a canonical block that is causally tied to that specific L1 block.

Scenario: Alice on L2‑A swaps token X for Y on L2‑B, but only if a small L1 rebalance also succeeds.

1. Alice submits one tx to L2‑A.

2. In execution, her contract calls xcalloptions(to=L2‑B) then DEX_B.swap(...).

3. On L2‑B the swap succeeds and returns amountOut.

4. Back on L2‑A, logic says: if amountOut ≥ threshold, perform an L1 direct top‑up (e.g., move ETH in a treasury). It marks that step L1‑Direct.

5. The builder records: (a) L2‑A & L2‑B state diffs, (b) the expected return data for the L1‑Direct call, and ( c) orders the L1 AA call.

6. The ULTRA TX is proposed. Onchain, Gwyneth verifies the pre-state and proof first, primes the ExtensionOracle with the recorded return data, then replays the L1 AA call and diffs exactly as recorded—any mismatch reverts everything.

7. ExEx rebuilds both L2 blocks and finalizes them relative to that L1 block. Alice sees her swap and the L1 top‑up as a single atomic outcome.

Below is a concrete, example that moves an ERC‑20 balance from L2‑A to L2‑B. Users call this on L2‑A; Gwyneth routes the mint on L2‑B during build and enforces it during replay.

// On L2-A, user/script calls:
function moveTokensL2AToL2B(
    XERC20 token,      // deployed on both L2-A and L2-B (same code)
    uint256 chainIdL2B,    // destination chain ID
    address recipientL2B,  // recipient on L2-B
    uint256 amount
) external {
    // Debits sender on L2-A and requests a mint on L2-B.
    // Under the hood, token.on(chainIdL2B)._mint(...) is invoked cross-chain.
    token.xTransfer(chainIdL2B, recipientL2B, amount);
}

• During build, Gwyneth REVM interprets token.on(chainIdL2B) as a cross‑chain frame and simulates _mint(to, amount) on L2‑B. It journals the L2‑A debit and the L2‑B mint diff.

• The builder adds both diffs to the ULTRA payload and records witnesses.

• On replay, the ULTRA contract enforces that the L2‑A debit and the L2‑B mint match the recorded witnesses; if anything differs, the whole ULTRA TX reverts (atomicity).

• One container, one proof: The whole bundle shares inputs, so you can prove/verify once. If any piece disagrees with the recorded witnesses/outputs, everything reverts.

• Top‑of‑block placement: Ensures the builder’s view of “latest L1 state” matches what the block will actually use.

• Reorg handling: If L1 reorgs, ExEx rewinds each L2 to the heads that were tied to the now‑canonical L1 block at that height.

• Stateless replay: Witnesses let independent verifiers reconstruct the execution without full state, making fraud/imprecision detectable.

• No L1 hard fork required. ULTRA TX is “just” a big AA transaction with rules enforced by contracts + proofs.

• Builder sophistication increases. To be competitive you need fast execution, witness generation, and (eventually) fast proving.

• Real‑time proving. Full L1↔L2 synchronicity with proofs under 12s is still an active engineering goal; interim designs can use TEEs/AVSs or limit what’s proven per block.

Note: Proving is still under development, SGX and TDX coming soon.

These diagrams showcase multiple different scenarios for synchronus operations across chains, it should help you see how different origin/destination txs travel through the ULTRA TX pipeline.

Key takeaways: L1 account-abstraction frames can synchronously lock WETH on L1 while crediting L2-B. The ExtensionOracle feeds the recorded credit receipt so replayed AA logic observes the same xTransfer outcome the builder saw.

Key takeaways: L2-origin WETH withdrawals hit the actual L1 vault inside the same ULTRA container. The builder records the release diff, and replay enforces that the live vault movement matches the simulated xTransfer exactly.

Key takeaways: Cross-L2 WETH transfers reuse the same builder journal. With no L1Direct frame, the ExtensionOracle stays idle while both L2 ledgers atomically debit/credit once the ULTRA transaction finalizes on L1.

Q: Why must ULTRA be first in the block? A: So all transactions inside can reason about the latest L1 state without awkward workarounds. (If you drop strict synchronicity with L1 you can loosen this.)

Q: Can I still include ordinary L1 transactions? A: Yes—inside the ULTRA container as AA txs, in any order the builder chooses.

Q: How do L1→L2 calls with return values work? A: The builder simulates them, records outputs, and the ExtensionOracle returns those outputs during onchain replay.

Q: What happens on an L1 reorg? A: ExEx rewinds each L2 to the head associated with the new canonical L1 block at the same height.

• ULTRA TX — a single powerful L1 transaction that carries many txs/blocks/proofs.

• Account abstraction (AA) — L1 transactions from smart accounts, enabling flexible packaging and ordering.

• ExtensionOracle — simple contract that returns pre‑recorded outputs for calls not natively available on L1 during replay.

• ExEx — execution extension that reconstructs L2 blocks from an ULTRA payload.

• Journal — the detailed execution trace REVM writes (reads/writes/calls) used for

Explore open positions on our job board.

Get the latest from Taiko:

• Website: https://taiko.xyz.

• Discord: https://discord.gg/taikoxyz.

• GitHub: https://github.com/taikoxyz.

• Twitter: https://twitter.com/taikoxyz &

• Community forum: https://community.taiko.xyz.

• YouTube: https://www.youtube.com/@taikoxyz.

• Warpcast: https://warpcast.com/taikoxyz.

Contribute to Taiko on GitHub and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing manual.