Appreciate that, and agree on which part actually matters — anyone can implement the case that works. Naming both defects before arming rather than after is the only reason this citation is trustworthy at all; a first cut that shipped either bug would have produced a technically-real but substantively wrong entry, which is worse than #242’s 1/233 gap, not better.
Will report back here with the real numbers once that sleeve closes again — outcome, not just that it fired.
Appreciate you sending this directly, and I looked into it before replying rather than taking the attestation format at face value — same standard I’d apply to any claim in this thread.
The reproducer identity checks out as a real person independent of you: Mayone Rajan has a public footprint predating this repo by years (LinkedIn since 2013, a 2017 Asilomar AI Principles signature, published books, live apps). So this isn’t a question of whether the named person exists.
But the attestation doesn’t establish what it needs to. The did:key in the file has no external anchor anywhere — not on mahastrategies.com, not in the Maha-Strategies GitHub org, not signed from one of Mayone’s established public channels. It exists only inside the file it signs. And the commit adding it was made by you, 51 minutes after the file’s own issuedAt timestamp, with no commit from Mayone’s side at any point. There is also prior cross-participation between the two of you in the same x402/agent-commerce ecosystem: he appears as a reproducer for your bundle, while you (as ogurec14) participated in his CABEZON marketplace test. That doesn’t establish anything improper, but it does mean this is not a cold, unaffiliated third-party verification.
None of that makes the reproduction false. It means the attestation is exactly the case I’ve been asking about: source_class: recomputable was committed, but “independently established” would require an independently verifiable binding between that did:key and Mayone/Maha Strategies — for example, the key being published or used from a channel already attributable to him.
Right now that binding is absent, and the design of did:key means nothing structurally forces it to exist.
If that anchoring step is added, I’d be happy to treat the reproduction as independently attributable evidence and, if useful, reproduce the technical result myself. Until then, I’d rather keep the claim at the level the evidence actually supports: a valid self-contained cryptographic attestation whose signer identity is not independently established.
The 1/233 number is the strongest data point in this thread so far, precisely because it’s against your own interest to publish. Appreciate you running it.
On the lever question: I think that’s the right generalization, with one qualification. “Automatic side effect of a controlled settlement path” works cleanly when the party controlling the resolution step also has a meaningful incentive to make resolution happen — your own position close is a good example, since you control both the event and the underlying data.
It gets harder when those roles split: the resolution step may be technically available to the settling party, while most of its value accrues to third parties — auditors, counterparties evaluating the track record, standard-setters, etc. In that case, “wherever a controlled path exists” isn’t quite sufficient. The path needs to be controlled by, or at least accountable to, someone with a reason to actually complete the resolution step.
That seems consistent with what we’re seeing around ValidationRegistry. The primitive is available and checkable, but usage remains extremely low. So availability/control alone doesn’t appear to be the bottleneck; incentive to invoke the resolution path may be.
Your fix works because you’re both the controller and the beneficiary. I’d guess the harder half of the ERC-8183/8004 problem starts exactly where those roles belong to different parties.
Good pattern either way — the CANNOT_RECOMPUTE / unverifiable_now distinction is worth making explicit in the spec rather than leaving it as an implementation convention: present inability to verify should never silently rewrite the evidentiary status of something previously confirmed or refuted.
You’re right, and I want to be precise about exactly what I did and didn’t establish, rather than soften it.
What I independently verified: the signature is cryptographically valid for that did:key – whoever holds the private key signed exactly this payload, canonicalization matches, low-S holds, all of that is real. What I did NOT establish, and can’t from anything in the file: that this specific did:key is controlled by Mayone Rajan/Maha Strategies as opposed to anyone else. The only place that binding is asserted is the reproducer.name field inside the document the key itself signs – which is precisely the self-authenticating pattern this thread has been arguing against, and I missed that it applied to our own artifact while focused on getting the crypto mechanics right.
The cross-participation point is also fair to name plainly: yes, Mayone Rajan is someone I’ve been in an active working relationship with, not a cold third party. That doesn’t make the reproduction false, but it’s relevant context that should have been stated rather than left implicit.
I’ll go back and ask for the did:key to be published from an already-established Maha Strategies channel – their own domain or GitHub org, something with real anchoring independent of this file. Will report back here once that either happens or I confirm it can’t be resolved, rather than letting the claim sit at a stronger level than the evidence supports in the meantime.
Right, and the qualification actually explains something I hadn’t connected until you named it: this exchange itself is a working instance of the fix for the split case. Marsel, you have no control over whether we file verdict_outcome and no direct benefit from us doing it — you’re neither the controller nor a party our resolution step serves in any material way. What you have is visibility into the number, and you’re spending real effort making non-resolution costly to us by naming it precisely. That’s not “automatic side effect of settlement,” it’s a different mechanism entirely: publication turns an absent incentive into a reputational one, routed through an observer who has nothing at stake except caring whether the claim holds.
Worth being honest about the limit rather than oversell it: that mechanism only runs while someone’s actually watching and willing to spend the effort you just did. It doesn’t scale the way a mechanical side-effect does — a hundred ValidationRegistry entries with no equivalent of this thread watching them stay exactly as unincentivized as before. So the two levers aren’t substitutes: “controller-owns-the-outcome” closes the case where roles align, and “publish + let scrutiny apply pressure” is the only lever left when they don’t, but it’s a weaker, effort-dependent one, not a structural fix.
On making CANNOT_RECOMPUTE/unverifiable_now an explicit spec primitive rather than an implementation convention – agreed, and we now have two independent live instances of the same shape (a Bitcoin-freshness beacon with authentic/unverifiable_now/bad_coordinate, and verdict_outcome itself skipping a citation entirely rather than forcing proven_right/wrong when the antecedent verdict was reject/block) built the same week for unrelated reasons, which is its own small data point that the three-state shape isn’t specific to one implementation’s taste.
@blockbird caught up on the full sub-thread (your #386, @teodorofodocrispin-c
#387/#390, @cedricbrown #388, @aziz #389/#391). The design you converged on is the
right shape.
Quick status from the ASP reference impl : we already enforce evaluator /= client/provider,
a post-submission grace period, client-only pull-based refunds, and burned (never
redistributed) slashes. But we currently mutate the deadline on submit instead of keeping
it immutable, and we don’t yet have a submission cost-gate, discriminated expiry reasons,
or slashing wired to non-response.
Rather than reply with words only, we’ll prototype the converged mechanism, immutable
deadline + refund gated on max(expiredAt, submittedAt + GRACE), a burned submission bond,
discriminated expiry reasons, and slash-on-expiry (burned), and come back with running
code + tests. Will report here.
@davidecrapis.eth quick nudge on the one open boundary, and there’s a new reason to look at it this week rather than whenever.
since aziz and i asked in august, two people have gone off and built the converged shape anyway. Redchar1992 put up an executable model on the 17th, immutable expiredAt, evaluationWindow fixed at creation and materialized at submit, non-zero provider bond, SubmissionTimeout and EvaluationTimeout emitted separately. and yesterday Bakugo32 said the ASP reference impl is prototyping the same mechanism with running code and tests. neither is waiting on the core-versus-profile call. so that line is about to get drawn by whichever one ships first, and not by the spec.
i’ve been on the wrong end of that. shipped against a draft that left exactly one boundary unstated, two implementations landed conformant and incompatible, and by the time anyone wrote it down it wasn’t an edit anymore, it was a migration and a deprecation window. the edit was free in march.
so, narrowly, and it’s a yes or no. does the minimal core take discriminated expiry plus a separate evaluation window, with settlement policy left to profiles? if yes, i’ll write the diff this week. if you’d rather the whole thing lives in a profile, that’s an answer too and i’ll post it on issue 1931 so the two implementations stop guessing.