# 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:

```solidity
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`.

```solidity
function consumeNonceAsAllocator(uint256 nonce, address allocator) internal {
    _consumeNonce(nonce, allocator, _ALLOCATOR_NONCE_SCOPE);
}
```

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

```solidity
struct Compact {
    address arbiter;
    address sponsor;
    uint256 nonce;
    uint256 expires;
    uint256 id;
    uint256 amount;
}
```

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 `Sponsor`s' 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.