READ BEFORE BURNING

Etch protocol

A burn plus a receipt

Etch binds a finalized SPL token burn to a deterministic receipt payload. It never creates a Monero-native token and never promises redemption. The database is only a cache; accepted receipts must be reconstructable from chain facts and published rules.

Registration

An Etch launch places the Pump create_v2 instruction and ETCHREG1 registration in the same Solana transaction. The registration fixes the mint, creator, minimum burn, decimals, pair, rules version, and nonce. Etch verifies the finalized launch and mint authorities before indexing it.

Qualifying burns

A qualifying event is a genuine SPL Token or Token-2022 burn for the registered mint, signed by the token-account authority, at or above the collection minimum. The same transaction must contain the matching ETCHBURN1 intent. Transfers to dead addresses do not qualify.

Canonical receipt

The receipt commits to the Solana cluster, mint, burn transaction, instruction index, burner, raw integer amount, slot, collection registration, optional destination commitment, and protocol nonce. Etch canonicalizes the payload and hashes it with SHA-256.

Monero payload = "ETCH01" || receipt_hash[32]

Privacy boundary

The Monero transaction stores a recognizable public commitment. That can create metadata patterns and is not equivalent to making the original Solana activity private. Etch minimizes the payload to a version tag and one 32-byte digest.

Independent verification

The validator CLI does not use the Etch database. It can verify a receipt offline, re-fetch the finalized registration and burn from Solana RPC, and independently decode a submitted Monero transaction. Each receipt reports its actual pending, submitted, or confirmed anchor state.

Authority and custody

Etch does not hold wallet keys, tokens, or launch funds. Your wallet signs the reviewed transaction. A burn is permanent and cannot be undone, reversed, or refunded.