Skip to main content

​
Bitcoin Script, the UTXO Model and its limitations

Bitcoin tracks ownership through Unspent Transaction Outputs (UTXOs).
Each UTXO locks value to a script that defines the conditions under which it can be spent - most commonly a signature check. Transactions consume existing UTXOs as inputs and create new UTXOs as outputs. This design has several important properties:
  • Local validation – Transactions can be verified independently, without referencing global state
  • Strong composability – Outputs of one transaction naturally become inputs to another
  • DAG structure – Transactions form a directed acyclic graph (DAG), rather than a linear chain of state updates
These properties are core to Bitcoin’s security and scalability.
However, they come with important tradeoffs. Every UTXO spend must eventually be confirmed onchain. This implies waiting for block inclusion, competing for block space, and complying with mempool relay policies such as ancestor limits and pinning rules. As a result, even simple multi-step contracts become fragile, slow, or expensive on Bitcoin L1.

Dive deeper into Bitcoin’s UTXO paradigm, its commit-reveal pattern and how state transitions work

​
Bitcoin’s Mempool and Fee Market

Before confirmation, transactions reside in the Bitcoin mempool, where miners select which transactions to include based on fee rate (sats/vbyte). Because:
  • Block space is scarce
  • Blocks arrive roughly every 10 minutes
  • Demand for inclusion is unpredictable
users are forced into a fee auction for timely confirmation. For applications, this leads to:
  • Unpredictable latency
  • Volatile transaction fees
  • Unreliable execution ordering
Taken together, these properties make Bitcoin L1 unsuitable for real-time, interactive, or highly composable smart contracts. Any application requiring fast feedback, multiple state updates, or coordination between parties cannot rely on onchain execution alone.

​
Arkade’s Offchain Execution Layer

Arkade addresses these limitations by introducing Virtual Transaction Outputs (VTXOs). VTXOs behave like regular UTXOs from a user and application perspective:
  • They are spent as inputs
  • They create new outputs
  • They preserve local validation, composability, and DAG structure
The key difference is where execution happens. VTXO transactions execute offchain, inside Arkade’s virtual mempool, where they are validated and tracked by an operator. This allows users to transact instantly, without waiting for block inclusion or paying onchain fees for every state update. To anchor offchain activity to Bitcoin, Arkade uses a batch settlement model:
  • The operator collects and co-signs valid VTXO transfers
  • Multiple offchain transactions are aggregated into a single Bitcoin transaction
  • That transaction settles the entire batch onchain at once
This dramatically reduces fees and block space usage by compressing many logical transactions into a single onchain anchor. Learn more about:

​
TL;DR: Solving Bitcoin’s Onchain Constraints

Arkade’s design directly addresses the core limitations of Bitcoin L1:
  • Latency: VTXOs can be created and spent offchain with instant preconfirmation, bypassing block confirmation delays.
  • Fee Volatility: Users are insulated from fee spikes; batch settlement amortizes costs across many participants.
  • Mempool Constraints: VTXO transfers live outside the Bitcoin mempool—no ancestor limits, pinning attacks, or RBF edge cases.
  • Composable Contracts: Arkade enables multi-step execution and coordination via presigned, verifiable offchain commitments, while preserving Bitcoin’s DAG-based transaction model.
VTXOs remain cryptographically tied to real Bitcoin UTXOs through commitment transactions. At any time, users can unilaterally exit to Bitcoin L1 using presigned transactions. The operator cannot steal funds—they can only facilitate execution or delay settlement, with misbehavior being detectable and punishable.
Arkade’s preconfirmation provides speed without Bitcoin-level finality.
Full security is achieved once VTXO state is settled onchain in the next Bitcoin block.