What the Battle of the Bitcoin Metaprotocols Means for the Future of Bitcoin

\ Who this is for: Bitcoin developers, indexer builders, and product teams evaluating Bitcoin-native DeFi architectures.

The question that actually matters

Bitcoin now has credible ways to represent assets. Runes gives a UTXO-native fungible token standard. Ordinals covers unique artifacts. The harder question is where execution should live. If execution moves into indexers (e.g., BRC20, Alkanes, OP_NET), the indexer becomes the de facto settlement layer. If execution is coordinated through DPS (Decentralized PSBT Signing), Bitcoin remains the court of final settlement while users still get fast, composable flows.

Why indexer extensions look attractive

Teams pick indexer-embedded VMs for good reasons:

• Rapid iteration without integrating another chain.
• Familiar smart contract tooling and one deployment surface.
• Fewer moving parts to bootstrap in the early stage.

These benefits are real. The trade-offs are equally real:

• Execution ordering happens in the mempool, which enlarges the MEV surface.

• The indexer mediates state and becomes a settlement bottleneck.

• Users can face finality surprises and inconsistent state around reorgs.

  

How DPS changes the user experience

DPS keeps Bitcoin as the final settlement layer. Coordination and signing happen in a transparent, verifiable environment. A typical flow looks like this:

1. A user submits a PSBT or intent to a sequencer.
2. The contract environment checks terms and state, then signs inputs.
3. The finalized transaction is broadcast to Bitcoin for settlement.

What users feel:

• Seconds-level feedback instead of waiting a block or two.

• Composable, atomic flows across multiple steps or pools.

• Fewer failed-on-finality surprises, since the contract state is updated before broadcast.

  

| Dimension | DPS (Decentralized PSBT Signing) | Indexer Extensions (VM in indexer) | |----|----|----| | Settlement model | Bitcoin stays the settlement layer | Indexer becomes de facto settlement layer | | Latency | Seconds, pre-settlement sequencing gives fast feedback | One or two confirmations, roughly 10 to 20 minutes typical | | MEV surface | Smaller public intent surface, ordering is auditable where sequencing runs | Larger public intent surface in mempool, ordering shaped by fee competition | | Composability | Atomic multi-step flows, pool-based designs | Often single-asset and brittle, harder to compose | | Standards alignment | Works with runes and Ordinals using PSBT | Often wraps or abstracts standards | | Failure modes | Pre-settlement reverts, consistent contract state | Possible state drift until confirmation and reorg safety |

PSBT today: strength and pain points

PSBT (BIP-174) gave wallets and markets a common language for multi-party coordination. It unlocked peer-to-peer trading for Ordinals and runes. It also introduced public intent surfaces when partially signed transactions or order templates sit in [mempools]() or public boards. This creates room for sniping and pinning, and it pushes builders to seek better coordination. DPS provides a solution to that need.

Case study in brief: P2P PSBT order flow under pressure

Peer-to-peer PSBT markets proved non-custodial swaps are possible. They also showed limits:

• Public PSBTs can leak terms and enable sniping through replace-by-fee races.

• Orders are often rigid. You take the whole thing or nothing. Liquidity feels thin.

• Without pooled liquidity and programmable agents, trades resemble barter.

  

\ DPS reduces the attack surface by coordinating before broadcast and enables pooled, programmable designs that feel closer to modern DeFi while preserving Bitcoin settlement.

Why the runes standard does not add a VM to the indexer

The runes design favors minimal centralization pressure. Execution inside the indexer would shift trust and ordering away from Bitcoin. Keeping execution out of the runes indexer aligns with Bitcoin’s neutrality and avoids making indexers the real court.

https://x.com/rodarmor/status/1823803508967268678?embedable=true

REE on the Internet Computer, facts only

Omnity’s Runes Exchange Environment (REE) uses DPS and runs the coordination and signature logic on the Internet Computer. Key points:

• Chain-key and threshold signing let canister smart contracts check Bitcoin state, sign inputs, and broadcast without offchain intermediaries.

• Reverse gas removes the need for users to hold ICP for fees, which reduces friction.

• REE is open source and designed for composability. Apps can share liquidity.

• Indexing for runes is onchain, with an Ordinals indexer planned for release in the same model.

• Users sign PSBTs with their existing Bitcoin wallets. No wrapped assets.

  

Practical evaluation checklist for Bitcoin DeFi Devs

Use this when choosing an execution model:

1. What is the actual settlement layer, and can app state drift from it?
2. How is ordering decided before settlement, and can the public verify it?
3. How much intent data is public before broadcast?
4. What happens under reorgs or partial failures?
5. Do you preserve open standards like runes, Ordinals, and PSBT?
6. What is real time to feedback at p50 and p95?

Conclusion

Metaprotocols can't weaken Bitcoin security. The goal is programmability without less security. DPS keeps transactions on Bitcoin and gives developers fast, flexible UX tools. Indexer-based VMs have greater offchain risks; choose your character wisely and keep building on Bitcoin!

➡️FREE DOCS

Suzanne Leigh is the Editor of Omnity Network.

\ \