Cross-protocol technical foundations

Primitives shared by multiple Dogenals protocols: addressing, inscription_id layout, JSON habits, and (for ÐMP) the signed-message pipeline. This folder is informative glue; authoritative encoding rules for a given op always come from that protocol’s spec.md under ../protocols/.

Navigation: Full documentation map · Protocol comparison index · Reference code

What lives here

In-document sections below summarize address format, txid / inscription id, JSON amount encoding, and indexer invariants used across the repo’s specs.

Addressing (Dogecoin mainnet, summary)

• P2PKH (P2PKH-style): often starts with D in base58check.
• P2SH: A / 9 (legacy patterns; verify against your network parameters).
• Testnet: n / m prefixes.

Always use your node or library to validate, not a README substring rule.

Transaction and inscription ids

• txid: 64 lowercase hex characters, double-SHA256 of the serialized transaction (same convention as Bitcoin-derived chains).
• inscription id: "{txid}i{vout}" (lowercase hex txid, i separator, decimal output index, typically 0 for a simple reveal).

JSON conventions (common)

• Koinu / DOGE-denominated amounts: string decimal integers in the smallest unit (e.g. koinu) to avoid float error — as used throughout ÐMP and other specs.
• Display tickers: case-insensitive for humans; normalize to lowercase in indexers where the spec is fungible.
• Protocol id p: lowercase string, exact match.
• Optional fields: absent and null are not interchangeable unless a spec equates them.
• Unknown fields: unless a spec says to reject, ignore for forward compatibility.

ÐMP-style signed message (when a spec references it)

1. Canonical JSON: object keys sorted lexicographically at every level; omit transport fields such as sig / sig_msg for signing, per that protocol.
2. Prefix: Dogecoin signed message prefix, length-prefixed payload (see ÐMP §6 for the normative byte layout).
3. Hash: double SHA-256.
4. Signature: secp256k1, recoverable form so the signer’s address can be checked.
5. Verify: recompute canonical JSON; never trust sig_msg alone as the signed bytes without recomputation.

Time and block height

Where a protocol cares about ordering or finality, block height and confirmation depth are authoritative; Unix timestamps in JSON are for display and off-chain policy unless the spec ties an action to a wall time.

Formal Grammar (BNF-like for JSON structures)

This is an informal BNF for common JSON payload structures across protocols. Parsers should implement the normative rules from each protocol’s spec.md, not this summary.

Common envelope

envelope ::= "{" protocol_id "," version? "," operation "," fields "}"
protocol_id ::= "\"p\":" string
version ::= "\"v\":" string
operation ::= "\"op\":" string
fields ::= field ("," field)*
field ::= string ":" value

Amounts and IDs

amount ::= "\"" [0-9]+ "\""
inscription_id ::= "\"" [0-9a-f]{64} "i" [0-9]+ "\""
txid ::= "\"" [0-9a-f]{64} "\""
ticker ::= "\"" [a-zA-Z0-9]{1,4} "\""

DMP example

dmp_list ::= envelope "," "\"inscription_id\":" inscription_id "," "\"price\":" amount "," "\"seller\":" string

Indexer baseline (all protocols)

1. Process blocks in ascending order; transactions in canonical block order.
2. Reorgs: roll back to fork point, replay.
3. Invalid or unknown ops: policy-defined (often skip without polluting state).
4. Never assert ownership from JSON alone if the protocol demands a UTXO or signature check.

Full documentation index: ../docs/INDEX.md · Ecosystem entry: ../README.md