Dog Marker Envelope Specification (Dogenals Era 2)

This specification defines the dog marker envelope for Dogenals Era 2 inscriptions. The dog marker provides a cleaner, more future-proof alternative to the ord marker while maintaining full compatibility with the Dogenals ecosystem.

Overview

The dog marker uses the pattern OP_FALSE OP_IF "dog" followed by a versioned envelope structure. It supports:

• Versioned envelopes for evolution
• CBOR-preferred metadata for efficiency
• Quantum-safe signature hooks
• Optional private vault commitments
• P2SH-style script structure

Envelope Structure

Basic Format

OP_FALSE
OP_IF
  "dog"
  <version_byte>
  <envelope_data>
OP_ENDIF

Where:

• version_byte: Single byte indicating envelope version (0x01 for v1)
• envelope_data: Version-specific data structure

Version 1 Envelope (0x01)

For version 1, the envelope uses a CBOR-encoded structure:

{
  "p": "protocol_name",  // Protocol identifier
  "v": "1.0",           // Protocol version
  "op": "operation",    // Operation type
  // ... protocol-specific fields ...
  "meta": {             // Optional metadata
    "content_type": "application/json",
    "encoding": "utf-8",
    "size": 1024
  },
  "sig": "hex_signature",  // Optional quantum-safe signature
  "vault": "commitment_hash"  // Optional private vault commitment
}

Script Encoding

The CBOR data is encoded as script pushes:

OP_FALSE
OP_IF
  "dog"
  0x01  // Version byte
  <push_cbor_data>
OP_ENDIF

Where <push_cbor_data> is the CBOR bytes pushed using appropriate OP_PUSH operations.

Version Evolution

New versions can introduce:

• New CBOR fields
• Different serialization formats
• Enhanced signature schemes
• Additional commitment types

Indexers MUST support all defined versions and gracefully handle unknown versions by falling back to basic inscription detection.

CBOR vs JSON

• CBOR preferred: More compact, binary-efficient
• JSON fallback: For simple protocols or debugging
• Content negotiation: Clients can request preferred format

Quantum-Safe Signatures

The sig field supports post-quantum signature schemes:

• Dilithium (recommended)
• Falcon
• SPHINCS+

Signatures are over the canonical CBOR data excluding the sig field.

Private Vault Commitments

The vault field allows commitments to private data stored off-chain:

• Hash of encrypted payload
• Merkle root of data structure
• Zero-knowledge proof commitments

This enables privacy-preserving inscriptions while maintaining on-chain verifiability.

Compatibility

Dog marker inscriptions are fully compatible with:

• Dogenals numbering (continuous sequence)
• ÐMS metadata
• ÐMP marketplace
• All protocol participation

They produce the same unified Dogenals state as ord inscriptions.

Implementation Notes

Parser Requirements

Indexers MUST:

1. Detect OP_FALSE OP_IF "dog" pattern
2. Extract version byte
3. Parse envelope according to version
4. Convert to unified Dogenals format
5. Apply protocol-specific validation

Fallback Handling

For unknown versions:

• Extract basic inscription data
• Mark as “unsupported version” but still index
• Allow protocol participation where possible

Security Considerations

• Validate CBOR structure to prevent exploits
• Verify signatures when present
• Handle malformed envelopes gracefully
• Prevent resource exhaustion from large payloads

Future Extensions

Version 2+ may include:

• Compressed CBOR
• Batch inscription support
• Multi-party signatures
• Temporal commitments

Examples

Simple JSON Protocol

{
  "p": "example",
  "v": "1.0",
  "op": "create",
  "data": "Hello Dogecoin!"
}

With Metadata and Signature

{
  "p": "nft",
  "v": "1.0",
  "op": "mint",
  "name": "Rare Doge",
  "meta": {
    "content_type": "image/png",
    "size": 2048
  },
  "sig": "dilithium_signature_hex"
}

This envelope provides a solid foundation for Dogenals Era 2 while maintaining the ecosystem’s core principles of openness, verifiability, and future-proofing.

Conformance test vectors (byte-level)

These vectors are intended for parser conformance tests and indexer cross-checking.

Vector A: witness dog v1, minimal payload

• CBOR diagnostic: {"data":"hi"}
• CBOR hex: a16464617461626869

Tapscript assembly:

OP_FALSE OP_IF "dog" OP_1 <cbor> OP_ENDIF

Expected script hex:

00 63 03 64 6f 67 51 09 a1 64 64 61 74 61 62 68 69 68

Expected indexer behavior:

1. Detect dog marker envelope.
2. Parse version as 1.
3. Decode CBOR map.
4. Materialize body bytes as UTF-8 hi.
5. If no content_type is present, default to application/octet-stream.

Vector B: witness dog unknown version

Tapscript assembly:

OP_FALSE OP_IF "dog" OP_9 <opaque bytes> OP_ENDIF

Expected indexer behavior:

1. Detect dog marker envelope.
2. Treat version 9 as unsupported.
3. Preserve opaque bytes.
4. Index as unsupported (do not drop silently).

Vector C: era1 script_sig dog marker

Data pushes:

PUSH("dog") PUSH(0x01) PUSH(<cbor bytes>)

Expected indexer behavior:

1. Parse as dog v1 envelope path when no ord marker exists.
2. Apply same CBOR decoding semantics as witness dog v1.
3. Produce the same unified inscription representation as witness path.