Skip to main content

​
Overview

Ark is a Bitcoin layer 2 protocol that enables fast, low-cost, self-custodial payments at scale. Unlike Lightning, Ark uses a client-server model where users can transact off-chain while maintaining the ability to unilaterally exit their funds on-chain at any time.
Bark is Second’s implementation of the Ark protocol on Bitcoin, consisting of the bark wallet client, the captaind server, and a set of protocol libraries.

​
Protocol Architecture

The Ark protocol coordinates multiple users sharing control of a single Bitcoin UTXO through a tree of pre-signed, off-chain transactions. This enables instant payments while preserving self-custody.

​
Core Components

​
ArkInfo Structure

The ArkInfo struct (defined in lib/src/lib.rs) contains all critical protocol parameters: 
pub struct ArkInfo {
    pub network: Network,
    pub server_pubkey: PublicKey,
    pub mailbox_pubkey: PublicKey,
    pub round_interval: Duration,
    pub nb_round_nonces: usize,
    pub vtxo_exit_delta: BlockDelta,
    pub vtxo_expiry_delta: BlockDelta,
    pub htlc_send_expiry_delta: BlockDelta,
    pub htlc_expiry_delta: BlockDelta,
    pub max_vtxo_amount: Option<Amount>,
    pub required_board_confirmations: usize,
    pub max_user_invoice_cltv_delta: u16,
    pub min_board_amount: Amount,
    pub offboard_feerate: FeeRate,
    pub ln_receive_anti_dos_required: bool,
    pub fees: FeeSchedule,
}

​
Key Design Elements

Client-Server Model
  • Server (captaind) coordinates rounds and manages the shared UTXO tree
  • Clients (bark wallet) participate in rounds and hold VTXOs
  • All state transitions require cryptographic proofs - the server cannot steal funds
Shared UTXO Control
  • Multiple users share control of a single Bitcoin UTXO
  • Each user’s portion is represented by a Virtual Transaction Output (VTXO)
  • Pre-signed exit transactions ensure users can always recover funds
Transaction Tree Structure
  • Uses a radix-4 tree structure for efficient batching
  • Tree nodes organize VTXOs hierarchically
  • Minimizes on-chain footprint when users cooperate

​
Protocol Operations

​
Boarding (On-chain to Ark)

Users can board funds onto Ark in two ways:
  1. Direct Boarding: Send Bitcoin to a board address that the server co-signs
  2. Round Participation: Board during a round for better efficiency
The required_board_confirmations parameter (from ArkInfo) determines when boarded funds become spendable.

​
Arkoor (Off-chain Transfers)

“Arkoor” (Ark-to-Ark) transfers allow instant, off-chain payments between Ark users:
  • Users exchange VTXOs without touching the blockchain
  • Server cosigns the transfer using MuSig2 aggregated signatures
  • Both parties receive new VTXOs in the next round
  • Fees are typically lower than on-chain transactions
Arkoor transactions are named after the protocol’s ability to transfer funds off-chain between Ark users, combining “Ark” with “oor” (Dutch for “across” or “through”).

​
Offboarding (Ark to On-chain)

Users can exit Ark cooperatively with the server:
  • Submit VTXOs to be redeemed for on-chain Bitcoin
  • Server includes the payment in the next round transaction
  • More efficient than unilateral exits
  • Subject to round fees and timing

​
Lightning Integration

Ark integrates seamlessly with the Lightning Network: Sending Lightning Payments
  • Use VTXOs to pay Lightning invoices, offers, or addresses
  • Server routes payment through Lightning
  • HTLC VTXOs lock funds until payment settles
  • Expiry deltas (htlc_send_expiry_delta, htlc_expiry_delta) protect both parties
Receiving Lightning Payments
  • Generate invoices that settle into Ark VTXOs
  • Funds arrive as VTXOs in the next round
  • No channel management required

​
Security Model

​
Self-Custody Guarantees

The core security property: users can always unilaterally exit their funds, even if the server becomes malicious or offline.
Every VTXO includes pre-signed exit transactions that:
  • Require only the user’s signature after vtxo_exit_delta blocks
  • Cannot be censored by the server
  • Can be broadcast at any time for emergency recovery

​
Timelock Parameters

Two critical timelocks protect users:
  1. Exit Delta (vtxo_exit_delta): Relative timelock before users can unilaterally exit
    • Allows server to refresh VTXOs in cooperative scenarios
    • Typically set to a reasonable value like 2016 blocks (~2 weeks)
  2. Expiry Delta (vtxo_expiry_delta): Absolute expiry height for VTXOs
    • After expiry, server can reclaim unclaimed funds
    • Users should refresh VTXOs before expiry
    • Prevents indefinite locking of server liquidity

​
Cryptographic Foundations

MuSig2 Aggregated Signatures
  • Server and user jointly sign transactions
  • Neither party can forge the other’s signature
  • Implemented in lib/src/musig.rs
Taproot Scripts
  • All VTXOs use Taproot for efficiency and privacy
  • Exit paths encoded in tapscript leaves
  • Cooperative spends use keypath (more efficient)

​
Network Parameters

Different networks have different trade-offs:
ParameterMainnet (typical)Signet (testing)
round_interval5-15 minutes1-5 minutes
vtxo_exit_delta2016 blocks (~2 weeks)144 blocks (~1 day)
vtxo_expiry_delta4032 blocks (~4 weeks)288 blocks (~2 days)
min_board_amount10,000 sats1,000 sats
Actual values are configured by each Ark service provider and may vary based on their risk tolerance and target use cases.

​
Fee Structure

The FeeSchedule (referenced in ArkInfo.fees) determines costs for various operations:
  • Boarding fees: Typically zero or minimal
  • Arkoor fees: Small percentage or fixed amount
  • Offboard fees: Cover on-chain transaction costs
  • Round participation: Proportional to VTXO consolidation
  • Lightning routing: Standard Lightning routing fees

​
Trade-offs and Limitations

​
Advantages over Lightning

  • No channel management or liquidity requirements
  • Instant onboarding without waiting for channel opens
  • Simplified UX for end users
  • Universal payments (Ark, Lightning, on-chain from single balance)

​
Current Limitations

  • Requires periodic round participation to refresh VTXOs
  • Users must monitor expiry heights to prevent fund loss
  • Server availability needed for cooperative operations
  • Trust in server’s liquidity (but not custody)
Bark is experimental software. Using it with real Bitcoin is reckless and can result in loss of funds. Known bugs and vulnerabilities can still lead to loss of funds.

​
Further Reading

VTXOs

Learn about Virtual Transaction Outputs

Rounds

Understanding the round system

Exits

Exit mechanisms and emergency recovery

Build docs developers (and LLMs) love

Get started for freeTalk to us