Overview
This is the formal Draft ERC for agent-native off-chain conditional settlement, evolved from the pre-RFC discussion.
Pull Request: Add ERC: Agent Conditional Settlement Interface by xrqin · Pull Request #1614 · ethereum/ERCs · GitHub
Problem
Existing agent-related ERCs cover identity, accounts, permissions, and payment signaling — but none define a common settlement layer for high-frequency machine-to-machine interactions.
Autonomous agents are natural state channel participants: always online, can sign and verify automatically, and actually benefit from liveness requirements that humans rejected. Yet there is no standard for how different wallets, hubs, relays, and adjudicators should represent and resolve proof-bound conditional obligations in an off-chain channel context.
What This ERC Standardizes
Three EIP-712 typed data structures:
| Structure | Purpose |
|---|---|
ConditionalLock |
The settlement envelope — who owes whom, how much, under what condition, with what |
| timeout | |
SettlementProofRef |
References the evidence used to settle a lock — proof type, digest, verifier address |
ClaimRelayRequest |
Allows a relay to submit a claim on behalf of an agent for privacy or convenience |
Canonical identifiers for two dimensions:
Condition types (conditionType) — what kind of condition must be met:
HTLC,ORACLE_ATTESTATION,ZK_PROOF,MULTISIG,TIMELOCK,COMPOSITE
Proof types (proofType) — what verification pathway to use:
RECEIPT_ROOT,ZK_PROOF,ORACLE_ATTESTATION,RELAY_CLAIM,MULTISIG_ATTESTATION,TEE_ATTESTATION
All identifiers use keccak256 over human-readable labels. Third-party extensions follow
keccak256("NAMESPACE.TYPE") — no ERC amendment needed to add new types.
A minimal on-chain extension interface:
function settleConditional(channelId, lock, proofRef, proof) external;
function refundConditional(channelId, lockId) external;
function lockStatus(channelId, lockId) external view returns (LockStatus);
function supportsConditionType(conditionType) external view returns (bool);
function domainSeparator() external view returns (bytes32);
Three optional extensions:
- Capability Discovery — hub advertises supported condition types, proof types, fee model
- Private Claim Relay — relay submits claims on behalf of agents
- Local Rebalancing Coordination — certificate format for capacity shifts between channels
What This ERC Does NOT Standardize
- Channel lifecycle (challenge, checkpoint, conclude, close, dispute)
- Custody and exit (deposit, transfer, reclaim)
- Routing or rebalancing algorithms
- Proof internals (ZK circuits, Merkle tree details, proof byte format)
- Application-layer protocols (jobs, orders, marketplaces)
- Hub economics (fees, collateral, solvency)
These are explicitly delegated to the host framework or left to implementation choice.
Key Design Decisions
Standalone companion, not coupled to any specific framework. This ERC composes with host frameworks like ERC-7824, but does not formally depend on them. Lifecycle and custody remain the host framework’s responsibility.
Happy path is off-chain at zero gas. The on-chain interface (settleConditional / refundConditional) is only invoked during disputes. Normal settlement completes via co-signatures without touching the chain.
Proof-system agnostic. proofType identifies the verification pathway (e.g., “use the verifier contract for a ZK proof”), not the proof internals (e.g., Groth16 vs. PLONK). This allows the proof ecosystem to evolve without breaking the settlement standard.
Open identifier registry. Canonical condition types and proof types provide interoperability out of the box.
New types can be added by anyone via the keccak256(“NAMESPACE.TYPE”) convention.
Changes Since Pre-RFC
Based on community feedback (thanks @Aboudjem):
- Added Proof Type Identifiers — six canonical proofType values with keccak256 open registry convention, preventing fragmented implementations
- Clarified standalone positioning — designed to compose with ERC-7824 and similar frameworks without formal coupling
- Scoped batch settlement out — settleConditional is a dispute-path hook; happy path is off-chain at zero gas. Batch finalization is better addressed at the host framework layer or as a future ERC
Reference Integration Pattern
- Agent negotiates a ConditionalLock with a hub off-chain
- Host framework binds the lock into its native state
- Hub executes or routes the requested action
- System produces a SettlementProofRef
- Happy path completes off-chain with co-signatures ← zero gas
- If dispute: host framework lifecycle + settleConditional / refundConditional
- If private claim: relay submits ClaimRelayRequest
Open Questions
- Should capability discovery be part of the core standard or remain an extension?
- Should the relationship to application protocols such as ERC-8183 be made more explicit?
- Should a future ERC define a canonical JSON schema for capabilityURI?
- Should relay fee settlement be standardized further?
- Should local rebalancing coordination be split into a dedicated ERC?
Looking For
- Feedback on the typed data structures and interface design
- Feedback on the canonical identifier sets (too many? too few? wrong categories?)
- Interest in contributing reference implementations or test vectors
- Perspectives from state channel / payment channel implementers
Full spec in the PR. Feedback welcome here or on GitHub.