Most Bark-based payments will be Lightning paymentsArk payments require both sender and receiver to share the same Ark server. Until individual Ark servers build significant user bases, most payments from Ark wallets will be routed over Lightning—reaching anyone on the network regardless of what wallet app or service they use.
Ark HTLCs
Both outgoing and incoming Lightning payments on Ark use HTLCs (hash time-locked contracts) to ensure atomic execution. An HTLC locks bitcoin with two possible outcomes: it can be claimed by revealing a secret (the preimage), or it returns to the sender after a timeout. HTLCs are integral to how the Lightning Network routes payments across the network.Sending a Lightning payment
When you send a Lightning payment, you spend one of your VTXOs to an HTLC. The Ark server routes the payment to the recipient over the Lightning Network using its own channels. The HTLC serves a similar role to the forfeit used in on-chain payments: it’s an off-chain transaction that the server holds as a safeguard, ensuring you can’t reclaim the VTXO after the payment has been delivered.The send process
- Initiate payment: You provide a Lightning invoice or address to pay.
- Construct HTLC: Your wallet app and the Ark server cooperate to spend one of your VTXOs into an HTLC—a conditional off-chain output that locks the payment amount until the Lightning payment succeeds or fails.
- Route payment: The Ark server routes the payment over the Lightning Network to the recipient.
- Settle: The server obtains the preimage from the Lightning Network and provides it to you as proof of payment.
Trust model for Lightning send
When a Lightning payment is delivered successfully, none of the HTLC’s spend paths are used. Like a forfeit, the HTLC is held off-chain as a safeguard against malicious exits—the server simply sweeps the round transaction when it expires. The spend paths only come into play when something goes wrong:| HTLC spend path | Scenario | How it works |
|---|---|---|
| 1. Cooperative revocation | Payment fails | The server has no preimage and cannot claim your bitcoin. The server cosigns a revocation, returning your bitcoin. |
| 2. Server safeguard | User attempts a malicious exit | If the user attempts to exit on-chain after the Lightning payment has been successfully delivered, the server can claim the bitcoin by revealing the preimage before the user’s timelock expires. |
| 3. User safeguard | Payment fails and server is uncooperative | If the payment was not delivered and the server stops cooperating, you can reclaim your bitcoin after the timelock expires via an emergency exit. |
Receiving a Lightning payment
On Bark, you can receive Lightning payments from anyone on the Lightning Network—no channels or inbound liquidity required. The incoming bitcoin is delivered as a VTXO, so bitcoin at rest are always held in VTXOs, not Lightning channel balances.The receive process
- Generate invoice: Your wallet app generates a preimage and payment hash on-device, then sends the hash to the Ark server. The server returns a Lightning invoice for the sender to pay.
- Incoming payment: A sender pays the invoice. The payment routes through the Lightning Network and arrives at the Ark server, secured by the preimage. The server sends your wallet app a notification that a payment has been received.
- HTLC prep: Your wallet app comes online and requests an HTLC from the server. The server constructs the HTLC—funded from its VTXO pool and locked to your preimage—then shares it with your wallet app.
- HTLC claim: Your wallet app verifies the HTLC, then reveals the preimage to the server. The server verifies the preimage and completes the payment via an arkoor transfer. You receive a VTXO.
Trust model for Lightning receive
The receive HTLC has three spend paths, each covering a different scenario:| HTLC spend path | Scenario | How it works |
|---|---|---|
| 1. Cooperative claim | Server completes the claim | You reveal the preimage and the server cosigns on the cooperative path, completing an arkoor payment from the HTLC to you. You receive a spend VTXO. |
| 2. Server safeguard | User fails to reveal preimage | If you receive the signed HTLC but don’t reveal the preimage, and then attempt a malicious exit from the HTLC, this path enables the server to claim back the bitcoin. Even if you can broadcast spend path 3 (“user safeguard”) before spend path 2’s absolute timelock expires, the preimage will be revealed on-chain, allowing the server to claim the bitcoin from the inbound Lightning payment. |
| 3. User safeguard | Server fails to complete the claim | If, after you cooperatively reveal the preimage, the server does not complete the arkoor payment from the HTLC, you can initiate an emergency exit via this path. The server safeguard has an absolute timelock which ensures that you have a sufficient window to broadcast your claim first. |
Offline receive, online invoice generation
On Bark, Lightning payments can be received when offline. Your wallet app does not need to be online when the sender pays—any HTLC from an inbound Lightning payment is secured by your invoice’s preimage. However, you do need to be online for invoice generation, which is an interactive process with the Ark server, and you do need to come online before the Lightning HTLC expires to claim the payment.Lightning payment fees
Sending
Sending a Lightning payment involves several cost components:- Liquidity costs: The Ark server must deploy bitcoin to route the payment over the Lightning Network. Costs depend on the payment amount and the server’s cost of capital.
- Lightning routing fees: Standard Lightning Network routing fees for the payment’s path through the network.
- Ark server fees: The Ark server may charge additional fees to cover operational costs including Lightning node infrastructure.