Periphery Contracts

Last modified: April 16, 2026

Emissaries

Emissaries provide a fallback verification mechanism for sponsors authorizing claims. They are particularly useful for:

1. Smart-contract accounts that may update their EIP-1271 signature-verification logic.
2. Accounts using EIP-7702 delegation that leverages EIP-1271.
3. Sponsors who want to delegate claim verification to a trusted third party.

A sponsor assigns an emissary for a specific lockTag via assignEmissary. The emissary must implement the IEmissary interface.

To change an emissary after one has been assigned, the sponsor must first call scheduleEmissaryAssignment, wait for the resetPeriod associated with the lockTag to elapse, then call assignEmissary again with the new address (or address(0) to remove the emissary entirely).

IEmissary interface

interface IEmissary {
    function verifyClaim(
        address sponsor,
        bytes32 digest,
        bytes32 claimHash,
        bytes calldata signature,
        bytes12 lockTag
    ) external view returns (bytes4)
}

Must return IEmissary.verifyClaim.selector on success.

Assignment and management

Assigning an emissary

function assignEmissary(
    bytes12 lockTag,
    address emissary
) external

The assignment is scoped to a specific lockTag — sponsors can have different emissaries for different resource locks.

Changing an emissary

The mechanism includes a security timelock to prevent sudden authorization changes:

1. Schedule — call scheduleEmissaryAssignment for the target lockTag.
2. Wait — the resetPeriod associated with the lockTag must elapse.
3. Execute — call assignEmissary with the new address.

function scheduleEmissaryAssignment(
    bytes12 lockTag,
    address newEmissary
) external

To remove an emissary, assign address(0):

assignEmissary(lockTag, address(0))

The timelock ensures that emissary changes cannot suddenly alter authorization logic for outstanding compacts without adequate notice, protecting claimants who may already be acting on the existing emissary's authority.

Role in claim verification

When a claim is submitted for a non-registered compact, The Compact verifies the sponsor's authorization in order:

1. Caller is sponsor — msg.sender == sponsor grants immediate authorization.
2. ECDSA signature — standard signature verification.
3. EIP-1271 isValidSignature — called on the sponsor's address (if it is a contract) with half the remaining gas.
4. Emissary verifyClaim — if the above methods fail and an emissary is assigned for the sponsor and lockTag, it is invoked as a last resort.

Events

event EmissaryAssigned(
    address indexed sponsor,
    bytes12 indexed lockTag,
    address emissary
)

Trust assumptions

Sponsors must trust that emissaries will not authorize claims maliciously — an emissary has the same authorization power as the sponsor for claim verification.

Claimants must trust that emissaries (if assigned) will faithfully authorize valid claims. For EIP-7702 sponsors and smart contracts with upgradeable EIP-1271 logic, claimants should require known, canonical emissaries that enforce delays before allowing key rotation.

Tribunal

Tribunal is a framework for processing cross-chain swap settlements on PGA (priority-gas-auction) blockchains. It ensures tokens are transferred according to the originating sponsor's mandate and enforces single-party settlement in the event of a dispute.

About Tribunal Tribunal is a reference implementation, not part of The Compact core protocol. The Compact itself is an unopinionated primitive with no awareness of any specific settlement engine. Tribunal is documented here as an example of how developers can build cross-chain settlement systems on top of The Compact's resource locks.

Other teams can (and should) build their own settlement engines with different trust assumptions, auction mechanisms, or cross-chain messaging approaches. Tribunal shows one proven pattern for orchestrating cross-chain fills and settlements.

Status: Tribunal is actively under development. See the Tribunal repository for the latest.

How Tribunal works

Fillers call fill and supply any native value required for cross-chain messaging. Tribunal verifies expiry, chain IDs, and validity conditions, then computes hashes and amounts before executing the settlement:

• Transfers filled tokens to the intended recipient.
• Same-chain fills — claims tokens via The Compact and calls back into the arbiter or recipient.
• Cross-chain fills — emits or processes directives that instruct remote arbiters to pull the claim.

By enforcing a single settlement path, Tribunal eliminates disputes and ensures fairness even when multiple fillers compete.

Extending Tribunal

External bridge protocols extend Tribunal by overriding internal functions to implement directive-processing logic — either pushing a message to the arbiter on the claim chain or ensuring the necessary state is available for the arbiter to pull the message itself.