# ULTRA TX & Gwyneth — Synchronous composability across L1 & L2 By [Taiko Labs](https://paragraph.com/@taiko-labs), 2025-11-11 --- _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_](https://x.com/arixoneth/) and reviewed by [Brecht](https://x.com/Brechtpd). 0) TL;DR (mental model) ----------------------- * **One fat L1 transaction (“ULTRA TX”)** sits at the top of each L1 block (mostly, not enforced yet). Read more about ULTRA TX [here](https://ethresear.ch/t/ultra-tx-programmable-blocks-one-transaction-is-all-you-need-for-a-unified-and-extendable-ethereum/21673). * 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)](https://reth.rs/exex/overview/) 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. 1) Why this exists (the problem) -------------------------------- 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. 2) The moving parts (roles) --------------------------- * **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. 3) The core idea (how it works, step by step) --------------------------------------------- ### 3.1 Build time (offchain) 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 5. **Propose.** The proposer sends an EIP‑4844 transaction carrying the ULTRA payload to the L1 rollup contract. ### 3.2 Inclusion time (onchain) 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. ### 3.3 Distribution time (to L2s) 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. 4) A concrete example --------------------- **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. 5) Developer surface (L2‑A → L2‑B ERC‑20 xTransfer) --------------------------------------------------- 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); } #### What Gwyneth/ULTRA does with this call * 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). 6) What makes it safe (atomicity & validation) ---------------------------------------------- * **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. 7) What it doesn’t change ------------------------- * **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._ 8) Example flows (for the visual learners like myself) ------------------------------------------------------ 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. ### 8.1 L1 → L2 WETH xTransfer ![L1 to L2](https://storage.googleapis.com/papyrus_images/82a3d1866ad4fce97230a7396b372c53379dbad03ccac8b25397364c7fb26f2c.png) L1 to L2 _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. ### 8.2 L2 → L1 WETH xTransfer ![L2 to L1 ](https://storage.googleapis.com/papyrus_images/544c0ae3482976db483c92d208ca62caf909d518992f36c999af3e63f6beb1f5.png) L2 to L1 _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. ### 8.3 L2 → L2 WETH xTransfer ![L2 to L2](https://storage.googleapis.com/papyrus_images/4feaa807d2b8d60354fc22f6c16e05620f6ca665c67142bb86ce9f854c41d4ca.png) L2 to L2 _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. 9) Frequently asked ------------------- **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. 10) Quick glossary ------------------ * **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 **Join us 💗** -------------- Explore open positions on our [job board](https://taiko.xyz/careers). **Follow us 🥁** ---------------- Get the latest from Taiko: * Website: [https://taiko.xyz](https://taiko.xyz/). * Discord: [https://discord.gg/taikoxyz](https://discord.gg/taikoxyz). * GitHub: [https://github.com/taikoxyz](https://github.com/taikoxyz). * Twitter: [https://twitter.com/taikoxyz](https://twitter.com/taikoxyz) & * Community forum: [https://community.taiko.xyz](https://community.taiko.xyz/). * YouTube: [https://www.youtube.com/@taikoxyz](https://www.youtube.com/@taikoxyz). * Warpcast: [https://warpcast.com/taikoxyz](https://warpcast.com/taikoxyz). **Contribute 🤓** ----------------- 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](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md). --- *Originally published on [Taiko Labs](https://paragraph.com/@taiko-labs/ultra-tx-gwyneth-synchronous-composability-across-l1-l2)*