ark-primary-sources-2026-05-15

Ark primary sources

Reviewed: 2026-05-15 UTC

Official protocol overview

• https://ark-protocol.org/
  • Best concise public framing for what Ark says it is.
  • Used to confirm that Ark positions itself as a client-server Bitcoin layer 2, distinguishes itself from Lightning’s channel-network model, foregrounds VTXOs and shared UTXOs, and highlights rounds plus out-of-round (arkoor) payments as core protocol surfaces.

Intro / high-level system model

• https://second.tech/docs/learn/intro
  • Best single entry point for the protocol design in this pass.
  • Used to confirm the client-server model, VTXO-based scaling, periodic server rounds, transaction trees, VTXO lifetime, server-provided liquidity, offboarding, emergency exits, same-server Ark payments, and Lightning gateway framing.

VTXO model and transaction-tree structure

• https://second.tech/docs/learn/vtxo
  • Best source for the underlying object model.
  • Used to confirm the board / refresh / spend VTXO distinction, transaction-tree structure, cooperative-versus-timelocked spend paths, shared-UTXO design, exit-cost tradeoffs, and the different trust assumptions attached to each VTXO type.

Rounds / refresh workflow / delegated signing

• https://second.tech/docs/learn/rounds
  • Best source for the periodic round process.
  • Used to confirm that rounds are now refresh-only, the interactive refresh flow, server-configurable interval policy, round atomicity via hash-locked forfeits, and the delegated-refresh / co-signer design for intermittently online devices.

Out-of-round payments and trust tradeoff

• https://second.tech/docs/learn/payments
  • Best source for arkoor payment behavior.
  • Used to confirm that payments occur out of round, create spend VTXOs, avoid liquidity requirements, and temporarily rely on sender-plus-server non-collusion until the receiver refreshes.

VTXO lifetime and server sweep rights

• https://second.tech/docs/learn/lifetime
  • Best source for the expiry model.
  • Used to confirm that all VTXOs have limited lifetimes, that expiry enables the server to sweep remaining bitcoin to recover deployed liquidity, and that users must spend, refresh, offboard, or exit before expiry to maintain control.

Liquidity economics

• https://second.tech/docs/learn/liquidity
  • Best source for the project’s capital model.
  • Used to confirm which operations require server liquidity, how opportunity cost is framed, how fees depend on amount and time-to-expiry, and why Ark shifts liquidity management from users to the server.

Lightning gateway behavior

• https://second.tech/docs/learn/payments-lightning
  • Best source for the protocol’s Lightning interoperability path.
  • Used to confirm that the server acts as a Lightning gateway, that outgoing and incoming Lightning flows use HTLCs, and that the server funds and mediates Lightning-side operations from its own infrastructure and VTXO pool.

Current fee surface

• https://second.tech/docs/learn/fees
  • Best source for the live policy layer in this pass.
  • Used to confirm that fee policy is server-specific rather than protocol-hardcoded, and that refresh, offboard, and Lightning pricing are explicitly tied to liquidity costs and remaining VTXO lifetime.

Main takeaways from this pass

• Ark is best understood as a layered server-mediated VTXO system: round coordinator, liquidity treasury, expiry/sweep policy, arkoor spend path, and Lightning gateway.
• The cleanest analytical split is between trustless board/refresh VTXOs and lower-trust spend VTXOs, rather than between custodial and self-custodial in the abstract.
• The most important economic question is not just throughput but who bears liquidity costs; Ark makes that the server’s problem, then prices user actions around that burden.
• Delegated refreshes and Lightning gateway operation matter because they reveal where mobile UX and external-network interoperability reintroduce additional trust or policy layers above the base emergency-exit guarantee.