Scene one / the original brief
Six jobs arrive. Eight can leave.
The intern has enough room for the tiny feature. The client is already asking for a second one.
The morning is ready to start. The intern still has desk space.
100bps.wtf Chain Workshop
The client asked for a tiny feature. The intern gave it arrivals, a work bill, and a queue.
Compare six jobs with sixteen. The second brief creates a queue, then the payment rule checks the paperwork.
Room one / the work queue
Then the queue filled up. Change the arrivals, work cost, budget, or block space and the board names the limit.
Scene one / the original brief
The intern has enough room for the tiny feature. The client is already asking for a second one.
The morning is ready to start. The intern still has desk space.
Scene two / “one more tiny thing”
The work rate did not change. Demand did. The feature now has a waiting room.
The crowded morning is waiting to start. The intern has found the queue.
Work queue blueprint
Local work queue model, not a chain benchmark. Arrivals add demand. They do not increase either limit.
The shift board
Ready. Capacity is 8 jobs per turn. Run the desk to see whether the brief queues.
The intern is holding the clipboard and waiting for the client to define “tiny.”
Collectible output
Run or step the model before exporting. The client has not approved the scope.
Each turn adds the chosen arrivals to the pending queue. The model serves the smaller of block space, computed capacity, and the queued jobs.
arrivals = pending + transactionsArriving
computeCapacity = floor(nodeWorkBudget / workPerTransaction)
served = min(blockSpace, computeCapacity, arrivals)
pending = arrivals - served
The displayed label calls a turn compute-bound when computed capacity is smaller than block space. A tie stays block-space-bound, so the label does not flicker between equal caps.
Room two / the payment counter
The client approved Sam. Pat submitted the same amount anyway. This toy rule checks the recipient and payout before anything leaves the room. No token moves.
Accepted locally. Sam gets the amount the rule approved.
Rejected locally. The amount balances. Pat is still not Sam.
The intern is checking the name on the form before touching the arrows.
The diagram will mark the destination and amount the rule sees.
require(recipient == "Sam")
require(payout == 98)
require(100 == payout + 2)
This is an illustrative local rule check. It is not a native VM, a compiled contract, or a real transaction.
For the real building path, read the existing covenant breaker, Silverscript, and Argent. Those links carry the actual source and status.