[Explainer] Async L1 Execution (for crosschain exec) aka TimeCapsules

TL;DR

Blockchains today operate with the following assumption: atomicity = single-slot. Every transaction either fully succeeds or fully fails within a block.

• You can’t do cross-slot flash loans.
• You can’t compose multi-step DeFi workflows that wait for future conditions.
• You can’t execute rollback-safe workflows over time without full reorgs.

To accomplish these order-of-magnitude composability gains, Smart Transactions introduces TimeCapsules or TimeCaps. TimeCapsules are a new blockchain primitive developed by STXN that enable asynchronous, multi-slot atomic transactions with rollback capabilities, all on Layer 1 or crosschain. TimeCapsules allow a sequence of actions (with logic, inter-action dependencies, and external conditions) to execute across slots, react to information (e.g., oracle prices) as late as latency/liveness demands, and be fully revertable if something goes wrong. This enables new usecases such as around reversible transactions, multi-slot flash loans, and virtual L2s on L1.

TimeCapsules redefine atomicity from being slot-bound to condition-bound (like time, state, oracles, or external triggers).

The core innovation is decoupling atomicity from block production. Instead, atomicity becomes a function of whether a declared halting condition has been met. This can be:

• a duration in slots (e.g., 10 slots)
• an external oracle trigger (e.g., ETH > $2500)
• a logical condition (e.g., all sub-transactions succeed)

Until then, state changes inside the TimeCapsule are provisional while being on L1 or crosschain, sandboxed from the rest of the chain — and will either finalize or fully reset depending on the final evaluation.

What is a TimeCapsule?

A TimeCapsule is a logical wrapper around a group of interrelated transactions or “intents”, executed asynchronously across multiple slots, with the ability to:

• Delay execution of some steps until future data is available (lazy evaluation)
• Reference future events or values in current transactions (like “future oracle price”)
• Revert all changes inside the capsule if any part fails — even retroactively

A TimeCapsule is the new atomic window, replacing the block as the unit of atomicity. Each TimeCapsule can be thought of as a Virtual Block.

Once a TimeCapsule is opened, the included transactions form a DAG of intents (directed acyclic graph), with explicit references between them (e.g., tx A depends on tx B’s output). These are tracked in a markup format called HIML (Hyper Intent Markup Language) which forces users/dApps to declare what outcome they want, not how to compute it.

For a deeper dive, check out:

Async L1 State Transitions (research update)

Under the hood, TimeCapsules are powered by solvers, dependency DAGs, MEV-time search, and two rollback mechanisms to be chosen based on the context (though mostly the latter one): revert-style (SAVI, Semi-Atomic Virtual Invalidation) or state-reset-style (Smart Atomicity).

How TimeCaps work?

At its heart, a TimeCapsule is a multi-slot atomic execution window. You define a set of smart contract actions (called CallObjects) that are to be executed only when certain future conditions are met — like a price threshold being crossed, or a time limit being reached. During its "open" period, the TimeCapsule records all execution attempts, tracks side-effects, and evaluates whether the final conditions for success were satisfied. If not, all intermediate states are rolled back.

This is not a Layer 2 rollup. All execution happens on L1. However, TimeCapsules offer L2-like features like sequenced async logic, virtual sandboxing, and MEV protection — all without moving user funds off-chain.

Key Design Features

1. Closing Condition: TimeCapsules must define a strict and enforceable halting condition. If this isn’t met, the capsule rolls back.
2. DAG of Intents: All CallObjects are mapped into a Directed Acyclic Graph (DAG) that encodes their dependencies (e.g., call B needs output from call A). This DAG defines the order and scope of execution.
3. Lazy Evaluation: Calls that depend on future outputs are deferred until those outputs become available — enabling logic like “execute only if ETH > $3000 three blocks from now.”
4. Rollback Semantics: On failure or unmet condition, TimeCapsules revert all side-effects — either through full-on reverts (SAVI, Semi-Atomic Virtual Invalidation) or state resets (Smart Atomicity).
5. Side-Effect Containment: All state changes remain “transitional” until the TimeCapsule closes successfully, making these transactions safe to include mid-stream without corrupting global state.

Tx Execution Acros Multiple Slots

Intent-Based Design

Each user/dApp submits intents (encoded as CallObjects): desired end states (e.g., “I want to swap ETH for USDC only if price is above X, then bridge the result to Cosmos”).

These intents are:

• Declarative (specify goals, not steps)
• Composable (can depend on each other)
• Deferred (execute only when ready/needed)

Solvers analyze these intents, discover dependency relationships, and MEV-mine them to construct viable execution paths.

Execution Flow w/ DAGs

Each TimeCapsule carries a DAG of CallObjects, each representing a step in the transaction plan (or execution strategy). Some nodes may depend on outputs of others — including from future blocks. Solvers execute these calls lazily, only when all dependencies are resolved.

Delayed Execution w/ Intermediate States

Calls can be executed immediately, scheduled, or deferred. State outputs (like token balances) from one step are stored and carried over to future steps. For example:

Step 1: Swap 1 ETH → 10,000 USDC  (only if ETH/USDC ≥ 10,000)
Step 2: Send USDC to Cosmos       (only if Cosmos bridge is open)
Step 3: Burn receipt              (only if Cosmos confirms)

This structure mirrors Rust Futures in async programming: execution only proceeds when poll() indicates readiness.

Atomic Rollback in a Multi-Slot World

Side-Effect Containment

TimeCapsule state transitions are sandboxed. No external contract can safely rely on the provisional state inside a capsule unless it explicitly opts in (i.e., makes itself part of the capsule DAG). This avoids cascading failures.

Conditional Execution

The capsule enforces strict deferred execution — if an intent references a future one (e.g., “swap only if price check passes later”), it won’t run until the future condition is known and evaluated.

This protects against premature execution and enforces the causal flow of time — even if the reference goes “backward” in slot order.

Reversibility is core to TimeCapsules. If at any point during the capsule’s lifetime (say, at slot 6 of 10), a condition fails (e.g., a hack is detected, or an invariant breaks), the entire DAG is rolled back. Two rollback strategies exist:

Strategy 1: Rollback by REVERT

Revert-based (SAVI): Like classic EVM reverts, but across blocks. Transactions revert if out-of-order or invalidated.

• Each intent checks its preconditions at execution time
• If any fails, everything is reverted
• Think “Flash Loan-style atomicity”, extended across slots

Strategy 2: Rollback by RESET

Reset-based (Smart Atomicity): Snapshot account states before TimeCapsule starts, and reset them if final conditions fail. Inspired by git reset, not git revert.

• At TimeCapsule start, take snapshots of all touched accounts
• If condition fails, revert all accounts to pre-capsule state
• Think “Git reset” and not “Git revert” since for the former no compensation txs needed

Solver Ecosystem

In traditional Ethereum, the execution of a transaction is deterministic: it’s submitted, ordered by the mempool, and picked up by a block producer. There’s no real notion of searching for the right time to execute. In STXN’s TimeCapsule model, that responsibility shifts to solvers — specialized actors who: Monitor the network for pending TimeCapsules, Search for the optimal time (slot) and sequence to execute them, Execute the TimeCapsule logic once all dependencies and conditions are satisfied.

Thus, TimeCapsules depend on a decentralized solver network to pick up deferred transactions and execute them optimally.

• Solvers receive tips for successful execution.
• Slashing applies if solvers commit but fail to finish (ensures liveness).
• Risk-reward models account for volatility (e.g., “I converted 1 ETH for 10,000 USDC, but ETH spiked before rollback — who pays?”).

This forms a crypto-economic engine where rational actors are incentivized to only execute when success is likely — avoiding griefing or partial failures.

As an analogy, we can think of Solvers as Time Oraclers combined with Offchain Executors. In the same way that block producers are miners of “space” (block inclusion), solvers are miners of “time”. They mine not by hashpower, but by simulation, analysis, and economic optimization. This is MEV Mining.

Use Cases and Applications

Here’s what TimeCapsules enable:

• Multi-Slot Flash Loans Atomic loans spanning multiple slots — borrow, operate, and repay asynchronously.
• Conditional DeFi Trades Execute trades only if time-based or oracle-driven conditions are met (e.g. TWAP, price bounds).
• Reversible Transactions Roll back actions automatically if conditions fail or when an adress marked as bad interacts with it provided it is still within the timecap window — no reorgs or L2s required.
• Asynchronous Order Matching Match and settle user intents arriving in different slots — securely and conditionally.
• Cross-Chain Token Flows Bridge assets across L1s with slot-spanning logic that validates finality before settling.
• Composable Async dApps Build DeFi workflows and multi-step protocols that span time, slots, and chains — with atomic guarantees.
• Optimistic Trustless Offchain Compute For txs that need high throughput (such as for gaming), use offchain compute but verify onchain by embedding the tx inside a timecap that is open for long enough that enough nodes have verified, and till that moment, the tx remains reversible.
• Crosschain txs Open timecaps on two chains, such as for Ethereum and Solana, provided their closing condition is that the other is in a valid state, making the txs across chains depend on each other for valid state transition.