Allocator
In TheCompact system, the Allocator plays a pivotal role in conditionally authorizing the use of deposited assets (Resource Locks). Acting as a trusted intermediary between the Sponsor (asset owner) and the Claimant (asset user/recipient), the Allocator enables functionality beyond simple time-delayed locks, facilitating programmable asset operations, cross-chain interactions, and intent-based processing.
Conditional Claim Authorization: The
Allocatorapproves asset usage viaCOMPACT.claim()only when specific conditions are met. This allowsTheCompactto create "Enforceable Commitments," which prevent users from arbitrarily disposing of locked assets while enabling programmatic execution through an authorized intermediary.AllocatorSignature Verification: TheAllocatorcryptographically proves its approval of a claim through its signature. When processing a claim,TheCompactcontract callsIAllocator.authorizeClaim()to validate this signature (or other proofs contained inallocatorData). This function verifies if theAllocatorultimately approves the claim and, upon approval, informsTheCompactcontract by returning its own function selector (IAllocator.authorizeClaim()). If verification fails, the transaction is reverted, halting claim processing. Off-chain, theIAllocator.isClaimAuthorized()function can be used to pre-check the validity of a claim.
Register Allocator
To use an Allocator in TheCompact, it must first be registered with TheCompact via _registerAllocator. An Allocator can be registered if it meets one of the following three conditions:
function canBeRegistered(address allocator, bytes calldata proof) internal view returns (bool) {
return (msg.sender == allocator).or(allocator.code.length > 0)
.or(proof.length == 85 && (proof[0] == 0xff)
.and(allocator == address(uint160(uint256(proof.hashCalldata())))));
}When
msg.senderis the same as the address of theAllocatorto be registered.When the
Allocatoris registered as a Smart Contract, or has code associated with it (e.g., per EIP-7702).When the
Allocatoraddress to be deployed viaCREATE2matches the hash of an 85-byte proof.
A registered Allocator is linked to a specific Resource Lock and provides a signature for Claim requests related to that Lock.
Nonce Management
In TheCompact system, nonces are managed dependently on each Allocator.
This means that when recording and checking the usage status of a nonce, the Allocator's address is primarily used as the reference. Such a design can lead to potential nonce collisions if different Sponsors use the same Allocator.
To address this potential nonce collision issue and segregate nonce spaces per Sponsor, exemplary off-chain Allocator implementations for TheCompact adopt a convention: the upper 20 bytes (40 hexadecimal characters) of the 256-bit nonce are fixed as the Sponsor's address, and the lower 12 bytes are used as a sequentially incrementing value within that Sponsor's context.
Before signing a claim request, an off-chain Allocator performs the following verification steps:
Checks if the upper 20 bytes of the submitted nonce match the address of the
Sponsorwho actually requested the claim.Verifies if the
Sponsor's signature (sponsorSignature) is valid and if the signer is the actual Sponsor.Confirms through an internal database (DB) or similar means that the nonce has not already been used.
Through these verifications, malicious users are prevented from arbitrarily consuming other Sponsors' nonces or causing nonce collisions. In essence, while the contract level maintains the flexibility of Allocator-dependent nonce management, security and individuality are enhanced at the off-chain Allocator level through Sponsor-specific nonce space separation and validation.
Last updated