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 Allocator approves asset usage via COMPACT.claim() only when specific conditions are met. This allows TheCompact to create "Enforceable Commitments," which prevent users from arbitrarily disposing of locked assets while enabling programmatic execution through an authorized intermediary.

  • Allocator Signature Verification: The Allocator cryptographically proves its approval of a claim through its signature. When processing a claim, TheCompact contract calls IAllocator.authorizeClaim() to validate this signature (or other proofs contained in allocatorData). This function verifies if the Allocator ultimately approves the claim and, upon approval, informs TheCompact contract by returning its own function selector (IAllocator.authorizeClaim()). If verification fails, the transaction is reverted, halting claim processing. Off-chain, the IAllocator.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.sender is the same as the address of the Allocator to be registered.

  • When the Allocator is registered as a Smart Contract, or has code associated with it (e.g., per EIP-7702).

  • When the Allocator address to be deployed via CREATE2 matches 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:

  1. Checks if the upper 20 bytes of the submitted nonce match the address of the Sponsor who actually requested the claim.

  2. Verifies if the Sponsor's signature (sponsorSignature) is valid and if the signer is the actual Sponsor.

  3. 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