Virtual Transaction Outputs (VTXOs) are the fundamental building blocks of Arkade’s execution layer. They are programmable, offchain objects that mirror Bitcoin’s UTXO structure but exist within Arkade’s Virtual Mempool.Each VTXO is backed by a presigned, unbroadcast Bitcoin transaction. These transactions represent a user’s claim to a specific portion of value within a batch output and include defined ownership, value, and spending conditions, supporting both collaborative and unilateral exit paths.In an optimistic scenario, these transactions will never be broadcast, as they are only relied on to provide unilateral exit.VTXOs enable Bitcoin transactions to occur entirely offchain while preserving the security properties of onchain settlement. This allows users to transfer value instantly without competing for block space or paying mining fees for each individual transaction.
VTXOs operate like Bitcoin UTXOs but with lower latency and cost. Each VTXO carries a discrete Bitcoin value and associated spending conditions encoded via Arkade Script.
This paves the way for composable Bitcoin-native contracts within the virtual execution layer.
VTXOs are presigned Bitcoin transactions secured by a Taproot script (keypath unspendable) with two distinct spending paths:
Exit Path (Unilateral) This path is exclusively controlled by the VTXO owner. It allows the user to move their offchain funds onchain at any time without requiring permission or cooperation from the operator.
Collaborative Path This path is the default path being used for Arkade transactions as well as for standard exits of user funds. An Arkade transaction simply requires a cosignature from the Arkade Signer in addition to the owner’s signature. Such design allows for rapid offchain execution within the virtual mempool.
Every VTXO carries a CSV delay that prevents double-spending. Without it, a malicious user could spend their VTXO in a batch swap while simultaneously withdrawing the same funds through an exit - essentially spending the same money twice.
Every VTXO is tied to the lifetime of the batch output it originates from. To maintain unilateral exit rights, users must periodically renew their VTXOs before expiry. If that expiration window is missed, the operator regains control of the underlying funds and issues a redeemable Arkade Note in exchange.This liveness requirement can be managed directly by the user, but it can also be delegated. Through Arkade’s Intent system, a user may appoint a delegate to automatically renew VTXOs on their behalf. Such delegate can be a wallet provider, the operator, or any other trusted partyImportantly: during the renewal process via a delegate, users retain full unilateral control of their funds at all times.
Deep transaction chains: VTXOs that are part of a deep Arkade transaction chain increases unilateral exit exit cost as all transactions of the chain would need to be broadcast, which might make a unilateral exit economically burdensome
Preconfirmation status: VTXOs as part of an offchain transaction chain require honest operator behavior. Preconfirmed VTXOs can be batch swapped at any time which implies inheriting Bitcon finality
Batch Expiry: If a VTXO is not renewed (manually or via a delegate before batch expiry, a user loses unilateral control of their funds
Dust Limits: Arkade supports sub-dust VTXOs by representing them as OP_RETURN outputs tied to a taproot pubkey. These VTXOs are valid within Arkade’s offchain protocol but cannot be exited unilaterally. They cannot be reused in offchain transactions. Sub-dust VTXOs can be included in BIP322-based Arkade intents
VTXO vs. Traditional Account ModelsUnlike account-based systems that maintain a global state ledger, Arkade’s VTXO model requires no global state machine, only local transitions between VTXOs. This enables parallel execution across independent transaction branches without the bottlenecks common in account models, where operations must be serialized to maintain consistent state.
A virtual transaction is just a regular Bitcoin transaction that will optimistically never go onchain