A Primer

One of the interesting ideas in crypto right now is something called resource locks, which flips the mental model of how we as users see the crypto space from a chain first model to an asset first model.

This is the mental model we’ve all internalized:

Today’s UX: chain first

This may have worked well in crypto’s earlier days, when there were only a handful of chains and wallets to worry about. But today, steps (2) and (3) in the process above have become far more confusing. The number of chains has exploded to the hundreds, and managing funds across them has become exponentially harder and arguably more frustrating. Accessing them has gotten easier thanks to better wallet UX and bridge integrations, but keeping track of everything is a whole different challenge.

The idea of resource locks is simple: what if the user could just… use the app or request an asset, and the rest was handled by infra that works?

The bet on tomorrow’s UX: asset first

The chain(s) fade into the background and the funds in your wallet are essentially treated as universally composable – available anywhere at any time to be used. For onchain spending, this model is simpler and faster for the users – they simply pretend that their wallet is magic and tell the magic portal to give them their asset using whatever funds they have on any chain in any denomination. That’s the promise of resource locks – you get the asset you want, where you want it, by locking up the asset that you have. That’s it.

Resource Locks: Asset first, chains second

You could call this “chain abstraction” or “balance abstraction” but really it’s just: meeting users where they are and allowing them to use their funds, wherever they might be.

There’s a clear directional shift underway: toward a world where assets, and the ability to use them instantly, are central to the user experience.

Today, powering much of this shift, including resource locks, is one core primitive: intents. The intent-based model, where a third-party steps in to magically fulfill whatever the user wants, has quietly become a default in cross-chain UX today. And why not? It promises things users care about: fast execution, less friction, and eventually, no need to think about the “how” behind every interaction.

That said, intents still face early design challenges, particularly for solvers such as:

Capital intensity: solvers need to maintain substantial inventory across multiple chains to be competitive.
Low profit margins and profitability challenges: intense competition to win orderflow and operational costs of running a solver forces solvers to operate on very thin margins.
Inherent operational risks: solvers take on risks in different forms – asset volatility which necessitates sophisticated hedging strategies to protect against price movements, risks of underlying chains which requires solvers to meticulously assess the risk profile of each chain (e.g., reorg risk, "rugging" risk) when deploying liquidity, risks of non-reimbursement or failed transactions due to user-side malicious intent or griefing in addition to the source chain finality risk for every transaction, inventory management challenges and risks due to unpredictable peaks in demand which make automation hard, among other things.
Misaligned mental model: A misconception slowing the maturity of intent-based systems is treating them primarily as a bridging primitive. Intents actually originated as a swapping primitive, where solvers abstract the complexity of sourcing and routing liquidity for assetX → assetY swaps. Bridging came later, largely marketed on the promise of faster delivery to the destination chain, but this model breaks down at scale and size. Only now is the mental model evolving, away from “bridging – move the same asset across chains” and towards “cross-chain swaps – swap one asset for another across chains,” which is closer to how intents are meant to operate.

You can read more about these problems in the research article here and more latest updates on the dynamics here.

This isn’t a critique of intents; they’re still evolving. Teams are still in the lab, actively experimenting with new designs to smooth out rough edges. Most of these efforts share a common goal: making life easier for solvers. When we lower solvers’ burden to participate in intent networks, and mitigate some of the timing risks they incur, we improve transaction execution for everyone involved.

Here are a few notable developments I’m especially excited to see evolve in the wild:

Across Prime is introducing a “bonded” bridging model. Solvers get access to user funds instantly on the source chain, but in return, they must post a security deposit. This bond limits their exposure by capping the amount they can have “in flight” - a smart way to balance capital efficiency with risk.
Relay Vaults enable anyone to contribute liquidity to Relay and earn yield. That capital is then made available to solvers, reducing the burden of maintaining large inventories and unlocking more scalable intent fulfillment across more chains.
Sprinter is set to launch its new crosschain liquidity protocol, enabling solvers to access deep liquidity without the need to maintain private inventories.
Stargate’s love letter to intents with the Stargate Foundation proposing to allocate up to $20M of the Stargate DAO's treasury as capital for an intents-based system. The pitch is that a Stargate funded solver could offer deep liquidity and better spreads, and it will also be integrated directly into the Stargate front-end.
Everclear brings the concept of “clearing layers” to crypto, introducing netting mechanisms for cross-chain capital flows that promise to make rebalancing far more efficient for solvers. It's finally seeing meaningful orderflow, a key factor for Everclear, as the system performs best at scale. Future integrations will only accelerate this momentum.

Resource locks represent another meaningful design change in the traditional intent flow that promises to address some of the core challenges intent-based systems are grappling with today. They lower risks for solvers and push intent fulfillment from fast to really fast. By making small but smart changes to the traditional intent flow, resource locks unlock a more scalable future for intents. That said, like any solution, they come with their own set of tradeoffs and complexities, which we will explore later in the article.

Another idea we’ll explore is how resource locks, by shifting the mental model from chain-first to asset-first, are now being used by a growing number of teams at the account level, shaping how users spend and transact onchain.

Resource locks. What are they? How are we seeing them applied in interop? Why do they represent a meaningful improvement over the traditional intents model? And why are so many teams betting on account-based resource locks as the next major primitive shaping onchain user experience?

Let’s dive in!

Resource Locks 101

Resource locks are mechanisms that temporarily restrict access to funds, data, or assets in an associated wallet until certain predefined conditions are met. Resource locks function kind of like digital escrows behind the scenes, ensuring that something remains unavailable for double spend while a transaction, process, or agreement is being settled.

During the lock period, the resource is inaccessible, typically for a duration longer than the expected time needed to fulfill the pending transaction. While the asset is locked, a third-party agent (such as an intent solver) can step in and do the work required to complete the task. This guarantees that the resource is reliably available to the intended counterparty or process once the conditions are satisfied.

Resource locks ensure controlled access to shared resources, preventing conflicts and race conditions when multiple entities attempt to read, write, or modify the same asset or state at once, and guaranteeing availability for the intended task.

Two of the best examples to understand the concept of resource locks come from our daily life:

a) When you're booking a ticket online, the website often temporarily "locks" your chosen seats for a set period. This prevents anyone else from booking those same seats (avoiding "double-booking") while you complete your payment. If you don't finalize the payment within the given time, the seats are released.

You might’ve noticed this yourself if you drop off halfway through booking movie tickets, then come back and try again, the seats you picked might still show as unavailable. That’s because they’re still locked from your previous session. Even though you’ve started a new session, the system doesn’t know it’s the same person, so those seats stay occupied until the lock expires.

b) Or think about withdrawing cash at the ATM from your bank account. The backend system places a temporary lock on the funds while your transaction is being processed. Until that session is over, no one else, not even you from another machine, can touch that balance.

A resource lock in crypto functions similarly – offering guarantees that any resource (tokens, NFTs, arbitrary data, smart contract state) remains available for a set period of time. During that window, the locked funds can be accessed to fulfill the specific purpose the user originally signed off on (whether that’s a swap, a complex multi-step transaction, NFT purchase, etc.), so long as the conditions set by the system are met. More on this later.

What differs across resource lock implementations is how these guarantees are ensured:

In the case of the movie tickets, a centralized server of the ticket booking system (e.g., BookMyShow, Fandango) is handling the coordination. The guarantee is enforced by trust in the centralized platform’s logic and uptime.
In the ATM withdrawal instance, it’s the bank’s unique tracking system, likely backed by a centralized transaction processing engine. The guarantee is enforced by the bank’s internal ledger coordination, often with transactional level guarantees enforced by regulatory bodies.
In crypto, depending on the implementation, it could be anything from simple escrow contracts to resource locks powered by Trusted Execution Environments (TEEs) or something like Multi-Party Computation / chain signatures (MPC).

From the above, we can see that with resource locks, there’s one role that guarantees everything (also known as the resource lock machine or the credible commitment machine) that’s really important and a few key benefits that are highly desirable. Let’s expand on them:

How an asset first UX works with resource locks

Machines — The Coordination Mechanism Putting the Lock into Resources

Resource lock machines are composed of different components that work together to coordinate between multiple parties to execute resource locks.

The components of a resource lock machine form an architecture where:

Users express intents by committing their funds to a resource lock, which is typically time-bound.
Allocators ensure that resources are correctly locked and available to be used.
Solvers fulfill user intents, acting in confidence that their fulfillment of terms will be honored. These solvers are typically accessed via an intent marketplace.
Arbiters ensure that value is only released when valid, observable conditions are met. These can be simple oracles or interop protocols or anything else used for verification – generally also accessed via the intent marketplace in the implementation.
The allocator and arbiter together form the backbone of a resource lock machine.

While we’re aware of users and solvers, the Allocator and Arbiter are two new key roles in a resource lock machine that we need to understand.

1) Allocator — An allocator is a trusted third party responsible for sequencing user intents and validating the locks. It ensures that the user has committed the necessary resources (e.g., funds) and that no conflicting commitments exist. Its main role is to monitor activity across systems and attest to the validity of user’s commitment and availability of user’s resources, acting as the gatekeeper to ensure the lock can be relied upon by solvers.

Each resource lock implementation has varying degrees of trust assumptions, depending on how the allocator is implemented and where its signature/attestation happens. The design space spans many different options, each with its own tradeoff between UX, cost, and security.

The benefit for users: convenience, less mental overhead to figure out things, faster experience.

The tradeoff: users give up some fund sovereignty and place trust in the correctness and security of the resource lock system.

For detailed information on the different types of resource locks in crypto, read this article: Supercharging Intents: Resource Locks.

2) Arbiter — Broadly refers to the component (or set of components) responsible for verifying that the conditions for unlocking the resource have been met. Depending on the implementation, the role of this actor can range from basic signature checks to full settlement validation (ex: confirming a swap occurred), after which the asset is released to the designated solver that fulfilled the user’s intent.

This structure creates a resource lock machine where trust is embedded in the architecture, which forms the root of trust in a resource lock system. This shift introduces new risks for solvers that we’ll address in the “Risks for Solvers in Resource Locks Intent Flow” section.

Sometimes, both roles of the Allocator and Arbiter are handled by a single actor. Other times, they’re split. For example:

In OneBalance, the team itself runs the infra for both the Allocator and Arbiter roles.
In The Compact, these roles are left open by design. For instance, Rhinestone acts as its own Allocator in its implementation, while the Arbiter can vary based on configuration.

In LI.FI Intents, which is built with resource-locks in mind, teams can plug into The Compact with any custom Allocator or Arbiter, ranging from frameworks like Tribunal to interop protocols, simple oracles, or modular setups tailored to specific use cases.

Now that we understand the foundations of how resource locks work and some of their implementations in crypto, let’s get into the meat of this article: exploring how resource locks improve the traditional intent flow.

Traditional Intents vs. Resource Lock Intents

In intent-based systems, users express desired outcomes (e.g., bridge 1 ETH from Ethereum to Arbitrum), and solvers race to fulfill them. This model creates a smooth user experience as solvers are incentivized to act quickly and ensure reliability.

However, the intents design space is still early, and current implementations face persistent challenges. At the core, most of them stem from solver's capital requirements; when and how they’re repaid, and the risks they take in the whole process. Reducing these frictions is essential to building more scalable and resilient intent-based infrastructure.

Risks for Solvers in Traditional Intent Flow

In a traditional intent flow, when a user submits an intent, their funds are supposed to be locked in an escrow contract on the source chain. But in practice, it takes a few blocks for this to finalize – on Ethereum, for example, guaranteed finality can take around 13 minutes, while on chains like Solana, Avalanche, or most L2s, finality is often reached within seconds. Solvers don’t wait for finality as they are often incentivized to act optimistically. They detect the intent in the mempool and act immediately, racing to fulfill it on the destination chain to win the transaction.

This creates a gap: while the solver is acting, the intent-source lock on the user’s funds is not yet finalized. This gap exists because solvers are competing in real time (e.g., in systems like Across, which run a first-come, first-serve auction), and speed matters. As a result, solvers not only take on source chain finality risk, but also double-spend risk, all for the chance to win orderflow.

This risk isn’t just theoretical. While there aren’t many public examples of solvers being griefed in intent-based systems due to double-spending or finality issues, such vulnerabilities have been identified before. For instance, security researcher Jason Matthyser (iosiro) identified a flaw in a very early design of Across in 2022 that enabled a double-spend scenario. The vulnerability stemmed from the ability to modify the relayerFeePct field when a user speeds up their deposit, allowing the same deposit to be fulfilled twice by different solvers.

To summarise, this optimistic execution model in current intent-based systems exposes solvers to:

Finality risk: The user’s transaction might never be fulfilled (e.g., due to chain reorgs or network congestion).
Double-spend risk: From the solver’s perspective, the same funds may be reused elsewhere before their action completes. This creates the possibility of executing a fill that’s no longer valid, resulting in a loss. It must be noted that while resource locks eliminate this specific attack vector for double spends, they are reintroduced in a different form: if the allocator acts dishonestly, solvers are still exposed.
Denial-of-service risk: Malicious or unreliable users can degrade solver performance by submitting conflicting or misleading intents. For example, slow relays or dummy transactions can trick the solver into inactivity or wasteful behavior, ultimately harming both solver incentives and user experience. In the worst case, this can throttle the entire protocol by flooding it with intents that appear valid but are never meant to be fulfilled.

These risks discourage solver participation and likely increase price spreads by increasing uncertainty and the potential for loss. As a result, the cost of capital rises, and the system becomes more fragile, especially under high demand or in adversarial conditions where reliability matters most. Without stronger guarantees, intent-based systems struggle to scale securely.

Resource Locks Intents

While resource locks are not a silver bullet that can magically solve all of these problems, they tackle some of the problems with intents by improving the working conditions for solvers, not by directly changing the role of the solvers themselves, but by augmenting the traditional intent model with a commitment mechanism: users must lock their resources before expressing the intent. This guarantees exclusive access to the funds for a bounded time period, verifiably attested to by a resource lock machine.

Here’s how the resource lock intent flow works in practice: 1) The user initiates a lock — They deposit funds into a resource lock, effectively committing not to overwrite their request for a set time window.

2) Allocator validates the lock — The Allocators checks that the funds exist and the lock is valid. It guarantees that the same resources won’t be promised to multiple processes and provides an attestation that acts as the guarantee for all parties involved in the process.

3) User expresses intent

4) The intent marketplace that the RL machine is using selects a solver that will be designated the responsibility to execute the user intent.

5) Solver executes user's desired event — For example, a cross-chain swap or a multi-step intent, executed by the solver.

6) The user gets the desired assets on the destination chain.

7) Arbiter validates fulfillment — The Arbiter verifies that the intended action took place correctly. If so, it authorizes the final release of the resource to the solver. This can be anything from a trust-me-bro 1 signature validator setup to a more trustless m of n verification mechanism using zk proofs for instance.

8) The funds are released to the solver on the source chain as their repayment.

High level diagram for the resource lock intent flow. Note: The scope of work for the Allocator and Arbiter spans both the source and destination chains. They may be any type of entity, depending on the specific resource lock implementation.

Benefits of Resource Lock Intents

Drawing from Schelling’s theory of credible commitment, resource locks offer:

Irrevocability: Users cannot cancel or repurpose locked funds.
Cost to reverse: Backing out is financially or operationally intensive.
Observability: The lock and its guarantees are publicly verifiable.

These characteristics enable more secure coordination between untrusted parties, such as solvers and users. Resource lock intents eliminate key risks that solvers face:

In essence:

Traditional intents – User expresses intent, solver acts optimistically without waiting for the inclusion transaction on the source chain that the user’s funds are locked in the escrow. There’s a finality risk.
Resource-lock intents – User commits funds, Allocator in the resource lock machine attests to commitment. The solver acts with certainty. The risk of double-spending is eliminated by the enforced locks.

As a result, solvers can:

Operate with improved capital efficiency.
Accept more complex intents given better capital repayment guarantees.
Scale operations with fewer risks.

Consequently, as solvers can now work faster and more efficiently, users also experience improved UX:

Faster execution: Solvers no longer need to second-guess intent validity. Once a resource lock is observed, they can act immediately and deterministically so long as they trust the allocator/arbiter.
Higher reliability: Reducing ambiguity and edge-case failures (e.g., duplicate fills, griefing attacks) results in fewer failed or delayed transactions.
More inclusive solver participation: While resource locks don’t eliminate risks entirely for solvers, they help reduce certain coordination overhead and auction logistics challenges. This doesn’t necessarily increase the number of solvers, but by reducing risk and coordination overhead, resource locks can theoretically lower the barrier to entry, making it easier for more solvers to participate. With a fairer shot at fulfilling intents (rather than competing on speed), there are more takers for user orders, which can lead to better terms for users overall.

That said, these benefits come with a clear trade-off: the solver must trust the allocator that it isn't colluding with users or acting erroneously, as any such behavior could directly impact the solver’s execution and outcomes.

Case Study: Resource Lock Bridges

Note: skim this section if you already know your bridges well.

To illustrate the performance benefits, consider different bridge models:

1) Classical Bridges (ex: Stargate) Wait for source chain finality before releasing funds. Slower in theory, but in practice, optimizations like shorter confirmation windows where teams play with hard finality vs soft finality guarantees to speed up transfers. Stargate (Taxi) on Jumper average transfer times of under 1 minute.

2) Intent-Based Bridges (ex: Across) Solvers front capital instantly and take on finality risk. This leads to much faster transfers for users Across averages under 5 seconds. Some, like Relay, skip auctions altogether and use a more centralised approach with a single solver.

3) Resource Lock Bridges Take it a step further. Users lock funds upfront, giving solvers instant finality guarantees. OneBalance’s Bitcoin bridge shows this in action.

While the case study above focuses on bridging, it's important to note that resource locks are a generalizable primitive and their benefits can extend to any flow where intents are used — whether it’s trading, payments, or something else entirely.

Risks for Solvers in Resource Locks Intent Flow

Resource lock systems introduce a new root of trust for solvers in the actors who serve as Allocators and Arbiters. Together, these actors form what we have described as a resource lock machine.

Within this architecture, solvers must operate under a fresh set of trust assumptions. These assumptions reflect key open challenges that must be addressed:

1. Trusting the Allocator

Solvers are required to trust that the allocator behaves honestly and reliably - that it is neither colluding with users nor acting adversarially against solvers. This includes trust in the allocator’s allocation decisions and the integrity of its coordination logic. If the allocator misbehaves, solvers may end up executing intents that result in economic loss.

From a solver’s perspective, this trust requirement can feel like a liability. Ideally, allocation and execution constraints would be encoded directly into the token state at the contract level across virtual machines, making behavior verifiable and minimizing reliance on off-chain or intermediary logic. This aligns more naturally with an asset-centric model, where the asset itself defines how and when it can move, reducing the need to trust external allocators entirely.

But like it always happens, because protocol-level changes are slow, hard to implement and even harder to standardize, a wave of external solutions tends to emerge in the meantime to address today's problems. In fact, that’s arguably how the entire interoperability niche was born: Ethereum’s slow finality and the seven-day settlement period for rollups created a massive opening for third-party bridges to step in and offer faster, more usable ways to move assets across chains. The same pattern is playing out here. Resource lock machines with trusted allocators might be the best solution we have right now, even if a more elegant answer technically exists at the token level.

2. The Off-Chain Surface Area

Many implementations of resource locks rely on offchain coordination. This creates multiple risks:

Solvers may mistakenly assume resources are locked when they aren’t, leading to potential losses.
The state of locked balances is not globally visible and only the allocator has access to it, reducing transparency and increasing the likelihood of griefing or misallocation.
Failure modes are harder to detect or recover from, as the guarantees shift to offchain logic that may be closed-source, mutable, or centrally operated.

Resource locks shift critical execution and trust guarantees from the chain to a trusted machine. To earn their place as a foundational primitive for interop and more broadly, the crypto space, these systems must evolve into true credible commitment machines.

In order to do that, observability – "the ability for all parties to verify commitments" as outlined in Schelling’s theory of credible commitment, is essential. If resource locks are to deliver on their promise, they must progress toward trustless systems where logic, state, and guarantees are transparent and verifiable.

So far we’ve looked at what resource locks are and how resource-lock intents can help solvers manage capital more efficiently and operate with fewer risks and resources. But that’s only half of the story. At the end of the day, what really matters is the user experience. In the next section, we’ll explore the form factors resource locks are taking across the interop ecosystem, and how these are shaping the way users engage with cross-chain activity, whether they realize it or not.

Resource Locks for Interop

While the term “resource lock” may be new, the underlying idea isn’t. Escrow contracts have been a foundational primitive in interoperability from the very beginning. Resource locks can be thought of as the next evolution of that concept: generalized, programmable escrows built at the account-level to solve a broader and more nuanced set of user experience problems in the modern multi-chain crypto landscape.

One of the earliest examples is the Hashed Time-Locked Contract (HTLC), used in atomic swaps. It was simple: both sides of a trade locked up funds on their respective chains, and either the swap happened atomically, or not at all.

In essence, these HTLCs functioned as a simple yet effective form of resource lock: they committed specific tokens for a predefined purpose (the swap), ensuring their availability of funds for the counterparty and preventing their double-spending until the specific conditions (secret revelation or timelock expiry) were met. This design was used by Connext in their early iterations, where their network of “routers” (think solvers) would leverage HTLCs to front liquidity on the destination chain, knowing they could safely claim funds on the source chain once the secret was revealed.

Over time, that idea has evolved. Today, resource locks are primarily seen in two form factors: traditional escrow contracts and the rapidly emerging account-based contracts:

Escrow Based

Escrow contrasts are smart contracts that hold and manage user funds under predefined conditions. Whether it’s a lock-mint bridge, a burn-mint bridge, or an intent-based system, the pattern is the same: users move assets out of their wallet and into an escrow contract that guarantees availability until the process is complete. These are effectively the precursors to Resource Locks today.

This model powers token standards like LayerZero’s OFT, Wormhole’s NTT, Chainlink’s CCT, and Hyperlane’s Warp Tokens. These designs are essentially global accounting systems that use escrow to preserve a consistent supply of tokens across chains, with the token issuers effectively allocating a certain portion of the total supply for each chain and maintaining that balance through rate limits.

Circle’s CCTP V2 and Circle Gateway go one step further. Both initiatives function as a highly efficient and centralized resource management system for USDC's global supply across chains and describe their process as a more explicit "resource lock flow". They also introduce concepts like fast transfers, global allowances, and unified balances, all backed by off-chain attestations and rate limits.

Intent teams are also shipping a new class of escrow-based products that enable the general public to provide liquidity for solvers. These systems allow anyone to deposit assets into specialized smart contracts, such as Relay’s Vaults or Nomial, which solvers can then draw from to fulfill intents. In return, liquidity providers earn yield on their deposited assets. The yield for depositors can come directly from solver activity (e.g., through fees earned during intent execution) or from external sources like lending protocols (e.g., Aave, Morpho) where idle assets are simultaneously deployed. This model helps solve capital efficiency issues for solvers and enables faster rebalancing across chains. Then there’s Eco’s Crowd Liquidity, aimed at sourcing stablecoin liquidity for intents through a hybrid approach that combines pooled capital with account-like control to route solver liquidity more efficiently.

However, there’s a bigger shift happening from escrow-based resource locks to account-based resource locks. It is this category where a significant strategic bet is being placed by wallet infrastructure teams (both old and new), intent teams, and solver teams. This investment stems from a shared belief that the crypto ecosystem is poised for a fundamental shift from "chain-first" (where users must be aware of and navigate specific chains) to "asset-first" (where users simply interact with their assets and apps, regardless of their underlying chain) or even just “action first” (where in some cases the user may not only be chain agnostic, but also asset agnostic to take a given action).

The Compact

Somewhere between traditional escrow contracts and full-blown account-based systems sits The Compact — a new design space for programmable, reusable resource locks.

Developed by Uniswap Labs, Rhinestone, and LI.FI, The Compact is an ownerless ERC-6909 smart contract that allows users to deposit tokens and create a reusable “resource lock” that can be activated across chains. What makes it interesting is its modularity: users can assign roles like allocator, arbiter, reset period, and a fallback verifier called the emissary. These roles govern who can execute, validate, and unlock the funds — giving developers fine-grained control over how and when resources move.

The Compact is already being used in production. Rhinestone, for example, has integrated it into their Omni Account system which builds on EIP-7702 to enable temporary smart accounts. In this setup, Rhinestone self-hosts the allocator, uses LI.FI’s Intents and other intent systems to find solvers and customize the arbiter logic to validate fulfillment. Other examples include LI.FI’s, which integrates The Compact through its intent system. This setup gives teams the flexibility to define their own allocators and arbiters, while also unlocking added functionality like customizable order types and other modular features based on specific use cases. Additional examples include CompactX, a cross-chain swap demo, and Tribunal, a framework for selecting arbiters that handle settlement verification.

While still technically escrow-based (tokens are deposited into a contract), The Compact is like the bridge between escrow contracts and the emerging world of account-based resource locks. That’s because it’s being built in close collaboration with account providers like Rhinestone and interop teams like LI.FI, allowing it to integrate more deeply with smart accounts and support more native intent fulfillment.

Account Based

While the concept of locking resources in crypto dates back to traditional escrow contracts, account-based resource locks represent a fundamentally new form factor.

As many in the account abstraction space will tell you, this evolution is made possible by the post ERC-4337 world, where user wallets evolve from static EOAs into fully programmable smart accounts. This programmability allows developers to embed internal logic, like a resource lock module, directly into the wallet itself, a capability that simply didn't exist before. It created the blueprint for the modern smart account.

This new model underpins the work of teams like OneBalance, Rhinestone (with omni accounts), Safenet and Particle Network (with universal accounts) to build a unified view of your assets across chains with one balance (a nod to whoever named OneBalance), no matter where your funds actually live. In this model, instead of transferring funds to an external escrow contract, the lock is enforced within the account’s own programmable logic, preserving user custody and enabling richer functionality.

An obvious hurdle for this design is the adoption deadlock facing smart accounts due to the cold-start problem:

users stick with EOAs out of habit.
apps don’t prioritize smart account compatibility due to low adoption.
devs hesitate to build advanced smart account features without clear demand.

This is where EIP-7702 comes in as the bridge. It solves the cold-start problem by allowing existing EOA wallets to use the new smart account features on-demand, for specific transactions, removing the need for users to migrate.

And adoption is beginning to increase, slowly but surely:

The embedded wallet space has been an aggressive early adopter of smart accounts, with full compatibility for standards like EIP-7702 and ERC-4337. As adoption of players like Privy and Dynamic grows, the new wave of apps launching with them are shipping smart account functionality from day one.
EIP-7702 is officially part of the Ethereum protocol since the Pectra upgrade.
Major wallet providers, including MetaMask and others, have started rolling out support for EIP-7702. However, this is largely on an opt-in basis - which continues to be a big point of friction for adoption.

Account-based resource locks are quietly becoming one of the fastest-growing sectors in crypto. They reshape how users spend onchain and promise to offer a totally different mental model of accessing the crypto ecosystem—one that only focuses on the assets and the actions a user wants to take, and where chains are relegated to background settlement of the transaction (unless of course the user is opinionated about the particular chain). Moreover, they also open the door to credit-based systems in crypto, like the buy now, pay later mechanisms – where settlement can be deferred, just like how Visa or Mastercard work today.

That’s why so many teams are betting on an account-based future for crypto, one where resource locks are a key part of the foundation.

Why LI.FI is Building a Resource-Lock Aware Intents System

Crypto is moving from a chain-first world to an asset-first one. In this world, users don’t think in terms of chains, they think in terms of what they want to do with their assets. And to reach that future, we need two things: an account-based mental model and technology that enables expressive, generalized intents.

LI.FI Intents is purpose-built for this world: powered by intents, designed to integrate seamlessly with resource locks, and engineered to unlock fully expressive onchain interactions through smart accounts.

Combined with LI.FI Zaps, it’s one click to execute anything, anywhere. That’s where crypto UX is headed and we’re building the rails to get there.

The details are in the docs: LI.FI Intents.

Thank you to Mark Murdock and Damian Alvarez for the edits and valuable input. Also a big thank you to Kurt Larsen, Ryne Saxe, Jim Chang, Ankit Chiplunkar, and the Sprinter team for reviewing the article and sharing their thoughts.

LI.FI: Intents Are Taking Over; Resource Locks Make Them Scale