Which Dogenals protocol should I use?

A practical map for builders and indexers. Dogenals is the Era 2 standards body — Doginals are historical; continuous inscription numbering is preserved.

Start here: CORE_SUITE.md (simplified launch suite).

Use Ðunes for new fungibles. Classic DRC-20 is legacy — Dogenals indexers stay clean; there is no wrap/burn-to-Ðunes program. Compare Ðunes vs Treats. ÐSwap Core ships with Era 2; ÐAMM and ÐLend are Phase 2.

See also: INDEX.md, dogenals-protocols-comparison.md, drc721-and-dmp.md (DRC-721 vs ÐMP).

Quick Decision Tree

What are you building?
│
├── New fungible token (default)
│   └── → Ðunes (UTXO-native hero standard)
│
├── Non-arbitrary / NAT-style commodity (supply from block data)
│   └── → Ðune + DMT claim sidecar (`p:"dunes" op:"dmt-claim"`) — flagship $BITS; see protocols/dunes/DMT.md
│
├── Rare sats–style koinu identity / rarity tiers
│   └── → Rare Koinu (indexer FIFO; no p marker)
│
├── Meme launch / Black Doge lane ($NOIZ-style)
│   └── → ÐogeTreats (p:"dt" OP_RETURN)
│
├── Legacy DRC-20 balance (existing holder)
│   └── → Hold as-is (read-only); no new deploys; no wrap to Ðunes
│
├── Programmable ZK assets (experimental)
│   └── → Charms (opt-in only)
│
├── Fundraising campaign or community grant
│   └── → ÐFund
│
├── Token launch with bonding curve / fair distribution
│   └── → ÐLaunch (graduates to Ðunes)
│
├── NFT / Doginal marketplace (list, auction, offer, settle)
│   └── → ÐMP  (collection membership ≠ DRC-721 parent proof — drc721-and-dmp.md)
│
├── Native ord trailer (parent, delegate, traits) on a piece
│   └── → DogeRelics Core (DRC-721). Add ÐMP when you list / register a collection.
│
├── Retire a junk Doginal so ord no longer tracks a live owner
│   └── → BurneÐ product — circulating burn TL;DR: out of circulation forever; not erase; not burn address — docs/INCINERATOR.md
│
├── Live / private OTC deal (webcam, Discord, chat) — cheap on-chain receipt
│   └── → DOTC (`dotc|1|…` OP_RETURN). Optional later ÐMP settle for richer provenance.
│
├── Swap DOGE for Ðunes or ÐogeTreats / provide liquidity
│   └── → ÐSwap Core (constant-product pools; see protocols/dswap/CORE_LITE.md)
│
├── Public social (posts, react/tip, follows, threads)
│   └── → Ðocial only (Ð:SOC) — see docs/SOCIAL_LAYER.md
│
├── Profile picture / profile audio for a wallet
│   └── → ÐPFP / ÐPFA (identity — not Ðocial; dogex GET /api/profile/:address)
│
├── .doge name / on-chain website (jon.doge) — holdable, transferable
│   └── → DNS (inscription name object — not ÐN05, not Ð𝕏, not OP_RETURN)
│
├── Nostr name (bob@dogenals.com / NIP-05 purple check)
│   └── → ÐN05 (NIP-05 names on Dogecoin — not Ðignal, not Ð𝕏)
│
├── Encrypted on-chain messages
│   └── → Ðignal (Ð:DIG + encrypted inscriptions)
│
├── Public guestbook / message to Earth, Moon, Mars, or humanity
│   └── → Ð:WOW (WOW SIGNAL) — protocols/wow/spec.md · app jonheaven/wow-signal
│
├── On-chain X identity and reputation
│   └── → Ð𝕏 + ÐRep
│
├── DAO proposals and weighted governance
│   └── → ÐogenalÐAO (ÐRep × ÐLock × ÐVow × signals_consistency)
│
├── DEX / AMM / Lending
│   └── → ÐSwap Core now · full ÐSwap + ÐAMM + ÐLend → Phase 2 (deferred)
│
├── Cross-protocol indexer
│   └── → Index core suite first; legacy DRC-20 read-only
│
└── Something new / unsure
    └── → Open a [protocol-proposal] issue and follow SPEC_TEMPLATE.md

ÐFund — Fundraising on Dogecoin L1

ÐFund

Best for: Projects, communities, and individuals running on-chain fundraising campaigns that need to accept contributions in any form — DOGE, DogeTokens, Ðunes balances, DogeRelics, Koinu Relics, or ÐMaps block-title claims.

Choose ÐFund if:

• You want to raise funds for a project, grant, or community initiative with on-chain transparency
• You want donors to be able to contribute their existing Dogenals assets (not just DOGE) via Donate-by-Sale
• You want automatic contribution reputation (ÐRep) that rewards donors and makes giving a visible identity signal
• You want to define reward tiers (DogeRelics airdrops, token mints, allowlist spots) for contributors
• You want Ð𝕏 reputation gating to keep campaigns legitimate and sybil-resistant

How Donate-by-Sale works:

A donor lists one of their Dogenals assets for sale with the proceeds going to the campaign. A buyer purchases the asset; the DOGE payment routes automatically to the campaign beneficiary. The donor contributed their asset’s market value. The buyer got an asset. The campaign got funded. All of it verifiable on-chain via PSBT settlement.

ÐRep — Contribution Reputation:

Every verified contribution earns an on-chain ÐRep attestation (via ÐMS). Contributions accumulate across campaigns to unlock Bronze → Silver → Gold → Platinum donor tiers, non-transferable badge inscriptions, and creator-defined perks. Donors build a permanent, portable contribution reputation linked to their Ð𝕏 identity.

What ÐFund does not do:

• ÐFund does not custody funds — all DOGE routes directly to the campaign beneficiary address on-chain
• ÐFund does not guarantee reward fulfillment — tiers are on-chain commitments, not escrow
• ÐFund does not issue fungible tokens — use ÐLaunch or DogeTokens for token-based reward mechanics

Full spec: spec/protocols/dfund/spec.md

ÐLaunch — Token Launches on Dogecoin L1

ÐLaunch

Best for: Projects that want a bonding curve launch with graduation mechanics, ticker protection, and reputation gating — all natively on Dogecoin L1.

Choose ÐLaunch if:

• You want a fair distribution mechanism with a deterministic on-chain bonding curve
• You want reputation gating (via Ð𝕏) to prevent sybil launches and scam entries
• You want ticker exclusivity enforced at the protocol level
• You want automatic graduation to DogeTokens for secondary market trading
• You want a true L1 Dogecoin launch — not a Solana fork with Doge branding

What ÐLaunch does not do:

• ÐLaunch does not custody funds — all economics are inscription-encoded and indexer-verified
• ÐLaunch does not replace ÐMP — graduated tokens trade through ÐMP marketplaces
• ÐLaunch does not require bridges, wrapped assets, or cross-chain dependencies

Reference implementation: Drok

Full spec: spec/protocols/dlaunch/spec.md

Legacy classic DRC-20 (inscription DogeTokens)

Status: Deprecated for new deploys · Read-only for existing holders · No wrap to Ðunes

Classic inscription DRC-20 uses a two-step transfer: inscribe a transfer, then send that inscription. That design:

• Confuses normal users and wallets (available vs transferable balance)
• Costs extra fees and chain space per send
• Invites front-running and ticker-squatting games
• Bloats indexers for a fragmented, insider-heavy token layer

There is no clean fix that turns two-step into one-step without either breaking existing balances or adding wrapper complexity that is just a new standard in disguise.

What we do instead:

Who pushes back? Often early ticker claimants and mint-out projects with bags to defend — not the broader community. Honor the Doginals spark; build Dogenals for everyone going forward.

Full legacy spec: spec/protocols/dogetokens/README.md · Hero fungible: spec/protocols/dunes/README.md

Fungible Token Standards — Detailed Guide

DogeTokens (classic inscription DRC-20) — DEPRECATED

Status: Legacy read-only. Do not launch new tokens on classic inscription DRC-20.

For existing holders: Balances may remain visible. There is no wrap to Ðunes. New launches and Era 2 features use Ðunes or ÐogeTreats.

Why deprecated:

• Two-step transfer process (users must first create a transfer inscription, then send it)
• Higher on-chain footprint (inscriptions are permanent)
• More complex indexer required (tracking available vs. transferable balance)

Full spec: spec/protocols/dogetokens/spec.md

ÐogeTreats

Best for: Communities that want to bark fungible tokens onto Dogecoin with one-step transfers and normie-friendly branding. Companion lane to Ðunes — see DUNES_VS_TREATS.md.

Choose ÐogeTreats if:

• You want the lowest possible on-chain footprint
• You want single-step atomic transfers (no locked “transferable” balance)
• You are launching at or after Dogenals genesis (block 6_142_069)
• You want a dedicated "p":"dt" wire namespace — no confusion with inscription DogeTokens

Tradeoffs to accept:

• Requires an archive (non-pruned) Dogecoin node — OP_RETURN data can be pruned
• Newer ecosystem (indexer and wallet support still rolling out)
• 83-byte scriptPubKey cap (Core MAX_OP_RETURN_RELAY) — no room for metadata in the operation itself (use ÐMS / ÐLaunch for rich data)

Full spec: spec/protocols/ÐogeTreats/spec.md

Ðunes

Best for: Projects that want UTXO-native token ownership, similar to Bitcoin Runes. Default Era 2 fungible.

Not sure vs Treats? See DUNES_VS_TREATS.md.

Choose Ðunes if:

• You want token balances bound to UTXOs rather than tracked in an external database
• You want divisibility control (0–38 decimal places)
• You want a token model where composing UTXOs composes balances naturally
• You are building a product that needs to integrate with UTXO-aware wallets

Tradeoffs to accept:

• Requires understanding the edict/runestone model (more complex than JSON operations)
• Risk of accidental burns (unallocated input balances are permanently burned)
• Smaller Dogecoin-specific ecosystem than DogeTokens

Full spec: spec/protocols/dunes/spec.md

NFT & Marketplace — ÐMP and DRC-721

They compose. They are not two encodings of the same job. Full map: drc721-and-dmp.md.

DRC-721 (DogeRelics Core)

Best for: Native tags on one inscription: parent, delegate, properties.

Choose DRC-721 if:

• You need a child piece to point at a collection / parent inscription
• You want a display delegate or CBOR title/traits on the envelope
• You will (optionally) verify parentage by spending the parent UTXO in the child’s first reveal

What DRC-721 does not do:

• It does not register a collection slug, supply, or royalty
• It does not list or settle sales
• Tag 3 / parent without a parent UTXO spend is claimed, not spec-verified

Full spec: spec/protocols/dogerelics/README.md

ÐMP (Doginals Marketplace Protocol)

Best for: Anyone building a Doginals NFT marketplace, aggregator, or provenance tracking system.

Choose ÐMP if:

• You are building a marketplace that lists and settles Doginals sales
• You want buyers and sellers to be discoverable across multiple platforms
• You need on-chain verification that a sale actually happened (settlement verification)
• You want to track ownership history of a specific Doginal
• You want auction support (time-based, seller-can-accept-early, no-early-accept)
• You want offer/counter-offer negotiation flows
• You want a collection manifest (slug, supply, royalty). criteria.mode: "parent" is a membership rule, not DRC-721 UTXO proof.

What ÐMP does not do:

• ÐMP does not custody funds or NFTs
• ÐMP does not issue tokens
• ÐMP does not prove a child is spec-verified DRC-721
• ÐMP does not prevent a seller from listing the same item on multiple platforms (but settlement verification catches double-sells)

Full spec: spec/protocols/dmp/spec.md

ÐMP DogeTag Offers

Best for: Marketplaces or buyers that want to send lightweight buy-interest signals to a wallet without requiring the recipient to be connected to a marketplace.

Use DogeTag Offers when you need wallet-detectable pings, optional sound hints, and anti-spam via small DOGE attention outputs. Use full ÐMP offer when you need normal marketplace offer state.

Full spec: spec/protocols/dmp/dogetag-offers.md

DOTC (Dogecoin OTC Deal Protocol)

Best for: Live or private inscription sales that need an atomic on-chain receipt without a full ÐMP inscription.

Choose DOTC if:

• Parties already agreed on price + inscription (webcam, Discord, Telegram, private chat)
• You want the receipt in the same transaction that moves the inscription UTXO
• You need ≤ 80 bytes of OP_RETURN data and zero forced marketplace fee
• You may optionally attach a ÐMP settle later that references the DOTC txid

What DOTC does not do:

• DOTC does not list, auction, or discover orders
• DOTC does not custody funds or replace wallet signing
• DOTC does not encode venue brands on-chain

Full spec: spec/protocols/dotc/spec.md

Public social — Ðocial (canonical)

Best for: Everything public and social on Dogecoin L1: posts, threads, follows, reacts, and Likes that tip the creator in DOGE. One protocol. Self-custodial. No platform-owned graph.

• Content → inscriptions "p":"Ð:SOC"
• Engage / follow → 30-byte Ð:SOC OP_RETURN (tip amount = UTXO to pay_to, not the signal)
• Private → Ðignal, not Ðocial
• Legacy ÐPulse / Doge Signals / ÐEcho → do not use for new wallets

North star: SOCIAL_LAYER.md
Spec: dsocial/spec.md · INTEGRATION.md · public: jonheaven/docial-spec

Encrypted Messaging — Ðignal

Best for: Encrypted collector-to-collector messages, private rooms, board-level whispers, marketplace negotiation context, and wallet-native communication that should be permanent but not publicly readable.

Ðignal uses Ð:DIG OP_RETURN signals for discovery, short messages, room announcements, and encrypted inscriptions for richer content. It is not anonymous by default; transaction graph metadata remains public. Public timelines → Ðocial only.

Full spec: dignal/spec.md

𝕏 link and reputation — Ð𝕏

Ð𝕏 (Ðoge𝕏ID pillar)

Best for: Builders who want an optional, voluntary public 𝕏 handle link + on-chain reputation (Ðoge𝕏ID pillar) for gating — not legal ID, not KYC.

Use Ð𝕏 if:

• You are building ÐLaunch and need reputation gating (Bronze / Silver / Gold / Platinum tiers)
• You want marketplace or creator flows to show an optional 𝕏-linked signal (sybil resistance, accountability for a public persona)
• You want creator permissions tied to on-chain reputation rules in this spec

Not Ð𝕏: Map parcels / H3 titles → ÐMaps (p: "Ð:MAPS"). Fuzzy presence, findable places, Earth/Moon/Mars pings → ÐGPS (p: "Ð:GPS").

Full spec: spec/protocols/dx/spec.md

.doge names — DNS

DNS (Dogecoin Name System)

Best for: A name you own as a Doginal (jon.doge), can sell or gift, and can point at a website or an on-chain HTML inscription.

Use DNS if:

• You want SNS / sats-names style names-as-objects on Dogecoin
• You need url (HTTPS) and/or site (HTML inscription) records
• You are not binding a Nostr pubkey (ÐN05) and not linking an 𝕏 handle (Ð𝕏)

Do not put DNS in OP_RETURN. That would make names non-transferable. See dx/spec.md §11.

Full spec: spec/protocols/dns/spec.md

Nostr names — ÐN05

ÐN05 (NIP-05 on Dogecoin)

Best for: Binding a Nostr pubkey to a first-come localpart so Nostr clients can resolve bob@dogenals.com via NIP-05.

Use ÐN05 if:

• You want an OP_RETURN Bot–style name etch on Dogecoin (N05 magic)
• You need /.well-known/nostr.json to be a projection of dogex, not a second registry
• You are not sending messages (Ðignal) and not linking an 𝕏 handle (Ð𝕏)

Full spec: spec/protocols/dn05/spec.md

Metadata and RWA References — ÐMS

ÐMS (Dogenals Metadata Standard)

Best for: Builders who need shared metadata fields, verifiable file references, attestations, or Real World Asset (RWA) disclosure records that can attach to ÐMaps titles, Koinu Relics, ÐMP collections, art inscriptions, or future Dogenals assets.

Choose ÐMS if:

• You need structured metadata that multiple indexers and wallets can understand
• You need to reference PDFs, images, legal documents, or media by hash
• You want an RWA disclosure model that does not falsely claim on-chain metadata equals legal title
• You want a metadata layer that composes with ÐMP marketplace records

What ÐMS does not do:

• ÐMS does not create legal title, custody, compliance, or regulated security status
• ÐMS does not settle trades; use ÐMP
• ÐMS does not replace ÐMaps or Koinu Relics title rules

Full spec: spec/protocols/dms/spec.md

Location — ÐGPS (parent) vs ÐMaps (titles)

ÐGPS (fuzzy presence + findable places, any body)

Best for: One location protocol for Earth, Moon, and Mars: coarse pings and home regions (privacy), plus dog parks / DOGE merchants at street-findable precision. Product globe = filters on this protocol (+ optional ÐMaps overlay).

Use ÐGPS if: you are publishing where — a coarse cell for a person, or a fine pin for a place — not who owns the block-title. Marker stays Ð:GPS — do not mint Ð:EARTH / per-planet protocols.

Full spec: spec/protocols/dgps/spec.md

FCFS titles — ÐMaps and Koinu Relics

ÐMaps (block-height parcels)

Best for: Builders who want a canonical, transferable title per Dogecoin block height, a deterministic H3 geospatial cell per parcel, ÐMP-compatible trading, and an optional visual / collector scoring layer (spec §17–§18).

Choose ÐMaps if:

• You are claiming or indexing one FCFS title per block_height (tier standard in v1)
• You want H3 recomputed from public rules (no trusted geo oracle for the cell)
• You will inscribe with the same Doginals v1–style model but prefer the dog witness envelope (Era 2); ord remains a valid carrier where your indexer documents Era 1 support
• You want the familiar social label <height>.dogemap (often shown as #<height>.dogemap) as a display convention alongside title.block_height

Principles (informative) — decentralized validation, fair FCFS + friction, trusted recomputation, minimal core with optional extensions — are spelled out in spec/protocols/dogemaps/spec.md §1.

Comparison: dogemaps-koinu-titles.md (block title vs transaction title).

Full spec: spec/protocols/dogemaps/spec.md

Koinu Relics (transaction-bound titles)

Best for: FCFS titles keyed to transaction / chain position rather than block height. See the comparison doc above and spec/protocols/koinu-relics/spec.md.

Rare Koinu

Best for: Collectors, wallet developers, and indexer builders who want to identify and track koinu with special historical significance.

Use Rare Koinu if:

• You want to display rarity badges for koinu in a wallet UI
• You are building a marketplace where rare koinu can be listed separately from regular DOGE
• You want to track which UTXOs contain Mythic, Legendary, Epic, Rare, or Uncommon koinu
• You are building a full-chain indexer and want to include ordinal tracking

Key difference from Bitcoin Rare Sats:

• Dogecoin’s Digishield difficulty adjustment (every block) means there is no natural “Rare” tier equivalent to Bitcoin’s difficulty-period sats — the Rare tier in Dogenals Rare Koinu uses calendar-year milestones in the fixed-reward era instead
• Dogecoin had real epoch boundaries (7 reward reductions before the fixed era) that serve as Epic/Legendary anchors — these are as historically meaningful as Bitcoin halvings
• Early epochs (blocks 0–144,999) had random coinbase rewards, requiring a full blockchain scan to determine exact koinu starting numbers

Requires: Full indexing from block 0 (genesis). Cannot be added on top of an inscription-only indexer.

Full spec: spec/protocols/rare-koinu/spec.md

I’m Building an Indexer — Which Should I Implement First?

If you are new to the Doginals ecosystem: Start with Ðunes and ÐSwap Core. That is the Era 2 default path for fungibles and liquidity.

If you maintain legacy data: Keep classic DRC-20 read-only if you already index it — do not prioritize new deploy support. There is no wrap program.

If you want the most impactful contribution: Build a ÐMP indexer. There is currently no production-quality open ÐMP indexer. A working indexer enables marketplaces to go live.

If you want the easiest starting point: Build a ÐogeTreats indexer. The parsing logic is among the simplest DogeTokens metaprotocols. See implementations/ÐogeTreats/ for the reference validator.

If you are building a launchpad: Implement ÐLaunch indexing alongside Ð𝕏 reputation verification. Reference implementation: Drok.

Protocol Comparison Summary

See also: comparisons/dogenals-protocols-comparison.md | README.md