Overview
The Allocator is the component responsible for authorizing withdrawals from Depository contracts. When a solver wants to claim funds they’ve earned by filling orders, the Allocator verifies their Hub balance and generates a cryptographic proof that the Depository will accept. The Allocator uses MPC chain signatures for signing, meaning no single entity holds the private keys needed to authorize withdrawals. It is governed by the Security Council, which can pause or replace it in an emergency.How It Works
The withdrawal authorization process:- Solver requests withdrawal — The solver specifies the target chain, asset, and amount they want to withdraw
- Balance check — The Allocator reads the solver’s balance on the Hub to confirm sufficient funds are available
- Payload construction — A chain-specific Payload Builder constructs the withdrawal request in the format the target chain’s Depository expects
- MPC signing — The Allocator requests an MPC signature from the NEAR chain signatures network. This generates a valid signature without any single party having access to the full private key
- Proof delivery — The signed withdrawal proof is returned to the solver, who submits it to the Depository contract on the target chain
Payload Builders
Different chains require different transaction formats. The Allocator uses specialized Payload Builders for each chain type:| Builder | Chains | Signature Format |
|---|---|---|
| EVM Payload Builder | Ethereum, Base, Arbitrum, Optimism, + all EVM chains | EIP-712 typed data |
| Solana Payload Builder | Solana, Eclipse, Soon | Ed25519 |
| Bitcoin Payload Builder | Bitcoin | ECDSA (secp256k1) |
| Sui Payload Builder | Sui | Ed25519 |
CallRequest for EVM, TransferRequest for Solana) with the appropriate encoding (ABI for EVM, Borsh for Solana).
MPC Signing
The Allocator uses Multi-Party Computation (MPC) chain signatures for withdrawal authorization. Instead of a single private key controlling access to Depository funds, the signing key is split across multiple independent MPC nodes. A threshold of nodes must cooperate to produce a valid signature — no single entity ever holds the full key. Key properties:- No single key holder — The private key is split across multiple MPC nodes, and a threshold must cooperate to produce a signature
- Programmable authorization — The Allocator enforces rules (balance checks, rate limits) before requesting any signature
- Chain-agnostic — MPC signing can produce signatures for any curve or format (ECDSA, Ed25519, etc.), enabling support for EVM, Solana, Bitcoin, Sui, and other VMs
- Auditable — All signing requests flow through an onchain contract, creating a transparent record
The MPC signing layer is designed to be implementation-agnostic. While NEAR chain signatures are used today, the architecture allows for alternative MPC networks or signing backends without changes to the rest of the protocol.
Security Model
The Allocator is a trust-critical component — it controls access to funds in the Depository. Several safeguards protect against misuse:- MPC signing — No single entity holds the full signing key. A threshold of independent MPC nodes must cooperate to produce a valid signature.
- Balance-bounded — The Allocator can only authorize withdrawals up to a solver’s existing Hub balance. It cannot mint new balances or alter the ledger.
- Security Council — A multisig that can pause all withdrawals with a single transaction, or replace the Allocator entirely.
- Replay protection — Every withdrawal proof includes a unique nonce and expiration timestamp, preventing reuse of stale proofs.
Source Code
The Allocator contract (RelayAllocator.sol) is part of the settlement-protocol repository.