Hold Invoices: How Your Funds Stay Safe

The short version: your bitcoin is protected by math, not by trusting anyone.

How a Normal Lightning Payment Works

In a regular Lightning payment, the whole thing happens in under a second:

  1. You create an invoice ("pay me 1,000 sats")
  2. The sender pays it
  3. You receive the sats instantly

Simple. But for l402-train, we need something slightly different — we need to hold the payment in escrow while your work gets checked.

What Is a Hold Invoice?

A hold invoice (sometimes called a "hodl invoice") is a Lightning invoice where the payment is locked but not yet settled. The bitcoin leaves the sender's wallet and is held in the Lightning channel — but the receiver can't spend it yet.

Think of it like a check that's been cashed but the funds are on hold. The money has left the sender's account, but it hasn't arrived in the receiver's account yet. It's sitting in between, controlled by rules, not by any person.

There are only two possible outcomes:

There is no third option. Nobody can redirect the funds elsewhere. Nobody can keep them locked forever. This isn't a policy — it's enforced by the Lightning protocol itself.

How l402-train Uses Hold Invoices

Here's what happens when you submit work to a coordinator:

Your Computer Coordinator 1 Submit work Lock payment work sats locked in escrow 2 Check quality Did this improve the model? 3a Pass ✓ Sats received! payment released instantly or 3b Fail ✗ Sats refunded automatic after timeout No third outcome is possible. Nobody can redirect or keep the funds.
  1. You submit your work. At the same time, the coordinator locks your reward payment in a hold invoice. The sats are now in escrow — the coordinator can see them but can't spend them.
  2. The coordinator checks your work. It applies your contribution to the AI model and measures whether performance improved. This is a deterministic test — the same inputs always produce the same result, and anyone can re-run it to verify.
  3. Two outcomes:
    • Your work helped → the coordinator reveals the preimage, the hold invoice settles, and the sats land in your wallet instantly.
    • Your work didn't help → the coordinator does nothing, the timer expires, and the sats return to the coordinator's wallet automatically. You lose nothing except the small submission fee.

Why This Is Secure

The security doesn't come from trusting the coordinator. It comes from the rules of the Lightning protocol itself:

What's the Worst That Can Happen?

Let's be honest about the absolute worst case: a malicious coordinator rejects valid work on purpose. In this scenario:

That's it. Compare this to traditional freelance platforms where a client can simply refuse to pay after receiving your work, and you're stuck fighting it through customer support. With hold invoices, the refund is automatic and instant — no dispute process, no appeals, no waiting.

A Simple Analogy

Imagine a vending machine that works in reverse:

  1. You put your product (work) into the machine
  2. The machine tests whether the product is good
  3. If it is → coins drop out immediately
  4. If it isn't → your product is returned, and the coins the machine was going to pay you go back to the machine's owner

The machine can't keep your product and the coins. It can't give you fewer coins than promised. The rules are built into the machine itself. That's what a hold invoice does.

For the Technically Curious

Hold invoices use the same HTLC (Hash Time-Locked Contract) mechanism as regular Lightning payments. The difference is that the receiver delays revealing the preimage until a condition is met.

In LND (the Lightning implementation l402-train uses), this is supported natively via the AddHoldInvoice and SettleInvoice RPCs. The hold period is bounded by the HTLC's CLTV (CheckLockTimeVerify) timeout — after that block height, the HTLC expires and the sender's funds are released back along the payment route.

Key properties:

For the full technical deep-dive, see Hold Invoices (Lightning Escrow) in the incentive mechanisms research.

← Back to protocol overview