Offchain Arkade transactions in the virtual mempool operate under the preconfirmation trust model. If a user wants full Bitcoin finality for their funds, they need to settle them onchain via a batch swap. Users accomplish this by submitting an intent that specifies which VTXOs they forfeit and which VTXOs they expect to receive in the upcoming batch. The operator coordinates the settlement process and broadcasts the associated commitment transaction onchain. The following sections detail this workflow and the respective functions involved.
Users can safely sign forfeit transactions because the commitment transaction atomically creates both the new VTXOs and the connector output that enables the operator to claim forfeited funds.

​
Client Workflow: Participating in a Batch Swap 

Initial Setup and Information Gathering To participate in a batch swap, users begin their participation by querying the server through the GetInfo endpoint to retrieve (GetInfoResponse) essential network parameters like round intervals, exit delays, and amount limits that clients need for proper operation. sequence-onchain-new.png

​
Client Workflow: Steb by Step 

1

Intent Registration

  • Client creates and registers an intent (RegisterIntent) as a PSBT signed with BIP322, defining inputs and outputs
  • Server stores it under a unique intent_id
  • Client can revoke an intent via DeleteIntent
2

Batch Updates & Confirmation

3

Tree Signing & Multi-Signature Coordination (MuSig2)

  • Server builds unsigned VTXO tree, commitment transaction and connector outputs
  • Server sends unsigned VTXO tree and commitment transaction to client
  • Client verifies data and creates random nonces for every branch transaction
  • Client submits tree nonces (SubmitTreeNonces)
  • Server verifies tree nonces, aggregates and returns them
  • Client submits tree signatures (SubmitTreeSignatures)
  • Server verifies, aggregates and finalizes via signing the VTXO tree and connectors and returning them to the client
  • Client verifies data
4

Forfeit Transaction Handling

  • Client creates forfeit transactions with connector outputs
  • Client submits signed forfeit transactions (SubmitSignedForfeitTxs)
  • If initial boarding, users also sign the commitment transaction
5

Onchain broadcast

Server broadcasts the signed commitment transaction on the Bitcoin mainchain
VTXO renewal undergoes the exact same process of participating in a batch swap. The renewal can either be done manually, which implies a liveness requirement of the user. VTXO renewal can also be delegated to a third party without key handoff.

​
Workflow Monitoring

The actual offchain execution workflow uses the ArkService. While the IndexerService doesn’t directly handle offchain execution, it provides several supporting query functions that clients might use: Commitment Tx Analysis
  • GetCommitmentTx returns details of a commitment transaction (TxId), including batches, amounts, and timestamps
  • GetForfeitTxs returns forfeit transactions linked to a commitment transaction
  • GetConnectors returns the connector output tree with positioning details for a commitment transaction
VTXO Monitoring
  • GetVirtualTxs: Retrieves virtual transactions in hex format for specified transaction IDs
  • GetVtxos: Queries VTXO states by scripts or outpoints
  • GetVtxoChain: Traces transaction chains for specific VTXOs
Transaction History
  • GetVirtualTxs returns raw virtual transactions for given Arkade transaction IDs
  • GetVtxoChain traces the lineage of Arkade transactions from a VTXO leaf spend to a specified VTXO outpoint, enabling full history reconstruction
Batch Operations
  • GetBatchSweepTransactions returns transactions swept from a given batch output, indicating whether the operator claimed it after expiry or a user unrolled the tree
Script Subscriptions
  • SubscribeForScripts: Subscribe to notifications for specific VTXO scripts
  • GetSubscription: Receive real-time notifications about subscribed scripts i