Method
Every verdict on this site is reproducible by hand. Each rung below says what question it answers, how it decides, what happens when it cannot decide and the command that gets the same answer without this site. If any of them disagree with what a page here says, the page is wrong.
the one rule that governs everything else
false means we read the chain and the transaction is not on it. unknown means we could not look or could not read what we fetched. These are never collapsed.
The difference is the whole reason this project can be published. These verdicts have people's names attached. Folding a timeout into a negative would let somebody else's outage publish as our accusation, automatically, at scale. It showed up live rather than in a test: one endpoint returned HTTP 525 mid-run and the verdict came back unknown. Collapsed the tempting way, that run would have published "this transaction does not exist" on the strength of an outage.
the ladder
1. declared
Does the record say anything at all?
- how it decides
- Read `feedbackURI` off the NewFeedback event. It is a non-indexed field, so it exists in the log and nowhere else. `readFeedback()` does not return it.
- when it cannot decide
- A feedback with an empty URI points at nothing, so there is nothing to be right or wrong about. It never reaches a verdict.
re-derive it
curl -sS http://localhost:8081/v1/graphql -d '{"query":"{ Feedback(limit:1, where:{feedbackUri:{_neq:\"\"}}) { id feedbackUri feedbackHash } }"}'2. resolvable
Does the document it points at still exist?
- how it decides
- Fetch it through the SSRF guard. `data:` URIs decode in process with no network at all, which is 92% of this corpus. `ipfs://` goes through a gateway, so it is still a guarded fetch.
- when it cannot decide
- A host that times out, rate limits or returns an error gives `unknown`. Never `false`. A failure to look is not evidence that a payment did not happen.
re-derive it
curl -sS -o /dev/null -w '%{http_code}\n' '<the document url>'3. intact
Are the bytes the ones committed on chain?
- how it decides
- keccak256 over the raw fetched bytes, compared against `feedbackHash` from the event.
- when it cannot decide
- A mismatch stops the ladder at `unknown`, deliberately. The bytes served are not the bytes the author committed, so any claim read out of them would be attributed to somebody who never wrote it. Ten documents on Monad are in exactly this state: the URL is stable and the bytes are not.
re-derive it
curl -sS '<url>' | cast keccak # compare against feedbackHash
4. parsed
Does the document assert a payment at all?
- how it decides
- Run the published atlas below. Exactly one mapping must match; two matching is refused rather than resolved by declaration order.
- when it cannot decide
- A shape no mapping reads is `unknown` and is reported as a coverage gap with its keys, so it can be added. Adding one mapping moved the count of resolving claims from 2 to 12, which is why the gap is published rather than folded into something softer.
re-derive it
node --experimental-strip-types verifier/src/cli/locate.ts <network> <txHash>
5. true
Did the thing the document describes actually happen?
- how it decides
- Read the cited transaction on the chain the document names, not on the chain we would prefer. The receipt is fetched and the chain head is recorded alongside it.
- when it cannot decide
- Absent receipt on a chain we read successfully is `false`. Any other error from the provider is `unknown`. The match is on the error type rather than on a message substring, because a provider is free to reword a message and getting this backwards turns an outage into a wave of accusations.
re-derive it
cast receipt <txHash> --rpc-url https://rpc.monad.xyz
the atlas
The mappings that read a document shape, induced from real documents on Monad and then published. A reader re-running the pipeline executes these deterministically, with no model anywhere in the loop and gets the same numbers.
proof_of_payment.payment_tx, network from the inner object first
every document this mapping read →older execution.market shape, hash under transactions.payment_tx
every document this mapping read →1,026 of 1,029 decoded data: documents. Game rating, asserts no payment
every document this mapping read →3 of 1,029 decoded data: documents. Conversation rating, asserts no payment
every document this mapping read →grokandmon.com well-known cards. Capability description, asserts no payment
every document this mapping read →A mapping can move a verdict, so every one carries the date it was induced. Two mappings matching one document is refused rather than resolved by array order, because declaration order is invisible to a reader and changes silently when somebody appends a mapping. A document no mapping reads comes back with its keys attached, so the shape can be added rather than guessed at.
chain coverage
A transaction that is not found means nothing without the list of chains it was looked for on. This is what makes a negative falsifiable.
| chain | id | names a document may use |
|---|---|---|
| Monad | 143 | monad · monad mainnet · monad-mainnet · monadmainnet |
| Ethereum | 1 | ethereum · eth · mainnet · ethereum mainnet · homestead · l1 |
| OP Mainnet | 10 | optimism · op · op mainnet · optimism mainnet · op-mainnet |
| Base | 8453 | base · base mainnet · base-mainnet |
| Arbitrum One | 42161 | arbitrum · arbitrum one · arb · arbitrum-one · arbone |
| Polygon | 137 | polygon · matic · polygon mainnet · polygon-pos |
| BNB Smart Chain | 56 | bsc · bnb · binance · bnb smart chain · binance smart chain · bnb chain |
A chain with no endpoint configured returns null rather than a client pointed at a default. A silent fallback would make an unconfigured chain look checked, which is the difference between "not found" and "not looked for". A document naming a chain not on this list gets unknown and the reason says which chain it named.
what happens when we are wrong
Verdicts are stored append only. There is no update path anywhere in the code. A re-check writes a new row, so a document somebody repairs reads as false → true with both timestamps, rather than as a number quietly improving with no trace we ever said otherwise. Every claim page carries its full verification history for that reason. Claims whose verdict has changed →
The registry also gives an agent an on-chain right of reply. Where an operator has used it, the reply is rendered beside our verdict on the claim page. We do not get the last word on somebody else's reputation by construction.