proofline-match-verifier

Proofline Match Verifier

Use the Proofline MCP tools to produce an evidence-backed conclusion. Preserve the API's exact match/event identifiers, disclosure, source links, evidence score, conflicts, hashes, and transaction links.

Non-negotiable truth labels

1. Read mode and disclosure before describing any match data.
2. Say Historical Replay · Not Live for replay data. A replay can exercise the real verifier and contract path, but it is never a current match feed.
3. Say Scheduled · No Events Yet for a future fixture, and Delayed Snapshot · Not Live for a captured provider result. Do not infer a live feed from the tournament year.
4. Say Live only when the API explicitly reports live mode and current provider provenance. Do not infer live status from a clock animation, recent timestamp, or a match status.
5. Identify synthetic fault-injection observations as synthetic. They test conflict handling and are not historical claims.
6. An Injective transaction proves that a hash was committed at a time. It does not make the underlying score or event true. Truth quality comes from source provenance, independent agreement, and conflict handling.
7. A demo receipt or sandbox x402 signature is not a token transfer or public chain transaction. Carry its demo disclosure into the answer.

Verification workflow

Use the Proofline MCP for match evidence and policy decisions. Use the official InjectiveLabs/mcp-server for Injective address, native USDC, balance, CCTP status, or raw EVM operations. Record the actual tool name, redacted input summary, success/failure, duration, and result hash for every call; a UI-derived illustration is never an execution log.

Follow these steps in order:

1. Call list_matches, then get_match for the chosen match.
2. Call get_match_events; retain its machine-readable dataMode, timestamps, provider payload hashes, adapter version, and disclosure.
3. Select the exact event ID. Call verify_event and inspect all active observations, independence groups, conflicts, evidence-score breakdown, and canonical event hash.
4. Call assess_settlement_readiness before any result-level conclusion.
5. If free evidence is sufficient, stop. Do not buy a report just because a paid tool exists.
6. If a complete signed proof packet is necessary and paid access is authorized, call quote_match_proof. Check the payment policy below before calling purchase_match_proof.
7. Pass the purchased packet to verify_proof_packet. Require three separate results: packet integrity, EIP-712 issuer signature, and on-chain commitment. A self-consistent packet without a valid configured issuer is not trusted.
8. If the packet claims a real testnet anchor, call verify_onchain_anchor with its match ID, event hash, and evidence root. Compare the fresh chain result, chain ID, registry address, match-wide latest revision, decision state, and packet receipt. Settlement must use verifyLatestSettlementProof; a successful verifyHistoricalProof only proves that an older revision once existed. Never treat a transaction URL or packet recomputation alone as a live chain read.
9. Return one of: VERIFIED FOR DISPLAY, READY FOR SETTLEMENT, HELD, or INCONCLUSIVE, followed by concise reasons and evidence links.