Arbiters

Arbiters are entities responsible for verifying and submitting claims against resource locks in The Compact protocol. When a sponsor creates a compact, they assign an arbiter per chain. That arbiter is the sole account that can trigger a claim against the compact on the respective chain and determines which accounts receive the locked balances and in what amounts.

Role and Responsibilities

Arbiters serve as intermediaries between sponsors and claimants with these key responsibilities:

Arbiter Selection

Arbiters are specified per compact or per element (in multichain compacts):

Single and batch compacts

struct Compact {
    address arbiter;    // The designated arbiter for this compact
    address sponsor;
    uint256 nonce;
    uint256 expires;
    // ...
}

Multichain compacts

struct Element {
    address arbiter;    // Can be different per chain
    uint256 chainId;
    Lock[] commitments;
    Mandate mandate;    // Required for multichain
}

Specifying Claimants

When submitting a claim, arbiters specify claimants through a Component struct that encodes both the recipient and the destination format:

struct Component {
    uint256 claimant;  // Encodes both lockTag and recipient address
    uint256 amount;    // The amount of tokens to claim
}

Claimant encoding

The claimant field packs two pieces of information:

Destination options

Based on the lockTag in the claimant field, arbiters can direct claimed resources to three different destinations:

1. Direct transfer (keep as ERC6909)

When the lockTag matches the original resource lock's tag, the ERC6909 tokens are transferred directly to the recipient. This maintains the same lock properties (allocator, reset period, scope).

2. Convert to new resource lock

When the lockTag is non-zero but different from the original, the tokens are converted to a new resource lock with different properties. This allows changing allocators, reset periods, or scopes while keeping funds locked.

3. Withdraw to underlying token

When the lockTag is bytes12(0), the ERC6909 tokens are burned and the underlying tokens (native or ERC20) are withdrawn to the recipient. This fully exits The Compact system.

Example

// Example: Arbiter specifying three different destinations
Component[] memory claimants = new Component[](3);

// Direct transfer - keep same lock properties
claimants[0] = Component({
    claimant: uint256(uint160(alice)) | (uint256(originalLockTag) << 160),
    amount: 100e18
});

// Convert to new lock with different allocator
claimants[1] = Component({
    claimant: uint256(uint160(bob)) | (uint256(newLockTag) << 160),
    amount: 50e18
});

// Withdraw to underlying token
claimants[2] = Component({
    claimant: uint256(uint160(charlie)), // lockTag is 0
    amount: 25e18
});

Submitting Claims

Arbiters submit claims using one of six available claim functions based on:

Single-chain claims

claim (Compact)

For single resource lock on a single chain:

function claim(Claim calldata claimPayload) external returns (bytes32 claimHash)

batchClaim (BatchCompact)

For multiple resource locks on a single chain:

function batchClaim(BatchClaim calldata claimPayload) external returns (bytes32 claimHash)

Multichain claims

multichainClaim (MultichainCompact - Notarized)

For single resource lock on the notarized chain (domain matches signature):

function multichainClaim(
    MultichainClaim calldata claimPayload
) external returns (bytes32 claimHash)

exogenousClaim (MultichainCompact - Exogenous)

For single resource lock on exogenous chains (not the notarized chain):

function exogenousClaim(
    ExogenousMultichainClaim calldata claimPayload
) external returns (bytes32 claimHash)

batchMultichainClaim (BatchMultichainClaim - Notarized)

For multiple resource locks on the notarized chain:

function batchMultichainClaim(
    BatchMultichainClaim calldata claimPayload
) external returns (bytes32 claimHash)

exogenousBatchClaim (BatchMultichainClaim - Exogenous)

For multiple resource locks on exogenous chains:

function exogenousBatchClaim(
    ExogenousBatchMultichainClaim calldata claimPayload
) external returns (bytes32 claimHash)

Trust Model

For sponsors

Sponsors trust arbiters to:

For claimants

Claimants trust arbiters to:

Arbiter Authorization

When an arbiter submits a claim, The Compact verifies authorization in this order:

1. Arbiter is Caller: The msg.sender must match the arbiter specified in the compact
2. Claim Validity: The claim must be valid (not expired, correct nonce, etc.)
3. Sponsor Signature: The sponsor's signature must authorize the compact (unless registered)
4. Allocator Authorization: The allocator must approve the claim

Best Practices

For arbiter selection

For arbiter implementation

Common Patterns

Automated arbiters

Smart contracts can act as arbiters to provide trustless claim verification:

Arbiter networks

Multiple arbiters can be coordinated through:

Error Handling

Common arbiter-related errors:

Events

Key events related to arbiter actions:

event Claim(
    address indexed sponsor,
    address indexed allocator,
    address indexed arbiter,
    bytes32 claimHash,
    uint256 nonce
)

Security Considerations

Arbiter compromise

Arbiter censorship

Front-running protection