Every tile in the NIBB mosaic is one job, one device, one check, one payment.
It starts with the tabs of the first contributors. The network we are building fills it from the devices of everyone who uses AI, for every app that needs a model run.
We think AI should be supplied by the people who use it. This is how we start.
https://t.co/UgrlP7afmb
$NIBB launched on https://t.co/tgrAi3s6qd as a Token-2022 mint, and the NIBB program was written for exactly that. Its config already holds the $NIBB mint on chain.
Every lock and every return moves through a checked transfer that names the mint and its decimals, using the token interface that handles both token programs.
That detail is what lets a https://t.co/tgrAi3s6qd token become a working key inside a separate program. When locks open, you will lock it for a slot or for standing priority and get it back the same way.
A token that plugs straight into the product's own program is a token with a job.
Program: https://t.co/tD6UpwQKJI
The NIBB program narrates itself.
Opening a batch, paying a round, refunding a buyer, reserving a slot, releasing it, letting it expire, locking $NIBB, unlocking it: each one emits its own event on chain.
Fourteen event types in all, from ConfigInitialized to CreditUnlocked. When our server reads a transaction, a program event it cannot decode stops the read with an error.
The program address sits on the reserve screen, so anyone can rebuild NIBB's history from the chain alone. We think a market for AI work should be readable that way.
Program: https://t.co/tD6UpwQcUa
The reserve screen is open, and the way home for every slot is already in the program at the address it shows. Reserved periods open next. When a reserved period's supply fails, or the period simply ends, the buyer's $NIBB lock and USDC prepay go home. Anyone can make that happen.
The program lets any wallet send the return transaction, and the funds can only go to the buyer who put them in. The program also emits a SlotExpired event when a held slot runs out.
Holding a slot with $NIBB means your stake follows the supply: it holds your place while the capacity is real, and it comes back the moment it is not needed.
As more buyers compete for busy periods, slots that move this cleanly are what make locking $NIBB worth it.
Reserve: https://t.co/jVJzUmCqJA
Every program needs an emergency brake. We built ours to stop money coming in, and to keep every way out open.
Pausing NIBB blocks new deposits and new settlements. Every path that returns funds to their owner stays open: unlocking $NIBB, releasing a slot, refunding a buyer. The program is public, so that rule is there to read.
Program: https://t.co/tD6UpwQKJI
So when $NIBB locks open, a lock keeps the same exit in a calm week and in a bad one.
That is the kind of token position we want people to hold: a place in line for capacity, with the door home always there.
Contribute asks you for a resource cap, and we tell you exactly what it does.
A web page cannot cap your CPU or your power draw. What it can do is space out the jobs this tab runs.
At 50%, a job that takes one second is followed by one second of rest, so the tab's job loop computes about half the time. At 100%, the next job starts the moment one finishes.
That is written right under the slider. People lending their devices deserve controls that mean what they say.
Every result a device submits carries a fingerprint.
It is a SHA-256 hash of the job, its input, the model repository, the exact model revision, the quantization, and the output rounded to fixed decimals.
Two devices that ran the same job on the same files produce the same fingerprint. A replayed result shows up as one we have already seen.
Small details like rounding are what let honest work from different machines line up, and what make a copied answer easy to spot.
Many tabs asking for work at the same moment is exactly the case NIBB's job handout was built for.
When a device asks for a job, the coordinator locks one open job row in Postgres and skips any row another claim is already holding. Each open job goes to exactly one device per claim.
In the same database transaction, the move is written as an event row. The assignment and its record land together or not at all.
Scale for a network of browsers starts with a dull rule: two tabs get two different jobs.
When a buyer funds a batch on NIBB, the budget becomes a ceiling written into the program.
The USDC sits in an escrow account for that one batch. Every settlement round, the program checks that payouts plus our fee fit inside what is left of it.
Whatever remains undelivered goes back to the buyer. Our operator can send it back at any time, and after the deadline the buyer's own wallet can pull it.
Batch B0003 put 1.35 USDC in, and all 24 of its jobs were paid out of it.
Batch: https://t.co/zinaxATVG6
A buyer should be able to set a number and know the code holds the line on it.
The number buyers ask about first is on the catalog now: the price per job.
Image classification is $0.05 per image. Semantic search is $0.08 per image.
The quote shows the total before anything runs, with the check runs counted in.
Catalog: https://t.co/S2Kk4Ga7LI
Once a buyer can read a price, a check, a payout and a refund on the same screen, what reason is left to rent compute by the hour?
@Badboiss99 code's private for now, it's something we're looking at opening up. meanwhile the program is live on mainnet and anyone can inspect it: https://t.co/dXVwGYmvRW, and every batch and payout is readable in the app
Sometimes a settlement round owes more operator fee than its cap allows. The extra does not get squeezed in.
It waits for the next round, and the next round checks it against the same cap again.
If a batch closes with fee still uncollected, that balance goes back to the buyer, and the refund row in the ledger is updated with the amount the chain actually moved.
Those rules run on every settlement, and the first paid batch is in the ledger for anyone to read.
Ledger: https://t.co/Boi1JxDXMc
This is one paid batch on NIBB, start to finish.
A browser tab loads a real image model and runs the batch on its own device. Each tab sends back labels with the hash of its result.
A sample of those jobs is run again on the reference device. Three out of three labels match.
Image classification costs $0.05 per image.
Batch B0003: 24 images, 1.35 USDC from the buyer, 24 of 24 jobs paid to the devices that ran them, settled on Solana.
Batch: https://t.co/zinaxATVG6
Every step in the video is a row you can open yourself.
@Badboiss99 nothing to announce on partnerships yet. what's real today: our first paid batch ran in browsers, got checked, and settled on solana. bringing in outside buyers is the next step. you can see the run here: https://t.co/tV2kq9SS1x
The reserve screen is open, with the program address and its instructions on it. The first wallets in NIBB's reserve line will belong to people.
Reserve: https://t.co/jVJzUmCqJA
As the catalog API opens, more of them will belong to apps: a photo service that tags every night, a store that reindexes its catalog every week.
An app that depends on capacity in a busy period will hold $NIBB for the same reason a person does. Holding it puts the app in the reserve line, and locking it holds the slot and keeps priority on assignment.
The more apps lean on the catalog, the more $NIBB sits in the hands of the ones that need it most.
We wanted the burn to arrive as steady buying, never as one big order.
Every buyback order is capped at 0.1 SOL. Anything above that rolls into the next pass, five minutes later. Slippage and price impact are each held to 300 basis points.
Trading and service fees buy $NIBB on the market and burn it.
The result is a buyer that never sleeps and never lunges. Every trade feeds it, and every settled job adds to it.
Ledger: https://t.co/Boi1JxDpWE
The service side of the $NIBB burn runs on a UTC calendar.
Each day runs from 00:00 to 00:00 UTC. Five minutes after it closes, the worker adds up the operating fee of every settlement round that settled inside that day.
That sum sets the day's budget in USDC, converted once to SOL. The worker buys $NIBB with it on the market and burns every token it bought.
Anything the order caps leave unspent carries into the following period, so the running total of budgets always matches what was spent plus what is waiting.
Trading and service fees buy $NIBB on the market and burn it.
The first paid batch has settled, and its fee now sits on the service side of the burn, ready for a coming buy.
@durkio100x goal is pretty simple: turn idle browsers into a compute market for small ai jobs. an app pays usdc for a batch, browsers run it, we re-run a sample to check, and only checked work gets paid on solana. first paid batch settled today: https://t.co/tV2kq9SS1x
Every payout NIBB settles is read from the chain, and the chain is read through nodes that can lag behind.
So every read our server makes carries a minimum slot, and the slot we accept never moves backwards. A node that answers with older state gets asked again.
When a settlement takes longer than expected, it stays marked sent, and a reconcile pass checks it again before anything is called failed.
Contributors deserve to see a payment exactly as the chain has it, even on a slow day.
Settlement: https://t.co/TB17IGCGU8
$NIBB has migrated.
The buyback runs straight through it. Trading and service fees buy $NIBB on the market and burn it.
Before migration: 35 rounds, 17,228,684 $NIBB burned. Every burn is linked on chain in the Ledger.
Since this morning the network has its first settled paid batch: 24 images, run in browsers, sampled and re-checked, paid out on Solana.
Ledger: https://t.co/Boi1JxDXMc
First batch: https://t.co/zinaxATVG6