DRC-20

The three operations

Deploy is a birth certificate. It does not credit anyone. It tells later mints the rules: tick, max, optional lim (per-inscription mint cap), optional dec (decimals, default 18 in the published tables).

{ "p": "drc-20", "op": "deploy", "tick": "dogi", "max": "21000000", "lim": "1000" }

Mint credits the owner of the mint inscription, if the ticker exists, supply remains, and amt does not exceed lim. Using an inscription service can credit the service first — the indexer is literal about who held the mint.

{ "p": "drc-20", "op": "mint", "tick": "dogi", "amt": "1000" }

Transfer is a two-part trick copied from BRC-20. First inscribe a transfer intent to your own address. Then send that inscription. The first send of a valid transfer inscription is the one that moves the balance. A second send of the same object is, in the usual state machines, a souvenir.

{ "p": "drc-20", "op": "transfer", "tick": "dogi", "amt": "100" }

Not a contract

There is no approve(), no allowance, no on-chain totalSupply you can query from Core RPC. Content types accepted for DRC-20 events are typically text/plain and application/json. A JPEG of the same JSON is, in a strict indexer, decoration. First-seen deploy wins inside a given indexer. A second deploy of the same tick is invalid there even if another indexer never saw the first.

Sources

Primary texts for this chapter. The full index lives on Doginals sources.

• drc-20 standard — drc-20.org
• Deploy drc-20 — drc-20.org