DOGPACK/1

Status: draft-2, 2026-08-08. Chain: Dogecoin (doginal / ord-style inscription). Content type: text/plain;charset=utf-8. Sibling of BEACON/1, from which it takes its encoding, its forward-compatibility rule and its custody-is-authority model.

0. Why this exists

You buy a Doginal. It is yours. There is nowhere to write your name on it.

Everything a collector actually cares about — who owned it, why they bought it, what happened to it, who they gave it to — lives in Discord scrollback, in a marketplace's private database, or in somebody's head. All three go away. The inscription outlives every one of them and carries none of it.

DOGPACK is the smallest thing that fixes that: the holder of an inscription can attach a note to it, permanently, and nobody who comes later can take it down. The next owner writes theirs underneath. Ten owners later the piece carries ten statements by ten people who each actually held it, and the whole thing reads out of the chain with no website in the middle.

Packing a Doginal does not touch the Doginal. The original is never moved, never spent, never copied and never re-inscribed. A note is its own small inscription that names the original. The thing that is new is the papers, not the dog. Re-inscribing someone's artwork to annotate it would mint a permanent counterfeit of it, and cost more to do.

Nothing here depends on fdre.hankelsner.tech continuing to exist. A Dogecoin node plus any ord-style inscription index is sufficient. §16 is the list of things this protocol cannot do; read it before you trust a badge it prints.

1. Design rules

1. Plain text, line-oriented. If you can read the inscription, you can read the record.
2. Small. One record fits in a single data-bearing reveal. Target ≤ 480 bytes; hard cap 1000.
3. Forward compatible. An unknown key is preserved and ignored, never an error.
4. The chain is the record. Indexes, marketplaces and websites — including ours — are caches.
5. Authority comes from custody of the SUBJECT, not from an account, and not from custody of the note.
6. Nothing is ever superseded. There is no edit, no delete and no retraction, because the protocol contains no syntax capable of expressing one (§8).
7. A reader never drops a record. Disputed, unauthorised, malformed and unverifiable records are shown and marked, never silently omitted.
8. Every applied record is bound to its bytes. A record whose payload nothing committed to is never applied (§9.2).

2. Encoding

2.1 Normalisation, in this exact order

1. Strip at most one leading UTF-8 BOM (EF BB BF); if present, flag bom.
2. Split on LF (0x0A).
3. Strip one trailing CR from each line; if any, flag crlf.
4. Compare line 1 to DOGPACK/1 byte-for-byte, before any whitespace stripping. A leading space, a trailing space, a blank line or a comment before the magic means this is not a DOGPACK record.
5. From line 2 on, strip leading and trailing spaces and tabs.

The BOM and CR tolerances exist because both are invisible in every rendering a writer can see, and voiding a paid, permanent, honest record over three bytes nobody can see would be the cruellest failure this protocol could have. They are the only tolerances, and both are flagged.

2.2 Lines

KEY:VALUE

KEY matches [A-Z0-9]{1,8}. VALUE is everything after the first colon, with one optional leading space stripped, and may itself contain colons. A line with no colon, or an out-of-charset key, is ignored — never fatal. From line 2 on, blank lines and lines whose first non-space character is # are ignored.

2.3 Duplicate keys — first wins, with three repairs

First occurrence wins; later duplicates are preserved and ignored. First-wins is a shadowing surface, so:

• R — use the first syntactically valid occurrence; flag shadowed-key if an earlier invalid one was skipped.
• Z — more than one ⇒ treated as absent, flag ambiguous-signature. Never as verifying.
• A — more than one ⇒ treated as absent, flag ambiguous-delegate.

A signature or a write-grant that two conforming readers resolve differently is worse than none. The message lines 1–6 are six distinct keys, not repetitions of one, so this rule can stay absolute.

3. What a pack is

A pack is not an object. A pack is a set. The pack for an inscription is every DOGPACK/1 record naming it. Nobody creates a pack; the first note creates it by existing. There is nothing to own, nothing to transfer, and nothing to overwrite.

4. Keys

4.1 Permanently reserved — MUST NOT be written

P, S, ID, H, DATE, TS. Readers preserve and ignore them.

• P is BEACON/1's supersede pointer — "modify the record named here" — the one operation this protocol exists to forbid. Sharing the letter with an inverted meaning is how an implementer who shares a tokeniser between the two specs eventually shares a code path and silently destroys the guarantee. The letter is burned on purpose.
• S is BEACON's status. A note has no status; nothing about it can change.
• ID is BEACON's subject key. Ours is R, always an inscription id.
• H would be a content hash written in the payload — a hash the writer chose. §12.2 puts the digest in an output, where the transaction's own signatures cover it.
• DATE/TS are timestamps. Block position is the time. A self-asserted date a reader might sort by is the cheapest possible way to reorder an append-only record.

5. The subject — and every inscription-id-valued key

An inscription id MUST match, after lowercasing:

^[0-9a-f]{64}(i(0|[1-9][0-9]{0,3}))?$

A bare 64-hex value means index 0; writers SHOULD emit the explicit i<n> form. Readers MUST NOT accept i00, i0000, or an index above 9999 — a near-miss one reader files into your pack and another rejects is a switch an attacker flips to make two indexers disagree.

Normalisation applies to EVERY id-valued key — R, L, C and any future one — identically, and to BOTH sides of every lookup. Lowercase the hex; treat bare 64-hex and the same value with i0 as equal. Records are stored and re-served exactly as written; normalisation applies only to matching.

The scheme registers into BEACON/1's identifier registry as INSC, so a BEACON record can name an inscription with the same syntax and validation.

A subject that is not an inscription (a DRC-20 balance, a dune) has no single custodial outpoint, so §9's custody test is not computable and every note on one is INDETERMINATE with the terminal reason non-inscription-subject.

A subject may itself be a DOGPACK record — that is how you answer somebody. Such a record belongs to the replied-to record's pack, and a reader MUST NOT render it inline in the original subject's pack.

6. The message and the profile

1–6 are six ordered lines, joined with LF for display. T names a vocabulary for them; the default PLAIN assigns no special meaning. This is BEACON/1's six-line shape, deliberately: enough to say something real to a stranger, few enough that a record stays cheap.

7. Attributes — M

One key=value; list, ≤ 200 bytes total. Keys are [a-z0-9_]{1,16}; values must not contain ; or =. Unparseable pairs are preserved and ignored. Attributes are self-asserted claims by the writer, never facts about the artwork.

8. Append-only — enforced, not promised

There is no edit and no delete because there is no syntax for one. P and S are reserved specifically so that a future writer cannot express supersession by accident or by ambition.

• Ordering is (block_height, txid ascending). Nothing else. Intra-block order is explicitly meaningless: neither indexer this platform uses returns a transaction's position within its block, and an ordering key half the conforming readers cannot compute is not an ordering. A full-node reader MAY show true position as display-only and MUST NOT let it change any verdict.
• Q is advisory. It is what the writer believed; it never reorders anything. Two applied records sharing a Q are flagged same-number and neither is accused of anything.
• L must order strictly before its own record. An L naming something at or after it is flagged and ignored.
• A reader MUST NOT headline a gap computed from attacker-chosen integers. Gaps are reported from applied records only, and a number burned by a non-applied record is marked accounted-for, not missing.

9. Authority — who may append

9.1 The rule

The holder of the SUBJECT inscription at the height the note confirmed is authorised to append to it. Not the holder of the note. Custody of the piece is the right to write on its papers.

9.2 What binds a record to its bytes

Data pushed in a scriptSig is covered by no signature — the P2SH input is signed with the redeem script as subscript, so the payload pushes themselves are unsigned. Anyone watching the mempool could otherwise substitute the words of your note and have a conforming reader publish the substitute as your authenticated statement.

Therefore: every record MUST carry the §12.2 OP_RETURN memo, which is an output, and outputs are serialised into the signature preimage. A record whose payload no memo commits to is INDETERMINATE(unbound-payload) and is never applied. A memo whose digest does not match the payload is TAMPERED.

The record's author is derived from input 0's revealed redeem script, which MUST byte-match 0x21 <33-byte pubkey> 0xAD (0x75)*n 0x51, whose hash160 MUST equal the spent output's scripthash, and whose n MUST equal the data-push count. "Take the first data push" is not sufficient: the redeem script is attacker-chosen and only its hash is consensus-committed, so push(victimPub) OP_DROP push(attackerPub) OP_CHECKSIGVERIFY … impersonates any holder for the price of one inscription.

9.3 Z — the detached signature, over a CANONICAL input

Z is base64 (exactly 88 chars) of a 65-byte recoverable secp256k1 signature over 0x19 || "Dogecoin Signed Message:\n" || varint(len) || msg, where msg is:

sig_input := "DOGPACK/1\n"
           + for each KEY in CANON_ORDER present:   KEY ":" value "\n"
           + for each remaining key, sorted by (key, value): KEY ":" value "\n"

CANON_ORDER := R Q L N 1 2 3 4 5 6 M A B U T C X          (Z is never included)

Values are the parsed values, first occurrence only; id-valued keys appear normalised; every line ends in exactly one LF.

Signing a canonical reconstruction rather than the raw payload is deliberate. Raw bytes make authorship depend on details the signer does not control — key order, a trailing LF, a comment a relay adds — and in a relayed flow the modal failure was an owner's honest, paid note rendering as an unauthorised claim by the relay's own address.

Unknown keys ARE included, in the sorted tail, so a relay cannot inject anything — known or unknown — without breaking the signature, and an old verifier and a new one produce identical bytes.

A Z that is present and fails to verify is signature-broken ⇒ INDETERMINATE. It MUST NOT fall back to payer-derived authority and MUST NOT be scored UNAUTHORISED: a broken signature is evidence of alteration, never evidence of a claim by whoever paid.

9.4 Delegation is epoch-scoped

A grants append rights to another address for the current custody epoch only. Any transfer of the subject automatically revokes every outstanding delegation. Otherwise the seller — or a marketplace that briefly held the piece — keeps a permanent write channel inside the buyer's pack. A:NONE revokes explicitly.

9.5 Verdicts

A disputed record that is visible is safer than one that is invisible.

10. Cost

Measured against dogewallet-core.js buildInscription at the 0.20 DOGE/kB floor, with the memo attached. fee ≈ 0.1444 + 0.000205 × payload_bytes DOGE, linear in rate, within 0.25% across the whole range.

The cost does not grow with the length of the thread. A note chains by reference, so the tenth note on a pack costs the same as the first. Carrying every prior note forward in each new record would have made a ten-note pack cost roughly five times as much and a hundred-note pack impossible.

11. Wire format

11.1 The envelope

The ordinary doginal envelope, unchanged, so every existing Dogecoin inscription indexer already sees DOGPACK records: push("ord"), push(nParts), push(contentType), then per part push(partsRemaining), push(partBytes), with parts ≤ 240 bytes, revealed across a commit/reveal chain. The final reveal's output 0 carries 0.001 DOGE and is the inscription. A conforming record fits in exactly two transactions.

11.2 The memo (mandatory)

The reveal MUST carry exactly one OP_RETURN of 74 bytes:

"DOGPACK1"  (8)  ||  sha256(payload)  (32)  ||  subject txid  (32)  ||  index  (2, big-endian)

Fixed-width binary, not ASCII — an ASCII form mis-parses every non-zero subject index. The subject is repeated here so an indexer can find every pack for a piece by scanning OP_RETURNs alone, with no ord index at all.

Implementers whose wallet quarantines outputs of transactions carrying an OP_RETURN must whitelist the 8-byte DOGPACK1 prefix before writing a pack, or the change from their own reveal becomes unspendable to them.

11.3 Discovery

By the magic line, never by content type — a note inscribed under some other MIME type would otherwise be invisible to every conforming reader while looking perfect in every viewer. Two independent discovery paths: inscriptions whose first line is DOGPACK/1, and transactions whose OP_RETURN begins DOGPACK1.

12. What must not be written

Permanent and public are the same sentence here.

• No home address, no government identity number, no payment details, no passwords, no seed phrase.
• Nothing you would not want attached to that piece forever, in front of everyone who ever looks at it.
• Nothing about somebody else that you would not say with your name on it. N is self-asserted, but the custody of the subject that authorised your note is not.
• There is no delete. Not by you, not by us, not by a court order we would like to honour. An update can add context; nothing can erase.

13. Worked example

A first note by the owner:

DOGPACK/1
R:6f1c9a2be4d3c5a7089b2f4e1d6c8a3b5e7f9021d4c6b8a0e2f4d6c8b0a2e4f61i0
Q:1
N:Hank
1:Bought this the week the shelter opened. First one I ever adopted.
2:Named him Biscuit. He sits on the shelf above the splicer.
M:mood=fond;acquired=fdre;

The next owner, two years later:

DOGPACK/1
R:6f1c9a2be4d3c5a7089b2f4e1d6c8a3b5e7f9021d4c6b8a0e2f4d6c8b0a2e4f61i0
Q:2
L:c3d5e7f90a1b2c4d6e8f0a2b4c6d8e0f2a4b6c8d0e2f4a6b8c0d2e4f6a8b0c2di0
N:M. Reyes
1:Traded a splicer for this. Hank threw in the story, which was the point.
2:Keeping the name.

Nothing in the second record can alter the first. Both are rendered, in that order, forever.

14. Accepted limitations

Published rather than hidden, in the house style.

1. Custody is block-granular. During the block in which a subject changes hands, both parties test as authorised. Transaction position within a block is not obtainable from the indexers in use, and a rule you cannot compute is worse than a coarse one you can.
2. N is a claim, not an identity. Anyone may write any name. What is verifiable is that the holder of the piece wrote it; who they are is not.
3. Comments and blank lines are not covered by Z. A relay could add a comment without breaking a signature. It cannot add or change any key.
4. A lost key freezes your ability to append, forever. The pack stays readable; you simply cannot add to it.
5. Custody caches must be reorg-invalidatable. An append-only cache of chain-derived facts is a bug, because the chain is not append-only below the tip. Store (txid, blockhash, height) per hop and re-walk on mismatch.
6. If you would not let a service write on the piece, do not let it hold the piece. Custody is authority. An exchange, marketplace or custodian holding your inscription can write in its pack, and that is not a flaw in this protocol — it is what custody means, stated out loud.
7. Spam is possible and is answered by display, not by deletion. Anyone may inscribe an UNAUTHORISED record naming your piece. Readers show it, marked. That is the trade: a protocol that could hide a note could hide yours.

15. Versioning

The magic carries the version. DOGPACK/2 would be a new magic and a new document. Within DOGPACK/1, new keys, profiles and attribute names may be added without a version bump, because rule 3 guarantees an old reader survives them.