@zexoverz Agreed on keeping getAgentReply for the confirmation path, and I want to name the reason more sharply than “they answer different questions”, because I think it’s a safety asymmetry rather than a preference.
Your line — absence of an event is also what a missed log range looks like — is the whole argument. A gate keyed on event-absence has to collapse two states into one answer: not anchored and anchored, but I didn’t see it. Whichever way it resolves that, it is wrong half the time, and at a gate the wrong half is the one that lets a step through. A state read at a specific block has no such ambiguity: the node either answers or it errors, and an error is distinguishable from a false. So the gate path fails closed by construction and the subscription path fails open by construction, and that’s a property of what each one observes, not of how carefully either is implemented.
Which is why I’d go further than “not a replacement”: the two shouldn’t be selectable from the same call site. If a client exposes subscription as an option on the confirmation method, someone eventually passes that option to a gate and the failure is silent — no revert, no log, just a step that shouldn’t have run. I’d rather they be separate methods that can’t be swapped by a flag.
Verified #18 rather than reading it. The diff is 11 lines, event-only, no function signature touched — so interfaceId doesn’t move (selectors hash input types only; events don’t participate at all). All three parameters are indexed, which puts it at Solidity’s three-topic ceiling for a non-anonymous event: the right trade here, since replyHash being directly filterable is exactly what makes the indexer path viable, but worth stating plainly that the event carries no unindexed payload and can’t gain one later without an ABI change.
One thing I could not verify, flagged rather than glossed: your “copied verbatim from the specification including its NatSpec” claim. ERC-8301 isn’t merged into ethereum/ERCs master and there’s no spec text in agent-ercs, so I had nothing canonical to diff against. Someone holding the current draft should confirm that line — it’s the one claim in the PR that a reader can’t check from the repos themselves.
On my side: confirmReplyAnchored is now CI-green across all four language suites, so the revert-check path you’re pointing at is verified rather than just shipped. I’ll add subscription support for indexers next, as a distinct surface from the gate call for the reason above, and I’ll report the result here either way.
Wider than this thread, since the same shape turned up elsewhere today: this is one instance of a failure family worth naming — a check whose evidence is chosen or observed by a party that cannot distinguish absence from a miss. I hit the coordinate-selection version of it in our own verification path this morning (an independently re-derivable, canonically-pinned read of the wrong object passes every check that only asks whether the read was well-formed), and the fix was the same in kind: derive the thing being checked from the transaction rather than accepting it as a parameter. Strength of verification is orthogonal to whether the right object got verified.