Look up one identifier (chunk_id, proof_id, match_id, transfer id, or a BSV txid) in ENYAL's public verify lookup — no auth. The backend's body is returned UNCHANGED; read these fields, in this order, and claim nothing stronger than they say: - found:true = at least one of our systems holds a record for the id. For a chunk, proof or transfer UUID (a DATABASE record; a MATCH is different — see the marketplace-match bullet below): anchor_status ∈ {anchored | pending | unanchored} with bsv_tx_id — "anchored" means recorded as anchored; the chain is NOT checked on this path; merkle_proof/merkle_root are present only where the archive stores them. To check the chain, look up the returned bsv_tx_id. - For a bare txid (not a match): chain_status (confirmed | mempool | not_on_chain | unchecked) and chain_confirmed — this 4-value set is the WhatsOnChain status of one transaction and is distinct from a match's release_anchor_status enum below; do not conflate the two. Only chain_confirmed:true is a verified anchor. mempool can still be evicted. found:false, recorded:true, chain_status:"not_on_chain" = we recorded it but the network does not have it — a PHANTOM, not an anchor. Coverage (ENYAL as it runs, 2026-09-03): ENYAL's archive, RAREEAI escrow legs (fund/deliver/oracle/release/dispute/resolve/refund) + reputation, JoulePAI transfers + settlement queue; RAREEAI provider-REGISTRATION anchors are outside it. - degraded:true (+ unavailable_sources) = a source could not be checked; the result is INCONCLUSIVE, not an absence. Only found:false, degraded:false is a clean not-found. - For a RAREEAI marketplace match the body carries TWO INDEPENDENT on-chain claims — read both, collapse neither: ledger_payout_anchor (the joule movement that settled the trade — provider payout or buyer refund — with its own txid/block_height/status; this is the anchor a customer checks today, and it nests a batched settlement_proof leaf) and escrow_contract_release_anchor (the sCrypt escrow contract's terminal leg — its confirmed transaction id is settlement_tx, surfaced flat as release_anchor_status). release_anchor_status is an ENUM in the escrow lane's own vocabulary — read the value AND its note, never reduce it to anchored/not-anchored: confirmed | pending | unreachable | unanchored_open | closed_unanchored | fund_never_anchored | pre_contract | test_resolved | in_progress | ledger_lane. Only confirmed is a chain-confirmed contract release; pending/unreachable mean a release txid EXISTS but the chain has not confirmed it yet (pending) or WhatsOnChain could not be reached (unreachable) — retry, do not read them as unanchored. Every OTHER value explains why there is no contract txid at all — a ledger-lane, closed-unanchored, fund-never-anchored, pre-contract, test-resolved or in-progress trade is settled by the joule movement in ledger_payout_anchor, NOT by a missing anchor. Bridge-Ledger (contribution/fee) events are not in THIS ENYAL lookup, but they ARE anchored — batched into the hourly transparency attestation (bridge_root; anchored in an OP_RETURN transaction, usually within minutes, longer when the network is busy), and checkable with the bridge_proof tool (newest rows read anchoring "pending" until their batch is broadcast, then carry the batch txid). Graph edges are not verifiable here. This tool never decides — it relays ENYAL's verdict fields; a proof-ref it does not return does not exist as far as this lookup can see.