QUAD Receipts And Support

Support Contract

A good support request has enough public evidence to route the issue without asking for secrets.

FieldWhat to provideWhat to keep out

SurfaceCore, Infra, Bridge, Liquid, or main website.Do not merge surfaces or ask one chain to explain another chain's private state.

ActionObserve, fund, upload, verify, retrieve, route, quote, vote, settle, refuse, or check status.Do not describe an action as a sale, reward, allocation, or redemption unless the owning surface says so.

Public idReceipt id, transaction hash, quote id, route id, proof id, refusal id, status URL, or endpoint contract URL.Do not post seed phrases, keys, private payloads, private account details, or private logs.

Current statePending, accepted, refused, stale, expired, duplicate, unavailable, unpaid, unauthorized, degraded, quarantined, recovered, or settled.Do not hide uncertainty when the action may cost money, time, or reputation.

Expected next stepWhat you expected to happen next and which public page led you there.Do not use private chat as the only source of truth.

Receipt Search

Search starts at the surface that issued the receipt. A missing receipt should downgrade the claim, not invite guessing.

Core receiptsCore delivery, quarantine, supply, admission, and public chain receipt surfaces where published. Infra verifyReceipt verification, proof, retrieval, reissue, and retained-memory posture where public. Bridge proofPassage evidence, host evidence, route labels, refusal, quarantine, and destination handoff proof. Liquid proofMotion, position, wrapper, risk, settlement-request, and state-promotion proof labels where public. Main receipt guideHow to read what a receipt proves and what it does not prove. Integrator receipt schemaReceipt fields for downstream interfaces: owner, event, proof class, payload boundary, and verifier URL.

Receipt Summary Shape

A receipt should have a readable summary and a machine-readable shape when the owning surface exposes both.

Readable summary

Surface, action, status, public id, timestamp, amount or object label where relevant, and next public check.

Machine shape

receipt_id, surface, event, status, proof_class, source_url, boundary.

Proof statement

What the receipt proves: upload, retrieval, passage, refusal, quarantine, finality, quote, status, or settlement request.

Boundary statement

What it does not prove: payload truth, Core admission, destination admission, custody, redemption, yield, reward eligibility, or launch state.

Refusal Records

Refused: the owning surface rejected the action or interpretation.
Expired: the quote, route, proof window, or action window passed.
Duplicate: the request repeats a known receipt, transaction, or route id.
Invalid: the id, denom, payload class, route, or proof shape does not match the public contract.
Unavailable: the route or surface is not currently answering under its public contract.
Quarantined: delivered or observed material is held away from admitted state.

Reissue Path

Original receipts should be kept by the actor who performed the action.
Infra may expose lookup, certified reissue, evidence-bundle reconstruction, retention proof, linkage proof, challenge history, or bulk access where the product lane is open.
Paid reissue, if applicable, must show quote, denom, accepted amount, receipt id, and source surface.
Reissue does not broaden what the original receipt proves.
Private payload disclosure remains opt-in and product-specific.

Retention Support

Support should distinguish a missing receipt from ended payload access, pruned rows, tombstoned handles, cold retention, and certified reissue.

Support labelWhat to bringWhat not to send

Receipt retainedReceipt id, owner surface, event class, status label, and proof boundary.Private payload body or private contract terms.

Payload access endedReceipt pointer and the public access-state label shown by the owner surface.Private files or reconstruction detail in public support.

TombstonedPublic handle, owner surface, terminal state, reason class where public, and replacement route where public.Private report detail, private review material, or sensitive cause detail.

Reissue requestedOriginal receipt id, quote id where applicable, service class, and owner route.Seed phrases, account logins, private payment routes, or private diagnostics.

Retention support follows data/retention-policy.json. A reissue does not broaden what the original receipt proved.

Triage Flow

Support should narrow the issue before asking for more information.

1. Pick surface

Core, Infra, Bridge, Liquid, or main website.

2. Name action

Observe, fund, upload, verify, retrieve, route, vote, quote, or settle.

3. Add public id

Receipt id, transaction hash, quote id, route id, refusal id, status URL, or proof URL.

4. Read current state

Pending, stale, refused, unavailable, unpaid, expired, duplicate, invalid, unauthorized, degraded, or quarantined.

5. Downgrade claim

If proof is missing or stale, say what cannot be verified yet.

Do Not Send

Support should solve the issue without creating a new one.

Wallet secrets

No seed phrases, private keys, recovery phrases, signing prompts, or wallet exports.

Private payloads

No private files, contract bodies, customer material, or payload contents unless the product explicitly allows that disclosure.

Private accounts

No payment-account details, private invoices, private provider accounts, or sensitive contact routes in public channels.

Private diagnostics

No private logs, private endpoint paths, sensitive node details, exploit detail, or recovery timing.

Next Clicks

Receipt guide Support playbooks Status and error labels Action lifecycle Retention JSON Community Status labels Integrator guide Operator guide