x402 / canary Payment evidence verifier
checking live status

x402 v2 · Base mainnet · native USDC · read only

Compare x402settlement terms.

Paste a Base transaction hash and caller-declared PaymentRequirements. Canary compares the observable recipient and amount terms with finalized, source-agreed native-USDC evidence. It does not prove x402 wire/version provenance.

x402 settlement-terms case inputs
public onchain identifier

A public 0x-prefixed, 32-byte Base transaction hash.

declared intent · 4 KB maximum

Paste one public x402 v2 requirement. Never paste a payment signature, signed authorization, private key, seed phrase, or wallet export.

Input cannot select an RPC, token contract, wallet, signer, or transaction target. Collection remains fixed to Base mainnet and native USDC.

  • Base mainnet
  • Native USDC
  • Pinned read-only sources
  • No execution authority
Payment case ready

What this report can establish

  1. 01
    Strict x402 v2 requirement normalization
  2. 02
    Fixed-source Base receipt and finality
  3. 03
    Native-USDC EIP-3009 payment evidence
  4. 04
    Exact recipient and amount comparison

A match establishes only observable recipient and amount alignment. It does not prove x402 provenance, requirement issuance, resource binding, HTTP delivery, business effect, or retry safety.

01 / deployment surface

Same-origin status

Read-only status from this deployment. Missing, malformed, or contradictory responses are shown as unverified.

/api/health checking
Mode
not yet verified
Service
—
Health-route reads
—
/api/evidence-status checking
Release
not yet verified
Core
3ead8680d764ecbafe0739865f3789f8928f0fa6
Core suite
—
deployment checking
Environment
—
Served commit
—
Status checked
pending

Contacting the two same-origin status routes.

02 / evidence method

Four bounded steps

Normalize the declared requirement, observe fixed Base sources, compare only supported settlement fields, then seal one deterministic no-action report.

  1. 01

    Requirement Normalizer v0.2

    implemented

    Strictly accepts one x402 v2 exact requirement for Base native USDC. Unsupported fields, versions, schemes, assets, and methods fail before RPC.

    Emits normalized intent + intentHash
  2. 02

    Fixed Base Collector v0.1

    implemented

    Registry-pinned, read-only Base collection requires a canonical shared finalized anchor and exact native-USDC EIP-3009 event pairing.

    Emits source-agreed Base observation
  3. 03

    Settlement Comparator v0.2

    implemented

    Compares recipient and atomic amount only after one finalized payment is established. Scheme and timeout remain declared protocol metadata.

    Emits exact alignment rows + verdict
  4. 04

    Report Seal v0.2

    implemented

    Domain-separated case and report hashes bind normalized inputs to the sanitized response. Hashes identify content; they are not signatures.

    Emits unsigned JSON report · no action

03 / verdict contract

Six fail-closed outcomes

The public contract keeps Base evidence, requirement comparison, claim status, and execution authority separate.

x402 requirement verifier v0.2 verdict matrix
Case Base evidence Comparison Claim made Action
01 · settlement_terms_matched confirmed matched yes none
02 · settlement_terms_mismatch confirmed mismatched yes none
03 · pending_finality pending_finality not_evaluated no none
04 · not_observed not_observed not_evaluated no none
05 · multiple_payments_observed multiple not_evaluated no none
06 · contradiction contradiction not_evaluated no none

A mismatch is an evidentiary claim only when one finalized payment exists. Pending, missing, multiple, and contradictory observations never become a match. Every row carries actionDirective: none.

04 / assurance boundary

What remains unproven

Settlement alignment is useful only when protocol, authorization, resource, and delivery limits stay attached to every report.

false

External truth proven

HTTPS authenticates configured RPC endpoints, not Base consensus truth. The unanimous result remains bounded by those operator-declared trust domains.

false

Requirement authenticity proven

PaymentRequirements is caller-declared. A deterministic intent hash identifies its content but does not prove who issued, signed, or accepted it.

false

Resource binding proven

A bare PaymentRequirements object does not contain the protected resource URL. The transaction cannot reveal which HTTP resource the payment purchased.

false

Delivery or business effect proven

Onchain settlement does not establish HTTP delivery, business effect, logical purchase uniqueness, or whether another payment attempt is safe.