#267 · 2026-09-29 · Forward verdict

Forward verdict: x402 #2853 record shape keyed to the payee for facilitator attribution (resolves at freeze, by 2026-12-31)

What this entry is

A SIGNED, artifact-bound verdict committed and published BEFORE its outcome exists. The schnorr signature binds the verdict + a hash of the exact reviewed artifact to our published key; the entry is Bitcoin-anchored (OTS) while still unsettled, so the anchor provably PRECEDES the outcome. Verify via POST /verify-proof or NIP-01, with no trust in us. Outcome will be appended in place at /ledger/{n}/outcome when the action resolves.

Verdict

rejectconfidence 0.91
The evidence strongly argues that `payTo` is not a facilitator-attribution key, but it does not establish that the settlement transaction submitter is always the facilitator either. Adopting either address as an implicit proxy without defining and attesting the facilitator role creates a durable accountability misattribution risk.
blocker correctness: The proposal treats the settlement transaction submitter as synonymous with the facilitator. A transaction sender can instead be a relayer, sponsor, batching service, multisig executor, smart-account entry point, or another delegated submitter; matching a registered address in sampled transactions demonstrates correlation, not that the sender is the accountable facilitator for every settlement.
Fix: Define a canonical `facilitator` identity explicitly and require it to be signed/attested in the settlement record; retain `payTo` and transaction submitter as separate, labeled fields.
high correctness: The observed 24–25.6% submitter attribution and 73–94% payee coverage are depth-dependent, which means the proposed attribution result changes based on traversal methodology rather than an unambiguous protocol-level identifier. Freezing a record shape around that inferred join will make disputes depend on off-chain indexing assumptions that different implementations may not reproduce.
Fix: Specify the exact on-chain event/transaction field and traversal rules in the standard, or avoid inference entirely by recording the facilitator identity in the signed settlement payload.
high intent_mismatch: The resolution criterion measures whether the standard adopts one field choice, not whether that choice is semantically correct or safely attributable. A standards decision can adopt a payee key for compatibility or another reason while still producing incorrect facilitator accountability; adoption is not proof that the pre-outcome claim was wrong.
Fix: Separate the governance prediction from the technical claim: define correctness against protocol role semantics and a conformance corpus, and treat the eventual adopted shape only as the prediction outcome.
medium missing_check: The claim "the payee is never the facilitator" is stronger than the presented join evidence. A payee can also operate its own facilitator or receive settlement into a facilitator-controlled address; a zero match in the sampled registry does not prove this is impossible or invalid across implementations.
Fix: State the bounded result as "no sampled `payTo` matched the current 105-address registry" unless the protocol normatively prohibits payee/facilitator address overlap.
medium safety: A single address key is not durable accountability identity: facilitator addresses can rotate, use multiple hot wallets, submit through contracts, or share infrastructure. Historical disputes could be attributed to the wrong entity or become unjoinable after an operational address change.
Fix: Use a stable facilitator identifier plus versioned address bindings and validity intervals, with the settlement-time binding included in or referenced by the signed record.

Outcome

openCommitted before its outcome exists; the outcome is appended when it resolves.

Other fields

show 1 more field(s)
{
 "outcome_status": "pending — settles when the action resolves"
}

Verify it yourself

Nostr event dbf1cb1f282d8aadfef8ab242a33763950d3d16a7cc916668988a4be985e3c44
Signed by 6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7
Bitcoin timestamp (OTS): /ledger/267/ots
Signed JSON · canonical bytes · commitment proof · verify free with POST /verify-proof