@JimmyShi22 agreed, and ERC-8275 Layer 4 runs the exact same pattern. EscrowV1.challenge() takes a bytes4 proofType discriminator and routes to the correct verifier at settlement time, the registry never touches verifier addresses, it only handles staking and slashing. The settlement contract owns the verification logic. Glad ERC-8274 v0.2 is the shared ancestor here; these specs are converging on the same composition principle independently.
@Bakugo32 , appreciate the External References placement. Here’s a paragraph you can drop straight in if it fits:
ERC-8275 Usage-Based Economic Compensation for Heterogeneous Mesh Nodes (discussion): defines a four-layer settlement protocol for CCIP Read mesh nodes. Layer 4 (
EscrowV1) accepts a genericchallenge(uint256 periodId, bytes4 proofType, bytes calldata proofData)entry point whereproofTyperoutes to the correct verifier at settlement time, the same soft-declaration pattern asIAgentVerifiable.getAgentVerifier().VerificationCompletedevents carrying a full pre-image are compatible with ERC-8275’s period-keyed attestation index. No normative dependency in either direction.