Resource Lock Hook

Interop is all resource locks. It always has been and always will be. Since the inception of DeFi and token bridges, escrow contracts have been used as a foundational component to onchain lending, borrowing, and cross-chain liquidity. Escrow contracts are resource locks. They protect counterparties from user equivocation while maintaining self-custody by limiting the withdrawal and claim conditions.

Chain Abstraction has introduced a new form factor for resource locking: account-native resource locks powered by account abstraction. These locks enable low latency and atomic cross-chain intents — no bridges, no gas. However, account-native resource locks can enable so much more.

This article covers the different forms of resource locks and dives into how Rhinestone aims to enable composable resource locks for any emerging product use case, not just cross-chain intents.

TL;DR

In Q1 2025, Rhinestone will launch a new system for account-native resource locks. At its center is the Resource Lock Hook. This module enables any specialized execution layer to integrate with ERC-7579 accounts and seamlessly execute any intent through a single signature.

The existing account-native resource lock models (co-signer and escrow) have many trade-offs that either deteriorate the user experience or compromise the composability and interoperability of the user’s Smart Account. The Resource Lock Hook combines the best of both worlds to offer a trust-minimized, highly composable, and interoperable resource lock. We believe this approach will become the foundation for many applications that seamlessly integrate with a single locked balance. There is no separation of funds or requirement for a root signature validator module that co-signs all transactions.

What are Account-Native Resource Locks?

Account-native resource locks (herein, just “resource locks”) utilize Smart Accounts to bring onchain guarantees to the user account, creating equivocation and finality protection for any type of execution or intent the user expresses via a single signature. The user opts into censorship under specified conditions as an enabler for external counterparties. If session keys are positive permissions — i.e., the ability for a user to grant ephemeral and scoped keys — resource locks are negative permissions where the user opts into conditional censorship, giving other actors the guarantee that a user cannot do certain actions.

Resource locks allow users to express any intent to a specialized execution layer without the strict requirement of atomizing settlement. This allows for execution that is incredibly fast and perceived as atomic from the user’s perspective. However, negative permissions can be used in many new applications, such as account-native credit systems where collateral is resource-locked, off-chain order books with lightning-fast execution and delayed settlement on the account, and many more. If resource locks can be built in a generalizable and composable manner, they can become a critical Lego block for any developer building on Smart Accounts.

Current Forms of Resource Locking

There are currently two popular forms of resource locking. Each has its pros and cons.

• Co-signer: An offchain system co-signs all transactions only if those transactions do not violate a pre-committed guarantee to a counterparty.
• Escrow: Funds are moved to a separate contract with user access restricted to provide guarantees to external parties.

Co-signer

In the context of Smart Accounts, a co-signer is installed as a (Signature) Validator Module on the account. This Validator Module can be a Passkey or an ECDSA validator, but importantly, the validation only passes if the user and the co-signing system supply a valid signature. The resource locks occur within an offchain system that issues signatures per an accounting model that listens to user intents, records liabilities against the user’s assets, and only signs if an intent does not violate a commitment already made by the user.

There are many approaches to running these co-signer entities with lower trust requirements, such as MPC and TEEs, but this is not the focus of the article.

Advantages of the Co-signer Approach

The advantage of this approach is that the complexities of managing resource locks are taken offchain, and with every user action (cross-chain intent or not) flowing through this root validator, it’s simpler to manage security threats that would allow the user to double-spend the system. For example, the co-signer can block all account upgrades and module in/uninstall transactions if it deems it a threat to a pending commitment. This approach also ensures that assets are not separated or wrapped in a new contract with restricted withdrawal conditions — a quality-of-life feature for applications reading and tracking balances associated with a user’s account.

Disadvantages of the Co-signer Approach

The downside of the co-signer approach is that every transaction from the account must be reviewed and verified by this offchain system. This is a high trust barrier for some and can introduce censorship and liveness risks, but onchain escape hatches can remedy this. The more significant externality of all userOp validations going through a co-signer is that it limits the composability of the Smart Account. All Validator Modules installed on the account must have the co-signer integrated. Every interaction with these Validator Modules must also be integrated with the co-signer (so that the co-signer is not blind to requests going through the account). This is highly restrictive for any developer building on Smart Accounts and looking to utilize features enabled by modules.

Escrow

The escrow model moves the resource locking mechanism onchain. The user’s assets are moved to an escrow contract with scoped withdrawal conditions for users and scoped claim conditions for any counterparty performing executions on the user’s behalf. The Compact, developed by 0age from Uniswap, is an example.

Advantages of the Escrow Approach

The core benefit of the escrow approach is that it isolates the resource locking to a purpose-built contract. Smart Accounts are built to give users maximum access and control over their assets. Resource locking within the Smart Account requires greater complexity onchain to ensure dishonest users cannot double-spend the system. Locking assets within an escrow also maintains maximum composability and interoperability of the Smart Account. For example, no restrictions exist on the Validator Modules installed on the account; innovations like Smart Sessions will continue to work out of the box. Finally, the escrow approach is flexible regarding its trust model. Users are not required to lock all funds, only the assets required for chain abstracted intents or other resource lock-enabled applications.

Disadvantages of the Escrow Approach

Escrows require an extra deposit step from the Smart Account. This step must be abstracted for this model to feel “account-native.” Over time, users will come to expect their entire balance to be chain abstracted, and for this to be true, their entire balance must permanently reside in an escrow. This requires automated deposits into the escrow as soon as funds hit the account and the synchronization of valid signatures between the Smart Account and the escrow (to ensure a user can’t rug a solver by invalidating the signature after execution but before the claim event). In essence, the escrow becomes the account with the Smart Account as a privileged signer. This has knock-on effects on the design space for Modular Smart Accounts x resource locks that are under-explored (at least in the public domain).

The application data read problem under the escrow model is arguably worse than the co-signer approach (at least in the short term). While the total spendable balance will be wrong under both approaches (apps do not currently query multiple chains for balance), with an escrow approach, new wrapped versions of existing tokens must be widely recognized as equivalent, or services, like indexers, must be aware of these escrows.

Introducing: The Resource Lock Hook

The ideal resource lock model takes the best of both worlds.

• A flexible trust model
• No asset separation
• Maintains Smart Account composability and interoperability

At Rhinestone, we’re developing a new resource-lock model utilizing Hook Modules on the Smart Account. Hook Modules augment a Smart Account’s execution flow by hooking in pre- or post-execution and enforcing conditions or any custom logic against the execution. The Resource Lock Hook is a Smart Account Module that hooks into every execution and checks a simple invariant: will the execution, any approvals made during execution, reduce the account balance below the resource locked amount? If false, the Resource Lock Hook allows the transaction to pass. If true, the transaction will only pass with a signature from an offchain sequencer that performs a similar function to the co-signer discussed above (or an “Allocator” in the case of the Compact).

A flexible trust model

The Resource Lock Hook allows users to either perpetually lock all assets, partially lock, or lock just in time. This provides a full spectrum of options ranging from higher trust (a signature required for all transactions) with the cleanest UX to low trust with slower execution. The module only requests a signature from an offchain sequencer when the module deems that the transaction violates a resource lock. The co-signing behavior is limited to locked funds, with an onchain escape hatch to exit the system.

No Asset Separation

This new resource lock approach inherits the escrow’s flexible trust model without separating the user’s funds into a new contract. Although it can be argued that this is semantics — for example, ERC-20 tokens are stored in ERC-20 contracts with owner addresses and balances — it will remain a short-term coordination problem to ensure that new token wrapping standards for accurately reading and tracking user balances are adopted.

Composability and Interoperability

The Resource Lock Hook is unintrusive to the standard operations of a Modular Smart Account. The user can extend the account with any module, uninterrupted by the co-signing mechanism. This includes all core ERC-7579 modules, Smart Sessions, and any innovations on the horizon, such as Biconomy’s MEE, ZK Emails recovery module, or Superforms DeFi automation modules.

The Need for Offchain Sequencing

All resource locking solutions require an offchain accounting system that ensures users can not double-spend a counterparty. For a resource locking system to be genuinely composable and interoperable, the locked funds should be readily available to any specialized execution layer — rather than be married to one use case. For example, consider a simple debit card proposition that utilizes resource locks. A user should expect that their funds are equally available to both spend IRL via Visa payment rails and cross-chain on any network. They should not have to silo assets into use case-specific locks. For this to be true, the onchain and offchain locking system must be modular and composable — more on this soon^TM.

Conclusion

The solution space for resource locking and Chain Abstraction is rapidly expanding. The Resource Lock Hook evolves existing models to provide developers with a composable building block fully compatible with existing Smart Account features and infrastructure. In Q1 2025, the Resource Lock Hook and accompanying foundational components will be launched to chain abstract any ERC-7579 Smart Account. This system is already in beta and ready for early adopters. Reach out for more information.

Follow us

• On X @Rhinestonewtf
• By email gm@rhinestone.wtf
• Check out our website and docs