Proposal: dmt-redirect — opt-in redirects to unlock new DMT token mechanics

[dmtbit]

Proposal: dmt-redirect — opt-in redirects to unlock new DMT token mechanics

TL;DR

A new opt-in TAP op, dmt-redirect, that any eligible DMT deploy creator can configure for their own ticker via a constrained weighted-split rule (up to eight buckets across three recipient types, 144-block notice floor on every rule change). Generalizes the dmt-nat coinbase-redirect template — hardcoded in ord-tap since block 885,588 — into a single op composable at the inscription layer for any eligible DMT deploy.

Why this matters. TAP made deploys permissionless. The redirect path is not: today it is a hardcoded constant for one ticker (dmt-nat) plus a per-tick PR queue for everything else. This proposal extends the permissionless property to the redirect layer — for every eligible DMT deploy, by the same rules, no per-tick code and no per-tick gatekeeper. The grammar opens a class of token mechanics the protocol cannot express today without bespoke code: pay-the-block-winner deploys, solo-miner programs, pure solo-jackpot tokens, on-chain treasuries, cross-token tribute, multi-recipient distributions, hybrid weighted splits — each available as a single userspace inscription, no further protocol changes.

It does not add a subsidy. Total supply, emission curve, and deploy spec of every existing token are unchanged. dmt-nat stays exempt; its block-885,588 path is preserved verbatim.

A paired implementation (spec README amendment + ord-tap Rust patch with tests) is built locally against Trac-Systems/ord-tap HEAD. Paired PRs are opening concurrently with this issue. Design-level review belongs on the issue thread; line-level review belongs on the PRs.

Background

The dmt-nat redirect activated at block 885,588 (tap-protocol-specs/README.md — DMT-NAT Rewards to Bitcoin Miners). At that height, dmt-mint for dmt-nat is suppressed and per-block emission is credited pro-rata to coinbase output addresses. Block 941,848 added MinerRewardShield: token-transfer disabled by default (requires unblock-transferables), token-send and token-trade permanently disabled. The hardcoded path lives in three places:

• src/index/updater/inscription_updater/tap/ops/dmt_mint.rs:57 — tick_effective_lower == "dmt-nat" short-circuits the mint.
• src/index/updater/inscription_updater.rs:266 — index_dmt_nat_rewards_for_block opens with let tick_lower = "dmt-nat".to_string();.
• src/index/updater/inscription_updater/tap/mod.rs:18 — TAP_DMT_NAT_REWARDS_HEIGHT: u32 = 885_588;.

This proposal builds directly on that design — the dmt-nat template plus the Shield — and turns it into a reusable validator. Other DMT deploys that want similar mechanics currently have one path: a per-tick patch from the Trac team. That funnels every variant through one review queue and accumulates one-off code paths.

Proposal

A new TAP op, dmt-redirect, lets the deployer of an eligible DMT token replace the default dmt-mint-credits-inscriber payout with a constrained rule applied per block from a deployer-chosen activation height onward.

{
  "p": "tap",
  "op": "dmt-redirect",
  "tick": "<tick>",
  "act": <block_height>,
  "rule": {
    "type": "weighted-split",
    "must_sum_to": 10000,
    "buckets": [...],
    "solo_classification": {...}
  }
}

Authorization. The reveal transaction must spend the deploy inscription's UTXO, declared as the Ordinals parent (envelope tag 3) of the dmt-redirect inscription. ord-tap-style indexers only record a parent if its sat is actually transferred by the reveal, so a recorded parent is proof that the reveal signer controls the deploy inscription. Same-transaction deploy+redirect is rejected (the deploy would be a sibling envelope rather than a spent-UTXO parent), so "must spend the deploy inscription's UTXO" holds literally for every accepted case. Whoever currently holds the deploy inscription is the authority for that tick's redirect — no prv field on the original deploy is required, no separate signing scheme is required. This works for every eligible existing DMT token (see v1 scope; dmt-nat is exempt).

Activation per rule. Each dmt-redirect carries an act field with a protocol-enforced floor of act > current_block + 144 (one day at the 10-minute average). Indexers running the merged code honor dmt-redirect from any block; there is no global feature-height gate. Per-rule notice via act is the user-facing transparency mechanism.

Updates. A new dmt-redirect for the same tick supersedes the previous one at its own act, not at inscription time, regardless of whether the previous rule is in force or only scheduled. No separate update, revoke, or sunset op. Authority follows the deploy inscription's UTXO — if that UTXO is transferred, authority transfers with it.

Exempt tick. Inputs that normalize to dmt-nat (the user-supplied tick in any case form) are hard-rejected, as are prefix-form inputs (tick: "dmt-nat" or "-..."). The block-885,588 hardcoded path is preserved unchanged and never reached via this op. Migrating dmt-nat onto dmt-redirect is out of scope.

v1 scope. This version applies to DMT deploys whose per-block emission is the bits value of the block — element field 11 (bits) with no pattern (pat). This is the dmt-nat and dmt-bit shape: any new deploy that copies the canonical dmt.11.element reference (or a no-pattern field-11 element of its own) is covered. Pattern-based deploys (e.g., dmt-natcats with its 3b bits substring pattern), field 4 (block height) deploys, and field 10 (nonce) deploys are deferred to a v2 spec discussion — they require reusing dmt-mint's element-evaluation logic per-block rather than the direct bits read v1 uses. The validator loads the deploy's element and rejects redirect inscriptions on out-of-scope deploys with no state stored.

Rule grammar (weighted-split)

One rule type ships in v1.

Recipient type	Pays to	MinerRewardShield
coinbase-output	coinbase output addresses, pro-rata by output value	applied (parity with dmt-nat)
solo-coinbase-output	same, on solo-classified blocks; behavior on pool blocks per accumulate_when_no_solo	applied
address	a single configured mainnet BTC address	not applied

Up to 8 buckets per rule. Each bucket has a name, a share_bps (integer ≥ 1; sum must equal 10000), and a recipient. Solo buckets may set accumulate_when_no_solo: true (default — escrow on pool blocks, release to next solo block) or false (burned on pool blocks).

Solo classifier. A block is solo when its coinbase scriptSig contains a substring from the deployer-supplied tag allowlist OR its coinbase outputs include an address from the deployer-supplied address allowlist, AND it does not match any entry in the deployer-supplied pool blocklist (substring or address). Pool signals take precedence; matching neither falls back to treat_as_pool (default) or treat_as_solo. The classifier is fully deployer-configurable; no protocol-level constant lists.

Shield interaction. Coinbase and solo-coinbase recipients are subject to MinerRewardShield at parity with dmt-nat. Address-bucket recipients are not shielded. The Shield's existing semantics are preserved; this proposal does not modify them.

Use cases

Several deployer designs the grammar admits without further protocol changes:

1. Bitcoin security-budget contribution. A DMT deploy uses one coinbase-output bucket at share_bps: 10000 to direct its emissions to BTC miners pro-rata, following the dmt-nat pattern. Multiple deploys electing this stack as additional miner-revenue layers — a useful property as the block subsidy halves and the network leans more on transaction fees and adjacent revenue streams.

2. Solo-miner / hashrate decentralization programs. A deploy composes coinbase-output plus solo-coinbase-output with accumulator. Biases the deploy's own emissions toward independent miners (CKPool, Public Pool, Braiins Solo, NiceHash, SoloPool — deployer-supplied list). Direct on-chain incentive for hashrate decentralization on Bitcoin, a structural property valuable to the network beyond any single deploy.

3. On-chain treasury / development funding. coinbase-output plus a fixed address bucket directed at the project's treasury, audit reserve, or open-source-maintainer wallet. Sustainable funding aligned with token economics, publicly visible in the inscription, immutable without 144-block notice.

4. Cross-token tribute. Newer DMT tokens can include an address bucket directed at a predecessor or aligned project's wallet — bootstraps ecosystem goodwill and aligns incentives across deploys without any token bridge.

5. Pure solo-jackpot tokens. A single solo-coinbase-output bucket at share_bps: 10000 with accumulate_when_no_solo: true. Every pool block adds to a growing escrow that drops in full when the next solo miner wins. A Powerball-style mechanism not currently expressible without bespoke indexer code.

6. Multi-recipient ecosystem distribution. Two or more address buckets across coalition treasuries, maintainer rosters, charity panels, or multi-project tribute. All visible in the inscription, all immutable without 144-block notice. Aligns ecosystem participants without bridges or off-chain coordination.

7. Hybrid weighted splits. Any combination of the above at deployer-chosen weights — for example, 60% miners / 25% project treasury / 15% tribute, or 40% pool / 30% solo / 30% coalition. Up to eight buckets, bps weights summing to 10000.

The grammar is constrained: one rule type, three v1 recipient types, no scripting, no oracles, no off-chain computation. Additional recipient types (parent-holders, token-auth) are deliberately deferred to a post-v1 discussion — see Open Questions.

A note on the proposer's intent. These are use cases the grammar admits — they are not the proposer's roadmap. The proposer (the dmt-bit deploy) plans to use dmt-redirect for the security-budget mission specifically: directing dmt-bit's own per-block emissions to the miners — large pools, solo miners, or some weighted combination — that secure Bitcoin. The exact configuration will be decided by community vote among dmt-bit holders before the rule is inscribed. Other use cases (treasuries, tribute, multi-recipient distribution) are listed because the grammar admits them, available to other deploys on their own timelines if they choose.

Why this is worth shipping

Maintenance. The Trac team writes one validator and is done. Future redirect-style mechanics ship as userspace inscriptions, not patches. The per-tick PR queue stops growing.

New deploys. The protocol today can express structured token emissions through two channels: a hardcoded indexer path or an off-chain prv authority. Both are narrow. Generalizing the rule-based path opens a class of mechanics not currently expressible without bespoke code: pay-the-block-winner tokens, solo-miner-favoring tokens, treasury-funded tokens, tribute-aligned tokens, multi-recipient weighted splits. Each is a potential new DMT deploy with structured emission semantics.

The grammar is constrained: three v1 recipient types, no scripting, no oracles, no off-chain computation. TAP's permissionless property — the same one that already governs deploys — extends to the redirect path: every redirect is publicly inscribed, every recipient is on-chain, every rule change carries a 144-block notice floor.

Relationship to privilege-auth (prv)

A reasonable question: does the existing prv mechanism (privilege-auth, activated at block 841,682) already cover this for future tokens? It does not, and dmt-nat is the proof. If prv were sufficient, dmt-nat would have been deployed with prv set to an authority that signs coinbase-paying mints. Instead, dmt-nat is a hardcoded indexer redirect — because the use case (auto-per-block credit to multiple coinbase outputs, zero per-emission inscription cost, no always-online signer) does not fit prv's model.

The two mechanisms decentralize along different axes:

• prv is gating-by-authority. An off-chain authority signs every mint inscription. Decision criteria is opaque off-chain logic. The authority can be a multisig or threshold scheme, but the chain only sees the signature — the rule itself is not on-chain. The authority is always-online; if compromised, future mints can be diverted. The right tool for launchpads, KYC-gated mints, or any case where per-mint discretion is desired.
• dmt-redirect is gating-by-rule. A constrained rule is inscribed on-chain and authorized by spending the deploy inscription's UTXO (Ordinals parent). Once active, every indexer applies it deterministically — no party makes per-emission decisions. Rules can be replaced with 144-block notice. The right tool for autonomous per-block distribution, multi-recipient splits, miner-direct payouts, or any case where the criteria can be expressed as a rule rather than a discretionary decision.

	prv (gating-by-authority)	dmt-redirect (gating-by-rule)
Gates	who can submit a valid mint	who receives per-block emission
Decision model	off-chain, per-mint, by authority	on-chain rule, per-block, deterministic
Decision visibility	opaque (off-chain logic)	public (rule inscribed on Bitcoin)
Per-emission cost	one BTC inscription fee	zero (indexer state update)
Recipients per emission	one (per signature)	up to 8, weighted splits
Coinbase-aware	no (authority must know off-chain)	yes (indexer reads block coinbase)
Always-online authority	required	not required
Trust assumption	per-mint, ongoing	one-shot per rule, with notice on changes

The two are complementary. A future deploy can use both: prv to gate inscription submission, dmt-redirect to distribute per-block emission. dmt-redirect adds the rule-based autonomous distribution primitive that TAP currently lacks, removing the per-tick patch dependency for future deploys with similar needs.

Why this is not a new subsidy

dmt-redirect does not credit any new tokens to any address. It changes which address receives a per-block emission that already exists by virtue of the deploy. Specifically:

• Total supply, emission curve, and deploy spec of every existing token are unchanged.
• A deploy with no dmt-redirect keeps crediting the inscriber, exactly as today.
• A deploy with a dmt-redirect redirects its own emissions among addresses chosen by the rule's grammar (authorized by spending the deploy inscription's UTXO) — the deployer can do this only by giving up the inscriber path.
• No deploy gains access to outside emissions, treasury funds, cross-token credits, or any new token authority.
• The 144-block notice floor is a constraint on deployer authority that does not exist today.

The Trac team's stated position is no further subsidies via TAP than $NAT. The proposal is consistent with that position: it generalizes one existing validator, not the subsidy.

Implementation status

Paired patch built locally against Trac-Systems/ord-tap HEAD. cargo test --release --lib green at 784 passing (48 of which are dmt-redirect-specific), no regressions in the upstream 736-test suite. Touched files: new dmt_redirect.rs op handler; record additions in records.rs; module registration in tap/mod.rs; mint guard in dmt_mint.rs; per-block dispatcher extracted from index_dmt_nat_rewards_for_block via a shared pay_coinbase_share helper. Inline test coverage spans parent-inscription authorization (including same-transaction deploy+redirect rejection), validation, replacement semantics (including pre-activation replacement), solo classifier branches, payout correctness for pool/solo/hybrid rules, shield application, and the dmt-mint guard.

The paired PRs (tap-protocol-specs README amendment + ord-tap implementation) open concurrently with this issue. The validation table, edge-case matrix, test plan, and the dmt-bit example inscription all live inside the PRs.

Open questions

Genuine ones — answers may change the grammar.

1. Additional recipient types and element fields (post-v1 path). Deferred from v1: a parent-holders recipient (UNAT/Bitmap holder distribution at block H), a token-auth recipient (off-chain authority signs per-block redeem), and emission semantics for non-fld-11 deploys (block-height, nonce, pattern-based). The recipient types add storage / oracle complexity. The non-fld-11 emission requires reusing the dmt-mint amount calculation per-block; mechanically straightforward but expands surface area. The token-auth path opens condition-based recipient selection — programs that pay AI agents on Trac for verified work, jurisdictionally-scoped incentives, or any criterion the deployer can attest off-chain. All three belong in a v2 discussion once v1 lands. Should any move into v1?
2. Notice floor. 144 blocks (one day). Too short, just right, insufficient?
3. dmt-nat exemption. Permanent (proposed) or eventually migrated for code-cleanliness?
4. Replacement semantics on overlapping pending records. Each rule activates at its own act independently of inscription order. If A.act = X and B.act = Y, both are pending and the dispatcher promotes whichever's act is reached first (and again later if Y > X). Confirm this is the desired behavior versus, e.g., enforcing strictly-increasing acts.
5. Validation completeness. V1–V15 in the proposed grammar — anything missing or redundant?

Authorization (Ordinals-parent UTXO spend of the deploy inscription) and activation strategy (no global feature height) are committed positions; reasoned objections welcome.

Backwards compatibility

• dmt-nat: unchanged.
• All other existing DMT deploys: unchanged. They credit inscribers per current dmt-mint semantics until and unless their deployer inscribes a dmt-redirect.
• Indexers without the merged code silently ignore dmt-redirect inscriptions; their state diverges from indexers running the merged code from the first active rule. This is the standard expectation for any TAP op addition and matches the dmt-nat activation pattern in 2025.

Discussion

• Issue stays open for community comment.
• Paired PRs are opening concurrently — design-level discussion belongs here, line-level review belongs on the PRs. Grammar changes that emerge from the discussion will be applied as PR updates.
• Reviewers interested in walking the implementation — please reply.