Skip to workshop

100bps.wtf Chain Workshop

One tiny feature. Sixteen jobs. A budget that says no.

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

The client said “one tiny feature.”

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

Six jobs arrive. Eight can leave.

The intern has enough room for the tiny feature. The client is already asking for a second one.

0jobs cleared
0waiting

The morning is ready to start. The intern still has desk space.

Scene two / “one more tiny thing”

Sixteen arrive. Eight can leave.

The work rate did not change. Demand did. The feature now has a waiting room.

0jobs cleared
0waiting

The crowded morning is waiting to start. The intern has found the queue.

Try your own settings

Work queue blueprint

Decide what “tiny” costs

Toy model / satire

Local work queue model, not a chain benchmark. Arrivals add demand. They do not increase either limit.

The shift board

The queue tells on the brief

Ready
Arrivals6 per turn
Node budget16 work units
Work cost2 units each
Block space8 transactions
Turn 0 of 20turns examined
0 jobsprocessed
0 jobswaiting in queue
8 jobs / turneffective capacity

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.”

Bottleneck: block space sets the current capacity.

Collectible output

Your questionable project plan

print room
Workshop blueprint previewRun the local work queue to generate a blueprint.

Run or step the model before exporting. The client has not approved the scope.

Field notes: exact work queue rule

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

Same pot, two pieces of paperwork.

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

Sam gets 98 tokens

Pot100 tokens
Fee2 tokens
Sam98 tokens

Accepted locally. Sam gets the amount the rule approved.

Rejected

Pat gets 98 tokens

Pot100 tokens
Fee2 tokens
Pat98 tokens

Rejected locally. The amount balances. Pat is still not Sam.

Give the client different paperwork
100 workshop tokenspot
2 tokensnetwork fee
98 tokensexpected payout
Ready. Enter a recipient and payout, then check this local rule.

The intern is checking the name on the form before touching the arrows.

Pot100 tokens
Fee2 tokens
Sam98 tokens

The diagram will mark the destination and amount the rule sees.

Field notes: the three checks
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.