verify_proof

ai.greenlandai/greenlandai · Verify this server

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; five attestations per OP_RETURN transaction, roughly every five hours), 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.