The cross-chain atomicity problem is the inability to guarantee that a set of transactions spanning multiple blockchains either all succeed or all fail together. When a multi-chain operation partially executes, funds become stranded, arbitrage opportunities are lost, and protocol state becomes inconsistent across chains. Tesseract solves this with a three-phase coordination protocol (Buffer, Resolve, Execute) that enforces all-or-nothing execution across Ethereum L2s without relying on a trusted third party.
TL;DR
- The problem: Cross-chain transactions have no atomicity guarantee. If one leg of a multi-chain swap fails, you end up with funds stuck in an unintended state across chains. Bridges move tokens; they do not coordinate transactions.
- The cost: Partial execution losses in cross-chain DeFi are estimated to affect every protocol operating on multiple rollups, from failed arbitrage to broken governance to unbalanced liquidity pools.
- The solution: Tesseract is a cross-rollup atomic swap protocol built on our research paper “Towards Universal Atomic Composability” (recognized by a16z Crypto Startup School). It uses 7 Vyper smart contracts, a Rust relayer, and a Python SDK to enforce atomic execution across Ethereum, Polygon, Arbitrum, Optimism, and Base.
- The mechanism: A three-phase protocol (Buffer, Resolve, Execute) with MEV protection via commit-reveal, flash loan resistance, and configurable coordination windows (5-300 seconds).
- The tradeoff: Stronger guarantees come with coordination overhead. Tesseract adds latency (default 30-second coordination window) in exchange for eliminating partial execution risk entirely.
The Atomicity Problem, Explained From First Principles
On a single blockchain, atomicity is a given. When you call a smart contract that interacts with three DeFi protocols in one transaction, the EVM guarantees that either every state change persists or none of them do. If the third call reverts, the first two are rolled back. This is not a feature you configure. It is a property of the execution environment.
The moment your operation spans two or more chains, that guarantee disappears completely.
Consider what “atomic” actually means in database theory: a transaction is atomic if it is indivisible. There is no state in which half of the transaction has been applied. The transaction is either fully committed or fully aborted. The EVM provides this within a single execution context. No existing bridge, messaging protocol, or cross-chain framework provides this across execution contexts.
This is the cross-chain atomicity problem: there is no mechanism in the current multi-chain stack to enforce all-or-nothing execution across independent blockchains.
Why This Is Fundamentally Hard
The difficulty is not engineering sloppiness. It stems from a foundational property of distributed systems. Each L2 rollup has its own sequencer, its own state, and its own finality timeline. There is no shared transaction processor that can wrap operations across Arbitrum, Optimism, and Base into a single atomic unit.
Bridges solve the asset transfer problem. They let you move tokens from chain A to chain B. But moving tokens is not the same as coordinating transactions. When a bridge transfers USDC from Arbitrum to Optimism, it executes two independent transactions: a lock (or burn) on the source chain and a mint (or release) on the destination chain. If the source transaction succeeds and the destination transaction fails, the bridge protocol’s own recovery mechanism must handle the inconsistency. The user’s higher-level intent — the multi-step operation that required the bridge transfer — has no such safety net.
Messaging protocols like LayerZero and Wormhole improve on raw bridges by enabling arbitrary cross-chain messages. But a message is not a transaction coordinator. Sending a message from chain A to chain B tells chain B to do something. It does not guarantee that the action on chain B will succeed, and it provides no mechanism to revert the action on chain A if chain B fails.
What Actually Happens When Cross-Chain Transactions Fail
The atomicity problem is not abstract. Here are three concrete scenarios that occur in production multi-chain DeFi systems today.
Scenario 1: Cross-Chain Arbitrage Gone Wrong
You detect a price discrepancy: ETH is trading at $3,200 on an Arbitrum DEX and $3,250 on an Optimism DEX. The arbitrage play is simple: buy on Arbitrum, sell on Optimism, pocket the $50 spread minus gas.
You submit the buy transaction on Arbitrum. It confirms. You submit the sell transaction on Optimism. But in the 15 seconds between your two transactions, another arbitrageur closed the gap. The Optimism price has moved to $3,201. Your sell either executes at a loss or reverts due to slippage protection.
Result: You now hold ETH on Arbitrum that you bought specifically to sell on Optimism. The arbitrage opportunity is gone. You are exposed to ETH price movement on a position you never intended to hold. Your options are to sell at a loss on Arbitrum, bridge to Optimism and hope the price recovers, or hold and wait. All three cost you money. None of them would have happened if both legs executed atomically — either the full arb succeeds or neither leg fires.
Scenario 2: Liquidity Rebalancing Failure
Your protocol runs lending pools on Arbitrum, Optimism, and Base. The Arbitrum pool is over-utilized at 95% utilization, pushing borrowing rates to 12%. The Base pool is under-utilized at 40%, with borrowing rates at 3%. You need to move $5M in liquidity from Base to Arbitrum to rebalance.
The operation requires three steps: withdraw liquidity from the Base pool, bridge the assets, and deposit into the Arbitrum pool. You execute step 1 successfully — $5M is withdrawn from Base. The bridge transfer initiates but encounters congestion. Meanwhile, the Arbitrum pool utilization hits 98% and a large borrower liquidates, changing the pool state. When your bridged funds arrive and you attempt to deposit, the transaction parameters no longer match the pool state, and the deposit reverts with unexpected conditions.
Result: $5M in liquidity is sitting in your wallet on Arbitrum, earning nothing. The Base pool is now also under-capitalized because you withdrew from it. Both pools are in a worse state than before you started. Users on both chains experience degraded service. You have to manually rebalance again, paying gas twice, and the utilization rates may have shifted again by the time you retry.
Scenario 3: Multi-Chain Governance Catastrophe
Your DAO governs a protocol deployed on four chains. A governance proposal passes to update a critical parameter — say, the collateral ratio — across all deployments simultaneously. The update must be applied uniformly; if one chain has a different collateral ratio than the others, arbitrageurs will exploit the discrepancy.
The governance executor submits four transactions, one to each chain. Three succeed. The fourth — on Optimism — fails because the Optimism sequencer was temporarily down for a software upgrade.
Result: Three of your four deployments now have the new collateral ratio. Optimism still has the old one. Arbitrageurs immediately notice the discrepancy and begin exploiting the difference in collateral requirements between chains. By the time your team notices, resubmits the Optimism transaction, and it confirms, damage has been done. Users have been liquidated on some chains but not others for identical positions. Trust in the protocol’s governance is damaged.
Why Existing Cross-Chain Solutions Do Not Provide Atomicity
Every major cross-chain protocol today solves some subset of the interoperability problem. None of them solve the atomicity problem.
Comparison: Tesseract vs. Existing Cross-Chain Protocols
| Feature | Tesseract | LayerZero | Wormhole | Axelar | Chainlink CCIP |
|---|---|---|---|---|---|
| Approach | Coordination protocol with on-chain buffers | Generic messaging with configurable verification | Guardian-based message passing | Proof-of-stake validator network | Oracle-based cross-chain messaging |
| Atomicity guarantee | Full all-or-nothing across all chains | No native atomicity; application must handle failures | No native atomicity; relies on delivery guarantees | No native atomicity; message delivery only | No native atomicity; ordered message delivery |
| Trust model | Trustless (on-chain verification + commit-reveal) | Configurable (DVN-based, varies by deployment) | Semi-trusted (19 guardian multisig) | PoS validator set (delegated trust) | Oracle network (reputation-based trust) |
| Failure handling | Automatic revert of all legs if any leg fails | Application-level retry/fallback | Manual recovery or guardian intervention | Relayer retry with timeout | Manual retry with CCIP message status |
| MEV protection | Built-in commit-reveal scheme | None native; application-level only | None native | None native | None native |
| Flash loan resistance | Built-in staking and buffer requirements | None native | None native | None native | None native |
| Coordination latency | 5-300s configurable window (default 30s) | Seconds to minutes (varies by security config) | ~15 minutes (finality dependent) | ~30 seconds to minutes | Minutes (finality dependent) |
| Supported chains | Ethereum, Polygon, Arbitrum, Optimism, Base | 50+ chains (EVM and non-EVM) | 28+ chains (EVM and non-EVM) | 40+ chains (EVM and non-EVM) | 12+ chains (EVM focus) |
| Primary use case | Atomic multi-chain operations | General cross-chain messaging | Token bridging and messaging | General interoperability | Token transfers and messaging |
The key distinction is in the second row. LayerZero, Wormhole, Axelar, and Chainlink CCIP all provide reliable cross-chain message delivery. They ensure that if you send a message from chain A, it will arrive on chain B. But message delivery is not transaction coordination. None of them provide a mechanism to say: “Execute these five transactions across three chains, and if any one of them fails, revert all of them.”
This is the gap that Tesseract fills. It is not a messaging protocol. It is not a bridge. It is a coordination protocol that enforces atomic execution groups across independent chains.
The Three-Phase Protocol: How Tesseract Works
Tesseract’s architecture is based on our research paper “Towards Universal Atomic Composability,” which formalizes the cross-chain atomicity problem and proposes a coordination protocol that enforces all-or-nothing execution without requiring a trusted intermediary. The protocol was recognized by a16z Crypto Startup School for its contribution to cross-chain infrastructure research.
The protocol operates in three sequential phases. Each phase must complete successfully before the next begins. If any phase fails, the entire operation reverts.
Phase 1: Buffer
In the Buffer phase, all participating transactions are submitted to the TesseractBuffer contract on their respective chains. Each transaction specifies:
- The target contract and calldata
- The swap group it belongs to (a unique identifier linking all legs of the atomic operation)
- The coordination window (how long the system waits for all legs to be buffered)
- A commit hash (for MEV protection, the actual parameters are not revealed yet)
The Buffer contract holds each transaction in a pending state. No state changes occur. No tokens move. The transaction is registered, but not executed. This is analogous to a database’s write-ahead log: the intent is recorded before any mutation occurs.
Chain A (Arbitrum) Chain B (Optimism) Chain C (Base)
| | |
[Buffer TX1] [Buffer TX2] [Buffer TX3]
| | |
Pending... Pending... Pending...
| | |
+------ All TXs in swap group buffered? ------+
|
[Relayer confirms]The Rust relayer monitors all participating chains simultaneously. When it detects that all transactions in a swap group have been buffered within the coordination window, it signals the transition to Phase 2. If any transaction is missing when the coordination window expires, the entire group is cancelled and all buffered transactions are released.
Phase 2: Resolve
In the Resolve phase, the SwapCoordinator contract on each chain verifies that:
- All dependencies are present: Every transaction in the swap group has been buffered on its respective chain.
- All preconditions are met: Token balances, approvals, and contract states satisfy the requirements of each transaction.
- The coordination window has not expired: The operation is still within its configured time bounds.
- Commit-reveal is valid: The revealed parameters match the commit hashes submitted in Phase 1, preventing front-running.
Chain A (Arbitrum) Chain B (Optimism) Chain C (Base)
| | |
[Reveal params] [Reveal params] [Reveal params]
| | |
[Verify commit] [Verify commit] [Verify commit]
| | |
[Check balances] [Check balances] [Check balances]
| | |
[Check approvals] [Check approvals] [Check approvals]
| | |
+------ All verifications passed? ------+
|
[Coordinator: RESOLVED]If any verification fails on any chain, the coordinator marks the swap group as failed, and all chains revert to pre-buffer state. The resolve phase is the critical safety gate: it ensures that when execution begins, all prerequisites for success are already confirmed.
Phase 3: Execute
In the Execute phase, all buffered transactions fire. The SwapCoordinator on each chain executes the stored calldata against the target contracts. If any execution reverts, the coordinator propagates the failure to all chains, and all state changes are rolled back.
Chain A (Arbitrum) Chain B (Optimism) Chain C (Base)
| | |
[Execute TX1] [Execute TX2] [Execute TX3]
| | |
Success? Success? Success?
| | |
+------ All executions succeeded? ------+
|
YES: Finalize all state
NO: Revert all chainsThe coordination across chains in the Execute phase is handled by the Rust relayer, which submits execution transactions to each chain and monitors their outcomes. The relayer is a permissionless role — anyone can run one — but relayers must be registered in the RelayerRegistry contract and meet staking requirements to prevent griefing.
The Seven Smart Contracts
Tesseract’s on-chain infrastructure consists of seven Vyper smart contracts, each with a specific role:
| Contract | Role |
|---|---|
| TesseractBuffer | Receives and holds pending transactions; manages the buffering lifecycle |
| SwapCoordinator | Orchestrates the three-phase protocol; enforces atomicity guarantees |
| Token | ERC-20 interface for tokens participating in swaps |
| Staking | Manages relayer and participant stakes; enforces flash loan resistance |
| FeeCollector | Collects and distributes protocol fees across participants |
| RelayerRegistry | Registers and validates authorized relayers; manages stake requirements |
| Governor | Protocol governance; parameter updates and upgrade coordination |
The contracts are written in Vyper for auditability and reduced attack surface. Vyper’s restrictions on inheritance and operator overloading make the contract logic more linear and easier to formally verify.
Integrating with the Python SDK
Tesseract provides a Python SDK with synchronous and asynchronous clients for integrating atomic cross-chain operations into your application. The SDK handles connection management, transaction construction, buffering, and execution monitoring.
Basic Atomic Swap
from tesseract import TesseractClient
# Initialize client with chain configurations
client = TesseractClient(
chains={
"arbitrum": {
"rpc_url": "https://arb-mainnet.g.alchemy.com/v2/YOUR_KEY",
"buffer_address": "0x1234...abcd",
"coordinator_address": "0x5678...efgh",
},
"optimism": {
"rpc_url": "https://opt-mainnet.g.alchemy.com/v2/YOUR_KEY",
"buffer_address": "0x9abc...1234",
"coordinator_address": "0xdef0...5678",
},
},
private_key="0xYOUR_PRIVATE_KEY",
)
# Define an atomic swap group
swap = client.create_swap_group(
coordination_window=30, # seconds
slippage_tolerance=0.005, # 0.5%
)
# Add legs to the swap
swap.add_leg(
chain="arbitrum",
action="sell",
token_in="0xWETH_ARBITRUM",
token_out="0xUSDC_ARBITRUM",
amount_in=1_000000000000000000, # 1 ETH in wei
min_amount_out=3180_000000, # 3180 USDC (6 decimals)
)
swap.add_leg(
chain="optimism",
action="buy",
token_in="0xUSDC_OPTIMISM",
token_out="0xWETH_OPTIMISM",
amount_in=3180_000000, # 3180 USDC
min_amount_out=980000000000000000, # 0.98 ETH
)
# Execute atomically -- both legs succeed or both revert
result = swap.execute()
print(f"Swap status: {result.status}")
print(f"Arbitrum TX: {result.legs[0].tx_hash}")
print(f"Optimism TX: {result.legs[1].tx_hash}")Multi-Chain Client for Portfolio Operations
from tesseract import MultiChainClient
multi = MultiChainClient(
chains=["arbitrum", "optimism", "base"],
config_path="./tesseract_config.yaml",
)
# Rebalance liquidity across three chains atomically
rebalance = multi.create_swap_group(coordination_window=60)
rebalance.add_leg(chain="base", action="withdraw", pool="0xBASE_POOL", amount=5_000_000)
rebalance.add_leg(chain="arbitrum", action="deposit", pool="0xARB_POOL", amount=3_000_000)
rebalance.add_leg(chain="optimism", action="deposit", pool="0xOPT_POOL", amount=2_000_000)
result = rebalance.execute()
if result.status == "completed":
print("Rebalance succeeded across all chains")
elif result.status == "reverted":
print("Rebalance failed -- all chains reverted to original state")
print(f"Failure reason: {result.failure_reason}")Async Client for High-Throughput Applications
import asyncio
from tesseract import AsyncTesseractClient
async def run_atomic_operations():
client = AsyncTesseractClient(
config_path="./tesseract_config.yaml"
)
# Submit multiple independent swap groups concurrently
swap_a = client.create_swap_group(coordination_window=30)
swap_a.add_leg(chain="arbitrum", action="sell", token_in="0xWETH", token_out="0xUSDC", amount_in=1e18)
swap_a.add_leg(chain="optimism", action="buy", token_in="0xUSDC", token_out="0xWETH", amount_in=3200e6)
swap_b = client.create_swap_group(coordination_window=30)
swap_b.add_leg(chain="base", action="sell", token_in="0xDAI", token_out="0xUSDC", amount_in=10_000e18)
swap_b.add_leg(chain="arbitrum", action="buy", token_in="0xUSDC", token_out="0xDAI", amount_in=10_000e6)
# Execute both swap groups in parallel
# Each group is independently atomic
results = await asyncio.gather(
swap_a.execute_async(),
swap_b.execute_async(),
)
for i, result in enumerate(results):
print(f"Swap {i}: {result.status} (coordination time: {result.coordination_time_ms}ms)")
asyncio.run(run_atomic_operations())Gas Cost Analysis and Performance Characteristics
Atomic coordination is not free. Tesseract adds gas overhead relative to raw cross-chain transactions because it requires buffer registration, commit-reveal, coordinator verification, and execution through the coordinator contract rather than direct calls. Here is what to expect.
Gas Overhead Per Phase
| Phase | Estimated Gas (per chain, per leg) | Description |
|---|---|---|
| Buffer | ~80,000 - 120,000 gas | Storing transaction data, commit hash, and swap group metadata |
| Resolve | ~60,000 - 90,000 gas | Revealing parameters, verifying commit hashes, checking preconditions |
| Execute | Base TX gas + ~40,000 - 60,000 | Executing the underlying operation through the coordinator contract |
For a two-leg atomic swap (one leg on Arbitrum, one on Optimism), the total additional gas overhead is approximately 360,000-540,000 gas split across both chains. At L2 gas prices of 0.01-0.1 gwei, this translates to fractions of a cent in additional cost.
Performance Characteristics
| Metric | Value |
|---|---|
| Coordination window range | 5-300 seconds |
| Default coordination window | 30 seconds |
| Relayer monitoring latency | Sub-second (Rust async runtime) |
| Maximum legs per swap group | Limited by block gas; practically 10-20 legs |
| Concurrent swap groups | Unlimited (independent coordination) |
| End-to-end latency (typical) | 30-45 seconds for a 2-chain swap |
| End-to-end latency (minimum) | ~8 seconds with 5s coordination window |
When the Overhead Is Worth It
The gas overhead is negligible for any operation where partial execution risk exceeds the coordination cost. For a $50 cross-chain arbitrage, the overhead may not be justified. For a $500,000 liquidity rebalancing operation, the cost of partial execution dwarfs the gas premium by orders of magnitude.
As a rule of thumb: if the value at risk from partial execution exceeds $100, the coordination overhead pays for itself.
Security Model
Tesseract’s security design addresses three categories of attack: MEV extraction, flash loan manipulation, and coordinator compromise.
MEV Protection via Commit-Reveal
Cross-chain operations are inherently vulnerable to MEV. When a user submits a swap intent to the buffer, the transaction parameters (token addresses, amounts, slippage bounds) are visible on-chain. A searcher monitoring the buffer could front-run the swap by executing the same trade ahead of the user.
Tesseract mitigates this with a commit-reveal scheme. In Phase 1 (Buffer), the user submits only a hash of their transaction parameters. The actual parameters are not revealed until Phase 2 (Resolve), when the coordination window has closed and all legs are confirmed. By the time the parameters are visible, the swap group is locked and no new transactions can be inserted.
This does not eliminate all MEV — a sophisticated attacker who controls the relayer could still extract value. But it raises the bar significantly compared to systems where swap parameters are visible from the moment of submission.
Flash Loan Resistance
Flash loans enable an attacker to borrow a large amount of capital within a single transaction, manipulate a market, and repay the loan in the same transaction. In a cross-chain context, an attacker could use a flash loan to manipulate the price on one chain just before a Tesseract swap executes, profiting from the price impact.
Tesseract resists this through the Staking contract. Participants in swap groups must have staked tokens that have been locked for a minimum duration. Flash-loaned tokens cannot meet this requirement because they must be repaid within a single transaction. The staking requirement ensures that participants have persistent capital at risk, making flash loan attacks economically unviable.
Relayer Security
Relayers are the off-chain component that coordinates between chains. A malicious relayer could attempt to:
- Selectively execute: Execute some legs of a swap but not others. Prevented by the on-chain coordinator, which requires all legs to be confirmed before any execute.
- Delay execution: Hold a swap group hostage by not submitting execution transactions. Mitigated by the coordination window timeout: if execution does not complete within the window, all legs revert. Additionally, any registered relayer can complete the execution — relayers are permissionless and competing.
- Censor transactions: Refuse to relay certain users’ swaps. Mitigated by the permissionless relayer model: users can run their own relayer or use any registered relayer.
Relayers must register in the RelayerRegistry contract and stake tokens. If a relayer misbehaves, its stake can be slashed through the Governor contract.
Infrastructure and Deployment
Tesseract’s off-chain infrastructure is built for production reliability. The Rust relayer is designed for high-throughput multi-chain monitoring with sub-second latency. The project includes Terraform configurations for deploying the relayer infrastructure on AWS, with auto-scaling, health checks, and monitoring.
The protocol has 135 tests covering contract logic, cross-chain coordination, edge cases (partial buffering, expired windows, commit-reveal mismatches), and relayer behavior. The test suite runs against forked mainnet state for realistic execution conditions.
Supported chains for deployment:
- Ethereum mainnet and Sepolia testnet
- Polygon mainnet and Amoy testnet
- Arbitrum One and Sepolia testnet
- Optimism mainnet and Sepolia testnet
- Base mainnet and Sepolia testnet
For a detailed overview of how Tesseract fits into our cross-chain infrastructure products, see our solutions page.
Limitations and Tradeoffs
No system is without tradeoffs. Tesseract makes specific design choices that limit its applicability in certain scenarios.
Latency: The coordination window adds a minimum of 5 seconds (and a default of 30 seconds) to any cross-chain operation. For latency-sensitive applications like high-frequency cross-chain trading, this overhead may be unacceptable. Single-chain operations will always be faster.
L2 scope: Tesseract currently supports Ethereum L2 rollups and Polygon. It does not support non-EVM chains (Solana, Cosmos, etc.) or L1-to-L1 operations (Ethereum to BNB Chain). The protocol’s design assumes EVM-compatible execution environments.
Relayer dependency: While relayers are permissionless and anyone can run one, the protocol requires at least one operational relayer to function. If all relayers go offline, swap groups will time out and revert (safely, but without execution). Running your own relayer eliminates this dependency.
Gas overhead: The three-phase protocol adds gas cost on top of the underlying operations. For very small transactions, the overhead may exceed the value being protected. The protocol is designed for operations where partial execution risk justifies the coordination cost.
Coordination window tuning: Choosing the right coordination window requires understanding the latency characteristics of the participating chains. Too short, and legitimate legs may not buffer in time, causing unnecessary reverts. Too long, and capital is locked in the buffer for extended periods. The default of 30 seconds works well for most L2 combinations, but protocols should test with their specific chain configurations.
Finality assumptions: Tesseract operates at the L2 sequencer confirmation level, not at L1 finality. This means that in the extremely rare event of a sequencer reorg on one chain after a swap group has executed, the atomicity guarantee could be violated. In practice, L2 sequencer reorgs are exceedingly rare, but protocols that require L1-level finality guarantees should be aware of this assumption.
Frequently Asked Questions
How is Tesseract different from a cross-chain bridge?
A bridge moves assets from one chain to another. Tesseract coordinates transactions across multiple chains to ensure they all succeed or all fail together. You might use a bridge as one leg of a Tesseract swap group, but the bridge itself does not provide the atomicity guarantee. The difference is between “transfer tokens” and “execute a multi-step operation atomically.” Bridges solve the first problem. Tesseract solves the second.
What happens if the relayer goes offline during a swap?
If a relayer goes offline during the Buffer phase, the coordination window will expire and all buffered transactions will be released. No funds are lost — the operation simply does not execute. If the relayer goes offline during the Execute phase, other registered relayers can pick up the execution. The protocol is designed so that relayer failure results in safe reverts, never in partial execution.
Can I run my own relayer?
Yes. The relayer is a permissionless role. Anyone can register in the RelayerRegistry contract, meet the staking requirements, and run a relayer instance. The Rust relayer codebase and Terraform deployment configurations are available for self-hosting. Running your own relayer eliminates dependency on third-party relayer operators and gives you full control over execution timing.
What is the minimum transaction size where Tesseract makes sense?
The gas overhead of the three-phase protocol is approximately 360,000-540,000 additional gas across all chains involved. At current L2 gas prices, this costs fractions of a cent to a few cents. The practical threshold is not gas cost but value at risk: if partial execution of your cross-chain operation could cost you more than $100 in stranded funds, failed arbitrage, or manual recovery time, Tesseract’s coordination overhead is worth it. For institutional liquidity operations in the six- and seven-figure range, the overhead is negligible.
Does Tesseract support non-EVM chains?
Not currently. The protocol is designed for EVM-compatible execution environments and currently supports Ethereum, Polygon, Arbitrum, Optimism, and Base. Support for additional EVM chains can be added by deploying the Vyper contracts and configuring the relayer. Non-EVM support (Solana, Cosmos, etc.) would require significant architectural changes and is on the long-term roadmap.
How does the commit-reveal scheme work in practice?
When you submit a transaction to the buffer in Phase 1, you provide a hash of the transaction parameters (target, calldata, amounts) rather than the parameters themselves. This hash is stored on-chain. In Phase 2 (Resolve), you reveal the actual parameters, and the coordinator contract verifies that they match the hash. This prevents MEV searchers from reading your swap parameters during the buffering window and front-running your operation. The SDK handles commit-reveal automatically — you do not need to manage hashes manually.
What is the relationship between Tesseract and the “Towards Universal Atomic Composability” paper?
The paper formalizes the cross-chain atomicity problem, proves that existing messaging-based approaches cannot provide full atomicity guarantees, and proposes the three-phase coordination protocol as a solution. Tesseract is the production implementation of the protocol described in the paper. The paper provides the theoretical foundation; Tesseract provides the deployable smart contracts, relayer infrastructure, and developer SDK. You can read the paper and our other research at our research page.
What Comes Next
The cross-chain atomicity problem is not going away. As DeFi protocols deploy across more L2s and more capital flows between chains, the cost of partial execution failures will continue to grow. Bridges will continue to improve at moving tokens. Messaging protocols will continue to improve at delivering messages. But neither category provides the all-or-nothing execution guarantee that serious multi-chain operations require.
Tesseract is our answer to this gap. It is built on peer-reviewed research, implemented in auditable Vyper contracts, and designed for production deployment. If your protocol operates across multiple Ethereum L2s and you need atomic cross-chain execution, get in touch to discuss a pilot integration, or explore our solutions to see how Tesseract fits into a broader cross-chain infrastructure stack.