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:
- You create an invoice ("pay me 1,000 sats")
- The sender pays it
- 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:
- Settle — the receiver reveals a secret (called a "preimage") and collects the funds
- Expire — a timer runs out and the funds automatically return to the sender
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:
- 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.
- 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.
- 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:
- The coordinator can't take your money. Your reward is locked by a cryptographic hash. The only way to unlock it is to reveal the correct preimage — which triggers settlement to you.
- The coordinator can't keep funds locked forever. Every hold invoice has a timeout (typically a few minutes). When the timer expires, the funds release back automatically. No action needed from anyone.
- The coordinator can't change the deal after the fact. The amount, the timeout, and the conditions are all set when the hold invoice is created. They can't be modified later.
- You can verify everything. The validation check is deterministic. If you disagree with a result, you (or anyone) can re-run the exact same check and see if the coordinator was honest.
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:
- Your reward payment refunds automatically (you don't lose the reward)
- You lose the small submission fee (a few sats — the spam prevention cost)
- You wasted the electricity your computer used for that task
- You notice the rejection and stop working for that coordinator
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:
- You put your product (work) into the machine
- The machine tests whether the product is good
- If it is → coins drop out immediately
- 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:
- Non-custodial — funds are locked in the channel, not held by the coordinator
- Atomic — settlement is all-or-nothing, no partial states
- Time-bounded — CLTV timeout guarantees funds can't be locked indefinitely
- Verifiable — the preimage reveal is cryptographic proof of settlement
For the full technical deep-dive, see Hold Invoices (Lightning Escrow) in the incentive mechanisms research.