Operational reference

TAP on Doge reference

What the words mean, how an indexer must behave when the chain is uncertain, what bytes cost on a chain with no witness discount, what this protocol does not do, and what you must decide explicitly if you implement it.

Terminology

Confirmation semantics

A TAP message exists when the transaction carrying it is in a block. Before that it is a proposal. The Dogecoin difference is not the rule, it is the clock: the rule fires roughly ten times more often here.

• C-1

  A row with a block height is confirmed. A row with no block evidence is pending, and a pending row is not a claim about the mempool. See mempool semantics.

• C-2

  Messages apply in confirmation order, and within a block in the block's transaction order. An indexer that reorders is wrong even if its totals happen to match.

• C-3

  A tapped operation needs two confirmations before it has any effect: one for the inscription, one for the tap. On Dogecoin that is about two minutes. On Bitcoin the identical sequence is about twenty.

• C-4

  Universe decision. Marketplace settlement requires the exact Dogecoin transaction confirmation, a minimum of one confirmation, and the expected protocol state transition appearing in a later authoritative checkpoint. Confirmation alone is not treated as settlement, because a confirmed transaction whose protocol effect has not yet appeared in the indexer is not yet a completed trade.

• C-5

  Do not port a confirmation policy across chains by number. Six confirmations is about an hour on Bitcoin and about six minutes here. Use the comparator to see what a count buys before adopting it.

Mempool semantics

Dogecoin's one-minute block target makes the mempool feel less important, because the wait to confirmation is short. That is a feeling, not a guarantee, and it makes the honest position here more important rather than less.

• MP-1

  An unconfirmed TAP message has no protocol effect whatsoever. It moves no balance, opens no trade, and taps nothing.

• MP-2

  Universe decision. The Bitcoin Universe Dogecoin TAP source reports its coverage as partial, and one of the two recorded reasons is that the pinned reader exposes no Dogecoin mempool feed. The source therefore does not claim complete pending activity, and a caller must not read the absence of a pending row as evidence that no such transaction is in flight.

• MP-3

  An interface that shows pending TAP activity on Dogecoin should label it as incomplete rather than as a mempool view. The difference matters when a user is deciding whether their own transaction was seen.

• MP-4

  Because a block arrives about every minute, a payload that is malformed produces its non-result quickly. That speed is often mistaken for confirmation that the payload was correct. It is not: an inert inscription confirms exactly as fast as a valid one.

Reorg behaviour

This is where the one-minute block target changes an operational rule rather than just a wait. A rollback window measured in blocks is a much shorter window in wall clock time on Dogecoin, and a reorg of a given block depth costs less elapsed work to produce.

• RG-1

  Protocol state is a pure function of the confirmed chain. When the chain changes, state must be recomputed from the new chain, never patched forward from the old one.

• RG-2

  Universe decision. The Dogecoin inscription index keeps at most 5 savepoints, taken every 10 blocks, and only while within 25 blocks of the chain tip. The deepest recoverable reorg is therefore around 40 to 49 blocks depending on the current height. A deeper reorg is unrecoverable and the index must be rebuilt.

• RG-3

  At one minute per block, that whole recoverable window is under an hour of wall clock time. An indexer that falls more than an hour behind the tip has left the window it can roll back through, so on Dogecoin the monitoring interval matters far more than it does on Bitcoin.

• RG-4

  Universe decision. The pinned Dogecoin TAP reader publishes no block replacement notifications. Replacement is detected by re-reading a bounded tail of each source list and noticing a shorter list or a changed row. Invalidations are emitted only when that evidence exists, which is the second recorded reason the source reports partial coverage.

• RG-5

  An invalidated event that later returns keeps its source event id and receives a new journal entry, so a downstream projection can reactivate it rather than double-count it.

• RG-6

  Universe decision. Marketplace reorg reconciliation is automatic. Reorg observations are appended, affected orders are reopened or invalidated deterministically, and funding, broadcast, and replacement lineage is preserved rather than discarded.

Fees and size

Dogecoin's fee model is the part people most often carry over from Bitcoin unchanged, and it is the part where Bitcoin intuitions are most wrong in both directions.

• F-1

  Body chunks are at most 520 bytes, so a payload of n bytes needs at least ceil(n / 520) chunks. The validator reports both numbers for any payload you paste.

• F-2

  Whitespace in a JSON payload is not significant to the protocol and is fully significant to the fee. Minify anything you inscribe. A pretty-printed payload can easily be half again the size of the same message minified.

• F-3

  A multi-transaction reveal chain pays a fee per transaction, plus the per-transaction overhead of inputs and outputs. Cost does not scale linearly with content size once the chain begins; it steps.

• F-4

  The output carrying an inscription must stay above the dust threshold, which is a relay policy value read from the node rather than a protocol constant. Bitcoin Universe treats it as configuration and refuses to build an output below the configured value rather than guessing one.

• F-5

  ord-dogecoin configures no inscription content size limit for Dogecoin mainnet, so the ceiling on content is relay policy and cost, not the indexer. Typical Doginals content is substantially larger than typical Bitcoin ordinals content, which is a cultural fact about the chain rather than a protocol one, and it is why the multi-transaction reveal path is ordinary here rather than exotic.

The Bitcoin Universe Dogecoin TAP source

Bitcoin Universe reads Dogecoin TAP through a pinned immutable reader and republishes normalized batches to its explorer. These are the properties a consumer should know about, stated as the source itself states them.

• U-1

  Coverage is reported as partial, for the two recorded reasons in MP-2 and RG-4: no Dogecoin mempool feed, and no block replacement notifications.

• U-2

  The published checkpoint is the indexed tip, never the chain tip. Both are published alongside the distance between them, and that distance is the number to read before trusting any other figure. A measurement that could not be taken is reported as null, never as zero.

• U-3

  Authoritative integer amounts from the reader are used unchanged. Decimal-form values are converted with the deployment's declared decimal scale, in the range 0 to 18, without floating-point arithmetic.

• U-4

  Activity for a ticker whose deployment has not yet been observed waits for the deployment stream. If the deployment is still absent, the row is quarantined rather than scaled with a guessed decimal scale. A later deployment rewinds and retries the quarantined activity.

• U-5

  Raw source records are retained up to 256 KiB. An oversized row keeps its SHA-256 fingerprint and byte count, is quarantined, and is never guessed at.

• U-6

  Replaying the same source row does not create a second event. Each row's fingerprint, normalized event, wallet deltas, and journal sequence are stored, and new journal rows do not change previously served pages.

• U-7

  The service pins its source identity: protocol, chain, network, reader source, reader version, and channel. A database created against a different identity cannot be opened. This is why two Bitcoin Universe deployments cannot silently disagree about which Dogecoin TAP dataset they are reading.

• U-8

  Trade rows map to listing, unlisting, offer, accepted offer, or sale where the source gives that evidence. An unrecognised trade action maps to listing and keeps the raw action rather than being dropped.

Limitations

• No mempool truth. Pending TAP activity on Dogecoin is not completely observable through the Bitcoin Universe source. Treat pending as a hint.
• No protocol-level reversal. A tapped operation cannot be undone. A cancelled authority is cancelled indefinitely; a consumed transfer inscription is consumed forever.
• No recovery from a partial reveal. An interrupted reveal chain is spent money and no asset. The missing chunks cannot be supplied by a later transaction.
• No arbitration between authorities. Two privilege authorities may make conflicting statements about the same file hash. The protocol has no opinion; the project's published authority inscription id is what decides.
• No on-chain balance. Balances exist only as an indexer's reading. Disagreement between indexers is a real operational condition, not a theoretical one, and the first thing to compare is their indexed heights.
• No sell workflow in the Bitcoin Universe marketplace. Recorded reason: TAP on Doge has no executable offer workflow on that surface.
• No deploy in the Bitcoin Universe Inscribe surface. That surface offers mint for this protocol and nothing else.
• No testnet coverage. Dogecoin testnet TAP is not indexed by any Bitcoin Universe product.

Security considerations

• SEC-1

  Confirmation counts do not port. A policy of six confirmations moved from Bitcoin to Dogecoin silently reduces the wait by a factor of ten. Choose the count from the value at risk and from RG-2, and state the elapsed time you intend, not just the block count.

• SEC-2

  Read every pre-filled payload. A draft produced by any tool is a suggestion. Check the operation name against section 6 and the recipient against section 4 before inscribing it. A payload with p: "tap" and a bare mint or transfer operation confirms, costs a full fee, and is then indexed by nobody.

• SEC-3

  Verify addresses on this chain, not the last one. The published Dogecoin specification carries Bitcoin address wording and Bitcoin example addresses. A recipient that passed a Bitcoin address check is not thereby a Dogecoin address. Check the base58check checksum and the version byte.

• SEC-4

  Protect inscription outputs from being spent as change. A transfer inscription is an ordinary looking small-value output. A wallet that does not track inscriptions will happily spend it to fund an unrelated payment.

• SEC-5

  Consider blocking transferables for authority addresses. An address that operates a token authority and redeems from its own account can be griefed by unsolicited inbound transfers. block-transferables exists for exactly that case.

• SEC-6

  Authority hashes are single use. Reusing a hash invalidates the message. An authority that generates random salts and cannot regenerate them loses the ability to reindex its own history; prefer deterministic salts such as an inscription id.

• SEC-7

  Trade windows are short in wall clock terms. A valid window of 900 blocks is about fifteen hours on Dogecoin and about six days on Bitcoin. A window copied from a Bitcoin trading template expires far sooner than intended.

• SEC-8

  Never treat an indexer's balance as custody. Ownership is the chain's, not the indexer's. Before acting on a balance, check the indexer's indexed height against the chain tip.

• SEC-9

  Report vulnerabilities privately through GitHub private vulnerability reporting on this repository. Protocol-level findings should also go to Trac Systems.

Implementation checklist

If you are writing or auditing a TAP on Dogecoin indexer, these are the decisions you must make explicitly. Getting one wrong produces balances that look plausible and are not reproducible.