Arbiter Smart Contracts: Three Contracts for Consensus

Arbiter deploys three main contracts on Base L2 to provide consensus infrastructure. Each contract has a specific role: configuration, finality, and economic security.

The Three Contracts

ArbiterRegistry

Purpose: Store swarm configurations and verify membership

How it works:

• Swarm configurations stored as Merkle roots
• Membership verification via Merkle proofs
• Agents prove membership without revealing full configuration
• Efficient for large swarms (only root stored on-chain)

Use cases:

• Verify agent is in swarm before allowing operations
• Check swarm configuration without reading full data
• Update membership without rewriting entire configuration

ArbiterFinality

Purpose: Provide authoritative source of truth for leadership and locks

How it works:

• Leadership proofs with term numbers
• Fencing token registry (globally monotonic counter)
• Other contracts query this for authoritative state
• Resolves disputes about leadership or lock ownership

Use cases:

• Verify current leader and term number
• Check if lock is held and by whom
• Validate fencing tokens
• Resolve split-brain scenarios

ArbiterStaking

Purpose: Economic security for Sybil resistance

How it works:

• Agents deposit stake (USDC on Base)
• Stake determines voting weight
• Byzantine behavior creates slashing evidence
• Malicious agents lose stake

Use cases:

• Weight votes by economic investment
• Prevent Sybil attacks (creating many fake agents)
• Penalize malicious behavior
• Align incentives (agents with stake act honestly)

How They Work Together

Registration: Swarm created, configuration stored in ArbiterRegistry as Merkle root

Staking: Agents deposit stake in ArbiterStaking, receive voting weight

Operations: Agents perform consensus operations off-chain (fast, cheap)

Finality: Critical state recorded in ArbiterFinality (slow, expensive, permanent)

Disputes: On-chain state in ArbiterFinality resolves conflicts

Why Three Contracts?

Separation of concerns: Each contract has a single responsibility. Easier to understand, audit, and maintain.

Gas efficiency: Only query what you need. Don't pay gas for data you don't use.

Upgradeability: Contracts can be upgraded independently. Fix bugs or add features without touching other contracts.

Composability: Other contracts can integrate with specific parts. A governance contract might only need ArbiterFinality.

Integration Example

solidity
// Another contract verifies leadership
contract MyContract {
    ArbiterFinality public arbiter;
    
    function onlyLeader(address swarmId) view {
        require(
            arbiter.isLeader(swarmId, msg.sender),
            "Not the leader"
        );
        require(
            arbiter.getTerm(swarmId) >= currentTerm,
            "Stale term"
        );
    }
}

Other contracts can query ArbiterFinality to verify leadership, check locks, or validate fencing tokens.

Why This Matters

Three contracts enable:

• Modular design: Each contract has clear purpose
• Gas efficiency: Only pay for what you use
• Composability: Other contracts can integrate easily
• Upgradeability: Fix bugs without breaking everything

Without this architecture, consensus infrastructure would be monolithic and inflexible. With it, Arbiter provides composable, efficient consensus.

---

Part of the EchoRift infrastructure series. Learn more about Arbiter.