Virtual UTXOs (VTXOs) Explained

• Virtual UTXOs (VTXOs) are offchain analogues to UTXOs, defined with Taproot scripts that provide both collaborative and delayed unilateral spending paths.
• They amortize onchain costs via batched commitments, enabling many offchain coins to be anchored with a constant footprint of about 200 vB.
• VTXOs offer secure offchain transfer mechanisms with unilateral exit options, though they require periodic state refresh to manage expiry risks.

Searching arXiv for papers on VTXOs and closely related architectures. Virtual UTXOs (VTXOs) are offchain UTXO-like objects defined in Ark as outputs

$vtxo := (value, vtxoLockScript)$

whose locking scripts are Taproot scripts with an unspendable key path, at least one collaborative script path requiring the operator’s signature, and at least one unilateral script path that does not require the operator’s signature and is delayed by a relative timelock $t_u$. They are usually not present as onchain outputs yet, but are committed to indirectly by a compact onchain structure. In this construction, VTXOs preserve UTXO-shaped ownership and transfer semantics while amortizing onchain costs across batched commitments, so that balances remain collaboratively transferable offchain and individually redeemable onchain before batch expiry (Keer et al., 20 May 2026).

1. Formal definition and design rationale

A VTXO is introduced in Ark as an offchain analogue of a normal Bitcoin UTXO. Like a UTXO, it represents a discrete coin-like object with a value and spending conditions. Unlike a normal UTXO, it is usually not present as an onchain output yet. Instead, it exists as part of Ark’s offchain state and is only committed to indirectly by a compact onchain structure. The defining combination is collaborative spendability with the operator plus a delayed self-custodial unilateral path. A simple example is

$$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$

This yields a collaborative spend by Alice and the operator $O$, and a unilateral spend by Alice alone after the relative delay $t_u$ (Keer et al., 20 May 2026).

The virtual abstraction is motivated by the cost model of ordinary Bitcoin UTXOs. Ordinary UTXOs are explicit, global, and expensive because every creation and spend consumes block space. Ark’s formulation instead keeps the same coin-object semantics but lets the protocol commit to arbitrarily many VTXOs with a constant-sized onchain footprint of approximately $200$ vB, specifically $197$ vB in the implementation. This is the central batching property: UTXO-like ownership is preserved, while onchain footprint is amortized across many users (Keer et al., 20 May 2026).

The design rationale is also comparative. Ark is positioned against Lightning-style channels, payment pools, sidechains, rollups, and statechains. The stated novelty is not merely offchain balances, but UTXO-shaped offchain balances that are externally receivable, individually exitable, and only locally updated by the parties involved. In that sense, VTXOs are neither ordinary account balances nor merely local database entries at an operator; they are virtual claims with a defined unilateral materialization path (Keer et al., 20 May 2026).

2. Protocol roles and lifecycle

The Ark system model distinguishes users $P_1, P_2, \ldots$, an Ark operator $O$, counterparties in transfers, and an optional signer committee for fast finality. The operator is explicitly untrusted in the base protocol. The adversary may corrupt any subset of parties, including $O$, and behave Byzantine. What the operator can do is delay or censor offchain requests, refuse to collaborate in transfers, swaps, or cooperative exits, and force users onto the unilateral exit path. What the operator cannot do, assuming the protocol conditions hold, is steal an honest user’s unexpired committed VTXO without satisfying its spending conditions, or prevent unilateral redemption of a committed VTXO before batch expiry if the user has the relevant path data and exits in time (Keer et al., 20 May 2026).

A VTXO may be received in two main ways. First, a user can board from onchain funds by creating a boarding transaction that locks an onchain UTXO into a script spendable either collaboratively with $t_u$0 or unilaterally by the user after a timeout $t_u$1. Once confirmed, the operator includes it as an input to the next commitment transaction and creates one or more VTXOs for the user inside a batch. Second, a user can receive funds offchain without pre-locking any funds. In the canonical example, Alice owns $t_u$2, creates an Ark transaction spending $t_u$3 collaboratively with $t_u$4, and produces outputs such as a payment VTXO $t_u$5 for Bob and change back to Alice. Bob thus receives a VTXO without first performing any onchain transaction (Keer et al., 20 May 2026).

The offchain transfer primitive is the Ark transaction. Formally, it has inputs $t_u$6, collaborative witnesses, and outputs $t_u$7. The formal state distinguishes $t_u$8, the confirmed VTXOs in batches; $t_u$9, the outputs of Ark transactions not yet batch-swapped; and $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$0, the VTXOs already covered by reset or forfeit mechanisms. This means that a received output is not yet equivalent to a fresh committed VTXO; it remains an offchain derivative until swapped into a new confirmed batch (Keer et al., 20 May 2026).

To address safety and liveness issues found in the original testnet design, Ark introduces reset transactions. For each input VTXO $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$1 that Alice spends in an Ark transaction, she first creates a reset transaction with an output

$$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$2

The Ark transaction then spends these reset outputs. The paper states that the original testnet design was vulnerable to the hostage attack and spam attack, and that reset transactions are the fix now integrated into the mainnet implementation (Keer et al., 20 May 2026).

The lifecycle culminates in batch swap, refresh, and exit. A received offchain VTXO is made robust by batch swapping it into a fresh VTXO in a new confirmed batch. Because batches expire, users must periodically refresh VTXOs by swapping them into newer batches. Exit can then be cooperative, by requesting inclusion of a normal Bitcoin UTXO in the next commitment, or unilateral, by publishing the transactions in $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$3 and later spending the materialized VTXO through its unilateral path (Keer et al., 20 May 2026).

3. Commitment structure, VTXTs, and batching

Ark’s batching mechanism is based on commitment transactions, batches, VTXTs, connectors, and anchors. A batch is one onchain output whose script allows two possibilities: a sweep path after batch expiry, under which $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$4 can reclaim the whole output, and an unroll path before expiry, under which the batch can be spent according to a virtual transaction tree (VTXT). A VTXT is a rooted tree of presigned virtual transactions with one input each. The root spends the batch output, internal nodes create only batch outputs, and leaves each create exactly one VTXO. Thus, many leaf VTXOs are committed behind a single batch root (Keer et al., 20 May 2026).

This construction is what gives Ark its central asymptotic property. The paper’s experimental result is that a commitment transaction has size $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$5 vB, independent of the number of VTXOs in the batch. The abstract summarizes this by stating that Ark can commit onchain to batches of arbitrarily many VTXOs with a constant-sized footprint of approximately $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$6 vB. Cooperative exits add one output per user, while unilateral exits require $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$7 transactions of roughly $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$8 vB per VTXO for a batch of $$Taproot(False; chkSig\{pk_O \oplus pk_A\},\; chkSig\{pk_A\}\wedge relTlk\{t_u\}).$$9 VTXOs (Keer et al., 20 May 2026).

The connector is a separate commitment output used to bind old VTXOs atomically to future commitments during batch swaps and exits. It is also defined by a VTXT, but its leaves are anchor outputs of dust value $O$0, and its virtual transactions are signed solely by $O$1. During a batch swap, the user signs a forfeit transaction spending both the old VTXO and the anchor. This enforces atomicity: if the new commitment is not onchain, the forfeit is unusable; if the new commitment is onchain and the user later tries to redeem the old VTXO, the operator can claim it with the forfeit (Keer et al., 20 May 2026).

The concrete unilateral exit cost is specified as follows. Each intermediate virtual transaction on the path is $O$2 vB, and the leaf transaction is $O$3 vB, so a unilateral exit for a batch of $O$4 VTXOs costs

$O$5

The paper gives an example for $O$6: $O$7 It also reports that in a benchmark with one batch swap request from each of $O$8 users, for $O$9, users must be online simultaneously for about $t_u$0 seconds, and that the measured phases scale linearly in $t_u$1, as expected from MuSig2 overhead (Keer et al., 20 May 2026).

4. Ownership, expiry, and security properties

Ownership of a VTXO is not treated as purely database ownership. To own a VTXO is to possess the information and authorization required to eventually redeem it. For a standard single-owner VTXO, the owner can collaborate with the operator to spend it offchain immediately, or spend it alone after the unilateral timelock. For unilateral safety, the holder must also know the relevant script details and the fully signed transactions in $t_u$2. More generally, the paper notes that VTXOs may contain multiple complex script paths, so ownership generalizes to whoever can provide a valid witness (Keer et al., 20 May 2026).

Expiry is integral to the design. VTXOs live inside batches, and batches expire. The batch output includes a sweep path for $t_u$3 after an absolute expiry time. In the figures and text,

$t_u$4

where $t_u$5 is the height at which the commitment is submitted and $t_u$6 is the batch expiry interval. VTXOs are therefore time-bounded unless refreshed. The unilateral exit routine requires that the user possess the fully signed transactions along $t_u$7, that the batch output containing the VTXO exist and be confirmed, and that the user act before expiry. The liveness guarantee is stated carefully: an honest holder can unilaterally redeem before batch expiry, and this is safe if submitted by at latest block height

$t_u$8

for a batch expiring at height $t_u$9, so the whole path can confirm in time (Keer et al., 20 May 2026).

The paper formalizes VTXO Security in terms of safety and liveness. For an unexpired VTXO in a confirmed batch, VTXO-safe means that if a committed VTXO disappears from the confirmed set before expiry, then either it was unilaterally exited or there exists a valid collaborative spend witness. VTXO-live means that anyone knowing $200$0 can turn it into an onchain UTXO by height $200$1, w.o.p. These guarantees rest on assumptions including authenticated communication, a synchronous network with bound $200$2, secure signatures and hashes, Bitcoin ledger robustness with parameters $200$3, honest cosigners on the relevant VTXT path, user possession of $200$4, and timely action before expiry (Keer et al., 20 May 2026).

Operator safety introduces an additional timing condition: $200$5 The paper states that this ensures the operator can react to onchain appearance of spent VTXOs with reset or forfeit transactions before unilateral paths become spendable. Fast finality strengthens assumptions further, requiring a rational operator, an online signer committee with at least one honest signer, a broadcast network among fast-finality users, and known aggregate value $200$6 held by opt-in users. Without these extra assumptions, finality is delayed until onchain commitment (Keer et al., 20 May 2026).

The security discussion also records two attacks discovered in the original design. In the hostage attack, an Ark transaction consuming VTXOs from different batches could interact badly with expiry sweeps and create problematic dependencies. In the spam attack, a malicious user could try to force the operator to chase long chains of offchain transactions onchain. Reset transactions are presented as the fix for both attacks, and the paper notes that, against a fully Byzantine attacker, the operator may still need extra policy controls such as limiting Ark transaction chain length (Keer et al., 20 May 2026).

5. Position among Bitcoin payment and scaling systems

Relative to ordinary Bitcoin UTXOs, a VTXO is offchain but UTXO-like, committed inside a batch, and materializable onchain through a unilateral path. This preserves the coin-object model while compressing onchain footprint. Relative to Lightning balances, VTXOs are easier to receive because a receiver can accept one without any prior onchain action. Ark stresses that users can receive offchain payments without locking any funds beforehand, whereas Lightning-style channels require prior onchain funding and then ongoing management of capacity, routing, rebalancing, and top-ups (Keer et al., 20 May 2026).

Relative to payment pools and channel factories, Ark’s locality of updates is central. Payment pools can share a single UTXO among many users, but on Bitcoin they either require unavailable covenant functionality or require all users to participate in every state update. Ark instead requires only the operator plus the users involved in a given update. The paper presents this as a major contrast with CoinPool-style systems that require global coordination, and as the condition that makes VTXOs practical as transferable objects in a large user population (Keer et al., 20 May 2026).

Relative to statechains, the distinction is the trust model. Statechains transfer ownership of a UTXO offchain but require a trusted operator to not collude with previous owners. Ark’s VTXOs instead rely on committed batch structure, unilateral exit paths, and reset or forfeit atomicity, so the operator may be malicious while user funds remain non-custodial under the stated assumptions. Relative to rollups and sidechains, Ark stays anchored directly in Bitcoin and uses Bitcoin-compatible scripts, but does not post enough data onchain for the state to be reconstructed. Each VTXO holder must store their relevant local state and path data (Keer et al., 20 May 2026).

This comparative picture also sharpens the tradeoffs. Base Ark offers delayed finality until batch swap or commitment confirmation, unless users opt into the extra fast-finality mechanism. VTXOs have expiry and refresh requirements, whereas ideal covenanted pools could avoid some of that. Unilateral exits in Ark are $200$7, not constant. The paper therefore presents VTXOs not as a universal replacement for all Bitcoin Layer-2 designs, but as a specific compromise: no pre-locking required for receivers, only involved users update state, constant-sized commitments, and individually redeemable claims, but with expiry management and operator-centered coordination (Keer et al., 20 May 2026).

6. Relation to distributed-state UTXO architectures and optimistic verification

Two adjacent research directions are relevant to VTXOs without themselves being VTXO proposals. The first is the hUTXO model of "Scalable UTXO Smart Contracts via Fine-Grained Distributed State" (Bartoletti et al., 2024). That work does not explicitly define or discuss VTXOs, but it is relevant conceptually because it decomposes a monolithic contract state into many independently referenceable onchain state fragments. In the paper’s own VTXO-oriented interpretation, the base onchain unit is the hUTXO contract output, the virtualized subunits are hashed state locations and default intervals represented by those outputs, and independent shards can be processed like independent UTXOs. The important differences are equally explicit: these fragments are onchain, not offchain; they are not user-owned assets; they are covenant-controlled contract-internal representations; and the contract balance is deliberately moved to an account map rather than sharded into UTXOs (Bartoletti et al., 2024).

The second is "BitVMX: A CPU for Universal Computation on Bitcoin" (Lerner et al., 2024). It also does not mention VTXOs explicitly, but it contributes mechanisms with clear overlap: a pre-signed transaction DAG, a message-linking protocol for authenticated state passing across transactions, a challenge-response dispute game, and a hash-chain commitment to offchain sequential state evolution. The paper explicitly states that its presigned transaction design is related to the concept of connectors introduced in the Ark protocol. This suggests that BitVMX is best read as a toolkit of mechanisms for optimistic, challengeable, offchain state evolution over Bitcoin’s stateless UTXO model, rather than as a finished VTXO design. Its most direct relevance to VTXOs lies in pre-authorized fallback branches, timeout-driven forced-response flows, authenticated cross-transaction state handoff using $200$8, $200$9, $197$0, and $197$1, and selective revelation of disputed state fragments (Lerner et al., 2024).

Taken together, these related lines of work delineate a broader design space. hUTXO studies state virtualization within an extended onchain UTXO ledger; BitVMX studies optimistic verification and stateful behavior emulation over Bitcoin transactions; Ark defines VTXOs as offchain UTXO objects with collaborative transfer and unilateral redemption. A plausible implication is that VTXO research sits at the intersection of these themes: virtualization of granular claims, explicit fallback structure, and dispute-aware state evolution.

7. Limitations and open questions

The Ark paper is explicit that VTXOs come with tradeoffs. The operator remains operationally central even though the system is non-custodial: the operator coordinates updates, provides liquidity, and creates commitments. If the operator disappears, users can still exit, but the system degrades to the pessimistic path with more onchain cost. The operator also funds commitment outputs with its own capital, and that capital is tied up until batch expiry (Keer et al., 20 May 2026).

Expiry management is a persistent liveness requirement. Because batches expire, users must periodically refresh VTXOs through batch swaps. If users neglect refresh and wait too close to expiry, they may face congestion risk. The paper also notes that small VTXOs may become uneconomical to redeem during high-fee periods, so small holders may be priced out. This follows directly from the logarithmic but nonzero unilateral exit cost, combined with Bitcoin fee volatility (Keer et al., 20 May 2026).

The model also places a burden on local state retention. Unlike rollups, Ark does not put enough information onchain to reconstruct user state. Users must store their VTXO details, their VTXT path, and possibly additional Ark transaction history for fast finality. Lose that, and recovery becomes problematic. Online assumptions are lower than Lightning’s continuous dispute monitoring, but not zero: users must reconnect periodically for refresh, should act before batch expiry, and, if they opt into fast finality, must stay online until funds are spent (Keer et al., 20 May 2026).

Finally, the paper identifies systemic stress scenarios. If many users simultaneously force unilateral exits, onchain demand spikes. Since Bitcoin throughput is limited, users should not wait until the last moment before expiry. The paper also points to a rational miner attack surface in which timelock bribing might let a colluding operator try to censor unilateral exits until expiry and then sweep. These issues are presented as future-work territory, but they are directly relevant to the safety envelope of time-bounded VTXOs (Keer et al., 20 May 2026).