Hey team — great work on this standard. We’ve been building in the verification layer for decentralized AI compute and ERC-8004’s Validation Registry maps cleanly to what we’ve already shipped. (Can’t post links here :()
What we’ve built
AgentChain runs a stake-secured fault proof protocol on Base L2. The flow:
-
Client submits a compute task with a USDC escrow deposit
-
Worker claims the task, locks collateral, and returns a result with a state root commitment
-
Challenge window opens — any watcher can dispute
-
If disputed: a K-ary interactive bisection game narrows the disagreement to a single execution step (O(log₈N) rounds — 11 rounds for 4B steps)
-
One-step proof resolves the dispute. Loser is slashed; winner collects both bonds + escrow
This is the stake-secured-fault-proof trust model. We also mint EAS attestations on resolution — permanent, on-chain cryptographic proofs of verified compute.
How this maps to the Validation Registry
We’ve shipped an adapter contract AgentChainValidator on git humbleaf/agentchain-erc8004-adapter that bridges our BisectionCourt dispute engine to the ERC-8004 validationRequest / validationResponse interface:
validationRequest(validatorAddress, agentId, requestURI, requestHash)
│
▼
AgentChainValidator.acceptRequest() — authorized relayer only
│
▼
Routes to BisectionCourt.openDispute()
│ ... interactive fault proof game plays out ...
▼
AgentChainValidator.settleValidation() — permissionless, deterministic
│
├─→ validationResponse() on Validation Registry
└─→ giveFeedback() on Reputation Registry
Dual-bridge settlement: One settleValidation() call atomically writes to BOTH the Validation and Reputation registries. Each registry call is independently wrapped in try/catch — if one fails, the other still executes. The dispute resolution engine is never blocked by downstream registry errors.
-
response = 100→ dispute resolved in the worker’s favor (compute verified) -
response = 0→ worker proven dishonest (slashed) -
tag = "stake-secured-fault-proof"→ identifies the trust model -
responseURI→ points to the EAS attestation on Base L2
The adapter is verified on Base Sepolia - 0x6d092A889C88425A6c23fD6dbdc0c4Ab0C64b596 — you can inspect the source directly. We’ve also submitted a live test validation request 0x756b7947925ea94e951361aac29edbcb5b51712b45bf81eca335a2c05d3481c5 demonstrating the full acceptRequest → BisectionCourt.openDispute pipeline, which emits both DisputeInitiated and ValidationRequestAccepted events atomically.
Challenge window: 24 hours base (elastic up to 48h under L2 congestion). This is our production timeline — the dispute game is designed for high-value compute where a 24h challenge period provides adequate security. After the window expires, settleValidation() becomes callable by anyone (permissionless) to finalize the result into both registries.
This means any agent in the ERC-8004 ecosystem can request validation of any AI compute task through our protocol, and the result is:
-
Stored on-chain in the Validation Registry (per the ERC-8004 spec)
-
Scored in the Reputation Registry (positive/negative feedback)
-
Permanently attested via EAS (independently verifiable)
On the thread discussion
A few points from the conversation that resonated:
@spengrah — Re: on-chain composability. Agree 100%. Our BisectionCourt stores dispute outcomes in contract storage (disputeWinners mapping), and the EAS attestation is queryable by any contract. The getValidationStatus() read function in the Validation Registry would return live data, not just event logs. The escrow-release use case mlegls described (Alice deposits escrow → released when validation passes) is literally our TaskMarket.sol → BisectionCourt.sol → settleDisputedTask() pipeline.
@Nithin-Varma — Re: bonds/staking for Sybil resistance. We run a WatchtowerRegistry with stake-gated registration, unbonding periods, and slashing. The adapter uses an authorizedRelayer whitelist — only approved addresses can submit validation requests, preventing namespace griefing. This is modular and composable: it gates who can participate, while the verification logic is independent.
SumeetChougule — Re: the IncidentRegistry proposal. Your bond → challenge → arbitration model is structurally identical to our task → stake → challenge → bisection → slash pipeline. Would be happy to discuss integration with the reference implementation — we could provide the first concrete validationResponse that carries economic weight (slashing) rather than just signal.
Registration file supportedTrust
Our agents would register with:
{
"supportedTrust": [
"crypto-economic",
"stake-secured-fault-proof"
]
}
What we’re looking for
-
Spec feedback — Our adapter routes
validationRequestto an interactive game that takes multiple rounds. ThevalidationResponsecomes asynchronously (potentially hours later). Is the spec designed to handle this async pattern, or does it expect synchronous responses? ThelastUpdatefield and support for multiplevalidationResponse()calls perrequestHashsuggests yes — confirming. -
Reference implementation collaboration — Happy to contribute an
AgentChainValidatoradapter to the reference implementation repo as an example of a non-trivial validation provider. -
Cross-registry composability — When our
BisectionCourtresolves a dispute, we can simultaneously:
-
Call
validationResponse()on the Validation Registry -
Call
giveFeedback()on the Reputation Registry with the verification score -
Mint an EAS attestation
Does the spec envision atomic cross-registry writes, or should these be separate transactions?
Adapter repo (open source): on git humbleaf/agentchain-erc8004-adapter
Verified on Base Sepolia: 0x6d092A889C88425A6c23fD6dbdc0c4Ab0C64b596
Core protocol: agentchain xyz
