VTXO (Virtual Transaction Output)

What Is a VTXO?

A Virtual Transaction Output (VTXO) is an off-chain representation of Bitcoin ownership. It consists of one or more pre-signed Bitcoin transactions that could be broadcast and confirmed on the blockchain at any time, but the holder elects not to broadcast them. The critical property is that a VTXO represents a real, enforceable Bitcoin claim: converting it into a standard on-chain UTXO requires no permission from any third party.

The concept was introduced by Burak Keceli as part of the Ark protocol in 2023. Where Bitcoin's UTXO model tracks ownership through confirmed transaction outputs on the blockchain, Ark extends this model off-chain: users hold VTXOs that are just as valid as on-chain UTXOs but consume no block space during normal operation. Just as UTXOs are destroyed and created in every Bitcoin transaction, VTXOs are spent and created in every Ark transaction.

This approach differs fundamentally from layer-2 protocols like the Lightning Network, which require users to open and manage bilateral payment channels. With VTXOs, users interact with a shared pool managed by an Ark Service Provider (ASP), eliminating the need for direct channel relationships, inbound liquidity management, or complex routing.

How It Works

VTXOs are built on a tree structure of pre-signed transactions anchored to a single on-chain UTXO. Understanding this tree is key to understanding how VTXOs provide both scalability and self-custodial security.

Transaction Tree Structure

The Ark protocol uses a quad tree (each node splits into four children) to organize VTXOs efficiently. The tree has three layers:

Each transaction in the tree has two spending paths. The cooperative path uses MuSig2 multi-signatures (for branch nodes) or a 2-of-2 multisig between the user and the ASP (for leaf nodes). The fallback path uses timelocks: absolute CLTV locks on root and branch transactions (approximately 30 days), and relative CSV locks on leaf transactions (approximately 24 hours in the reference specification).

# Simplified VTXO tree structure (quad tree)
#
#              [Root TX]              ← On-chain (1 UTXO)
#            /   |    |   \
#       [Branch] [Branch] [Branch] [Branch]  ← Off-chain
#       / | | \
#   [Leaf][Leaf][Leaf][Leaf]                  ← Off-chain (VTXOs)
#
# Each leaf = one user's VTXO
# Exit cost scales logarithmically:
#   4 users   → 2 transactions to exit
#   16 users  → 3 transactions to exit
#   256 users → 5 transactions to exit

Rounds and VTXO Creation

New VTXOs are created during coordinated events called rounds, initiated by the ASP on a periodic basis (typically every hour, though this is configurable). During a round:

1. Users who need to create, refresh, or transfer VTXOs register with the ASP
2. The ASP and participating users collaboratively construct a new transaction tree
3. Users sign forfeit transactions for their old VTXOs (transferring them to the ASP)
4. The ASP broadcasts the new root transaction on-chain
5. Once confirmed, each participating user holds a new VTXO with a fresh 30-day lifetime

Atomicity is guaranteed through connector outputs: valueless outputs in the round transaction that each forfeit transaction requires as an input. A user's forfeit is only valid if the round transaction confirms on-chain, meaning users cannot lose their old VTXOs without receiving new ones.

VTXO Types

The protocol defines three distinct types of VTXOs, each suited to different operations:

Board VTXOs are the simplest: the root transaction spends directly to a single user's leaf, bypassing the branch layer entirely. Refresh VTXOs are created during rounds where multiple users share branch transactions. Spend VTXOs (also called arkoor transfers) enable instant payments between users without waiting for a round, but they inherit the source VTXO's remaining lifetime rather than receiving a fresh 30-day window.

Unilateral Exit

A user can convert their VTXO into a standard on-chain UTXO at any time without the ASP's cooperation. This process involves broadcasting the chain of transactions from the tree root down to the user's leaf:

1. Broadcast the first branch transaction from the tree root
2. Wait for confirmation, then broadcast the next branch transaction
3. Repeat until reaching the leaf (exit transaction)
4. Wait for the relative CSV timelock to expire (approximately 24 hours)
5. Broadcast the final claim transaction to make bitcoin fully spendable

Exit costs scale logarithmically with the quad tree structure. For a tree serving 256 users, exiting requires only 5 on-chain transactions. If the VTXO's balance is less than the total fees required, the exit may not be economically viable: a tradeoff inherent to any off-chain system.

VTXO Expiration and Refresh

VTXOs have a finite lifetime of approximately 30 days (roughly 4,320 blocks), enforced through absolute CLTV timelocks on the root and branch transactions. After the timelock expires, the ASP can sweep all bitcoin in the expired round tree using a single on-chain transaction.

This means users must actively participate in a new round before their VTXOs expire. During a refresh, users forfeit their old VTXOs (which the ASP will eventually sweep) and receive new VTXOs with a fresh 30-day lifetime. The ASP fronts the liquidity for new VTXOs immediately, even though it cannot reclaim the forfeited VTXOs until their timelocks expire.

If a user fails to refresh before expiration, the ASP claims their bitcoin. This creates a liveness requirement: users (or software acting on their behalf) must come online at least once every 30 days.

Comparison with Other Off-Chain Models

VTXOs represent one approach to off-chain Bitcoin ownership. Understanding how they compare to other models clarifies their tradeoffs. For a broader comparison, see the Bitcoin Layer 2 comparison.

The most significant difference is in user experience. Lightning commitment transactions require each user to maintain a channel with locked liquidity and handle channel balance management. Statechain transfers move ownership of a fixed-value UTXO by transferring signing authority. VTXOs combine the flexibility of variable amounts with the simplicity of not requiring bilateral channels, at the cost of periodic refreshes and trust in the ASP's liveness for non-emergency operations.

For a deeper look at how Ark's VTXO model compares to other Bitcoin scaling approaches, see the Ark Protocol explained and Bitcoin L2 trust model comparison research articles.

Use Cases

Scalable Bitcoin Payments

VTXOs allow thousands of users to share a single on-chain UTXO while retaining individual ownership. During normal operation, transfers between users of the same ASP settle instantly off-chain. Only the periodic round transactions (roughly one per hour) touch the blockchain, batching potentially thousands of operations into a single on-chain transaction.

Self-Custodial Wallets Without Channels

Self-custodial Bitcoin wallets built on VTXOs avoid the complexity of Lightning channel management. Users do not need to worry about inbound liquidity, channel capacity, or routing. The ASP handles liquidity provisioning, while users retain the ability to exit unilaterally at any time. This model powers protocols like Spark, which uses a similar off-chain UTXO architecture to deliver fast, low-cost Bitcoin transactions with self-custodial security.

Interoperability with Lightning

VTXOs can be atomically swapped for Lightning payments through the ASP, enabling Ark users to pay Lightning invoices without maintaining their own channels. The ASP acts as a bridge: it accepts the user's VTXO forfeit and routes the corresponding payment over Lightning. This gives VTXO holders access to the entire Lightning Network without any channel setup.

Risks and Considerations

Expiration Risk

The 30-day expiration is the most significant operational risk. Users who fail to refresh their VTXOs lose their bitcoin to the ASP. While wallet software can automate refreshes, this creates a liveness requirement that does not exist with on-chain UTXOs or Lightning channels. Users who expect to be offline for extended periods must plan accordingly.

ASP Availability

Although the ASP cannot steal funds (users can always exit unilaterally), a non-cooperative or offline ASP can degrade the user experience. Without the ASP, users cannot create new VTXOs, make instant transfers, or participate in rounds. They can only exit to on-chain, which incurs fees and requires multiple confirmations.

Unilateral Exit Costs

Exiting unilaterally requires broadcasting multiple transactions (one per tree level). During periods of high fee market activity, the total cost of exit transactions may approach or exceed the VTXO's value, particularly for small balances. This dust threshold is a function of both tree depth and current fee rates.

Spend VTXO Trust Assumptions

Spend VTXOs (arkoor transfers) carry additional trust assumptions compared to board and refresh VTXOs. Because they extend the tree off-chain without a new round transaction, the receiver must trust that the sender and ASP do not collude to double-spend. This statechain-like trust model is weaker than the fully trustless guarantees of round-based VTXOs, though the economic incentives generally align against ASP misbehavior.

Liquidity Requirements for ASPs

ASPs must front liquidity for new VTXOs before they can reclaim capital from expired rounds. This creates a roughly 30-day liquidity lockup, requiring ASPs to maintain substantial capital reserves. The economics of running an ASP depend on transaction volume and the spread between capital costs and fee income.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.