BoilerBrokers

3,333 desks . one floor . Robinhood Chain

BoilerBrokers is 3,333 pixel-art characters working a 1980s sales floor, and a browser city that is the project's website rather than a picture of one. The piece you hold is meant to become the character you walk that city as.

This page is the public record: how it is built, what is decided, and what is not.

Start here

Collection

Supply

3,333

Chain

Robinhood Chain

Standard

ERC-721

Name / symbol

BoilerBrokers / BOILER

Artwork

1200 x 1200 PNG

Storage

IPFS

Each piece is drawn at 48 by 48 and scaled up by 25 with no smoothing, so every pixel stays a hard square at any size. A piece is eight layers deep - background, base, hair, shirt, neckwear, eyes, mouth, headwear - and the base is the body itself, in three variants.

Artwork and metadata live on IPFS and are addressed by content hash, so a file cannot be swapped without its address changing. The contract holds the pointer to that address, and the pointer can be frozen permanently once reveal has been checked. It has not been frozen yet, because nothing has been deployed to mainnet yet.

The collection name is set when the contract is created and there is no way to rename it afterwards.

Royalty

The contract implements EIP-2981 and reports a royalty of 5%. EIP-2981 reports royalty terms, it does not enforce them: a marketplace reads the number and decides for itself whether to honour it, and transfers sent directly between wallets pay nothing.

The royalty is also not fixed - the owner can change the receiver and the rate at any time. Listed with the other owner powers under Smart contract.

Rarity

Rarity is a property of the artwork, and every count below is exact rather than approximate. Which token number ends up holding which artwork is a separate question, settled after minting closes - see Reveal.

How the counts were fixed

Traits are not drawn by weighted random. Each layer starts as a pool of exactly 3,333 values holding the published counts, so the totals match the table by construction rather than by luck, and every piece is checked to be unique as a finished image rather than as a list of traits. Method in the appendix.

The chase

Fedora (33) and Cowboy Hat (99) are the headwear worth hunting, three times apart so there are two tiers of hunt rather than one. On their own layers the rarest are Monocle (33), Bolo Tie (43), Scarf (60), Cigar (67) and Night Skyline (83), and the rarest base is Zombie (88). Just under half the collection wears no headwear at all, so the eight hairstyles stay visible.

The 1-of-1

A Zombie wearing a Fedora. Exactly one exists. Left entirely to chance the combination might not have occurred at all, so it is locked to exactly one and was stated as such from the start. Which token number holds it is decided by the reveal draw, after minting closes, and nobody knows it in advance.

The city

The point of the city is that your piece is meant to live in it. A BoilerBroker is not only an image in a wallet: it is the character you are intended to walk these streets as.

That is the direction the whole project is pointed at, and the honest reason to want one beyond the artwork itself. It is also not finished.

What exists today

The site is not a page with a picture of a city on it. It is the city, with the page laid over it: nine blocks, four streets, and a park in the middle. Three doors open - the Mint Office explains how the sale runs, the Trading Hall is where allowlist entry happens, and The Ticker covers the token. Every other door is locked and says so on its sign, because a door that promises something and does not open is what loses people.

The street moves on its own. People walk the pavements, traffic runs both ways, birds cross overhead and a cat works the park. None of it is video - every figure on it is drawn frame by frame.

What does not exist yet

Nothing on that page responds to a keyboard. There is no character you control, no building interior, and no other players. Holding a piece does not currently unlock anything in the city, because there is nothing yet to unlock.

No date is attached to any of it, and none will be until it is close enough to be true. The status table lists each part as not built until it is built.

Ownership

What you own on chain

An ERC-721 token on Robinhood Chain, with the ordinary rights that carries: hold it, transfer it, sell it anywhere that supports the standard. The token points at metadata and an image stored on IPFS and addressed by content hash.

Licence and commercial rights Not final

No licence terms have been decided or published. There is no commercial-use grant, no CC0 declaration, and no published restriction either. Nothing has been written, so there is nothing to summarise.

The terms will be published on this page before the mint opens, dated, and applied to the whole collection rather than negotiated piece by piece. Nobody should have to buy first and find out afterwards what they are allowed to do with what they bought.

Until they appear here, the honest position is that owning a BoilerBroker gives you the token and nothing beyond it. This document will not imply rights that have not been granted by staying vague about them.

What holding one gets you today

• The artwork at full resolution, on IPFS, addressed by content hash rather than by a URL somebody has to keep paying for.
• A place in a fixed set whose trait counts are published, exact, and checkable by anyone.
• An asset that trades anywhere supporting ERC-721.

Not promised

• No revenue share, no staking, no yield, no airdrop.
• No guarantee about secondary price, floor, or a listing anywhere.
• No date for the city becoming playable.

Mint

Not final Prices and dates are not published, and will not be until they are final. A number quoted early gets repeated, and the first time one moves the whole thing reads as a promise broken.

The four phases

Rules that hold in every phase

• Phases only move forward. Without that rule the owner could reopen the cheapest phase after public closes and mint the remainder at a discount.
• A phase's list is locked before that phase opens. Nobody can be added to it afterwards - if the list could still change while the phase ran, we could put ourselves on it.
• Overpayment is refunded, not kept.
• Pieces left over from an early phase move into the public phase rather than expiring. If a phase sells 400 of the 700 set aside for it, the other 300 are still there to be bought.
• Whatever is left can be closed permanently, and that cannot be undone.

An unminted remainder with an unclear future hangs over every holder, who has no way to know when several hundred more pieces might appear and hit the floor. Closing it turns a mint of 2,500 out of 3,333 from a failure into a collection of 2,500.

Team allocation

33 of the 3,333 go to the team, minted at deployment before anyone else can buy.

The team draws blind, like everybody else. Which artwork those 33 hold is decided by the same draw as every other piece, after minting closes, and the team finds out what it got at the same moment you do. There is no way to pick them, and nowhere else in the contract that mints without payment.

Getting on the list

Entry is a short set of steps on X plus the wallet you intend to mint with. Entries are reviewed after they close, not at the moment you submit, so entering first buys nothing - take the time to enter the right wallet rather than the fast one.

The final list is locked into the contract before the mint opens, and every mint is checked against it. A place belongs to the wallet it was entered with and cannot be moved to another.

Reveal

The provenance hash, published before mint

a7ed16f5470654c27b1d46e31f7393487094698772f3e6b635b916ba77434139

Every image is hashed with SHA-256, the 3,333 digests are chained in artwork order, and that chain is hashed once more. It proves one thing and only one: the artwork set and its order were fixed before anybody minted, and were not rearranged afterwards to suit who turned up. The algorithm and a script that reproduces it are in the appendix.

Why there is a draw at all

The artwork is finished and hashed before anyone mints, which is what makes provenance possible. On its own it would also make the mint readable: if token #34 always showed artwork #34, anyone who got hold of the metadata address could wait for a rare number to come up. An address that must never leak is a hope, not a mechanism.

How it works

One number decides everything. It shifts every token onto a different artwork, the same distance for all of them, and it wraps around at the end - so no artwork is used twice and none is left out. Drawing that number takes two steps, and anyone can do either of them, not just us:

• Pick a future block. Only once minting is over. The block has not happened yet, so nobody can know or choose what will be in it - and once it is picked it cannot be swapped for another one.
• Use it. When that block arrives, its contents set the number, permanently.

Every attempt is counted on chain, so a draw quietly restarted is a draw anyone can count. And the contract will not reveal a single image until the number exists - that is enforced by the code, not promised by us.

Before reveal, and what gets frozen

Before reveal every token returns the same placeholder metadata - one shared file, not one per token - so nothing about any individual token leaks out of the contract. The artwork and metadata addresses are deliberately not published until reveal.

Until the artwork address is frozen, the owner can reveal again with a different one, which means the artwork can still be replaced. Freezing is permanent and cannot be undone. It has not been done yet, because nothing has been deployed to mainnet.

Smart contract

Standard

ERC-721 . ERC-2981

Chain

Robinhood Chain

Mainnet address

Not deployed

Source published

Not yet

Written around one question: what could the owner do to hurt a buyer, and which of those can be made impossible rather than merely promised. What is switched off is switched off in the contract itself, so it is not a promise but an impossibility.

Impossible after deployment

• Total supply, the team allocation, every phase allocation, every per-wallet limit and every price. No function raises supply, moves an allocation between phases, or lifts a wallet limit.
• Phases only move forward.
• A phase's list cannot be changed once that phase has opened.
• Freezing the artwork address is permanent.
• Closing the mint is permanent.
• Nothing can be revealed until the draw has happened.
• The collection name and symbol cannot be changed.
• The team's 33 are the only pieces ever created without payment, and they are created in the same moment as the contract itself. Nothing can add more later, for us or for anyone.

What the owner can still do

Listed in full, inconvenient ones included.

Things that need the owner to act

• If the sale does not sell out, only the owner can end it - and the draw cannot begin until the sale has ended.
• Only the owner can publish the artwork address at reveal.

Neither can be forced by a holder. Both are stated here rather than left to be discovered.

Testing & audit

Two different things, kept apart on purpose. One has been done and one has not.

Internal testing Done

35 tests, written to attack the claims rather than walk the happy path. If the contract says phases cannot move backwards, there is a test that tries to move one backwards and requires it to fail. The groups cover deployment state, phase direction, root locking, each mint path, pausing and closing, the draw, reveal, payment and refunds, access control, and the supply ceiling.

The full lifecycle has also been rehearsed end to end on the Robinhood Chain testnet, against real gas and real blocks. That rehearsal earned its place immediately: it exposed a fault in the draw that no local test could have found, because the fault only exists on a real chain of this kind. Detail in the appendix.

Independent audit Not done

The contract has not been audited by anyone outside the project. No firm has reviewed it, no report exists, and the tests above were written by the same people who wrote the contract. Tests prove what they test. They say nothing about the bugs nobody thought to write a test for.

It has also not been load tested against the hundreds of simultaneous transactions a real mint produces, and the source has not yet been published for outside review.

Treasury

Mint proceeds are held by the contract itself and moved by a withdrawal that sends the entire balance to the treasury address and nowhere else. There is no function that sends funds to an address chosen at the time of the call.

The treasury address is set at deployment and can be changed by the owner at any time. The royalty receiver is set to the same address at deployment and can also be changed. Both appear in the list of owner powers above, because a treasury that can be repointed is a different promise from one that cannot.

Not final What the proceeds will be used for has not been published. No budget, split, or spending commitment has been decided. Rather than fill the space with intentions nobody could check, this stays marked pending until there is something specific to state.

The mainnet treasury address will be published here alongside the contract address at deployment.

Future ecosystem

$BOILER

Status

Not deployed

Contract address

none

Ticker

$BOILER

Planned supply

1,000,000,000 Not final

$BOILER has not been deployed and there is no contract address. Anything trading under this name today is not it. The address will be published here and on the front page, and nowhere earlier.

What each is for, in one line. The NFT is who you are: the piece you hold is the broker you play as, it walks the city, and it is what a rank attaches to. The token is how that broker moves up: spending it promotes the piece through the ranks, which changes the title under your name and the way the character looks. Standing on the floor, not a yield.

A supply of 1,000,000,000 is the planned figure and nothing more than that. Allocation and launch date are not decided, and no part of this document should be read as a commitment on either. It would be a separate contract from the 3,333 pieces and would share none of their supply; the two numbers on this page are not the same number.

What the token would be for

There is a design for how the token and the collection would need each other: a piece carries a visible rank, a title under the name and a look that changes with it, moved by spending the token. What that offers is standing rather than yield.

Postponed It is not built, and postponed is not the same as coming soon. The thresholds in it are calculated against a supply that is not final, so they move if it moves, and one part has no answer yet: rank advances by spending a token that does not exist, so either the trigger changes or it waits. It is recorded here as the direction, not as a commitment.

The rest of the city

Making the city playable is the project's main direction and is described under The city, along with an honest account of how much of it exists. Interiors, other players and anything persistent sit behind that and are not dated.

Status

Still open

Decisions not yet made, listed so the record is complete rather than flattering.

• Mint date and prices.
• What the licence and commercial-rights terms should be. These are committed to be published before the mint opens.
• Whether the mint runs in four phases as planned, or three.
• Whether the contract source is published for outside review before mint, and whether an independent audit is commissioned first.
• What mint proceeds are committed to.
• Whether the mint happens here or through a marketplace drop page.

Technical appendix

Detail that belongs in the record but would slow down a first read.

Provenance algorithm

Each of the 3,333 images is hashed with SHA-256. The 64-character lowercase hex digests are concatenated in artwork order 1 to 3,333 with no separator between them, and that whole string is hashed once more with SHA-256. The result is the hash published under Reveal.

Note what is being hashed: the concatenated hex text, not the raw digest bytes. Hashing the bytes, or joining the lines with newlines, gives a different and equally valid-looking answer, which is why the recipe is spelled out rather than described.

Reveal threat model

The two-step draw removes the easiest attack. What it does not do is worth being precise about, since claiming the stronger thing would be the exact failure this document exists to avoid.

• Grinding by not settling. Anyone may commit, but nobody is obliged to settle. Whoever commits can read the block hash about two seconds later, dislike the result, and do nothing until it ages out of the 256-block window - roughly 26 seconds on this chain - then commit again. The commit counter records every attempt, so this is detectable, not prevented. What makes it costly rather than free is that any other holder may settle first.
• The settle window is about 26 seconds. Block hashes reach back 256 blocks and blocks here are roughly 0.1 seconds. A holder who wants to be certain a draw is settled rather than allowed to lapse needs a script watching the chain, not a person watching a page. Publishing such a script before the draw is on us rather than on the reader.
• Block hashes come from a sequencer. Robinhood Chain is an Arbitrum Orbit chain with a centralised sequencer. A block hash is not a value anyone here chooses, but it is produced by a single operator, and randomness sourced from a single operator is a trust assumption rather than a proof.
• The window between settling and revealing. Once the offset is settled it is public, and artworkOf(id) is a public view function, so the token-to-artwork mapping is computable by anyone. What is not yet public is what each artwork is. Anyone who obtained the metadata address early could read the full mapping during that window while nobody else can. The mitigation is to keep the window short and publish the address at reveal - a procedure, not a guarantee.
• A leaked metadata address before reveal would be a spoiler rather than an exploit: the offset is drawn after minting closes, so seeing the artwork early does not help anyone pick a rare token during the sale.

Artwork generation

Each layer is a pool of exactly 3,333 values holding the published counts, shuffled with a fixed seed and zipped together. Weighted random was rejected because it cannot hit a published table: a 1% weight on a 3,333 set returns a number near 33 but never reliably 33, and the counts are the thing collectors check one by one.

Three requirements then have to hold at the same time: no duplicate trait combination, exactly one 1-of-1, and no two pieces rendering to the same image. Fixing one can break another, so the pass repeats until all three hold on the same round. If they cannot, the build stops rather than shipping a set that misses the table.

Counts and uniqueness are checked before a single file is written, then checked again by a separate checker that shares no code with the generator. A checker built from the same code only proves the code agrees with itself.

Before generation, 1,791 layer combinations were tested for three defects that only appear when layers meet: enclosed gaps where the background shows through a body, a silhouette changed by something that is not hair or headwear, and any drift in the eyes or brows. Some of these come from a pair of layers that are each clean on their own, so the repair also runs at assembly time rather than in the assets alone.

Contract implementation details

Token number is not artwork number. A token's artwork number is ((id - 1 + offset) mod 3333) + 1, exposed on chain as artworkOf(id). The arithmetic runs in zero-based space and shifts back, because skipping that step is the easiest way to produce artwork 0 or 3,334 and point at a file that does not exist.

One consequence is worth knowing before somebody reports it as a bug: each metadata file carries the artwork number in its name field, so after reveal token #34 displays the name of whichever artwork it drew, not "#34". The token number is the thing you own; the artwork number is the thing you drew. The 1-of-1 is artwork #1374, which is not a token number and says nothing about who holds it until the draw settles.

Why the testnet rehearsal mattered. On an Arbitrum Orbit chain, block.number inside the EVM returns an estimate of the L1 block number, not the block number of the chain the contract is running on. When measured, it read 11.6 million while the chain itself was at block 110.8 million. A draw built on that number waits for a block that never arrives and asks for a hash that never exists, and it could not surface locally because a simulated chain has no L1 and L2 distinction at all. The contract now reads block numbers and hashes through the ArbSys precompile, detected by whether there is code at its address, with a fallback to the plain opcodes so the same contract is correct on the real chain and still testable locally.

Verification scripts

Reproducing the provenance hash, once the images are published. Files are named by artwork number.

for i in $(seq 1 3333); do sha256sum "$i.png" | cut -d' ' -f1; done | tr -d '\n' | sha256sum

Checking a single token after reveal: read artworkOf(id) from the contract, fetch that numbered file from the published metadata address, and confirm the image it points at hashes to the corresponding line of the published image-hash list.