Nice piece of work, and the semantic-immutability rules are the part I’d keep hardest, pinning verifierCodehash and stating the normative rule because the hash catches redeployment but not delegation is exactly the right pair. Most proposals in this space leave the upgradeable-verifier hole wide open.
I’m one of the co-authors of ERC-8294 (Validation Network extension for ERC-8004), and I think 8419 composes with two existing proposals in ways that would be worth stating explicitly, because right now an implementer reading 8419 wouldn’t learn either exists.
1. ERC-8294 - the registry you mirror into. 8419 mirrors conclusions into ERC-8004’s Validation
Registry under a kya: tag. 8294 extends that same registry so a validatorAddress can be a network of independent validators, with operator-diversity as a policy parameter and a standardised attestation envelope. These look complementary rather than competing: 8294 is the producer side (who checked, how many independent parties, how the response is aggregated), 8419 the conclusion vocabulary side (what was concluded, under which scheme, until when). A KYA assertion produced by a conforming validation network seems like a natural fit, and it would give a PROVED-adjacent third option where the strength comes from operator diversity rather than from a proof. Worth a line either way, even if the answer is “out of scope for v1”.
2. ERC-8354, an adjacent ZK construction already in the repo. ERC-8354 (Confidential Agent
Policy Verdicts, created 2026-07-16) already does ZK-proof-in-place-of-issuer-signature for agent
verdicts over ERC-8004: a committed policy root, a verifier contract, an expiry and a single-use
nullifier. Structurally very close to your PROVED mode trusted as (verifier, anchor).
The objects differ, and I think that’s the interesting part rather than a problem: 8354 authorises
one specific proposed action pre-execution, bound to an action commitment and a permitted executor; 8419 records a standing conclusion about the agent, with a validity window. “May this action proceed?” versus “what has been concluded about this agent?” Those are the per-action and the standing halves of the same need, and saying so would help implementers who currently have to work it out.
3. A naming question, stated as a fact rather than a claim. A kya.* namespace for agent key
bindings has been public since 2026-07-30 in trustless-ai/recompute-kit kya.pq_key_binding.v0, with kya-l4-* binding identifiers, and is still live in its conformance vectors. That predates this draft by about seven weeks and is unrelated to it, which is exactly why I’d rather ask than assume: does 8419 intend kya: / kya.* as a reserved framework prefix? If it does, we should rename ours before both are deployed and the collision becomes expensive for everyone. If it doesn’t, a sentence scoping the tag to the Validation Registry bridge would prevent the ambiguity.
Happy to help on the 8294↔8419 seam specifically, a worked composition example, or conformance vectors for the mirrored-assertion path, if that’s useful to you.