Inscription standard

The Inscription Standard says what a transaction is (a sale, a swap, a launch, a bridge deposit, a governance action). Marketplace and DeFi tags go on chain when assets move. A governance action is the inscription itself. Listings, offers, bids and cancels stay signed records.

The indexer reads Dogecoin Core. That index is the source of truth for the orbit.

The tag

{"ds":{"action":"<VERB>","ref":"<Doge Soft-issued id>"}}

• That's the whole tag. action is an UPPERCASE verb. ref names the record. Nothing else sits inside ds.
• Example: {"p":"drc-20","op":"transfer","tick":"DU$T","amt":"1000","ds":{"action":"BOND","ref":"…"}}
• The signature is on that record. It is a Dogecoin signmessage over the text Doge Soft ref record, a newline, then the JSON of the record. The orbit returns the record, the signer address, and the signature. Any Dogecoin wallet can check the signature against that signer. Doge Soft signs these records today. A partner record uses the same signmessage when the orbit issues one.
• Where it rides: for trades, the tag is an OP_RETURN note inside the trade transaction itself. That means no extra transaction, and Doggy Market and ord parsers ignore it.

Verbs

Marketplace

Anyone can run a marketplace on these seven verbs. The tag goes on the one transaction that spends the dog. One tag covers both sides. Price, seller and buyer are the outputs of that transaction.

{"ds":{"action":"BUY","ref":"r_1"}}

• Same shape for every verb. Swap BUY for AUCTION_SOLD, OFFER_ACCEPT, GIFT, BUNDLE, PARTIAL_FILL or COLLECTION_TRANSFER. It is one OP_RETURN of at most 80 bytes, appended after the seller's payment output.
• GIFT has no price. BUNDLE, PARTIAL_FILL and COLLECTION_TRANSFER name every dog those inputs moved.
• The ref is the long form of that sale. Doge Soft signs that record with the same Dogecoin signmessage after the outputs check. The indexer, reading Core, is the source of truth for the orbit.
• A listing, offer, bid or cancel is a signed record in that marketplace's own book. It is not an inscription, and it does not get a tag. Moving the dog anywhere else closes the listing.
• Who signs. The seller signs SIGHASH_SINGLE|ANYONECANPAY (0x83) on their payment output. The buyer, bidder or offer signer uses SIGHASH_ALL, so the tag is already in the template before they sign.
• Royalties are the collection record. A claim inscribes one creator-signed LAUNCH_DEPLOY record with royalty_bps and pay_to. Every marketplace on these verbs reads that inscription. The sale tag does not carry a royalty. A marketplace fee stays with that marketplace.
• The orbit lists these verbs with the rest of the standard. A listing is not an inscription.

Launchpad and art

• The art is a plain Doginal: "ord" <parts> <content-type> <n-1> <chunk> ? <0> <chunk>, with 240-byte chunks. Big files span a chain of reveal transactions (multi-reveal is live), and the inscription id is the first reveal's txid + i0. Every Doginals wallet, market and explorer shows it normally.
• LAUNCH_DEPLOY is a collection record: {"ds":{"action":"LAUNCH_DEPLOY","ref":"lp_<slug>"},"name":"?","supply":100,"sig":"?"}. sig is the creator's signmessage over that collection record. The ref names the Doge Soft ref record, signed with signmessage the same way as every other verb. A launch may also store a royalty for its own buyers. That number stays on the collection record and is not copied into a marketplace tag.
• LAUNCH_MINT is the tag on the buyer's mint transaction. Lazy mints inscribe nothing until someone buys.

Governance

A collection, a trait, or a council can inscribe its own organization. The indexer rebuilds it from Dogecoin Core. That rebuild is the source of truth. The organization picks the electorate in GOV_CREATE. The governance id is that inscription's id.

• Body. application/json. ds is still only action and an optional ref. The rules sit beside it.
• The orbit checks the body and returns the application/json and its SHA-256. You inscribe that JSON with your wallet. A ref on it names the same signmessage record as every other verb.
• Electorates. wallet_allowlist with one_wallet is the council the indexer can tally now. doginal_holder and doginal_trait are valid founding configs for a collection or a trait. Those ballots are stored and are not counted until holder-at-snapshot is indexed. open is not counted.
• Shares. asset_units names a unit_ledger_ref. This category does not mint that ledger. A 100×100 grid is 10,000 units in that later ledger, not 1,000 members, and not a governance verb.
• Tally. Quorum holds when participating × 10000 ≥ quorum_bps × eligible_weight. The proposal passes when quorum holds and yes × 10000 ≥ approval_bps × (yes + no) and at least one yes or no was counted. Abstain joins quorum only when the founding config says so. Set approval_bps to 5001 for a strict majority of yes against no. The indexer recomputes this. A finalize inscription that disagrees is rejected.
• Ballots. The voter string is not a signature. The indexer counts a ballot when that address holds the vote inscription and is on the allowlist. The first in-window ballot sticks. Order is block height, then transaction id, then inscription index.
• Custody. A passed proposal authorizes a spend. Two custodians of a 2-of-3 still sign. Replacing a signer moves the coins to a new output. GOV_EXECUTE records a transaction id and does not mark the effect verified. Delegation is recorded and is not applied to weight yet.
• Read it. Explorer · Governance.

Not part of this standard

• Dogecoin Names keeps its own signed format ("p":"dns" with a registrar sig). See Names.
• DRC-20 deploy, mint and transfer are their own protocol. They stay positional, so every DRC-20 wallet reads them.

Sizes

• Each push is at most 520 bytes (Dogecoin's limit). Doginals content uses 240-byte chunks, at most 1,500 bytes of pushes per reveal, and each reveal's scriptSig stays under 1,650 bytes.
• An OP_RETURN note is at most 80 bytes, and only one is allowed per transaction.

Signing with the wallet

window.dogesoft.signPsbt(psbt, options) returns { hex, psbtHex, signedPsbtHex, psbtBase64, signedPsbtBase64, txHex? }. hex, psbtHex and signedPsbtHex are the signed PSBT in hex; psbtBase64 and signedPsbtBase64 are the same PSBT in base64. txHex is the broadcast-ready raw transaction, returned when finalize or autoFinalize is set and every input is signed. See PSBTs.