DOCS

These four states are written by hand in RH_CONFIG, not read from a chain. Until the contracts exist there is nothing to read, and a status panel that fakes a live feed is worse than one that admits it. When the stack deploys, this panel gets wired to it and this paragraph gets deleted.

There are 6,502 machines — the MOS 6502, the chip the home-computer era was built on. Each is a pixel-drawn computer from one of six eras, and each is an ordinary ERC-721: minted in the drop, traded anywhere NFTs trade, yours from the moment you hold it. Nothing recalls a machine and nothing reassigns one. A machine arrives cold — powered down, and earning nothing.

$RHPC is a separate ERC-20 with its own market. Burn the boot cost in $RHPC against a machine you own and it boots: the screen lights up, and from that moment it earns a share of every trade. Booting is one-way. No contract in the stack un-boots a machine.

Every buy and sell through the canonical market pays a permanent 3% fee, enforced by the token rather than by this website. 2% of volume goes to booted machines, 0.55% compounds locked liquidity, 0.30% buys and burns $QUOTRON, and 0.15% pays the creator.

Rewards are paid in the WETH the fee was taken in. There is no converter, no epoch schedule and no keeper on the reward path — WETH goes into an accumulator and comes out when you claim. That is the whole system: a draw for flippers, a one-way commitment for holders, and a fee stream that cannot be routed around.

The words are ours on purpose. These are not standard ERC-721 states and calling them by standard names would be misleading.

Every machine is drawn on a 128×128 grid and upscaled nearest-neighbour — every pixel is authored. No filters, no vector scaling, no AI. Nine trait layers, sixty-two variants, one deterministic seed per id: the same id always draws the same machine, in this browser, in a Node script, or in a contract's metadata.

The counts below are not targets. They are the result of sweeping all 6,502 ids through the finished engine and counting what came out.

Every machine is in one of two states for its whole life, and it only ever moves one way. It arrives cold: an ordinary ERC-721 in your wallet, transferable, listable, and earning nothing. It becomes booted when its boot cost in $RHPC is burned against it — and then it stays booted, in whoever's wallet it ends up in.

Which machine you get is decided by the drop, not by a balance. Ids are assigned when the collection mints and they do not move afterwards: there is no pool a machine returns to, nothing is re-drawn, and holding more or less $RHPC changes nothing about which computer is yours. The only thing the token decides is whether a machine is lit.

A booted machine's reward weight is one number, and it is built from three:

CLOCK  =  era base  ×  special multiplier  ×  alliance boost

         100..300        100..300               100 or 125
         (the six eras)  (eight specials)       (holding a QUOTRON terminal)

Specials are the eight rare conditions the engine layers onto the art. They were drawn before any of this was designed — the counts are what the finished engine produced across 6,502 ids, and the multipliers were then fitted to them.

Rarity score is the sum of 100 / trait% across all nine layers. The tier cuts were set from the real quantiles of the full 6,502 supply, not guessed, and they drive the badge in the generator and on the marketplace — nothing else. A Mythic machine with a slow era earns less than a plain Rack 95.

If the weights in src/core.js ever change, these cuts must be re-derived from a fresh sweep of the full supply. They are not constants anyone is free to pick.

The permanent base fee is 3% of WETH-side volume, taken by the hook inside the swap itself. The pool's own LP fee is forced to zero and the protocol fee replaces it. The carve is fixed in the fee library as parts per 600:

uint256 internal constant FLOOR_FEE_BPS = 300;   // 3%, once finalized

// At the 3% floor these equal:
// 2.0000% reflections, 0.5500% locked LP,
// 0.3000% QUOTRON tribute, 0.1500% creator.
uint256 internal constant REFLECT_PARTS = 400;
uint256 internal constant LP_PARTS      = 110;
uint256 internal constant TRIBUTE_PARTS =  60;
uint256 internal constant CREATOR_PARTS =  30;
uint256 internal constant TOTAL_PARTS   = 600;

Each retained stream accumulates in a destination-locked pot on the hook: only the reflections sink can pull the reflections pot, only the LP vault can pull the LP pot, only the tribute burner can pull the tribute pot. The creator's share is taken inside the swap with no custody step. There is no general sweep function.

Two percent of volume is taken in WETH and credited to a single accumulator. Booted machines claim from it in proportion to CLOCK. That is the entire reward path.

QUOTRONS converts its reward pot into ten tokenized stocks through sealed routes on an epoch schedule, run by a keeper. That is a good design for a collection built around stocks, and it costs a keeper, a converter, ten liquidity assumptions and an epoch cadence. RH COMPUTERS is built around hardware, so it skips all of it: the fee arrives in WETH and leaves in WETH.

// One accumulator, scaled by total live CLOCK. No epochs, no routes.
function _accrue(uint256 wethIn) internal {
    if (totalClock == 0) { pendingPot += wethIn; return; }   // nobody booted yet
    accPerClock += (wethIn * ACC_PRECISION) / totalClock;
}

function pending(uint256 id) external view returns (uint256 weth);
function claim(uint256[] calldata ids) external;   // pays the owner of each id

Pending rewards stay attached to the machine id when the NFT moves. A seller can claim immediately before a sale, so a buyer should re-check pending(id) at execution time rather than trusting a listing page.

Cold machines trade and earn nothing. Booting burns the boot cost in $RHPC against a machine you own. In exchange the screen lights up and animates and the machine starts earning, for good and for whoever holds it next. This is one-way. There is no function in the stack that un-boots a machine.

// The machines are an ordinary ERC-721 and the token an ordinary ERC-20.
// This is the only call that touches both, and it moves neither of them:
// the NFT stays where it is, the token goes to address(0).
function boot(uint256 id) external {
    if (machines.ownerOf(id) != msg.sender) revert NotMachineOwner();
    if (isBooted[id])                      revert AlreadyBooted();

    rhpc.burnFrom(msg.sender, BOOT_COST);     // real supply reduction

    isBooted[id] = true;                       // never unset, anywhere
    totalBooted += 1;

    emit POST(id, msg.sender);
    reflections.onBoot(id, msg.sender, clockOf(id));
}

Booting is usually called deflationary. It is — $RHPC totalSupply really does fall with every burn — but that is the smaller half. The number that does not move is the collection:

/// Cold machines plus booted machines: always 6,502.
/// The border between them is crossed in one direction only.
function machines() external view returns (uint256 cold, uint256 booted) {
    booted = totalBooted;
    cold   = SUPPLY - booted;                 // SUPPLY == 6502, immutable
}

Every machine is always in exactly one of two states, and the count of the second never falls. Booting does not destroy value — it converts a quantity of tradable token into a permanent claim on that token's trading. The claim survives; only the burned float disappears.

• The float shrinks. Every boot burns the boot cost out of $RHPC supply forever, so the same buy moves price further.
• The cold set shrinks. A booted machine never goes back, so the unlit half of the collection only ever gets smaller.
• The claimant set grows. Each boot adds a permanent earner, so per-machine yield dilutes as commitment rises.

Said plainly: the fee stream is generated by the traded float and consumed by the booted set, and every boot moves value from the generating side to the consuming side. That tension is the design, not a flaw in it.

Two openings, and they are not the same event. The machines mint as a drop on OpenSea: a public stage with a price and a per-wallet limit, run by OpenSea's own contract, and when it is done every id has an owner. The token opens separately — liquidity is seeded and one irreversible transaction starts trading. This section is about the second one. The only question worth designing there is what the first ten minutes look like.

At launch the public fee starts at 90% and steps down to the 3% floor over the opening window. Wallets on the allowlist pay 3% from the first block. When the window closes, finalizeFee() is called once and the public rate is 3% forever — the function reverts on a second call.

Get on it through the intake terminal at the bottom of this page. One wallet per X handle.

RH COMPUTERS exists because QUOTRONS exists. The machines are the boxes those terminals sat next to, drawn by the same hands, shipped on the same chain. The relationship is written into the fee rather than into a paragraph:

• Perpetual tribute — 0.30% of volume buys and burns $QUOTRON, forever, through a destination-locked burner. No admin, no pause, no redirect.
• Permanent boost — hold a lit QUOTRONS terminal and every machine you have booted earns at 1.25× CLOCK, read live from the QUOTRONS collection. Sell the terminal and anyone can refresh() you back down.
• No shared treasury — separate contracts, separate pools, separate reward streams. The tribute flows one way and the boost reads one way. Nothing in QUOTRONS depends on this collection.

The supported market is one registered $RHPC/WETH Uniswap v4 pool reached through an immutable canonical router. What makes that claim worth anything is where it is enforced: in the token, not in the pool.

Every v4 pool — ours and any copycat — settles through the same PoolManager singleton, so an address allowlist cannot tell them apart. The token therefore treats the PoolManager as locked by default, and our hook unlocks it one swap at a time, writing a settlement allowance bound to that swap's exact direction and amount in transient storage so it cannot outlive the transaction.

// afterSwap: authorize exactly this swap's $RHPC movement
int128 rhpcDelta = wethIsCurrency0 ? delta.amount1() : delta.amount0();
rhpc.authorizePoolTransfer(rhpcDelta);

A rogue pool's swaps run without our hook, so no authorization is ever written and the settlement reverts. It cannot trade $RHPC — and because seeding a pool is itself a transfer to the PoolManager, it cannot even be seeded.

These are disclosed powers, not a claim of full decentralization. We would rather you read them here than find them in the source.

• The owner can pause the token and the fee hook, ban or unban non-EOA venue codehashes, and irreversibly finalize the public fee at 3%.
• Metadata base URIs and the transfer validator are frozen by the launch transaction: setTransferValidator reverts after launch by construction.
• Approvals are cleared on every ownership or state change, including booting. This closes the class of bug that retired QUOTRONS V1 — by construction, not by policy.
• There is no keeper on the reward path, no converter, no upgrade proxy and no arbitrary sweep. Adding any of them later would require a new deployment, not a setter.
• Recovery and blacklist powers, if any, will be published here with addresses before launch, not after. The row is empty today because the decision is not made.

The machines are an ERC-721 collection using ERC721-C transfer validation. Compatible marketplace sales enforce a 5% creator earning, split through an immutable royalty splitter. That is separate from the creator's 0.15% share of canonical volume.

Most collections advertising royalties mean ERC-2981, which is advisory — royalty-optional marketplaces ignore it. ERC721-C enforces by venue: a transfer initiated by a non-allowlisted operator reverts, so a machine cannot be listed on a marketplace that strips royalties at all.

Two precise limits. Wallet-to-wallet transfers you initiate yourself always pass, because the validator gates operators and not owners. And venue compatibility cuts both ways: a marketplace that does not support the configured validator may reject the transfer entirely. Check the consideration split before you sign.

Which machine each id is, and what it looks like, is decided by code you can run. The engine is deterministic: renderRH(id) returns the same framebuffer and the same nine traits every time, in Node or in your browser, with no network access.

• Run it yourself — the engine is one file with no server and no network. Render any id from 1 to 6502 and compare it against the collection. Same pixels, or the claim on this page is false.
• Re-derive the tables — every count on this page comes from one sweep of the finished engine. The sweep is nine lines of Node and it is in the repository.
• Check the commitment — at deploy the hash of the frozen engine bundle is written into the token as artHash, and the metadata base URIs are frozen by the launch transaction. Hash the bundle and compare.

# count every era, special and tier across the full supply
node -e "const c=require('./src/core.js');const n={};
for(let i=1;i<=6502;i++){const t=c.generateTraits(i).traits;n[t.era]=(n[t.era]||0)+1}
console.table(n)"

# the art commitment, once the bundle is frozen
sha256sum rh-engine.bundle.js
# compare against the chain (after deploy):
cast call <RHPC> "artHash()(bytes32)" --rpc-url <RPC>

Nothing is deployed. Every row below fills in from RH_CONFIG.CONTRACTS the moment it is, and each will link to verified source on the explorer. An address that is not in this table and not in a post from @RH_Computers is not ours.

The router will accept native ETH buys and return native ETH on sells. There is no API key, no backend and nothing to ask permission for — the canonical route is public infrastructure, and it is safe to publish precisely because the routing lock means it cannot be bypassed.

// Buys are payable in native ETH; sells return native ETH.
function buyExactEth(uint256 minRhpcOut, address recipient, uint256 deadline)
    external payable returns (uint256 rhpcOut);

function sellExactRhpcForEth(uint256 rhpcIn, uint256 minEthOut,
    address recipient, uint256 deadline) external returns (uint256 ethOut);

// Views: quoting needs no ETH, no tokens and no allowance.
function quoteBuyExactEth(uint256 ethIn, address payer) external view
    returns (uint256 rhpcOut, uint256 feeBps, uint256 feeWeth);

function currentFeeBps(address payer) external view returns (uint256);

// 1. quote for the actual payer — returns the full fee breakdown
const [rhpcOut, feeBps, feeWeth] = await client.readContract({
  address: QUOTER, abi: quoterAbi,
  functionName: "quoteBuyExactEth", args: [ethIn, account],
});

// 2. user-approved slippage floor on the quoted output
const minOut = (rhpcOut * (10_000n - slippageBps)) / 10_000n;

// 3. execute — only after showing quote, fee and minimum
await wallet.writeContract({
  address: ROUTER, abi: routerAbi,
  functionName: "buyExactEth", args: [minOut, account, deadline],
  value: ethIn,
});

Nothing on this surface touches a machine. Buying and selling $RHPC moves the token and only the token; the NFTs are a separate contract and are unaffected by any balance you hold.

// Ownership is the collection's own ERC-721 Transfer; these are the rest.
event POST     (uint256 indexed id,   address indexed owner); // booted, one-way
event Clocked  (uint256 indexed id,   uint256 clock);          // weight re-priced
event Claimed  (address indexed to,   uint256 weth);
event Tribute  (uint256 wethIn, uint256 quotronBurned);

Machine ids are stable for the life of the collection and the art for any id can be rendered offline, so an indexer never needs to fetch an image to know what it is showing.