You’re the first person outside the project to actually recompute the vectors instead of taking our word for it. Honestly, that’s the review I was hoping for when we published them — logged in External Reviews above.
Your linearity argument is better than mine. I’d been defending it as “this is what makes rollback detectable”; your framing — that allowing two valid successors makes the property uncheckable by construction, and the merge policy you’d then need is exactly the implementation-specific trust this thing exists to remove — is the actual reason. Mind if I fold that into the Rationale on the next rev, with credit?
On provenanceCommitment as the home for a signed verdict: yes, exactly. Since it sits inside the signed struct, whatever it binds is part of what the authorizer approved. Causal input, not a sticky note added later. For the record:
provenanceCommitment = keccak256(abi.encode(
PROVENANCE_DOMAIN, provenanceSalt, keccak256(provenanceBytes)
))
provenanceBytes is where the attestation reference set goes.
Which also answers the one-vs-list question you left open on t/25098: list, but treated as an unordered set. Canonically sort by decision_ref before serializing, drop duplicates, and consumers must not read meaning into position. If recency ever matters, it belongs inside the referenced verdict, not in array order — I’d rather not invent ordering semantics two specs have to agree on forever. (Post-hoc judgments still work fine, they just live outside the core and point at a transitionId, same pattern as the deletion attestation.)
Cite away — the stable anchors are the draft, test-vectors/v1.json, and the Sepolia registry at 0xDdf21937ba80b5fF973610877A0955b320C91241. The three check each other, which is the point. I’ll reference WYRIWE’s L4 verdict scheme from our informative docs in return, as a worked example of an external provenance profile. Informative on both sides, so neither spec ends up depending on the other. That boundary has served both proposals well so far and I’d like to keep it.
And yes on profileId — your free-text source_class is the same bet. A registry-enforced vocabulary would age faster than the field it describes. Saying “unsalted means public” out loud felt more honest than pretending a published vocabulary hides anything.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8004: Trustless Agents | 0 | 8.54 | 27-07-2026 |
| 2 | ERC-8348: Financial Lease | 0 | 8.24 | 28-07-2026 |
| 3 | ERC-8312: Bounded Agent Actions | 0 | 12.74 | 27-07-2026 |
| 4 | Proposing a family of candidate ERC interfaces for titled asset infrastructure — architecture review | 0 | 7.85 | 27-07-2026 |
| 5 | EIP Editing Office Hour (EIP + ERC ) Meeting #108, July 28, 2026 | 0 | 18.32 | 27-07-2026 |
| 6 | ERC-8307: Smart Contract Emergency State | 0 | 7.86 | 28-07-2026 |
| 7 | ERC-8313: Protocol Interaction Manifest | 0 | 7 | 08-07-2026 |
| 8 | ERC-7303: Token-Controlled Token Circulation | 0 | 5 | 08-07-2026 |
| 9 | ERC-8100: Representable Contract State | 0 | 5 | 08-07-2026 |
| 10 | ERC-8004: Trustless Agents | 0 | 7.44 | 26-07-2026 |