Introducing The Compact

0age, Chris Cashwell, Mark Gretzke, Christian Angelopoulos

Today we’re releasing The Compact v1, an ownerless ERC-6909 contract for reusable resource locks that enables tokens to be credibly committed in exchange for performing actions across chains.

Without the right primitives, the cross-chain landscape risks fracturing into siloed ecosystems where teams build infrastructure that fits their specific purposes but remains incompatible with one another. We imagine a better path forward: a shared, vetted, and interoperable primitive that flexibly adapts to support each project's requirements without sacrificing composability.

By providing exactly this primitive, The Compact creates a shared framework for developers to build customizable and composable systems that enable the vast potential and expressivity of programmable digital assets. The system will power cross-chain swaps on UniswapX as well as a broad suite of other applications across the ecosystem. Teams like LI.FI and Rhinestone are already building on top of The Compact.

The Compact v1 has undergone multiple independent security reviews by OpenZeppelin and Spearbit Cantina and the periphery contracts are under active development. Full audit reports will be published soon, and the system will become part of Uniswap Labs' bug bounty program.

How The Compact works

The Compact enables secure cross-chain settlement through a system of reusable Resource Locks and programmable commitments. When sponsors deposit assets, they create ERC6909 tokens representing those locked assets, which remain under the sponsors’ control.

These Resource Locks serve as the foundation for creating Compacts – verifiable commitments that specify conditions under which the locked resources can be claimed by others. This separation is key: the lock holds the assets, while Compacts define the rules for accessing them. A single lock can back multiple Compacts, making deposited assets instantly 'activated' for use across chains without giving up custody.

What makes the Compact uniquely flexible is that owners of Resource Locks can customize the rules and actors for these Compacts:

• Allocators prevent double-spending by authorizing the use of existing resource locks. They act as the "safety rails" that ensure commitments remain credible. Sponsors choose allocators based on their security needs – from fully on-chain allocators for maximum trustlessness to hybrid models that balance cost and speed.
• Arbiters process claims against resource locks by verifying that the terms and conditions of Compacts have been met. If the terms of a Compact have been met, claimants submit proofs via Arbiters. Sponsors can select arbiters based on their specific trust, speed and cost preferences (from simple signatures to complex cross-chain proofs).
• Tribunal is a specialized arbiter for cross-chain swaps, an extensible non-custodial settlement engine that runs auctions leveraging each chain's unique mechanics, verifies cross-chain transactions, and coordinates their settlement.
• Emissaries provide fallback verification for authorizing claims, particularly useful for smart contract wallets that might update their EIP-1271 signature verification logic or when signing keys rotate.

This modular architecture means developers can compose these components to fit their exact needs without being locked into rigid, one-size-fits-all infrastructure. In short, The Compact provides a generalized framework for cross-domain resource allocation with strong guarantees against equivocation.

The chain abstraction challenge

Cross-chain applications face a fundamental challenge: different execution environments operate asynchronously, making atomic transactions impossible. When a user wants to swap tokens across chains, there's no way to guarantee both sides of the trade execute simultaneously. This breaks the basic atomic guarantee that makes single-chain transactions safe and predictable.

What was once a manageable coordination problem between a few chains has expanded into a complex landscape of rollups and hundreds of execution environments, each with different finality assumptions. This creates an exponentially growing matrix of infrastructure that teams must reconcile, rebuild, and attempt to compose. Most protocols work around these constraints by building monolithic escrow systems with heavy trust assumptions. This approach has introduced critical challenges across the ecosystem:

• Fragmented liquidity: Each protocol uses its own escrow design, scattering capital across incompatible systems.
• Rigid trust models: Users must give up custody or rely on centralized intermediaries to transfer assets.
• Lack of composability: Existing escrow contracts are often bespoke and cannot be composed into more complex flows.
• Execution risk and non-atomicity: Asynchronous steps can leave transactions in intermediate states that are hard to unwind; finality mismatches can lead to double-spend exploits.
• No fallback for key rotation: Smart-contract sponsors can lose signing keys, leaving funds permanently stuck.
• Navigation complexity: Users are forced to juggle multiple chains, wallets, interfaces, and incompatible trust models, which makes cross-chain interactions prohibitively complex.

The Compact provides developers with the primitive they need to eliminate these challenges and abstract away cross-chain complexity entirely. With The Compact, developers can finally offer simple, declarative interactions where users never have to navigate the underlying complexity without building new infrastructure that risks ecosystem fragmentation.

How The Compact fixes cross-chain settlement

The Compact is an ownerless ERC‑6909 contract that manages resource locks. A resource lock is created by depositing tokens (ERC‑20 or native) into the contract. Each lock has an allocator, a scope (single‑chain or multi‑chain) and a reset period, encoded into a 12‑byte lock tag. Resource locks are represented as fungible ERC‑6909 tokens identified by the concatenated lock tag and the underlying token address. The holder of these tokens can act as a sponsor and create a compact—a credible commitment that others can claim against.

When a sponsor deposits into a lock, they assign an allocator and reset period. Allocators authorize all transfers and claims to prevent double‑spends. In other words, allocators enforce the credibility of commitments. If an allocator becomes unresponsive, sponsors can initiate forced withdrawals after waiting the reset period. Sponsors may also designate an emissary (think of it as a fallback signer) to authorize claims on their behalf, for example when their own keys rotate or as a delegated authority. This design minimizes trust assumptions: funds remain in The Compact at all times, only allocated amounts are ever at risk, and sponsors retain ultimate control.

Then when the sponsor wants to use the tokens inside of their lock, they will sign or register a compact and specify an Arbiter. The Arbiter is in charge of verifying that the conditions on that compact have been met, and then submits a claim against it, releasing the tokens. If the Arbiter rejects The Compact or it expires, the sponsor can create a new compact and reuse the funds in the lock with a new arbiter or other parameters.

Benefits of this design

• Instant activation across chains. Deposited tokens are “activated” and can be spent or swapped in asynchronous environments; claimants only need confidence in the allocator and arbiter.
• Minimal trust assumptions. Sponsors and claimants must trust allocators not to under‑allocate and arbiters not to process invalid claims. Sponsors can force‑withdraw if either party misbehaves.
• Maximum composability. Resource locks are reusable fungible tokens (ERC‑6909), making them easy to integrate into batch compacts and multi‑chain flows. The Compact supports single‑chain, batch and multi‑chain compacts out of the box.
• Reusable resource locks. Once deposited, a sponsor can create as many compacts as they like against a lock. Allocators manage nonces to prevent replay attacks.
• Guaranteed atomicity. Claims against compacts consume nonces and allocations in a single transaction. Double‑spends are prevented by the allocator’s attest and authorizeClaim validation. If a claim can’t be validated, funds stay locked.
• Self‑custody. Users never relinquish ownership of their underlying tokens. All balances remain in the user’s wallet in the form of ERC-6909 tokens until a claim is executed or the sponsor withdraws the underlying.
• Delegation & multisig. Emissaries, backed by a robust generalized key management system, allow for delegated authority and provide M‑of‑N multisig support, configurable reset periods and protocol‑aware signature verification. This enables 7702 wallets, hardware wallets, social recovery or MPC to authorize claims.
• Multi‑chain operations. Sponsors can scope locks to single chains or mark them as multi‑chain; a single compact can compose commitments across multiple chains, and Tribunal and allocators handle cross‑chain settlement atomically.

Inside The Compact

Below is an example of what a typical cross‑chain swap using The Compact might look like. This example uses a fully onchain allocator, and a pull-based arbiter for crosschain proofs. In general, a crosschain flow takes the following steps:

1. Deposit → Lock. A sponsor deposits tokens into The Compact, creating a resource lock. They choose a lock scope (single chain or multi‑chain), a reset period and an allocator. Deposit methods support native tokens, ERC‑20 tokens, batch deposits and gasless Permit2 deposits.
2. Commit (Create a Compact). The sponsor creates a compact by either signing an EIP-712 payload, registering it directly, or (as shown in the diagram) requesting an onchain allocator to create it on their behalf. The compact specifies the arbiter, commitments (token/amounts), expiry, and conditions for the swap.
3. Fulfill. Fillers detect the compact and fulfill the swap on the destination chain, delivering the output tokens to the user. On the destination chain, this typically happens through a settlement engine like Tribunal which non-custodially enforces the Compact conditions.
4. Claim. The arbiter receives proof of fulfillment (pushed or pulled from the destination chain), then submits a claim to The Compact. The Compact verifies the claim with the allocator, checks nonces and authorizations, and releases the locked tokens to the filler. The filler can specify a direct ERC6909 transfer, convert the tokens to a new resource lock, or withdraw to the underlying token.

Trust assumptions & security model

Sponsors trust allocators not to censor valid requests, while claimants trust allocators to prevent under‑allocation. Both parties trust arbiters to process claims correctly, and trust emissaries only as far as their key‑management implementation allows. Crucially, sponsors retain the ability to force‑withdraw funds if allocators are compromised.

Reference implementations & peripheral tooling

Alongside The Compact, we’re open‑sourcing several related components. While these implementations have been audited, they are intended as examples; integrators should adapt them to their own trust assumptions and risk models. See each repository for detailed integration guidance.

Allocators

Allocators are registered with The Compact and act as the mediator of locked token transfers. The protocol requests the allocator’s authorization for both claims and ERC-6909 transfers to enforce the credibility of committed resources. Allocators also define how nonces and expirations work, and provide safety checks for ERC‑6909 transfers. We’ve provided several reference allocator implementations:

• OnChainAllocator: a fully on‑chain allocator that manages per‑id allocations and nonces using a two‑phase prepare/execute flow.
• HybridAllocator: allows sponsors to allocate either on‑chain or by providing off‑chain signatures. Authorized signers are managed on‑chain.
• ERC7683Allocator / HybridERC7683: extend the above allocators to integrate with the ERC‑7683 cross‑chain order standard proposal and emit Open events for settlement via Uniswap Tribunal. Gas‑less order openings are supported with sponsor signatures or deposit‑based flows.

We’ve also developed two minimal server-based allocators intended as a reference for better understanding how hybrid allocators function in practice:

• Smallocator provides an API for sponsors to request resource lock allocations across multiple blockchains with support for EIP-4361 session-based authentication (Sign In With Ethereum). It also includes a frontend application for interacting directly with the server that also facilitates making deposits into resource locks it oversees. A sponsor’s allocations are never published on-chain, which enhances end-user privacy.
• Autocator is a fork of Smallocator that relies on sponsor signatures or on-chain registrations rather than session-based authentication and does not provide the same privacy guarantees as Smallocator; the currently allocated token balances and suggested nonces for any given sponsor are public. The primary use case for Autocator is the "deposit and register" flow, where information on the input tokens is already public, with support for retries and early withdrawals when necessary.

Tribunal

Tribunal is a reference implementation of a settlement engine that provides an example pattern for processing fills against priority-gas-auction (PGA) chains using The Compact's resource locks. Fillers call fill and provide any native value necessary to pay for cross-chain messaging. Tribunal verifies expiry, chain IDs, validity conditions, computes hashes and amounts, and then executes the settlement:

• Transfers the filled tokens to the intended recipient.
• For same‑chain fills, it claims tokens via The Compact and calls back into the arbiter or recipient.
• For cross‑chain fills, it emits or processes directives that instruct remote arbiters to pull the claim.

By enforcing a single settlement path, Tribunal eliminates disputes and ensures fairness even in the presence of multiple fillers. External bridge protocols can extend Tribunal by overriding internal functions to implement the relevant directive processing logic for passing a message to the arbiter on the claim chain (or check that the necessary state is updated to allow for the arbiter to "pull" the message themselves).

The Compact itself is unopinionated about crosschain settlement mechanisms. Teams can and should build their own settlement engines with different trust assumptions, auction mechanisms, or cross-chain messaging approaches. Tribunal simply provides a working example that teams can learn from, fork, or replace entirely with their own designs. The Tribunal does not itself take custody of assets at any time.

Emissary

Signing keys change, and smart‑contract sponsors often lack the ability to provide unequivocal signatures. Uniswap’s Emissary protocol generalizes key management and provides M‑of‑N multisig support, custom timelocks and protocol‑aware signature verification. Key features include:

• Registering Secp256k1, P256 and WebAuthn keys and scheduling key removal with configurable reset periods.
• M‑of‑N multisigs with flexible thresholds, bitmap storage and timelock protection.
• Protocol support for verifying signatures across multiple protocols and filtering compatible keys.
• A KeyManagerEmissary adapter that integrates with The Compact and validates keys against lock tags.

This allows sponsors to delegate claim authorization to hardware wallets, MPC systems or other key managers without sacrificing security. It also enables relying parties to trust that signatures can’t be equivocated after they’re made public.

Build with The Compact

The Compact is already deployed at 0x00000000000000171ede64904551eeDF3C6C9788 on Ethereum mainnet, Unichain, Base, and Arbitrum, with planned deployments across more chains to come.

The Compact is an ownerless public good and open standard for cross-chain infrastructure. Multiple teams are already building on it, and other projects are experimenting with novel allocators and arbiters. We invite the entire Ethereum ecosystem to explore this shared primitive and create applications that leverage Resource Locks in unexpected ways. To start building on the Compact, please check out the Github repo and the developer docs.

The Compact is an ownerless contract, which means anyone can deploy it wherever they’d like. If you’d like to deploy The Compact on a new chain, see the repo for more information.

Acknowledgements

The Compact v1 was built by the Uniswap Labs team, with contributions from LI.FI and Rhinestone, external audits from OpenZeppelin and Spearbit, and support from teams like Hyperlane, Ponder, Across, the Ethereum Foundation, the Ethereum OIF, and OneBalance. We are actively collaborating with ecosystem partners to add more allocators, message bridges, and solver integrations.

We also thank the early integrators who provided invaluable feedback and the broader community for their enthusiasm. We can’t wait to see what gets built with The Compact.