An idea.
A permanent record.

zpad connects a Solana token launch workflow with a public receipt on Zcash. A qualifying burn records the exact amount destroyed in one receipt. It does not create that many independently spendable Zcash tokens.

1. Prepare a collection. Prepare a Pump launch draft with the ZEC pair and approved fee terms, or save the details of an existing token.
2. Register and fund it. The creator signs immutable collection parameters committed in the Solana launch transaction. A prior Zcash block anchors receipt indexing. The platform treasury funds native Zcash receipt transactions.
3. Burn with intent. An enabled burn transaction includes the exact amount and a canonical memo binding the destination and collection.
4. Verify the receipt. The worker verifies source finality before inscription. An independent verifier then checks receipt content and delivery.

Launching a token

The launch form separates creating a token from registering an existing mint. You can download a draft as JSON or sign in to save it in Supabase. Uploaded images are previewed locally. In live mode, sign in and publish metadata to host a sanitized image and token JSON. Published content is public and cannot be replaced through your account.

zpad is configured for Pump launches paired with ZEC on Solana, with a 0.25 SOL launch fee and a 1% creator trading fee. The complete Pump transaction includes the registration commitment and fee policy in the same atomic transaction. Devnet does not currently support the selected ZEC pair; the site never substitutes a SOL pair silently.

The server independently verifies the finalized launch and its signed registration before indexing. Connecting a wallet or saving a draft does not launch a token. If submission times out, recover the saved transaction before starting another launch.

What a burn means

A burn permanently reduces the source token balance and supply. There is no reserve and no redemption mechanism. The source transaction and the Zcash destination are publicly linked. A transparent receipt does not provide privacy.

Amounts are parsed from exact decimal strings into integer base units. The form rejects commas, exponent notation, negative numbers, excessive precision, and overflow. Transparent Zcash addresses are checked with Base58Check, network bytes, and the expected payload size.

One burn produces one receipt with an amount field. The recorded amount has no guaranteed market value. The yellow receipt is a rendering of the record, not a promise that the full image is inscribed.

Two chains, separate steps

Wallet approval, Solana finalization, Zcash commit, Zcash reveal, and protocol validation are distinct states. There is no atomic cross-chain transaction. Preflight funding and service checks reduce risk but cannot guarantee delivery.

Token custody remains with the user until a burn. Fee funds sent to an operator-controlled Zcash funding account are controlled by that operator. Those are different custody arrangements.

Evidence before a verdict

The verifier accepts a source signature, receipt ID, or reveal transaction ID. It returns Valid, Invalid, or Unresolved. A provider outage, missing history, or an unconfigured chain adapter returns Unresolved.

The server checks creator-signed registration, the finalized burn, confirmed Zcash delivery and a fresh complete historical index. The ledger CLI can rebuild the relevant history directly from archival nodes without the application database. Download the signed registration proof from the collection page first.

npm run verify:ledger -- <reveal-id> ./registration.json

Our protocol namespace is zpad. It is distinct from the reference project. No compatibility with another receipt protocol is claimed.

{"p":"zpad","op":"mint","v":1,"collection":"…","mint":"…","burn":"…","amt":"…","to":"…"}

Receipt transfers and current ownership tracking are not enabled. An original issuance recipient is not necessarily the current owner. Ordinary wallet spending may consume a receipt-bearing output.

Risks & limitations

• Burns are irreversible. A receipt does not restore the burned tokens.
• Receipts are public. The source and destination can be linked.
• Zcash consensus does not verify Solana burns or interpret our receipt JSON.
• A chain inclusion is not proof of protocol validity.
• Future shielded asset conversion is not implemented or promised.
• No audit, guarantee, price peg, or mainnet readiness is claimed.

The register displays stored collections and recorded activity. Empty or unavailable data is shown explicitly.

Built from thoughtful details

Your reference layouts inform the collection gallery and three-step launch form. The print-shop palette and yellow receipt give the workflow a consistent identity.