Which Dogenals protocol should I use?

A practical map for builders and indexers choosing a standard. Dogenals is the open standards ecosystem for Dogecoin L1 inscriptions — the complete protocol layer for tokens, NFTs, collections, marketplaces, identity, messaging, and launchpads.

Use existing community-adopted protocols when you need maximum compatibility. Use Dogenals launch-draft standards when building the next generation of wallets, marketplaces, indexers, and applications on Dogecoin.

See also: INDEX.md (every spec.md in one list), dogenals-protocols-comparison.md (side-by-side).

Quick Decision Tree

What are you building?
│
├── Fundraising campaign or community grant
│   └── → ÐFund (DOGE pledges + any Dogenals asset via Donate-by-Sale + ÐRep reward system)
│
├── Token launch with bonding curve / fair distribution
│   └── → ÐLaunch (Dogecoin L1 native; reputation-gated; graduates to DogeTokens)
│
├── Fungible token (coin, memecoin, utility token)
│   │
│   ├── Do you need rich metadata or large supply descriptions?
│   │   └── YES → DogeTokens (inscription-based)
│   │
│   ├── Do you want the simplest possible transfer UX (no two-step)?
│   │   └── YES → Universal DogeTokens (OP_RETURN-based)
│   │
│   ├── Do you want UTXO-native token ownership (like Runes)?
│   │   └── YES → Ðunes
│   │
│   └── Do you want the most wallet/indexer support today?
│       └── YES → DogeTokens
│
├── NFT / Doginal marketplace
│   └── → ÐMP (the only *marketplace* protocol in this set)
│
├── Lightweight offer pings that wallets can detect
│   └── → ÐMP DogeTag Offers (OP_RETURN signal + recipient DOGE attention amount)
│
├── Encrypted on-chain messages or negotiation context
│   └── → ÐWhisper (OP_RETURN signal + encrypted inscription content)
│
├── Native *ord trailer* (parent, delegate, traits — PRC-721–aligned, no JSON `p`)
│   └── → DogeRelics Core — combine with ÐMP for listings / `collection` when you need them
│
├── Shared metadata, file references, or RWA disclosures
│   └── → ÐMS (metadata layer; legal ownership remains off-chain unless separately proven)
│
├── NFT collection with provenance tracking
│   └── → ÐMP (collection) + DogeRelics Core (optional strong `parent` in script; see ÐMP v1.0+)
│
├── On-chain X identity and reputation
│   └── → Ð𝕏 (Ðoge𝕏ID) — verified handle + reputation tiers used across ÐLaunch and ÐMP
│
├── Conviction locking to weight trust/governance
│   └── → ÐLock — deterministic lock multiplier for long-term participation
│
├── DAO proposals and weighted governance voting
│   └── → ÐogenalÐAO — on-chain proposals + voting power from ÐRep × ÐLock × ÐVow × ÐPulse
│
├── Rare / collectible koinu (like Rare Sats on Bitcoin)
│   └── → Rare Koinu (ordinal numbering + FIFO tracking, Dogecoin-native tiers)
│
├── Block-height parcel title (one canonical claim per height, H3 cell)
│   └── → ÐMaps (`p: "dogemaps"`; `dog` witness preferred, `ord` valid where documented; social label `<height>.dogemap`)
│
├── Transaction-bound FCFS title (relic keyed to a tx / chain position)
│   └── → Koinu Relics (`p: "koinu-relics"`) — see [dogemaps-koinu-titles.md](../comparisons/dogemaps-koinu-titles.md)
│
├── Cross-protocol indexer or aggregator
│   └── → Index all protocols; see comparisons/ for field schemas
│
└── Something new / unsure
    └── → See protocols/future-protocols/README.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: 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: protocols/dlaunch/spec.md

Fungible Token Standards — Detailed Guide

DogeTokens

Best for: Projects that want the broadest compatibility with existing Dogecoin tooling and the largest established token ecosystem.

Choose DogeTokens if:

• You want your token visible in existing wallets that support DogeTokens
• You want your mint accessible through established DogeTokens platforms
• You need token metadata beyond just a ticker and supply (store it in the inscription content)
• Your users are already familiar with BRC-20 or DogeTokens UX

Tradeoffs to accept:

• 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: protocols/dogetokens/spec.md

Universal DogeTokens

Best for: Projects that want a lightweight footprint and simple atomic transfers, and are comfortable building or hosting their own indexer.

Choose Universal DogeTokens if:

• You want the lowest possible on-chain footprint
• You want single-step atomic transfers (no locked “transferable” balance)
• You are building a new indexer from scratch and want simpler parsing logic
• You want a simple, lightweight OP_RETURN token standard with no inscription overhead

Tradeoffs to accept:

• Requires an archive (non-pruned) Dogecoin node — OP_RETURN data can be pruned
• Smaller existing ecosystem (fewer wallets, explorers)
• 80-byte hard limit — no room for metadata or protocol extensions
• Shares "p":"drc-20" identifier with DogeTokens (indexers must distinguish by container type)

Full spec: protocols/universal-drc20/spec.md

Ðunes

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

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: protocols/dunes/spec.md

NFT & Marketplace — ÐMP

Ð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

What ÐMP does not do:

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

Full 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: protocols/dmp/dogetag-offers.md

Encrypted Messaging — ÐWhisper

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.

ÐWhisper uses Ð:W 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.

Full spec: dwhisper/spec.md

𝕏 link and reputation — Ð𝕏

Ð𝕏 (Ðoge𝕏ID pillar)

Best for: Builders who want an optional, voluntary link between a Dogecoin address and a public X handle, plus on-chain reputation tiers 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, or fuzzy geo → use ÐMaps (p: "dogemaps").

Full spec: protocols/dx/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: protocols/dms/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 protocols/dogemaps/spec.md §1.

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

Full 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 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: 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 DogeTokens. It has the clearest documentation, the most community tooling to compare against, and the largest set of real-world tokens to test with.

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 Universal DogeTokens indexer. The parsing logic is the simplest of any Dogenals protocol. See implementations/dmp/ for the Python reference implementation pattern.

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