TWZRD Receipt Verifier (standalone)

Verify a real TWZRD receipt in one command. No wallet, no signup, no API key. Copy-paste this and watch it print VALID:

W=zoz7neLHXoaLwNBuckSqNqaMsacpqJsphtFuNNpQyt3
curl -s https://twzrd.xyz/r/$W.json | npx twzrd-receipt-verifier - --wallet $W

mode             : cNFT (Bubblegum anchor)
trusted pubkey   : 2ELSDxLkb7dYrN6EUG69tNtULAq4Fo7WPvXyrZPmuFif  [built-in genesis authority]
wallet           : zoz7neLHXoaLwNBuckSqNqaMsacpqJsphtFuNNpQyt3  [source: --wallet]
signature_valid  : true
RESULT           : VALID (TWZRD-authored, untampered)

That output came from your machine, not ours. Nothing in the command trusts a TWZRD server - it fetches bytes, then checks an Ed25519 signature against a published key using audited crypto libraries.

--wallet is required when piping. A cNFT receipt's wallet is inside the signed payload but not the anchor block, so it cannot be inferred from stdin. Save the file as <wallet>.json instead and the filename supplies it: curl -s https://twzrd.xyz/r/$W.json -o $W.json && npx twzrd-receipt-verifier $W.json

Verify a TWZRD receipt offline, trusting nothing from TWZRD's servers or codebase - only the receipt, TWZRD's published public key, and two widely-audited crypto libraries. The verifier auto-detects two receipt families:

For V5/V6 the verifier reads the domain the receipt carries and applies the matching leaf rules (V6 binds the reputation_* provenance fields into the signed leaf; V5 left them unsigned). For cNFT receipts there is no leaf - tamper-evidence is the signature: any change to a signed field (including the wallet) invalidates it.

If it says VALID, the receipt was authored by TWZRD and was not altered. Unsigned, wrong-key, wrong-wallet, or tampered receipts fail.

Since 1.3.0 the package also verifies a third, deliberately separate artifact class - the AgentReadinessReceipt - via the programmatic API only (see AgentReadinessReceipt V1 below). The CLI rejects it by design; that rejection is a feature, not a gap.

Where this fits: the agent trust loop

This verifier is the last step of the x402 trust rail an agent runs before and after it spends:

1. Discover a model/provider - wzrd-client (PyPI) or @wzrd_sol/sdk (npm)
2. Preflight the seller wallet, free - POST https://intel.twzrd.xyz/v1/intel/preflight (or MCP get_readiness_card_tool)
3. Pay with a signed receipt - GET https://intel.twzrd.xyz/v1/intel/trust/{seller} (0.05 USDC, x402)
4. Verify the receipt offline - this package (trust nothing but the bytes + the public key)

# zero-install: verify a receipt straight from the published package
npx twzrd-receipt-verifier receipt.json --pubkey Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS

# replay-resistance (opt-in): reject receipts older than 60s — and reject any with no timestamp
npx twzrd-receipt-verifier receipt.json --pubkey Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS --max-age 60

The published signing key

During the bounded rollout, twzrd-receipt-ed25519-v1 and its published legacy public keys remain accepted for verification only. New receipts are always signed with v2; do not relabel a v1 receipt as v2.

Also published, machine-readable, at:

• https://intel.twzrd.xyz/.well-known/x402 → receipt.signature.public_key
• https://intel.twzrd.xyz/openapi.json → x402.receipt.signature.public_key
• the MCP card agent-intel-mcp-card.json → receipt_signing.public_key

Most paranoid mode: pin the key out-of-band with --pubkey instead of fetching it, so you never trust the live endpoint to tell you which key to trust.

cNFT Receipts (the 95k genesis receipts)

Every genesis receipt is a compressed NFT on Solana mainnet (tree 8QFdTqBkSeyuvp47dXdpwfWzXTuYSbAC64oT4soPGnXS, verified creator 2ELSDx...). Its at-mint snapshot is published as a signed anchor block in the cNFT metadata, served at https://twzrd.xyz/r/<wallet>.json:

{
  "anchor": {
    "tier_at_mint": "Platinum",
    "score_at_mint": 255,
    "verified_tx": "<solana settlement signature>",
    "behavior_proof": "<sha256 hex>",
    "minted_at": 1782415336,
    "signature": "<128-hex Ed25519 sig>",
    "verify_pubkey": "2ELSDxLkb7dYrN6EUG69tNtULAq4Fo7WPvXyrZPmuFif"
  },
  "live": { "...": "current decayed reputation (NOT signed)" }
}

The signed payload is the compact JSON {wallet, tier_at_mint, score_at_mint, verified_tx, behavior_proof, minted_at} (exact key order). The wallet is the first signed field but is not stored in the anchor - it is the <wallet>.json filename / the cNFT leaf owner - so pass --wallet or keep the filename. The signing key (2ELSDx...) is built in to the verifier (pinned in the audited package); override with --pubkey, or fetch the published copy with --fetch-key.

# fetch a receipt and verify it (wallet inferred from the filename, key built-in)
W=zoz7neLHXoaLwNBuckSqNqaMsacpqJsphtFuNNpQyt3
curl -s https://twzrd.xyz/r/$W.json -o $W.json
npx twzrd-receipt-verifier $W.json --self-test

# or pass the wallet explicitly (e.g. when piping from stdin)
npx twzrd-receipt-verifier anchor.json --wallet $W

# fetch the key from the published descriptor instead of the built-in copy
# (cross-check, or pin to whatever the live domain publishes)
npx twzrd-receipt-verifier $W.json --fetch-key

The key is published, machine-readable, at https://api.twzrd.xyz/v1/receipts/pubkey (and https://twzrd.xyz/.well-known/twzrd-receipt-pubkey) with the full signing spec (public_key, signed_fields, scheme, tree). It must equal the built-in key and the on-chain verified creator of every cNFT in the tree - three independent sources.

mode             : cNFT (Bubblegum anchor)
trusted pubkey   : 2ELSDxLkb7dYrN6EUG69tNtULAq4Fo7WPvXyrZPmuFif  [source: built-in genesis authority]
wallet           : zoz7neLHXoaLwNBuckSqNqaMsacpqJsphtFuNNpQyt3  [source: filename]
signature_valid  : true
RESULT           : VALID (TWZRD-authored, untampered)

Only the anchor block is signed. The live block (current decayed reputation) is informational and intentionally NOT covered by the signature. For full on-chain binding, confirm the cNFT exists in the genesis tree with verified creator 2ELSDx via any DAS provider (getAsset / getAssetProof); the signature alone already proves 2ELSDx authorship of the at-mint snapshot.

AgentReadinessReceipt V1 (endpoint conformance, NOT trust)

An AgentReadinessReceipt attests one thing: this URL was probed at as_of_unix and this is what it did - x402 discovery, unpaid-402 conformance, wash screen on the resolved payTos. It is endpoint conformance observed at a point in time, not a trust vouch. That limit is machine-readable and signed: basis is always endpoint_conformance and not_a_trust_vouch is always true; a receipt claiming anything else does not verify. A ready verdict means the mechanics conform and no negative signal was found - it does not mean the seller is trustworthy.

Get one from POST https://intel.twzrd.xyz/v1/intel/verify-endpoint (x402, USDC on Solana) - the receipt is the receipt object in the response. A not_ready result is still delivered and still signed: the fee buys the observation, never a pass.

Verify it programmatically (same package, same published key):

const { verifyReadiness, isReadinessReceipt } = require('twzrd-receipt-verifier');

const receipt = require('./response.json').receipt; // from POST /v1/intel/verify-endpoint
if (!isReadinessReceipt(receipt)) throw new Error('not a readiness receipt');

const out = verifyReadiness(receipt, 'Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS');
console.log(out.valid);              // signature + leaf both check out
console.log(out.verdict);            // ready | warn | not_ready
console.log(out.ownership_proven);   // did the operator prove control of the origin?
console.log(out.past_recheck_after); // advisory staleness - see below

Pass { maxAgeSeconds: 3600 } as the third argument to additionally reject receipts whose as_of_unix is further than an hour from now.

recomputeReadinessLeaf(preimage) is also exported if you want to rebuild the keccak256 leaf yourself byte-for-byte.

Two verdict classes, only one is fatal. Signature or leaf failures mean the artifact is forged or tampered - out.valid is false, discard it. out.past_recheck_after === true is advisory: readiness is perishable (an endpoint can regress the minute after the probe), so every receipt carries a verdict-driven recheck_after_unix. A genuine-but-stale card stays cryptographically valid; your policy decides whether to demand a fresh one.

Why the domains are disjoint - and must stay that way. Readiness receipts sign under TWZRD:AGENT_READINESS_RECEIPT_V1; paid trust receipts sign under the V5/V6 reputation/attention domains. Neither allowlist contains the other, so a readiness receipt can never verify as paid trust intel through verify(), and a trust receipt can never verify through verifyReadiness() - both directions are asserted in the test suite. Without that split, a conformance observation ("the endpoint's 402 works") could be laundered into a trust claim ("this seller is safe to pay"), which the down-only screening doctrine forbids. This is also why the CLI - a payment-receipt tool - rejects readiness receipts on its domain allowlist instead of quietly accepting them.

Get a receipt to verify

Free sample first — the signature is real, so this proves the whole verify path without paying or holding a wallet:

curl -s https://intel.twzrd.xyz/v1/receipts/example -o sample.json
npx twzrd-receipt-verifier@^1.3.0 sample.json \
  --pubkey Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS

Live paid receipt: GET https://intel.twzrd.xyz/v1/intel/trust/{pubkey} (x402, 0.05 USDC on Solana mainnet) with any x402-capable client — the receipt is the twzrd_receipt object in the response. Since 1.2.2 the verifier auto-unwraps twzrd_receipt, so the raw API response verifies as-is.

This package is only the offline verify step of the trust loop. Free preflight, merchant cards, and discovery live on the remote MCP — https://intel.twzrd.xyz/mcp (24 tools, no wallet; includes twzrd_demo_gate).

The receipt object looks like:

{
  "version": "v5",
  "leaf": "0x...",
  "preimage": { "domain": "TWZRD:AO_REPUTATION_RECEIPT_V5", "agent_id": "...", "score": 15, "...": "..." },
  "signature": "base58 ed25519 sig",
  "signing_pubkey": "Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS",
  "key_id": "twzrd-receipt-ed25519-v2",
  "signing_alg": "ed25519"
}

Python

pip install twzrd-receipt-verifier   # PyPI; or: pip install pynacl pycryptodome for script-only use

# fetch the published key and verify:
twzrd-verify-receipt receipt.json
# or: python verify_twzrd_receipt.py receipt.json

# pin the key out-of-band (recommended):
python verify_twzrd_receipt.py receipt.json --pubkey Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS

# also confirm a tampered copy FAILS:
twzrd-verify-receipt receipt.json --self-test

# replay-resistance (opt-in; same semantics as the npm CLI --max-age):
twzrd-verify-receipt receipt.json --max-age 300

# from stdin:
cat receipt.json | twzrd-verify-receipt -

Source: twzrd-sol/twzrd-receipt-verifier

Node

npm install                          # tweetnacl + js-sha3 + bs58

node verify_twzrd_receipt.js receipt.json
node verify_twzrd_receipt.js receipt.json --pubkey Ak5SQwHpuQAqU7ty7ZWX7qgF39A9yi72c22KNn8sHzvS --self-test
cat receipt.json | node verify_twzrd_receipt.js -

Both exit 0 on VALID, 1 on INVALID.

What it checks (and the exact layout)

The keccak256 leaf preimage is a strict little-endian, length-prefixed concat (reproducible in any language):

domain            = "TWZRD:AO_REPUTATION_RECEIPT_V5"   (or ...ATTENTION... for attention receipts)
agent_id          = u16_le(len(utf8)) || utf8 bytes
score             = u16_le
confidence_bps    = u16_le
timestamp_unix    = u64_le
payer             = 32 bytes  (base58-decoded pubkey, or sha256(marker) for synthetic payers)
settlement_anchor = 32 bytes  (last 32 bytes of the utf-8 settlement_tx string, or 32 zero bytes)

leaf      = keccak256(domain || agent_id || score || confidence_bps || timestamp_unix || payer || settlement_anchor)
signature = Ed25519_sign(receipt_signing_key, leaf_bytes)

The verifier:

1. recomputes leaf from the preimage and compares it to receipt.leaf,
2. confirms receipt.signing_pubkey (if present) equals the trusted key,
3. verifies the Ed25519 signature over the 32 leaf bytes against the trusted key.

VALID requires all three. The settlement_tx in the preimage is an on-chain Solana signature you can independently check for ground truth.

BOUND vs FRESHNESS: what VALID does and does not attest

For trust-API receipts, both CLIs print a per-field card after the verdict. VALID covers ONLY the BOUND lines - the fields hashed into the keccak leaf that the Ed25519 signature signs. V6 receipts also carry a JSON-only freshness triple (recheck_after_unix, staleness_days, score_decay_model): consumption policy hints that are NOT signature-bound and can be edited without breaking the signature. The card says so explicitly, so a relying party never mistakes them for attested facts:

RESULT           : VALID (TWZRD-authored, untampered)
BOUND     domain   covered by Ed25519 over the signed payload
BOUND     agent_id   covered by Ed25519 over the signed payload
...
BOUND     reputation_score   covered by Ed25519 over the signed payload
FRESHNESS recheck_after_unix   present, NOT signature-bound; do not treat as proof
FRESHNESS staleness_days   present, NOT signature-bound; do not treat as proof
FRESHNESS score_decay_model   present, NOT signature-bound; do not treat as proof
VERDICT   valid-signature

If you need a freshness guarantee, enforce it yourself against the BOUND timestamp_unix (e.g. --max-age 300), never against the freshness triple.

Trust assumptions

You trust: the receipt you were given, the published public key (ideally pinned), and the crypto libraries (PyNaCl/libsodium, pycryptodome; tweetnacl, js-sha3). You do not trust TWZRD's API, database, or this repository's other code. Swap the libraries for your own if you prefer - the byte layout above is the whole spec.