@everest-an Thinking more about how 8274 and 8350 fit together — the relationship feels deeper than just adjacent ERCs in a lifecycle diagram.
The core connection: when an agent switches its verification backend (upgrading from TEE to zkML, or rotating to a newer model version), that switch is itself a memory evolution event. The switcher’s identity, the reason, the timing — those are all part of the agent’s long-term behavioral trajectory.
Right now 8274’s AgentVerifiable carries:
event AgentVerifierUpdated(address indexed oldVerifier, address indexed newVerifier);
Flat (old, new) pair. It tells you what changed, but nothing about why or in what sequence.
8350’s prevStateRoot → nextStateRoot chain plus provenanceCommitment is exactly the right audit trail for this. One idea I’d love your read on:
Add a second event — AgentVerifierUpdated(bytes32 transitionId) — as an alternative to the existing one. Deployments pick one:
- The original
(old, new)event for simple address-based tracking. - The new
(transitionId)event for deployments that want memory-versioned verifier upgrades — wired to 8350’stransitionId(the EIP-712 struct hash), traceable through the full state lineage, withprovenanceCommitmentcarrying why the switch happened.
A consumer who sees the bytes32 variant knows where to find the full story; a deployment that doesn’t use memory versioning sticks with the original. 8274 doesn’t need to know anything about 8350 internally — it just provides the seam.
Would really appreciate you taking a look — the 8274 spec is at Add ERC: AI Inference Proof Verification Interfaces by JimmyShi22 · Pull Request #1771 · ethereum/ERCs · GitHub, and the discussion thread is at ERC-8274: AI Inference Proof Verification. Curious whether the transitionId shape as 8350 defines it slots cleanly into this pattern from your side, or if there’s a mismatch I’m not seeing. Happy to iterate.