AI data labeling is human judgment sold to machine learning teams: a person looks at model output, compares it, corrects it, or rates it, and that decision becomes training or evaluation data. On Lightning Faucet you can do that work and be paid in bitcoin, in sats, straight to a Lightning wallet, with no payout threshold to grind toward and no bank account attached to the process.
The short version of the how: open Boltwork, our data work surface, sign in with your Lightning Faucet account, and start judging tasks. Each task shows you a prompt and two candidate answers. You pick A, pick B, or mark them equal. Your judgment is pooled with other workers looking at the same task. When the pool agrees on an outcome and your answer is on the winning side, your judgment is marked accepted and a flat per-judgment rate in sats is credited to your account balance. From there you withdraw over Lightning by scanning a QR code.
We wrote this from the operator side. We built the task pipeline, the consensus resolver, the fraud gates, and the payout loop, and we watch what actually gets accepted and what silently earns nothing. Most articles about paid data work list platforms. This one explains the machinery that decides whether your work counts, because that is the part that determines what you earn.
What AI data labeling actually is
Labeling is a broad word covering several jobs. Classic labeling means annotation: drawing boxes around objects, tagging sentiment, transcribing audio. The category that has grown fastest is preference and evaluation work: a model produces two responses to the same prompt and a human says which one is better. That signal is what alignment and evaluation pipelines run on, and it cannot be synthesized cleanly, because the whole point is capturing what a person prefers.
Boltwork is in that second category. Phase zero is pairwise judging: prompt, candidate A, candidate B, and three buttons. It looks trivially simple, which is exactly why the quality machinery behind it matters so much. Anyone can click a button. The system has to work out whether the click carried information.
Why buyers pay for it at all
A dataset is only worth money if a buyer can trust it. That trust is not a vibe, it is a set of measurements: how often independent annotators agree with each other, how often workers catch deliberately planted wrong answers, what share of tasks reach strong agreement, how many distinct workers and languages contributed. We compute exactly those figures as the artifact handed to a data buyer. Every one of them depends on individual judgments being real, considered, and independent.
That is the frame to hold while you work. You are not clicking to complete a task, you are producing a measurement. The pay follows the measurement.
Why bitcoin and Lightning fit this work
Micro-task work has a structural payment problem. A single judgment is worth a very small amount. Traditional payment rails cannot move a few cents, so platforms hold your earnings until you cross a payout minimum, then pay by gift card, or by a transfer that costs more in fees than the work was worth. Plenty of people have earned money on labeling platforms and never collected it.
Sats remove the threshold problem. A sat is one hundred millionth of a bitcoin, so a per-judgment rate in single sats is a normal amount to denominate rather than a rounding error. Lightning moves it. A withdrawal settles in seconds, costs a trivial routing fee, and works the same whether you are moving a few hundred sats or a few hundred thousand.
The second fit is jurisdictional. Data work is global by nature, and the languages with the least existing training data are often the ones spoken where payment options are worst. Lightning does not care where you are or what bank will have you. You need a wallet, not an account with a payment processor.
Sat denominated balances across the site
Sats you earn from labeling land in the same account balance as everything else on Lightning Faucet. There is no separate wallet to reconcile. You can withdraw them, or you can move them into anything else on the site: prediction markets, multiplayer poker, or the casino games. Nothing forces you to. Withdrawing is the default path and it is one screen.
How a Boltwork task works, step by step
The task you see
You are shown a prompt, in one of several languages, and two candidate answers labeled A and B. The prompt might be a technical explainer request, a short piece of user-facing copy, or a summary instruction. Your job is to decide which answer better satisfies the prompt, or to say they are equal in quality.
Equal is a real answer, not a skip. Sometimes the two candidates genuinely are of the same standard, and recording that is useful signal. It is tracked as its own outcome in consensus, not folded into A or B. What equal is not is a hedge. Marking everything equal because deciding is effortful is the fastest way to fall out of agreement with everyone else, and the system measures that.
Tasks are generated per language on a demand driven allocation. Each locale has a target inventory and a measured consumption rate, and generation is steered toward whichever language is draining fastest. Practically, that means the volume available in your language depends on how many other people are working in it and how quickly a batch is being consumed.
What happens after you submit
Your judgment is recorded and the task keeps circulating. Nothing resolves on your click alone. A task needs a minimum of three judgments before the resolver will even look at it, and the resolver runs as a batched pass over everything that has crossed that line.
When it looks at a task, it takes a strict plurality of the three outcomes. If A wins outright, every judgment for A is marked accepted and the rest are marked rejected. Same for B, same for equal. Accepted judgments are what get credited.
If there is a tie at the top, nothing resolves. A one to one to one split, or a two to two to one split once more judgments have arrived, marks the task disputed and leaves all its judgments pending. The task goes back out for another opinion. Disputed is a deliberate outcome, not a failure state: serving another judgment is cheap, and paying out on a coin flip corrupts the dataset that the whole surface exists to produce.
There is one more guard. A winning outcome needs at least two distinct voters behind it. Without that rule, a single worker with a strong track record could resolve a task alone against two others, which is both bad data and an obvious collusion target. A lopsided split with one highly trusted voter goes disputed instead.
What decides whether you get paid
Gold tasks
Some tasks have a known correct answer, seeded into the stream and visually indistinguishable from the rest. You will never be told which ones they are. Your gold accuracy is the share of those you get right, and it is the single most direct measure of whether you are reading the tasks.
There is a hard floor attached. Once you have seen a meaningful number of gold tasks, if your accuracy on them is at or below chance, your weight in the system is cut to a small fraction. This is the specific defense against clicking through tasks at random, and it is the reason random clicking is a poor strategy even though every individual click looks the same to you at the time.
Your trust score
Trust is computed from two halves, weighted equally: your accuracy on gold tasks, and how often you agree with the consensus outcome on ordinary tasks. If only one signal exists yet, it is used alone. A brand new worker with neither starts at a neutral middle value, so nobody is punished for being new.
Trust feeds a tier with an earning multiplier. Cross the lower trust threshold and accepted judgments pay a small multiple of the base rate. Cross the higher threshold and the multiple is larger. Both tiers additionally require that your trust score rests on a real number of scored observations, so a lucky first handful of tasks does not promote you.
This is the honest answer to "how do I earn more per task": there is no volume bonus and no streak trick. The lever is accuracy, because accuracy is the product.
The rate and the budget
Boltwork pays a flat rate per accepted judgment, set per batch and shown to you in the worker interface before you start, then adjusted by your tier multiplier. It is a small open beta with a real, finite budget: there is a rolling thirty day payout ceiling, and the serving side is gated against it so that work is not handed out when the remaining budget could not cover it. We built that gate after learning the hard way that a cap enforced only at payout time turns into an invisible wage freeze, with tasks still being served and accepted judgments piling up uncredited. Work that gets served is work we can pay for.
Treat this as supplementary sat earning that rewards care, not as a wage. Availability varies with the budget, the batch schedule, and how much inventory exists in your language.
What gets your work rejected
Beyond simply being on the losing side of consensus, several gates will discard a judgment outright:
- Served binding. You can only submit a judgment for a task that was actually served to your session. Constructing a submission for a task you were never shown does not work.
- Server side timing. Submission timing is measured on our side, not in your browser. Judgments returned faster than a human could have read the candidates are rejected.
- Address caps. There is a ceiling on judgments accepted from a single network address over a window, which limits multi account farming from one machine.
- Distinct address consensus. Agreement between judgments arriving from the same address is not counted as independent agreement. Two accounts you control agreeing with each other adds nothing to a task's resolution.
- Hedged and null cases. Judgments that cannot be attributed cleanly are excluded from the consensus tally rather than counted in your favor.
None of this is aimed at ordinary workers. It is aimed at the one behavior that would destroy the dataset's value, which is volume without attention. If you read the prompt and both candidates and pick honestly, you will never encounter these gates.
Getting your sats out
Withdrawal on Lightning Faucet uses LNURL withdraw, which means you never construct an invoice by hand. Choose withdraw, enter an amount in sats, and you are shown a QR code or a link. Scan it with a Lightning wallet, or tap the link if your wallet is on the same device, and the wallet fetches the invoice and presents the amount for you to confirm. Confirm, and the payment settles in seconds.
A few operational facts worth knowing before your first withdrawal. If a payment fails to route, the sats return to your balance automatically, typically within a minute or two, so a failed attempt is not a lost balance. Repeatedly retrying a failing withdrawal is counterproductive: more than a handful of attempts in a short window trips an automatic security hold that a human has to lift. If a withdrawal fails twice, the better move is to wait for the refund, then try a different wallet or a smaller amount.
Any Lightning wallet that supports LNURL withdraw will work. If yours does not, most wallets can still be paid by generating an invoice through a wallet that does.
Where labeling fits alongside the rest of the site
Lightning Faucet is a bitcoin faucet with games, earn surfaces, prediction markets, and builder tools. Labeling is the earn surface where the sats come from producing something of value rather than from a claim timer or a wager, which makes it the one we point people to when they ask how to accumulate sats without depositing.
The realistic pattern is stacking. The faucet claim and the other earn surfaces give you a starting balance with no work at all. Labeling adds sats in proportion to careful attention. If you are a developer, the builder tools are a separate track entirely, covering paid APIs and machine payable endpoints. All of it lands in one sat denominated balance you can withdraw at any point.
Getting started
Create an account, confirm your email, and open Boltwork. Do your first twenty or thirty tasks slowly and deliberately, reading both candidates fully, because those early judgments are what your trust score is built from and gold tasks are mixed in from the beginning. Check back after a resolver pass to see which of your judgments were accepted, and use the disagreements as calibration: when consensus went against you, it is usually because the losing candidate was fluent but did not actually answer the prompt.
Then decide what to do with the sats. Withdraw them over Lightning, or keep them working on the site. Both are one screen away.