Rhinestone collaborates with Uniswap Labs and LI.FI to build The Compact

TL;DR

• Resource locks are a key component of intent-based crosschain interoperability. Enabling near-instant crosschain transactions with zero slippage, zero bridging, and zero gas tokens required for the end user.
• We’ve collaborated with Uniswap Labs and LI.FI to develop The Compact, a singleton ERC-6909 resource lock contract that provides a permissionless and highly composable foundation for crosschain intents.
• This article provides a high-level overview of The Compact, its components, and why we believe it will become the de facto standard for resource-locked intents. 

The Compact is a foundational low-level building block for intents, much like Permit2.  

Introduction

Resource locks have become a frontier research topic within the blockchain interoperability space. This is often referred to as “chain abstraction”, with resource locks enabling crosschain balances to be instantly spent on any chain, giving the feeling that these crosschain balances are unified. 

In step one of a non-resource-locked crosschain intent, the user deposits into a contract on one chain and specifies a desired output token on another chain. A market of relayers (or solvers) observes this onchain event and competes in a pseudo-auction (pseudo because it is typically time-based) to fill and win the relayer fee. 

Resource locks enable the traditional intent flow to be inverted. 

• Step 0: The user resource locks funds without giving up custody and without the assets leaving the wallet’s control. 
• Step 1: The user submits an off-chain signature that is broadcast to relayers who trust the resource lock methodology (the intricacies of this relayer trust are detailed below). 
• Step 2: A chosen relayer optimistically fills the intent on the destination chain. 
• Step 3: The chosen relayer processes a claim event on the user’s resource locked balance.

Note: Step 0 is only performed once, after which the user can submit any number of intents using the locked balance (steps 1-3). 

The benefits of this are:

• Blazing-fast intents that only depend on the fill speed of the destination chain.
• Ability to create a unified balance for users across any supported chain.
• Delayed settlement opens the door to novel intent routing and gas optimisations.

Until now, resource locking methods have come with large trade-offs, limiting the composability of smart accounts and eroding the proposition of self-custody. The Compact presents an alternative that we believe will become the de facto standard, overcoming some of the shortcomings of escrow-based resource locks discussed in early research pieces. 

A clear example of this move to resource lock-based interop is Circle’s newest bridge, Circle Gateway, which uses resource locks to enable low-latency mint and burn on any chain from a locked balance on a single chain.

What is The Compact?

The Compact is an ownerless ERC-6909 contract that facilitates escrow-based resource locks and intent resolution (settlement) between committed counterparties. Users deposit funds into The Compact and create credible commitments by specifying actions that any third party can execute in exchange for locked resources. These actions can be performed asynchronously, and the third party can claim the user's funds once the user’s specified conditions are met.

The Future of Intents

Intent systems that are live today exhibit one or two of the following limitations:

• Intents are restricted to a single input token (e.g., CoW) and/or input chain (e.g., Across).
• All necessary steps to achieve an onchain outcome must be executed sequentially, with each step serving as input for the next, creating a rigid process that limits the range of possible solutions for fulfilling intents.

The Compact lays the foundations for breaking out of these constraints. Enabling multi-input intents with non-sequential and asynchronous execution, all while maintaining an atomic and single signature experience for the end user. 

In multi-input intents, users can fund an execution on one chain with multiple different input tokens from multiple different chains. With non-sequential execution, users can execute transactions on the destination chain before claim events take place, allowing solvers to apply novel strategies for price and gas optimization.

Core Components of The Compact

The Compact has four components:

ERC-6909 contract: Resource locks are entered through a native token or ERC-20 deposit. When a resource lock is established, the user receives an ERC-6909 token representation of the locked funds. At the time of making the deposit, the user also specifies the allocator for the locked funds.

Allocators: An entity that sequences intents against the resource-locked funds and mediates the settlement of intents. Its core function is preventing double-spending. In its simplest form, an Allocator is an offchain system that monitors user intents, performs accounting against the user’s resource-locked balance, and co-signs when intents are fully funded.  

Arbiters: A smart contract that is responsible for processing claim transactions. The Arbiter is set at the moment the user creates an intent and determines where claimed funds are directed once a user and Allocator have co-signed the intent. 

Emissaries: Users can optionally assign an Emissary to act as a delegated signer for authorizing claims against the Compact. This allows smart accounts to sign over intents, including the use of session keys, without the risk of future claims being invalidated through key rotation on the account. 

Only ECDSA signatures via EOAs are truly irrevocable. The Emissary plays a pivotal role in enabling smart account signatures to have irrevocability, allowing relayers (or solvers) to confidently fill a user’s intent without the risk of not being repaid. 

Below, we walk through the intent flow, mirroring the diagram above, and demonstrate the role of The Compact and the peripheral components. 

Trust Model

The Compact’s trust model depends on the specific Allocator, Arbiter, and Emissary in use. The user must verify that the Arbiter and Emissary are reliable and will process claims per the approved conditions set by the user. Third parties that fulfill these intents (i.e., relayers or solvers) must trust or verify that the Allocator is sound and will not allow user intents to be underallocated (leading to double-spend) and that the Emissary can ensure the user signature is not revocable. Importantly, the Compact has an onchain escape hatch that allows users to withdraw all underlying funds with a time delay if any components become untrustworthy.

Why The Compact

Trust Minimized

In a prior post, we discussed the various approaches to resource locking and their shortfalls. The most common resource locking model today is the co-signer model, where the user is forced to always transact through a specific signer that will only pass if a “commitment machine” authorizes the transaction. This is equivalent to an Allocator co-signing all transactions that go through the user account. This requires the user to have high trust in the commitment machine. If the commitment machine is down, the user cannot transact at all – the account is locked! 

The Compact is the opposite. It enforces a minimum trust model, if not trustless. The resource lock is onchain and only applicable to the locked balance. In other words, the commitment machine / Allocator does not sit on top of all transactions that go through the user’s wallet. 

Maximum Interop

Given The Compact is non-invasive in terms of the standard operation of the user's wallet, it allows for maximum composability and interoperability.

The co-signer approach, on the other hand, places a limiting factor on the composability of the integrated account. For example, all account configuration changes, such as key rotation, recovery, enabling session keys, etc, must be authorized by the co-signer. Any existing infrastructure that requires a user signature must go through the commitment machine. This introduces developer complexities and limits interoperability.

The Compact inherits the power of a co-signer model, but only when handling resource-locked funds, and therefore avoids all of its downsides. All other interactions that go through the account can follow existing signature validation flows, allowing for easy interoperability with existing tools and infrastructure that do not require a resource-locked balance.

Composability

The Compact is more than just an escrow-based resource locking system. The goal of The Compact is to provide foundational technology more akin to Permit2. A canonical and permissionless resource locking system that can be extended and reused by any team building new DeFi and intent-based primitives.

The benefits of this are threefold:

1. Open source and permissionless low-level foundations can drive an ecosystem of tools and utilities for developers building with resource locks.
2. The more teams that build on The Compact, the more transferable resource locks become between different intent-based products.  
3. The wider the adoption of The Compact, the greater the recognition that a “compact receipt” (i.e. a wrapped version of the deposited token) is equivalent to the underlying token. This fixes the issue of resource locks being separate from the account.

To be more specific, the biggest downside of escrow-based resource locks is that the users assets need to be separated. This has several downsides. For example, to index the user’s true balance, the indexing service must either index the escrow or recognise the escrow token. Or in DeFi, token rewards could be accidentally attributed to the escrow address instead of the user's wallet. These types of problems multiply the more escrow-based resource locking systems emerge. Given The Compact is a permissionless building block, it has a much greater shot at overcoming these problems. 

Smart Account Compatibility

To date, escrow-based intent systems rely on immutable signatures and assume that users can’t revoke a signature. This is a fair assumption given that EOAs can only make immutable signatures. However, smart accounts can rotate the signer and invalidate a prior signature. This creates an attack vector when combining smart accounts with escrow-based resource locks.

One of Rhinestone’s main contributions to The Compact is the introduction of the Emissary system. The Emissary is effectively a delegated signer that must be used whenever an intent is signed over by a smart account. The Emissary is effectively as a fallback signature validation scheme in the event a signature is invalidated. The Compact achieves this by checking ECDSA, then ERC1271 signatures, and then finally the set Emissary if all prior signature checks fail. 

The Emissary is a powerful system because it enables users to sign intents with passkeys, multi-sig, session keys, and other smart account-native signature methods. This, for example, unlocks killer features like crosschain intent automation built on top of The Compact.

Conclusion

The Compact, a novel resource locking system – developed in collaboration with Uniswap Labs and LI.FI – is a step change in the evolution of crosschain interoperability and intent execution. Check out the open source code and dive into our documentation to start building your intent-powered application.