CINDER / READ BEFORE BURNING

How CINDER works

A burn plus a receipt

CINDER 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

A CINDER launch places the Pump create_v2 instruction and its registration commitment in the same Solana transaction. The registration fixes the mint, creator, minimum burn, decimals, pair, rules version, and nonce. CINDER 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 signed burn 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. The payload is canonicalized and hashed with SHA-256.

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. CINDER minimizes the payload to a version tag and one 32-byte digest.

Independent verification

The validator CLI does not use the application 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

CINDER 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.

Advanced technical compatibility

CINDER's current canonical receipt and commitment encoding retains the internal ETCH v1 protocol identifier and the ETCHREG1, ETCHBURN1, and ETCH01 domain tags for backward compatibility with existing receipts and independent validators.

See integration status →