ArcSettle · USDC settlement on Arc

Prove the reserves, then settle. Never the other way.

A USDC settlement rail that physically cannot settle past what has been proven. Every settlement is checked against the signed proof-of-reserves attestation, on-chain and in the operator agent. Push past the gold line and the transaction reverts.

How it works

two layers, one invariant
Reserve oracle EIP-712 signed proof Operator agent reserve-aware, agent-core attestedReserves / ts propose settle Reserve gate supply+amt ≤ effective ? attestation fresh ? yes settle USDC Settled event no revert on-chain refuse off-chain every action agent-core ActionLimiter + audit trail

On-chain (ArcSettlement.sol): settle reverts with InsufficientReserves, StaleAttestation or FutureAttestation. Effective reserves are the attested USDC figure less any redemption the current attestation has not yet observed, so redeeming cannot reopen headroom. Off-chain: the agent runs the same check before broadcast, so it never wastes gas on a doomed tx, and every decision is recorded.

Settled supply / Proven reserves 0 / 1,000,000 USDC
RESERVES CAP
Settleable headroom 1,000,000 USDC
settled supply headroom proven reserves cap

Agent run trace

mirrors arcsettle propose_settle

    Contract event log

    Simulated, not a testnet receipt. This page runs the contract's gate logic in the browser, so there is no transaction hash and no block number to show, and it does not invent any. What is real and checkable: the event signatures, their argument lists, and the topic0 hashes below all come from src/ArcSettlement.sol. Run cast keccak "Settled(address,uint256,uint256,uint256,uint256)" to confirm. A refused settlement is shown the way a chain reports one, as an eth_call revert with the contract's own 4-byte error selector, not as an event, because a reverted transaction emits nothing.

    Ledger

    What am I looking at?