In development

The open protocol
for Bitcoin scaling

OpenArk brings trustless liquidity providers to Bitcoin scaling on Lightning. No single operator. No vendor lock-in.

Read the specificationHow it works
OpenArk protocol architectureOpenArk protocol architecture

The problem

What's missing from Ark today

Single-operator trust

In most Ark implementations, one operator (the ASP) holds a single signing key and funds every round with its own capital. Unilateral exit is always available, but day-to-day operation depends entirely on that one party — if the ASP censors, goes offline, or shuts down, users are on their own.

Locked-in liquidity

External capital providers can't participate without trusting the ASP. There's no way for an LP to verify their exit paths before committing funds. This creates a closed system where the ASP controls both operations and liquidity.

Fee extraction

Centralized ASPs recruit wallets, capture fees, and dictate terms. Wallet operators have no sovereignty — they're clients of the ASP, not peers in an open protocol.

Key concepts

The building blocks

ASP

Ark Service Provider

The operator that coordinates rounds and cosigns transactions. Can censor but cannot unilaterally spend your funds.

XLP

External Liquidity Provider

Supplies on-chain capital to fund rounds. Co-verifies the ASP's threshold key and confirms exit paths before signing.

VTXO

Virtual Transaction Output

An off-chain representation of a Bitcoin UTXO. Many VTXOs share a single on-chain root, each with a valid spending path for unilateral exit.

MuSig2

Threshold signing scheme

Multi-party Schnorr signing protocol. The ASP key is split across co-verifiers — no single party can sign alone.

Nostr

Transport layer

ASP-operated relay (NIP-150) for all coordination between ASPs, services, and users. No proprietary APIs.

Agent

Cloud agent

A delegated key that handles round participation on your behalf. Separate from the owner key, rekeyable every round.

Why OpenArk

A better foundation for Ark on Lightning

01

Trustless liquidity

XLPs verify their exit paths cryptographically before committing capital. No trust-based agreements. No single party controls the funds.

02

Trustless round transitions

Funds move to new rounds via co-verified forfeit transactions. No single party — not even the ASP — can redirect capital.

03

Key separation

Delegate round participation to a cloud agent without giving spending authority. Stay offline without risking your funds.

04

Lightning native

HTLC compatible. 4 messages per payment via MuSig2. ARK Services can run their own Lightning nodes, adding routing capacity and strengthening the network topology.

05

Wallet sovereignty

Wallet operators can run their own ASP and keep their fees. No vendor lock-in, no platform dependency.

06

Open transport

No proprietary APIs or vendor-specific protocols. Anyone can observe, audit, or build on the protocol.

Built for

Who uses OpenArk

Wallet operators

Run your own ASP

Embed Ark directly into your wallet. Control your fee structure, custody model, and user experience. No middleman taking a cut, no API dependency on a third-party ASP.

  • ◆Self-hosted ASP with external liquidity from XLPs
  • ◆Keep 100% of transaction fees
  • ◆Full control over round timing and capacity
Liquidity providers

Earn yield on Bitcoin capital

Supply on-chain liquidity to fund rounds. Co-verify exit paths before committing capital — no trust required. Earn fees proportional to your contribution.

  • ◆Trustless co-signing via threshold keys
  • ◆Verify exit paths cryptographically before each round
  • ◆Withdraw capital unilaterally if the ASP misbehaves
Developers

Build on an open spec

BOLT-ARK is a protocol specification, not an SDK. Build your own implementation, integrate with existing infrastructure, or extend the protocol.

  • ◆Open-source reference implementation
  • ◆Nostr-based transport — no proprietary APIs
  • ◆HTLC compatible for Lightning interop

How it works

VTXOs, rounds, and trustless exits

01

Join a round

The ASP announces a new round. Users declare their intentions — onboard, transfer, or offboard. The VTXO tree is constructed.

02

Sign and anchor

Everyone verifies the tree, signs the forfeit and recycle transactions, and the ASP broadcasts the vtxo-root on-chain.

03

Transact off-chain

Send and receive payments using HTLC-compatible spend requests. 4 messages per payment. No single party controls funds.

04

Refresh or exit

Capital moves to the next round atomically via forfeit. Offline users are handled by recycle transactions. Unilateral exit is always available.

Protocol architecture
UserA' + A''
Owner + Agent keys
VTXO
ASPCoordinator
Round orchestrator
threshold key
Co-signers— verify rounds, provide capital
XLP 1Co-verifier
Funds rounds
XLP 2Co-verifier
Funds rounds
XLP 3Co-verifier
Funds rounds
operate
Services— bridge to Lightning and on-chain
Lightning
GatewayLN ↔ Ark
Cross-network routing
Swap
ServiceOn/Off board
On-chain ↔ VTXO
|Bitcoin L1 settlement|HTLC compatible|Unilateral exit|Nostr transport|Bitcoin L1 settlement|HTLC compatible|Unilateral exit|Nostr transport|Bitcoin L1 settlement|HTLC compatible|Unilateral exit|Nostr transport|Bitcoin L1 settlement|HTLC compatible|Unilateral exit|Nostr transport

Infrastructure

Co-signing needs proximity

Colocated XLPs

XLPs are infrastructure operators, not end users. They run alongside the ASP in the same facility or region — like validators in a consensus network.

Users stay remote

Only the co-signers need proximity. End users connect to the ASP from anywhere — their latency doesn't affect round signing.

Proximity, not trust

Same region for latency, different providers for security. XLPs run on separate infrastructure with isolated key material — a compromised ASP should never be able to reach the XLP's signing keys.

Infrastructure diagram showing colocated XLPs and remote users

Comparison

How OpenArk compares

OpenArk vs other Ark implementations

Ark Labs and Second are company-backed Ark implementations. OpenArk takes a different approach to liquidity, custody, and operator sovereignty.

Liquidity providers
OpenArk

Trustless XLPs verify exit paths cryptographically before signing

Single-ASP Ark

ASP provides all liquidity; no external LPs

ASP operation
OpenArk

Any wallet can run an ASP with external liquidity

Single-ASP Ark

Wallets can run ASPs but must fund all rounds themselves

ASP key
OpenArk

Threshold key shared with XLP co-verifiers

Single-ASP Ark

Single operator key

Transport
OpenArk

Nostr (NIP-150) — ASP-operated relay, auditable

Single-ASP Ark

gRPC / REST — proprietary client-server API

Offline handling
OpenArk

Cloud agent handles round transitions automatically

Single-ASP Ark

~30-day VTXO expiry; user must refresh or funds swept

Specification
OpenArk

BOLT-ARK — open protocol spec, no SDK lock-in

Single-ASP Ark

SDK-driven integration, proprietary extensions

Entity
OpenArk

Community-driven protocol; no company, no token

Single-ASP Ark

Company-backed implementations (Ark Labs, Second)

OpenArk in the Bitcoin L2 landscape

Bitcoin has several scaling approaches. Each makes different tradeoffs around custody, liquidity, and trust.

Custody
OpenArk

Threshold key — no single party can spend

Lightning

Self-custodial (channel-based)

Liquid

Federated multisig (11-of-15)

Fedimint

Federated multisig (community guardians)

Unilateral exit
OpenArk

Always available via VTXO spending path

Lightning

Force-close to L1

Liquid

Not available — federation controls peg-out

Fedimint

Not available — trust the federation

Liquidity model
OpenArk

External LPs (XLPs) fund rounds trustlessly

Lightning

Channel partners lock capital bilaterally

Liquid

Federation members provide L-BTC backing

Fedimint

Guardian operators hold reserves

Lightning interop
OpenArk

Native — HTLC compatible, 4-message payments

Lightning

Native

Liquid

Submarine swaps or bridge

Fedimint

Lightning gateways (bridge)

Operator sovereignty
OpenArk

Run your own ASP, keep your fees

Lightning

Run your own node

Liquid

Apply to join the federation

Fedimint

Deploy your own federation

Offline tolerance
OpenArk

Cloud agent participates in rounds automatically

Lightning

Watchtowers or risk channel theft

Liquid

Always online (federation handles)

Fedimint

Always online (guardians handle)

Roadmap

From testnet to mainnet

01
Q2 2026Now

Public testnet

Functional testnet with the core protocol loop running end-to-end. Developers can integrate, test, and break things.

  • ◆Testnet ASP deployment
  • ◆Open-source SDK and CLI release (LDK based)
  • ◆Developer documentation (full VTXO lifecycle)
  • ◆NIP-150 Nostr transport reference implementation
  • ◆XLP signing ceremony tooling
02
Q3 2026

Mainnet beta

Real sats on a production ASP. Limited capacity, open to early adopters and liquidity providers.

  • ◆Live mainnet ASP launch
  • ◆Lightning Gateway integration
  • ◆Reference wallet (owner key / agent key separation)
  • ◆Initial XLP onboarding
  • ◆Cloud agent reference implementation
03
Q4 2026

Protocol hardening

Security audits, stress testing, and ecosystem tooling. Making the protocol production-grade.

  • ◆Independent security audits
  • ◆Network stress testing
  • ◆ASP operator toolkit
  • ◆Third-party wallet integrations
  • ◆BOLT-ARK v1.0 specification freeze

Technical FAQ

Protocol and architecture

Protocol
Lightning has improved with LSP-based wallets (Phoenix, Breez) that abstract away channel management. But the underlying architecture still requires bilateral channels — each user needs dedicated on-chain capital and inbound liquidity, which LSPs provide by managing channels on the user's behalf. OpenArk takes a structurally different approach: hundreds of users share a single on-chain UTXO via the VTXO tree. Onboarding is joining a round, not opening a channel. Payments still use HTLC semantics — the same hashlocks and preimage reveals — so OpenArk is compatible with Lightning, not a replacement.

Two companies build on the original Ark protocol: Second (bark, Rust, signet) and Ark Labs (Arkade, mainnet beta). Both share the same core limitations that OpenArk addresses:

  • Liquidity — single-operator model with no external LPs. OpenArk has trustless XLPs that cryptographically verify exit paths before signing.
  • Transport — proprietary APIs (gRPC/REST). OpenArk uses Nostr (NIP-150) with ASP-operated relays.
  • Co-verification — single operator key. OpenArk uses a threshold key shared with XLP co-verifiers.
No. OpenArk works on Bitcoin as it exists today — no OP_CTV, no OP_CAT, no covenant opcodes required. Like other covenant-less Ark variants, it uses pre-signed transactions with MuSig2 multi-signatures. A future soft fork adding covenants would improve the protocol (removing the interactivity requirement during rounds), but it's not a dependency. OpenArk ships without waiting for consensus changes.
Yes. OpenArk preserves HTLC semantics — the same hashlocks, timelocks, and preimage reveals that Lightning uses. Existing Lightning nodes don't need to understand OpenArk internals. It's compatible with Lightning, not a replacement for it. ARK Services — including XLPs and Lightning Gateways — can run their own Lightning nodes, which adds routing capacity and improves the overall network topology. More ASPs means more well-connected Lightning nodes, not a parallel network.
How it works
Each round produces a single on-chain transaction — the vtxo-root — regardless of how many users participate. All VTXOs are committed in one Taproot output. Unilateral exits require revealing a Merkle path, but cooperative transitions (the common case) add no extra on-chain load. This means hundreds of users can share one UTXO.

When joining OpenArk, you present two keys: an owner key (full spending authority, stays on your device or cold storage) and an agent key (limited to round participation and fraud monitoring — cannot spend funds).

The agent runs as a lightweight process — a VPS, a wallet provider's background service, or a home server. It connects to the ASP via Nostr and rolls your VTXOs into new rounds automatically, so you can close your wallet and your funds stay current. You can rekey the agent every round.

If the agent goes down, your funds remain safe — claim them via unilateral exit before the VTXO's timelock expires. The agent is a convenience, not a custody requirement.

If you are offline, your agent transfers your funds safely to the next round. Your agent is also responsible for guarding against partial unilateral exits. If you don't run an agent, you can claim your funds via unilateral exit before the VTXO's timelock expires.
Standardized, auditable transport. A gRPC/REST API means every ASP defines its own communication protocol — no interoperability, no standard message format. With Nostr (NIP-150), every ASP runs its own relay and all coordination follows a standard message spec. Protocol messages are auditable — clients can verify the ASP is behaving honestly by inspecting relay traffic.
Trust & security
Not on its own — the ASP can censor (refuse to cosign) but cannot spend your funds, because its key is a threshold key shared with co-verifiers. All co-verifiers would need to collude to misbehave, which is why co-verifiers are independent operators. Every VTXO maps to a valid on-chain spending path — you can broadcast your VTXO path on-chain (unilateral exit) before the timelock expires. That's your ultimate protection, but it requires you (or your cloud agent) to act within the VTXO's expiry window.

The threshold group (ASP + XLPs) cannot spend your VTXOs — they don't have your private key. The real risk is a double-spend: the sender colludes with all threshold signers to spend the same input elsewhere. This requires sender + ASP + all co-verifiers to collude. If the sender is the ASP operator, the bar drops to needing all co-verifiers — which is why independent co-verifiers matter.

Out-of-round payments are anchored on-chain with the vtxo-root — once confirmed, they're final. In-round payments rely on the threshold group's honesty until the next round anchors the state. The vulnerability window is only between receiving an in-round payment and the next round confirmation.

The ASP sees which VTXOs are involved in a spend request and cosigns them. It knows the amounts being transferred and the participating public keys within its own rounds. It does not learn the real-world identity behind a key, and it cannot see payments routed through Lightning that originate from an OpenArk VTXO. The privacy model is similar to Lightning — the coordinator knows its direct peers but not the full payment graph. Nostr relay traffic is public, but messages are encrypted between participants.
You exit unilaterally. Every VTXO has a pre-signed on-chain spending path that doesn't require the ASP's cooperation. You broadcast your branch of the VTXO tree to L1, wait for the timelock to expire, and claim your funds on-chain. Your cloud agent can do this automatically if it detects the ASP is unresponsive. The worst case is paying on-chain fees and waiting for the timelock — you never lose funds.

Economics & Incentives

Capital, fees, and incentive design

The capital problem

In other Ark implementations, the ASP must lock up matching capital for every user deposit — typically for ~30 days until VTXOs expire. This creates a structural problem:

  • To onboard 100 BTC of user funds, the ASP needs ~100 BTC of its own capital locked up
  • That capital is frozen until the round expires, so serving more users means raising more external capital indefinitely
  • The ASP becomes a capital-intensive business that scales linearly with user deposits — the opposite of what a protocol should do

Capital-intensive ASP operations typically require external funding to scale. OpenArk eliminates this by letting external liquidity providers fund rounds directly.

Any Ark implementation lets a wallet run its own ASP — that part isn't new. The problem is capital. Running your own ASP means funding every round yourself: for every 1 BTC a user deposits, you lock ~1 BTC of your own capital for ~30 days. Without external funding, only well-capitalized companies can operate ASPs at scale. OpenArk's XLP model breaks this constraint. Wallets can source round liquidity from external providers trustlessly, so running your own ASP no longer requires a massive balance sheet.
Because the ASP holds a single operator key. An external LP can't independently verify that their capital is safe — they'd be trusting the ASP not to mismanage funds. OpenArk's threshold key model with co-verifiers means no single party has unilateral spend authority, which is the prerequisite for trustless LP participation.
Wallet operator incentives
One round is active at a time. When the round-end block is found, the ASP finalizes the VTXO tree, handles refreshes, and starts the next round. Users pay transaction fees on VTXO transfers — similar to how Lightning charges routing fees. LPs earn yield by providing round liquidity. Because the wallet operates its own ASP, fee capture stays with the wallet operator — not a third-party service provider.
Control and revenue. When you run your own ASP, you set the fee structure, capture transaction fees directly, and don't depend on a third party for uptime or policy decisions. With OpenArk's XLP model, you don't even need your own capital — external liquidity providers fund the rounds. The wallet operator provides the coordination infrastructure, the LPs provide the capital, and users get a sovereign payment experience. Everyone earns from their contribution.
Yes. The BOLT-ARK specification defines the full protocol surface — message types, transaction templates, key derivation, and Nostr relay coordination. Any wallet or application can implement the spec. There's no SDK lock-in — you build directly against the protocol.
OpenArk is designed so that any wallet can run its own ASP. The specification is available on GitHub and a reference implementation is in development. Since the protocol is an open spec, wallet developers can integrate it without permission or partnership agreements.
Liquidity provider incentives
External Liquidity Providers (XLPs) can fund rounds by contributing on-chain inputs. In return, they receive matching outputs in the forfeit and recycle transactions. Before signing anything, the XLP can cryptographically verify that their exit paths exist in every execution branch. No trust in the ASP required — it's verifiable on-chain.
XLPs contribute on-chain inputs to fund rounds and receive matching outputs in the forfeit and recycle transactions. They earn fees from the round in exchange for their capital commitment. Because exit paths are cryptographically verifiable before signing, XLPs don't need to trust the ASP — they can calculate their exact risk and return. This opens Ark liquidity to any capital provider, not just the ASP operator.
Bitcoin treasury companies are a natural fit. They already hold BTC on their balance sheet and are looking for native yield — not DeFi risk, not wrapped tokens, just Bitcoin-denominated returns on Bitcoin. As an XLP, a treasury company commits capital to rounds, earns fees, and can cryptographically verify every exit path before signing. It's a low-trust, auditable yield source that doesn't require moving BTC off-chain or into someone else's custody.
XLPs participate in every round's signing ceremony, so low-latency connectivity to the ASP matters. Same-region infrastructure (e.g. both in eu-central) keeps MuSig2 signing rounds fast. But same region doesn't mean same trust boundary — the XLP's signing key should be isolated in an HSM on separate infrastructure. Colocation for latency, separation for security. The cost is a VPS with a secure enclave, not a data center.
Ecosystem & adoption
No. OpenArk is a protocol specification, not a product or platform. There is no OpenArk token, no governance token, and no plans for one.
The specification (BOLT-ARK) is published and implementation is in development. The project is fully open-source and contributions are welcome. There is no company behind OpenArk — it's a community-driven specification.

Get involved

Build on the protocol.

OpenArk is an open protocol — no permission, no vendor, no gatekeeper. Clone the repo and start building.

terminal
$git clone https://github.com/dukeh3/openark.git
$cd openark
$cat 15-open-ark.md # read the BOLT-ARK spec
Read the specificationContribute on GitHub
Join the community:DiscordTwitter / X