Depositing Bitcoin on Lightning Faucet takes four actions and finishes in about a second: sign in, open the deposit page, enter an amount in sats, then scan the QR code with any Lightning wallet. Your balance updates on screen without a page refresh. There is no confirmation wait, no block to sit through, and no minimum of "one Bitcoin" or anything like it. The floor is 100 sats.
That speed is not marketing language, it is a consequence of how the deposit path is wired. Lightning Faucet does not poll a blockchain for your payment and it does not run a cron job that sweeps for new deposits every few minutes. Our node holds an open subscription to its own invoice stream, so the moment your payment settles, the settlement event is pushed to us, pushed to your browser, and written to your balance. The rest of this guide is the operator's view of that path: the exact steps, the rules that decide whether a deposit lands, what actually happens in the second after you tap Pay, and the handful of things that genuinely do go wrong.
What a Lightning deposit is on Lightning Faucet
A Lightning deposit is a payment of a BOLT11 invoice that our Lightning node generates specifically for your account, for the exact amount you chose, denominated in satoshis. It is not an address you send to repeatedly. Each deposit creates a fresh, single-use invoice tied to your authenticated session, with a fixed expiry.
Two consequences fall out of that design, and both matter to you as a player:
- The invoice knows who to credit. Your account is stamped onto the payment record at the moment the invoice is created, not guessed afterwards from the amount or the memo.
- The invoice is perishable. It is valid for ten minutes. After that it expires and paying it is no longer possible, which is a protection rather than an inconvenience.
Lightning Faucet is Lightning only for deposits. There is no on-chain deposit address, which is precisely why the credit is instant instead of taking an hour of confirmations.
The deposit, step by step
1. Sign in first
The deposit invoice is created against a validated session token. If you are signed out, or your session has expired, the invoice cannot be issued at all. You will get an authentication error rather than a payable QR code.
This is also why you should never reuse an old screenshot of a deposit QR, and never pay an invoice you saved from a previous visit. That invoice belonged to one specific payment record with one specific expiry. If you are having trouble signing in at all, the LNURL-auth QR sign-in option is the fastest route back in, since it authenticates with your wallet key and requires no password.
2. Choose an amount in sats
Everything on Lightning Faucet is denominated in satoshis, including the deposit box. A satoshi is one hundred millionth of a bitcoin. You are not converting to a chip balance or a house token; the number on your balance is the number of sats we hold for you.
The practical range for a single deposit runs from 100 sats at the low end to 1,000,000 sats at the high end. If you want to fund an account with more than the per-invoice ceiling, make more than one deposit. Nothing about the system penalises multiple deposits.
Small deposits are genuinely fine here. A large share of accounts fund themselves with a few thousand sats and play micro-stakes, and several games accept single-digit sat wagers.
3. Scan the QR, or copy the invoice string
Your wallet does the rest. Any Lightning wallet works, custodial or self-custodial, because a BOLT11 invoice is a standard. Scan the QR from a phone wallet, or use the copy button and paste the lnbc... string into a desktop wallet.
Two details worth knowing:
- The amount is fixed in the invoice. Your wallet cannot pay a different amount than the one you selected, which removes an entire class of "I sent the wrong number" mistakes.
- The routing fee, if any, is paid by your wallet out of your wallet, and it is usually a sat or two. Lightning Faucet charges no deposit fee. The sats named on the invoice are the sats that land in your balance.
4. Leave the page open and watch it credit
Do not refresh, and do not navigate away to check. The deposit screen holds a live connection and updates itself. In the ordinary case you will see the balance change before you have put your phone down.
What happens in the second after you tap Pay
This is the part that no generic explainer can tell you, because it is specific to how one operator built their settlement path.
When your wallet pays the invoice, our Lightning node marks it settled and emits a settlement event on a streaming subscription that a dedicated service holds open at all times. That service is not a scheduled job. It is a long-lived process that is already listening when your payment arrives.
On receiving the settled invoice it does several things in a deliberate order:
- Deduplication. The payment hash is checked against already-processed hashes so a replayed or re-delivered settlement event can never credit you twice.
- Instant feedback first. Before any accounting work, a response file is written and a real-time push is sent to your browser session. This is why the number on screen moves so quickly: the user-visible acknowledgement is deliberately ordered ahead of the slower bookkeeping.
- A durable job is queued. The settlement is written into a payment job queue so that if anything downstream fails, the credit is retried rather than lost. Reliability is separated from speed.
- The balance and ledger are written. The payment record moves from pending to completed, your balance is credited, and the movement is recorded in the financial ledger.
The whole sequence typically completes in a few hundred milliseconds. The design intent is that the slow, fallible parts of a payment system can never make you stare at a spinner wondering whether your money arrived.
There is one more quiet safeguard: on larger deposits your session token is rotated as a defence against session fixation. It is invisible in normal use and requires nothing from you.
The rules that decide whether a deposit lands
These are the actual gates in the deposit path, in the order you are likely to meet them.
A valid session. No session, no invoice. Covered above.
The ten minute expiry. From creation, an invoice is payable for ten minutes. The deposit screen keeps checking for roughly eleven minutes, slightly longer than the invoice life, so a payment that settles right at the boundary is still caught. If your invoice expires before you pay it, nothing bad has happened. Close it and create a new one.
Amount bounds. Below the 100 sat minimum, the deposit is rejected before an invoice is ever generated. There is also a hard per-payment ceiling well above the normal maximum, as a blunt safety limit.
Duplicate protection. Deposit requests can carry an idempotency key. If the same request arrives twice, for example because a flaky connection caused your browser to retry, you get the same invoice back rather than two invoices for the same intent. You cannot accidentally end up owing two payments.
Pending payment limits. There is a cap on how many payments can sit pending from one network address at once. Ordinary players never approach it. If you somehow do, complete or abandon the invoices you already have open.
Note what is deliberately absent from that list: there is no velocity limit on deposits. Withdrawals are rate limited for fraud reasons, but there is no reason to slow down money coming in.
Troubleshooting a deposit that did not appear
Your wallet says paid but the balance has not moved. Give it a few seconds, then reload the page once. The credit is written by a queued job with retries, so a transient failure results in a delayed credit, not a lost one. If a minute passes with no change, contact support with the payment hash from your wallet. That hash is the exact key our records are indexed by, so it makes the lookup immediate.
Your wallet says the invoice expired. It did. Ten minutes passed. Generate a new one. No sats left your wallet.
Your wallet says no route or payment failed. This is a Lightning routing outcome between your wallet and our node, and it means no payment was made. Your sats are still yours. Most wallets will retry automatically; if not, try a slightly different amount, which changes the route search, or top up your wallet's outbound liquidity. Custodial wallets almost never hit this.
You paid from a wallet you no longer control. Deposits credit the account the invoice was issued to, not the wallet that paid it. Which wallet you pay from is irrelevant, so this is not a problem, and it also means you can fund from any wallet you like.
The deposit match bonus, and the part people misread
New accounts that deposit within the eligibility window after signup can receive a first deposit match. The mechanics are worth understanding before you accept one, because the way it works is not obvious.
The match is credited as a locked bonus. It is not immediately spendable balance. It carries a playthrough requirement, which is a total amount you need to wager before the bonus becomes claimable. Until then the bonus sits in a locked state and the playthrough counter climbs as you play.
Three things people get wrong about this:
- Spending down the bonus does not complete playthrough. Playthrough is measured in wagering volume, not in whether the bonus balance is gone. Losing the bonus and finishing the requirement are unrelated events.
- A locked bonus affects withdrawal. If you want to withdraw your own deposited sats while a locked bonus is outstanding, you can forfeit the bonus. That removes it, subtracts its playthrough contribution from your totals, and frees your funds. It is a deliberate escape hatch, not a penalty.
- One per person, not one per account. The eligibility check looks at accounts sharing network addresses. Creating a second account to collect a second match does not work; it blocks the bonus rather than granting it.
If you would rather not have the constraint, simply decline the match. A plain deposit with no bonus attached has no playthrough attached either, and your balance is withdrawable subject only to the ordinary withdrawal rules.
Why your maximum bet may be capped after a small deposit
Accounts that have deposited very little have a lower per-bet ceiling than fully funded accounts. This is not a stealth restriction on winners. It exists to stop free promotional balance from being parlayed into a very large single bet, which was a real abuse pattern. Deposit past the low threshold and the normal limits apply. If your bet slider seems to stop short of where you expect, this is almost always the reason.
You might not need to deposit at all
Honest positioning: Lightning Faucet is a Bitcoin faucet first, with games and prediction markets attached. Depositing is optional, and plenty of accounts never do it.
The earn surfaces fund an account with real sats for free: the faucet claim on its timer, scratchcards, and the other earn tasks. If your goal is to try the games with no money at risk, start there and skip the deposit entirely. Deposit later, if you decide you want stakes above what the faucet provides.
Where the sats go once they land
A funded balance is spendable anywhere on the platform immediately. There is no separate transfer step between a wallet section and a games section, because there is only one balance.
- The casino games are provably fair. Every result is derived from a server seed, your client seed, and an incrementing nonce, and you can verify any individual result yourself after the fact. You can set your own client seed, which is what makes the verification meaningful rather than decorative.
- Multiplayer poker is sat-denominated at the table, with real stakes and real chips measured in sats rather than dollars.
- Prediction markets let you take positions on Bitcoin network events such as difficulty adjustments and mempool fee levels, alongside weather and sports markets.
Getting your sats back out
Withdrawals run the mirror image of deposits, with one important difference in how you present your wallet.
Withdrawal uses LNURL-withdraw. You scan a QR or tap a link, and your wallet fetches and presents the invoice automatically. You do not generate an invoice yourself and paste it in. If any guide tells you to create an invoice manually for a withdrawal, it is not describing Lightning Faucet.
Two operational facts worth knowing in advance: a withdrawal that fails to route is automatically refunded to your balance within a couple of minutes, so a failed payout is a delay rather than a loss; and repeated withdrawal attempts in a short window will trip an automatic hold, which support removes once the account checks out. If a payout is failing, wait for the refund and try once more rather than hammering the button.
Ready to fund an account
Sign in, open the deposit page, pick an amount of at least 100 sats, and scan the code with any Lightning wallet. The invoice is good for ten minutes, the credit lands in about a second, and the balance is spendable across every game the moment it appears.