| Abstract | |||
|---|---|---|---|
Recent agent-related ERCs have defined the identity (8004/8239), authorization (8118), and escrow (8183) layers of the agent economy. ERC-8203 explores conditional settlement flows; the Autonomous State Gateway (ASG) focuses earlier in the stack, standardizing the routing of off-chain solver outputs into a verifiable, settlement-ready state.
ASG treats off-chain work as a Proposed State Transition. It defines a domain-neutral gateway where agent outputs – whether code patches, vulnerability proofs, model context updates, dataset transformations, or strategy updates – are committed, collateralized, and verified before final settlement.
W̲h̲y T̲h̲i̲s̲ M̲a̲t̲t̲e̲r̲s̲ N̲o̲w̲
The agent ERC stack is standardizing identity and commerce faster than it is standardizing execution handoff.
We are entering a period where agents will produce high-value, off-chain results that are economically sensitive before they reach the ledger. Without a standard routing layer, the ecosystem faces fragmented, ad hoc verifier gateways for every marketplace. ASG gives this middle step a standard shape:
Off-chain Result → Collateralized Commitment → Verifier Attestation → Dispute Window → Settlement
Architecture: Core / Profile Split
ASG is layered to allow for a domain-neutral engine with domain-specific interpretations.
1. ASG Core (The Gateway)
The Core defines the common state machine and economic constraints.
# Vyper-style pseudocode
struct StateTransition:
proposer: address
domain: bytes32 # e.g. REPOSITORY, MODEL_CONTEXT, DATASET
job_id: bytes32
commitment: bytes32 # keccak256(state_root, salt, proposer, job_id)
state_root: bytes32 # revealed after commit
evidence_hash: bytes32
evidence_uri: String[256]
collateral_reserved: uint256
verifier_type: bytes32 # e.g. TEE, CI, MAINTAINER, ZK
settlement_target: address
Core invariants:
- A revealed state_root must match a prior commitment.
- A transition cannot settle unless collateral was reserved.
- A verifier attestation must bind job_id, proposer, state_root, verifier_type, chain_id, and gateway address.
- The earliest valid commitment has primary claimant priority.
- Settlement and slashing are terminal states.
2. ASG Profiles (The Domain)
Profiles define how a domain interprets the state_root.
-
Profile A: Repository State
state_root is the hash of a repository patch, PR head commit, or commit delta. -
Profile B: Vulnerability Proof
state_root hides an exploitable proof until collateral and ordering are anchored. -
Profile C: Model Context Update
state_root is the hash of the resulting context bundle after applying a proposed update. -
Profile D: Dataset Transformation
state_root represents the Merkle root of the transformed dataset. -
Profile E: Strategy State
state_root is the hash of a proposed action plan, such as a DeFi rebalance or execution strategy.
Submission Flow: The Gateway Path
1. Commit
A solver hashes the state_root with a salt and reserves collateral. This reduces payload copying before ordering is established.
2. Reveal
The solver discloses the state_root and supporting evidence after the commitment is anchored.
3. Verify
The gateway routes the payload to pluggable verifiers. The reference implementation is TEE-first, while ASG Core treats verifier types such as CI, ZK, maintainer signature, and multisig evaluators as pluggable.
4. Dispute
A temporal window opens for challenges, duplicate validation claims, or arbitration requests. Earliest valid commitments retain primary priority; duplicates do not automatically split the payout.
5. Settle / Slash
Final state is routed to the settlement_target. Accepted transitions settle; invalid or fraudulent transitions may be slashed.
Implementation Pressure / Reference Work
This draft is derived from implementation pressure, not theory. The first reference implementation, maceip/asg-genesis, originated from earlier work on agent-submitted repository improvements and collateralized review flows.
Example reference flow:
- A solver finds a security patch against a repository.
- The solver commits the patch hash and reserves collateral from a virtualized internal ledger. This is efficient for high-frequency workflows, though ASG Core can also support direct ERC-20 transfers, Permit2 pulls, and paymaster-backed reservations.
- The solver reveals the patch root after ordering is anchored.
- A TEE verifier runs the repository audit policy against the patch.
- If accepted, a dispute window opens.
- If unchallenged, ASG routes the transition to the settlement contract.
- If automated verification is inconclusive, a maintainer-signed arbitration path resolves the transition.
Open Questions
1. Queue Scope
Should congestion stake be calculated per repository, per job, per verifier, or globally?
required_stake = base_stake * multiplier ^ unresolved_queue_depth
Should the curve be exponential, linear, sigmoid, or auction-based?
2. Signature Standards
Should ASG mandate EIP-712 for verifier attestations to ensure better domain separation and tooling clarity, or allow EIP-191 for simpler verifier integrations?
3. L1 vs L2
Given the multi-step flow of commit, reveal, verify, dispute, and settle, is ASG practically restricted to high-throughput L2s, or are some high-value solver outputs worth L1 settlement?
4. Profile Registry
Should ASG Core maintain a registry of approved profile schemas, or remain a dumb gateway that only routes bytes and attestations?
5. Slashing Logic
Should the gateway execute profile-specific slashing logic directly, or route slash signals to the settlement_target?
Boundary Statement
ASG does not define agent identity, skill taxonomy, verifier internals, payment-channel lifecycle, or marketplace UX.
It defines the Gateway Path:
Commit → Collateral Reserve → Reveal → Verify → Dispute → Settle/Slash
That is the one thing ASG owns.