Supercharging Intents: Resource Locks

Disclaimer: cyber•Fund is investor in OneBalance.

Acknowledgements: Special thanks to Edward and many others in the interoperability ecosystem who contributed to this article.

1. Where we are: Intents 1.0

Ethereum's rollup-centric roadmap, along with other Layer 1 protocols, have demonstrated significant progress in the evolution of blockchain design. However, scaling chains above 10,000 TPS remains an open research area in mechanism design. This scaling challenge must be solved to realize the potential of a new financial system, built on onchain rails without sacrificing decentralization.

When we take a step back and look at what is needed to solve this challenge, it becomes clear that we will need two classes of nodes: (1) very powerful sequencers that build proofs; (2) lightweight verifiers that keep the system censorship-resistant, safe, and live. Transitioning towards this architecture is a significant technical challenge, which will take time to resolve.

Beyond this, there’s also a political and social one happening: businesses like Robinhood and Coinbase are increasingly launching dedicated app-chains because they want to own the infrastructure and capture the full fee stack, to tailor the stack to specific regulatory or product needs, and to secure room for future demand.

Those are the main tailwinds for the multi-chain future: no single chain can serve all use cases while maintaining the performance requirements of a truly global financial system.

However, this comes with a set of unique problems that urgently need to be addressed: 

1. Fragmentation of user balances
2. Transaction reliability
3. Cross-chain pricing execution
4. Cross-chain infrastructure complexity
5. Composability

This article introduces Resource Locks as the foundation for supercharging intents, which enable reliable cross-chain execution while providing the user experience necessary for mainstream blockchain adoption.

2. Current challenges for users

The culmination of the current underlying complexity creates an environment that presents significant challenges for users to express even the most basic forms of intent onchain.  

To demonstrate this, let’s explore an example where a user wants to make a bet on Polymarket, one of the most popular onchain apps, and then go on to purchase a trending token:

1. Off-ramp from CEX to Polymarket: Deposit a supported asset into Polymarket (stablecoin variations on different chains or a major L1 token), and pay any withdrawal or network fee (this varies depending on the exchange and asset).
2. Wait for network confirmation: This will vary based on the token and network used for the deposit, followed by a secondary wait for Polymarket to process the deposit. 
3. Deposit converts into USDC on Polygon.
4. Make the bet: Use the USDC to bet on the desired market. This happens instantly without the user worrying about approvals or gas fees.
5. Withdraw funds to an external wallet: Withdrawals happen only on Polygon and with USDC, even if the user deposited an alternative asset. They will either need to send their funds back to the CEX or an external wallet, where they will need to have POL as a gas token.
6. Create a Solana wallet: The trending token exists only on Solana, requiring them to create a new wallet since their current wallet only supports EVM networks.
7. Bridge USDC to Solana: To move funds from Polygon, they must first find a bridge, which is a new concept, to move their USDC to Solana, and also pay a small gas fee.
8. Wait for funds to arrive: This can take a few minutes, but it can feel like an eternity for users who are unfamiliar with using blockchains.
9. Fund Solana wallet with SOL: Without SOL, the user is unable to use their USDC on Solana, as they need the gas token to make transactions.
10. Swap USDC for trending token: This can occur within the wallet of choice or a popular app on Solana and includes a small gas fee.

By the end of this ordeal, the user now has balances fragmented across multiple chains, different tokens for gas management, numerous wallets, wasted time waiting for funds to arrive on various networks, and has jumped through many hurdles. 

What should be a consistent experience, and only a couple of clicks, is instead fundamentally broken. 

Chain Abstraction fixes this.

3. But what is Chain Abstraction?

There are many definitions of Chain Abstraction, but the one I'll use serves different properties for both developers and users:

For developers:

• Removes bridge complexities to create cross-chain applications
• Removes indexing problems across chains
• Eliminates multi-RPC management complexity 
• Simplifies state management by eliminating the need to track user balances, allowances, and transaction states across multiple chains
• Reduces infrastructure costs by minimizing chain-specific monitoring, alerting, and node infrastructure requirements
• Enables faster development cycles with a build once, deploy everywhere approach

For users:

• Removes the need to know which chain they're on
• Removes the need to have separate tokens to pay gas
• Unifies same token balances across different networks into a single spendable balance (for example, arbUSDC, opUSDC, USDC, USDC.e would show as USDC or USD)
• Makes every onchain transaction one-click across any chain, action, or token
• Provides better price execution by accessing liquidity across all chains simultaneously with minimal slippage and MEV
• Enables synchronous composability by allowing users to execute complex multichain workflows atomically, as if they were on a single chain 

All this, while preserving self-custody.

Developers want to build without being limited by poor cross-chain design, and users want onchain apps that "just work".

Several existing protocols and chains have attempted to deliver these properties, but most require full trust in centralized entities and introduce single points of failure to the system. While these represent progress toward Chain Abstraction, they fall short of the trustless, decentralized infrastructure that is needed.

4. Introducing Resource Locks: Intents 2.0

Resource Locks enable cross-chain transactions to be as fast or faster than same-chain transactions, even when slower chains, such as Bitcoin or Ethereum, are involved. They work by temporarily locking the specific asset and amount the user wants to spend, creating a cryptographic commitment that guarantees exclusive fund availability based on predetermined conditions such as successful transaction execution or expiry time. 

The Resource Lock Machine (also known as the Credible Commitment Machine, Allocator, or Sequencer) provides immediate cryptographic proof that funds are exclusively reserved for a specific intent, allowing solvers to execute destination transactions immediately while being guaranteed payment, even before the source chain confirms the transaction. This commitment signals transaction intent to solvers, enabling them to execute the destination-chain transaction immediately without requiring origin-chain inclusion while cryptographically preventing double-spending.

An alternative way of viewing Resource Locks is that they are very similar to rollups, as they both have:

1. State (accounts)
2. State transition functions
3. Integrity proof system (such as Trusted Execution Environments or other proving methods like ZK or fraud proofs). 

The key difference between a rollup and Resource Locks lies in real-time proving, where proofs are generated immediately when locks are created or modified, rather than being batched periodically. Additionally, Resource Locks maintain direct access to the native state of multiple settlement chains simultaneously, eliminating the need to maintain separate states or require users to bridge funds between ecosystems.

However, this isn't a new concept. Resource Locks are fundamental to traditional finance and internet infrastructure, utilized in database management systems, financial transaction processing, and distributed computing environments to prevent race conditions and maintain consistency. When multiple users attempt to access or modify the same bank account simultaneously, banks apply locks to ensure that transactions are processed sequentially and accurately, preventing double spending and maintaining transaction atomicity. Similarly, web services implement resource locks in their APIs to manage state changes and ensure critical operations complete without interference.

This proven infrastructure model becomes particularly powerful when applied to intent-based systems in crypto, addressing many of their core limitations. Understanding this requires examining three key areas: how intents work today, current problems in intent-based systems, and how Resource Locks address these issues.

5. How intents work today

To understand why Resource Locks are supercharging intents, we first need to examine the current intent-based transaction flow and its inherent limitations.

1. A user signs a message that contains the desired output and the authorized assets (the assets that the user is willing to spend). The intent is included in the source chain at time T, with the user's assets locked to prevent double-spending.
2. Solvers see the user's intent and compete to create the optimal solution for the desired output at time T+1.
3. The selected solver executes the solution on the destination chain at time T+2 while awaiting payment confirmation from the source chain.
4. The solution gets included in the destination chain at time T+3, and the solver receives the user's locked assets in time T+4, completing the cross-chain transaction.

5.1 Current problems in intent-based systems

While intent systems offer significant improvements over traditional cross-chain interactions, they face fundamental architectural constraints that limit their effectiveness.

• Intent-based systems cannot provide synchronous composability due to their four-step transaction process, resulting in timing delays where users must wait from T through T+3 before their cross-chain transaction is completed.
• This multi-step process exists because both the intent system and solvers need protection from double-spending. If solvers were to front capital for users' intents, users could change their transaction nonce and spend assets the solver was counting on receiving as payment. This would result in solvers losing their capital.
• The intent protocol serves as the trusted intermediary in this process, guaranteeing users will receive their desired output while securing their assets for solver payment. Similarly, it ensures solvers will be compensated after executing user intents. Though this trust requirement spans only the T to T+3 window, it creates a crucial centralization point in the protocol's operation.

5.2 How Resource Locks solve these problems

Resource Locks eliminate the fundamental timing and trust issues that plague current intent systems by introducing a new coordination mechanism.

• Resource Locks function like a stamp machine, providing essential security guarantees for intent protocols, users, and solvers while eliminating certain trust assumptions present in existing intermediary-based protocols.
• By removing these trust assumptions, intent systems can now provide synchronous composability with T+1 execution timing, where cross-chain transactions complete as quickly as single-chain operations. This eliminates the T through T+3 delay that characterizes current intent systems. However, users and solvers still have to trust the Resource Lock Machine.
• When a Resource Lock protocol is cost-effective, fast, and has sufficient volume, it can deliver a cross-chain experience that feels identical to operating on a single chain, enabling true chain abstraction.

This fundamental shift in architecture addresses the core limitations of intent-based systems, but the question remains: 

How exactly do Resource Locks achieve these improvements, and what makes them technically superior to existing approaches?

6. How do Resource Lock Machines work?

Resource Lock Machines provide essential infrastructure for wallets and apps, enabling interoperability on their respective platforms. These systems consist of two main parts:

6.1 Offchain component

The offchain infrastructure operates similarly to traditional intent protocols but incorporates a critical additional component: the Resource Lock Machine. This component serves as the coordination layer responsible for managing users' transaction sequencing rights and protecting solvers from double-spending.

For example, consider a user with 1 ETH who submits two intents—first, a cross-chain transfer of 1 ETH, and second, a simple 1 ETH transfer. Without proper sequencing, if the solver executes the first intent while the system allows the second transfer to process simultaneously, the solver could lose their capital when the second transfer depletes the user's balance. The Resource Lock Machine prevents this by controlling the transaction order, maintaining the integrity of the intent execution process.

6.2 Onchain component

The onchain component varies between implementations but follows a consistent architectural pattern. This component is essential for the system's functionality and consists of a smart contract (wallet) controlled by both the Resource Lock Machine and the user's signers.

The smart contract supports various configurations depending on the specific implementation. Some allow the main signer to remove the Resource Lock Machine after a timelock period, while others rely entirely on Resource Lock Machines. 

Different solutions exist for various security and decentralization requirements, ranging from approaches that prioritize user control to those that emphasize coordination efficiency.

7. The different types of Resource Locks

Resource Locks transfer sequence rights from blockchains to Resource Lock Machines, with different implementations offering distinct trade-offs between security, decentralization, and user experience.

7.1 Fully offchain Resource Locks

Fully offchain Resource Locks face a unique challenge: providing security guarantees without relying on smart contracts. The Resource Lock Machine must control user funds while remaining trustworthy to both users and solvers.

Trusted Execution Environments (TEEs) provide computational integrity guarantees and have established use cases in crypto, from privacy applications to rollup state transition verifications. TEEs can also power Resource Lock Machines by providing the necessary trust assumptions for users. 

In fully offchain Resource Locks, the private key that controls users' accounts can be managed through various credential systems, including private keys, passkeys, or Google accounts (basically, anything that can be used as credentials). This approach maximizes flexibility in user authentication while maintaining security through the use of TEE-based execution.

The TEE-based Resource Lock Machine operates through a straightforward process:

1. Credential Verification: The user provides credentials to the TEE through the application interface, which then verifies their validity and confirms account ownership
2. Intent Processing: The TEE verifies that the credentials are valid and belong to the user, then processes the intent request
3. Authorization: After verification, the TEE authorizes solvers to view the user's intent and execute transactions
4. Settlement: Once the user's intent is executed, the TEE enables the solver to receive payment through account control

This process leverages TEE programmable preconditions, where developers configure the specific requirements that the TEE program must verify before execution. In this implementation, the program signs messages using a private key stored securely within the TEE environment.

Fully offchain Resource Locks offer significant advantages in simplicity and user experience. Users can deposit funds into accounts and immediately begin spending across every supported chain without complex onchain smart contract interactions. This user experience rivals traditional centralized services while maintaining cryptographic security guarantees.

However, depending solely on TEEs creates censorship issues (TEE operators can decide to censor and block specific users) and liveness problems (if TEE stops working, there is no way to transfer your assets). As Resource Locks essentially transfer sequence rights from blockchain to Resource Lock Machines, you’re making a tradeoff between user custody and improved UX.

7.2 Semi-onchain (co-signer) Resource Locks:

The semi-onchain Resource Lock approach uses a smart contract wallet with two signers. 

1. First signer belongs to the user (which can be a passkey, simple EOA, or any credential provable onchain). 
2. The second signer comes from the TEE, providing the necessary Resource Lock guarantees for the system.

In practice, a user would use a passkey credential to log in, and the TEE holds another private key, making the experience look like this:

1. User Intent Signing: The user signs the intent with their passkey (this could be any type of private key, but we're using a passkey as an example)
2. TEE Verification: The TEE verifies the message inside the TEE and ensures that the account owner requested this intent
3. Intent Fulfillment: The solver fulfills the intent
4. Settlement: Following the execution of the intent, the TEE signs the message, and a 2/2 multisig onchain smart contract executes another transaction for the solver to get paid

The user's signer can remove the second signer (which is the TEE signer) after a timelock period. The timelock is crucial, as it provides double-spend protection and other security guarantees to the solvers, and the ability to remove the TEE signer.

This structure gives better censorship guarantees for users and more sovereignty for developers.

While this system appears more elegant in theory, it introduces practical complexities: developers must handle cross-chain state tracking, and there's additional overhead in both smart contract implementation and key management. 

Nevertheless, the user experience remains comparable to centralized exchanges and other high-quality interfaces.

7.3 Fully onchain Resource Locks (a.k.a. escrow, or RL hooks)

Fully onchain Resource Locks address the trust and sovereignty concerns of TEE-based approaches by moving all coordination onchain. This approach utilizes a subaccount structure, where users deposit assets into a separate contract, thereby keeping their main account unchanged.

This subaccount mechanism enables any wallet that has built its own ERC-7702 smart contracts to adopt Resource Locks without adjusting its core architecture. It can offer Resource Lock capabilities to the subaccount while keeping primary assets untouched, enabling enhanced functionality without disrupting existing infrastructure.

For users, this works as follows:

1. Deposit: Users deposit funds into a Resource Lock subaccount before using chain-abstracted features
2. Intent Processing: The system processes the user's intent request through the subaccount
3. Authorization: Authorized solvers can view and execute the intent using subaccount assets
4. Settlement: The onchain smart contract handles payment to solvers from the subaccount

However, this also has a drawback: users must deposit funds into the escrow contract for the system to function, which adds an extra step and compromises the desired user experience.

When discussing Resource-Lock Machines, we often focus on TEE-backed verification; however, TEEs are not mandatory. A practical alternative is to split the RLM’s two fundamental roles—executing intents and verifying them—across separate actors:

• Execution signer (e.g., the allocator)
• Verification signer (e.g., an oracle)
• User signer

A straightforward implementation is a 3-of-3 multisig in which the oracle, allocator, and user each hold one key. By decoupling execution from verification, developers can adopt trust assumptions that align with their risk tolerance, rather than relying on a single TEE-secured Resource Lock Machine (Several teams are already experimenting with these configurations and delivering viable non-TEE alternatives).

8. Looking ahead with Resource Locks

Resource Locks have evolved beyond just an idea. Several dedicated teams (like OneBalance) and major players (like Circle and LiFi) are now developing products with Resource Locks. While these products haven't yet significantly impacted our ecosystem due to their early stage of development, there are some potential challenges that Resource Locks may face.

At a high level, there are two main problems:

1. 7702 has the "master key," making it impossible to build a pure 7702 account-based Resource Locks, even when the user delegates assets to another contract
2. Applications cannot determine spendable assets without checking all chains (which they likely won't implement due to the overhead)

Fortunately, we have solutions for these challenges…

9. The open secret about Ethereum’s approach to Account Abstraction

Ethereum recently had an upgrade (7702), which was a step in the right direction for bringing Account Abstraction to the network by enabling upgraded features for EOAs:

1. Users can now do batch transactions
2. Utilize paymasters
3. Delegate some properties to smart contracts

However, there is still a "master key" that controls the account. While users can still utilize fully onchain Resource Locks, this is a blocker for implementing semi-onchain Resource Locks.

The way semi-onchain Resource Locks work depends on true "multi-signature" ownership. For this to function properly, developers need customizability at the key management level, which 7702 does not provide. It also does not allow delegating full account "rights" and "controls" to another contract. There is always a master key that retains ultimate control over the account.

Fortunately, there is an EIP to solve this issue: It allows any EOA to delegate account ownership to a smart contract with an option for the master key to regain control "with a delay." This means we could use Resource Locks with the semi-onchain approach in EOA accounts. However, this solution is not ideal; it introduces changes to the Ethereum protocol for a very specific use case and is unlikely to be part of an Ethereum upgrade.

The preferred solution would be to have native Account Abstraction with full customizability at the key management level. However, as we have seen, this is sadly not going to happen anytime soon…

10. Resource Lock aware applications are not here (yet!)

Despite the efforts of great researchers to introduce Account Abstraction to the Ethereum ecosystem through ERC-4337, it became clear that there was a persistent challenge that was difficult to overcome: applications are lazy and don't want to change their UI unless forced.

 The result? A classic chicken-and-egg problem where adoption stalls:

• Applications won't support Account Abstracted wallets because there aren't enough users
• Users won't adopt Account Abstracted wallets because applications don't support them

10.1 What does being "Resource Lock aware" mean?

Resource Locks will face the same adoption challenges as Account Abstraction, but with additional complexity:

1. Applications aren't yet Resource Lock aware
2. Implementation complexity is higher than Account Abstraction

The challenge isn't understanding what Resource Locks do. It's the technical overhead that applications face to support them. Being Resource Lock aware means an application needs to:

• Track user assets across multiple chains simultaneously
• Calculate total spendable balances from fragmented holdings
• Create appropriate spending intents based on cross-chain asset availability

The solution: Wallets should handle the complexity, not applications

Since applications are unlikely to implement this complex integration themselves, wallets should take on this responsibility. A promising solution would be for wallets to develop a unified API that displays apps with the total spendable assets across chains (something they already track in their own interfaces). This is what ERC-7811 proposes with the GetAsset Proposal...

Thus, the getasset proposal shifts complexity away from application builders to wallet teams, who already handle these complex tasks in their systems and provide this shared consciousness of being Resource Lock aware. 

Another challenge is integrating the solvers of existing intent systems into Resource Lock Machines. If Resource Lock Machines cannot utilize existing solver infrastructure and liquidity, adoption will be slow. The solution is to create modular components within Resource Lock Machines that can trade off specific properties while providing users with the most cost-effective prices.

Finally, it's important to remember that not every transaction requires cross-chain transfers. When a wallet uses Resource Locks at the account level, simple transfers can be executed on the same chain. After all, users won't want to pay a $1 fee for a $1,000 transfer when traditional payment rails are available.

11. The future of intents

We’re entering a new era of onchain UX where users will focus on apps, not chains. Resource Locks are the last missing piece: they enable fast, reliable intent execution at T+1.

No more asset fragmentation. No more complex flows. No more approvals.

Onchain, as intended.