Resource locks allow users to commit tokens to something or someone without making an on-chain transaction to issue the lock or recover the lock after its expiry. In a resource-lock context, it is important that these tokens are inaccessible for a certain period, longer than the expected settlement time for a claim.
In a sense, they are a form of credit account allowing users to provide guaranteed allowances to protocols.
Actors
In a resource lock flow, there are three actors:
- Sponsor, user, owner: The actor that initially owns the funds in the resource lock.
- Allocator, manager, credible commitment: The actor that validates that no conflicting locks are issued.
- Arbiter, validator, settlement: The actor that is capable of validating whether a lock has been resolved and can be paid.
Depending on the resource lock system, each user chooses an allocator, and each lock chooses the arbiter. When the term “the arbiter” is used, it refers specifically to the arbiter of a lock, not to a general single arbiter that the user has chosen.
Think of a lock as a time-bound approval, co-signed by an allocator, to a specific protocol (arbiter).
While resource lock flows can look very different depending on the application, they generally follow four steps:
-
The sponsor makes a deposit into a resource lock, if one does not already exist.
-
The sponsor signs a lock that describes a desired outcome.
-
The allocator ensures that the appropriate funds exist for the lock to be valid. In other words, if the sponsor has deposited 10 tokens, no set of approved locks shall exceed 10 tokens. The allocator then co-signs the lock.
-
The desired event takes place.
-
The arbiter validates that the event has taken place and releases the token to the appropriate recipient.
In this flow, two signatures and one transaction – ignoring the 0th step – are required. The lock has to be signed by the sponsor and co-signed by the allocator. Then the arbiter makes the final call on whether the desired event took place.
Resource-Locked Intents
In an intent system, the third step – the execution of the desired event – is usually performed by a fourth actor, often referred to as either the solver or the relayer.
Additionally, there are generally two ways to build intent systems around resource locks:
Intent system as executor (Tribunal)
In these flows, the intent system describes how the action takes place on the destination chain. However, the system does not directly validate the resource lock completion.
These systems instead rely on allocators as arbiters or resource lock support by general message passing (GMP) protocols.
The advantage of such a system is its simplicity. The third party (whether allocator or GMP) generally handles the entire validation/settlement pipeline, and thus solvers only have to concern themselves with filling orders.
Intent system as arbiter (Catalyst)
In these flows, the intent system is the arbiter and usually describes how the entire system is constructed: output settlement, validation, and input settlement. This makes the system more flexible and customizable.
While these systems may also rely on GMPs, they can also use other – potentially cheaper – validation layers like optimistic oracles, storage proofs, or secret reveals (like HTLCs).
The advantage of such a system is indirectly its complexity. Since more logic is explicitly defined by the system itself, the expressivity of intents can be greater and more specialized.
For more on the resource locks Catalyst supports, read the chapter on Input Settlement Implementations.
Trust Assumptions
In a resource lock system, the actors need to trust each other, but generally, no single actor can independently access any funds.
- The sponsor needs to trust the arbiter such that issued locks are not fraudulently finalized. However, the arbiter can never access any of the sponsor’s funds without a relevant signed lock. The trust assumptions between the sponsor and the arbiter are equivalent to permit/permit2 approvals.
- The arbiter/solver needs to trust that the allocator does not co-sign overlapping locks that exceed the tokens the user has deposited. Otherwise, a filled intent may not have enough tokens available to resolve the payment to the solver for the fulfillment of the lock.
