docsReference LibraryWhich Protocol

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; optional light migration. Compare Ðunes vs Treats. ÐSwap Core ships with Era 2; ÐAMM and ÐLend are Phase 2.

See also: INDEX.md, dogenals-protocols-comparison.md.


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)
│   └── → ÐMT (p:"dmt") — reusable; flagship $BITS; see docs/DMT_AND_RARE_KOINU.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)
│   └── → Read-only indexer + migrate to Ðunes (no new deploys)

├── 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

├── 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)

├── Encrypted on-chain messages
│   └── → Ðignal (Ð:DIG + encrypted inscriptions)

├── Native ord trailer (parent, delegate, traits)
│   └── → DogeRelics Core + ÐMP when listing

├── 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 · Migrate 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:

ActorPath
HoldersWallets show legacy balances; one-way migrate to Ðunes (burn/wrap + optional ÐRep bonus)
New launchesÐunes (default) or ÐogeTreats (p:"dt") — not classic DRC-20
IndexersRead-only classic balances; reject new deploys post policy
Marketplaces / poolsEra 2 features prioritize Ðunes and ÐogeTreats

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 · Light migration: MIGRATION_DRC20.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 remain visible; migrate to Ðunes for one-step transfers, ÐSwap Core pools, and Era 2 marketplace features.

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)
  • 80-byte hard limit — 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

Ð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: 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


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


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


Ð𝕏 (Ð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, or fuzzy geo → use ÐMaps (p: "Ð:MAPS").

Full spec: 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: 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 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 for migration — do not prioritize new deploy support.

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

DogeTokens (legacy)ÐogeTreatsÐMSÐMPÐunesÐLaunchÐFund
Asset typeFungible tokenFungible tokenMetadata / RWA refsNFT marketplaceFungible tokenLaunchpad projectCampaign / pledge
Transfer steps21N/A1 (settle tx)1 (edict)1 (buy/graduate)1–2 (pledge or donate-sale+settle)
On-chain footprintHighLowMediumHighLowMediumMedium
Metadata supportYesNo (use ÐMS)Primary purposeYesLimitedYes (via ÐMS)Yes (via ÐMS)
Indexer complexityMediumLowMediumHighMediumHighHigh
Ecosystem maturityMost establishedLaunch draftDraftEarlyGrowingLaunch draftLaunch draft

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