BurneÐ — product orientation (not a metaprotocol)

Product name: BurneÐ (spoken “burned”; Ð = last letter)
Surface: dogenals.com / dogecoin.dog (web-com) + @dojak/web
Status: Product draft · greenfield
Route: /burn

BurneÐ is the storefront product for retiring live Doginal / ord v1 inscriptions so well-behaved indexers (dogex, wonky-dogeord, Bitcoin-ord ports) drop them from circulating ownership. It is not a new p: metaprotocol and MUST NOT mint a marker such as Ð:INCINERATOR.

Plain language (read this first)

Dogecoin cannot delete a confirmed transaction. The JPEG/JSON from an inscription reveal stays in block history forever. Anyone with a full history can re-index the bytes.

What wallets, marketplaces, and ord-style indexers treat as “your NFT” is not the picture alone — it is the live satpoint: which UTXO currently carries that inscription. BurneÐ spends that carrier into a valued OP_RETURN. Dogecoin Core treats OP_RETURN as unspendable and does not keep that output in the UTXO set. dogex then records TransferReason::Burn and clears the live owner.

So:

Useful slogan: out of circulation forever.
Bad slogan: never existed / erased from the chain / cleaner chain / stronger DOGE.

This is not a client hide-list. It is an on-chain spend. It is also not “send to a burn address” (see below).

Why the product is useful

Three real jobs — all honest:

1. Wallet & marketplace hygiene — dump scam mints / junk from address indexes and listings.
2. Postage retirement — the DOGE glued to the inscription UTXO dies with the satpoint.
3. Cultural / scarcity signal — communities can prove pieces left circulating supply (same social lane as ÐLocker time-locks, but irreversible).

Wrong pitch kills trust: do not sell BurneÐ as ecology-of-the-blockchain or consensus hardening. Archival nodes keep every reveal forever; the burn tx even adds a few hundred bytes.

Honest claims (use these; drop the rest)

Ad / marketing scorecard

Cultural / narrative use (same lane as ÐLocker)

BurneÐ and ÐLocker are both on-chain commitment theater communities can share to push a project narrative. Difference is permanence:

Example: 10k PFP collection

If holders burn 50 pieces of a 10k set and share explorer links:

• Honest indexers stop treating those ids as owned inventory.
• Live float for trading / holding is thinner.
• Reveal art for those ids still exists in history (provenance feature, not a bug).
• Price is never guaranteed — the product only supplies a provable scarcity story.

Doginal Dogs and other blue chips: anyone who can spend the carrier UTXO can burn it. There is no collection allowlist, ban, or special exemption. A Doginal Dog burns the same as spam junk. Socially that is a stronger sacrifice signal (and a worse personal loss).

Storefront share copy supports two voices after burn:

• Community — scarcity / out-of-circulation narrative + proof link.
• Technical — valued OP_RETURN, Core-unspendable, not a burn address.

Taxonomy (MUST keep clear)

Rule of thumb: if the inscription should leave every honest ord collection / address index, the carrying UTXO must become unspendable at Dogecoin consensus. That is OP_RETURN. A well-known burn address is still a live coin.

There is no first-class burn address in Dogecoin Core. Community burn addresses are ordinary destinations with (hopefully) no known private key — still UTXOs. That is abandonment, not consensus burn. If the key is ever found, the “burned” inscription comes back.

Dogecoin Core facts (from ./dogecoin/)

Cite these when someone says “just send it to a burn address — that’s the Dogecoin way”:

1. CScript::IsUnspendable (script/script.h) — script beginning with OP_RETURN is guaranteed to fail; Core treats it as unspendable.
2. CCoins::ClearUnspendable (coins.h) — unspendable outs are nulled and not kept in the UTXO set (“provably prunable”).
3. CTxOut::IsDust (primitives/transaction.h) — returns false for unspendable scripts, so non-zero value on OP_RETURN is allowed (postage can die there).
4. Standardness (policy/policy.cpp) — at most one TX_NULL_DATA / OP_RETURN per tx; script size capped (MAX_OP_RETURN_RELAY = 83).
5. createrawtransaction "data" (rpc/rawtransaction.cpp) — builds a zero-value OP_RETURN. Fine for messages; wrong for inscription burns (see sat assignment trap).

Mechanism: true circulating burn

Dogecoin has no protocol-level erase. Indexers treat “the NFT” as the live satpoint. dogex records TransferReason::Burn when that satpoint lands on a script with no P2PKH/P2SH hash160 — including OP_RETURN and fee-lost (vout = u32::MAX).

Ord sat assignment (the trap)

Inscriptions follow koinu offsets, not “first output that looks like OP_RETURN.” A zero-value OP_RETURN absorbs zero sats, so the inscribed koinu can skip it and land on change — not burned.

Canonical BurneÐ layout (one or many inscriptions):

1. Inputs (first): each inscription-carrying UTXO, in order.
2. Inputs (rest): plain DOGE for the miner fee (never other inscriptions / Ðune bags).
3. Output 0: OP_RETURN + short tag, value = sum of inscription input values (postage destroyed).
4. Output 1 (optional): change ≥ soft dust (0.01 Ð) back to the burner.

dogex / wonky-dogeord assign offset 0 … postage-1 into output 0.

Optional UTF-8 tag: ÐI (U+00D0 I) — product signature only; not required for the burn. ÐLotto carrier burns may use ÐB. Any unspendable dest is still a burn in dogex.

What we will not do

• Send to DSomethingBurn… vanity addresses.
• Deduct the miner fee from inscription postage (can move the sat onto change).
• Claim the JPEG/JSON is gone from the chain.
• Claim the burn “cleans” or “strengthens” the Dogecoin network.
• Invent an envelope “burn” that leaves the UTXO in the wallet.
• Ban or special-case blue-chip collections.

Skeptic FAQ (copy-paste answers)

“You’re just hiding it from my wallet.”
No. Hide-lists are client-only. BurneÐ spends the carrier into Core-unspendable OP_RETURN. dogex sets owner_hash160 = none and logs TransferReason::Burn.

“The inscription still exists.”
Yes — the content does, in the original reveal. What ends is circulating ownership. Say that out loud.

“Just send it to a burn address.”
A burn address is still a spendable UTXO. OP_RETURN cannot be spent by anyone, ever. Core has no official burn address.

“Cleaner chain / stronger DOGE.”
Do not use those slogans. History is append-only. At best you prune a dust UTXO and clean live indexes.

“Is this useful then?”
Yes: hygiene, postage kill, irreversible retirement proof, community scarcity theater. Wrong pitch kills trust.

“Can a community burn to create bullish scarcity?”
Yes — same cultural lane as ÐLocker locks, but permanent. Honest line: out of circulation forever with explorer proof. Not never existed. Does not guarantee price.

“Can someone burn a Doginal Dog?”
Yes, if they hold and can spend the carrier. No collection protection in the product.

“What if a marketplace still shows it?”
Some UIs lag or ignore burn indexing. Truth is the spend + honest indexer (TransferReason::Burn). Ghosts are a client bug, not a resurrection.

Product shape on web-com

Nav: Tools → BurneÐ (beside ÐLocker; hub /tools)

Help copy and post-burn share must stay honest (community + technical templates).

Indexer / backend roles

command.dog does not need a product cache. Truth is the spend.

Related

• ÐLocker — time-lock (reversible after locktime); temporary commitment signal
• ÐLotto burn §5.5.1 — same circulating OP_RETURN pattern for tickets
• ÐSeals — indexer policy, not consensus freeze
• which-protocol — BurneÐ is a product, not a p: protocol