SWITCHBOARD404

4,004 positions on HyperEVM. One token is one position. Patch to light it. Lit positions bill in HyperCore spot. Dark trades, lit bills.

This is the working spec. It is written to be published as the app's documentation once the contracts are deployed, and to be argued with before that.

The short version

$SWTCH is a token with only 4,004 units in existence, trading through one canonical SWTCH/WHYPE pool on HyperEVM. Hold a whole liquid token and a dark switchboard appears in your wallet, assigned to one of ten panels. Sell below a whole token and the dark board dissolves back into circulation.

Patch the token backing a board and it is hardwired: permanent, irreversible, and billing its assigned HyperCore spot asset from that moment on. The token supply shrinks with every patch; the fee stream it bills from does not.

Every buy and sell pays a permanent 3% fee, enforced by the token itself rather than by the front end. 2% of volume bills lit boards in spot, 0.6375% compounds the locked liquidity, 0.2125% buys and burns, 0.15% pays the operator.

A gacha for flippers, a one-way commitment for holders, and a fee engine that cannot be routed around, feeding the committed.

Glossary

The vocabulary is deliberate. These are switchboards, not terminals, and the states are not standard ERC-721 states.

What HyperEVM changes, and why it is simpler here

This design is a fork of a Robinhood Chain protocol built on Uniswap v4. Three things are different on Hyperliquid, and two of them are in our favour.

1. There is no Uniswap v4 on HyperEVM, and that makes the routing lock easier

Verified on chain: the canonical v4 PoolManager has no code on HyperEVM. The venues are v3 forks — HyperSwap v3 (0xB1c0fa0B789320044A6F623cFe5eBda9562602E3) and Project X (0xFf7B3e8C00e57ea31477c32A5B52a58Eea47b072).

The v4 protocol we are forking needed transient-storage authorisations because every v4 pool settles through the same PoolManager address, so an allowlist cannot tell the real pool from a copycat. In v3 each pool is its own contract at its own address. So:

• the token charges its fee on transfers to and from the one registered pool address, and only that address;
• any other contract that looks like an AMM can be refused by runtime codehash, reactively, the same way;
• wallet-to-wallet transfers pay nothing and can never be blocked, because an EOA has no codehash to ban.

No hook, no transient storage, no canonical router required. The fee lives in _transfer, which is the only place that cannot be routed around.

⚠ Honest limit, unchanged from the original: a novel AMM contract would work until it is identified and banned. Meaningful off-route liquidity is hard to bootstrap and arbitrage returns volume to the deep pool, but that is an economic tendency, not a contract guarantee.

2. HyperCore is the billing venue, and a contract is an account holder there

A contract deployed on HyperEVM holds an account on HyperCore at the same address. It reads its own state through the precompiles and acts through CoreWriter at 0x3333333333333333333333333333333333333333. That means the billing engine is not a manager sitting on top of a treasury: it is the account. Any holder can paste its address into the Hyperliquid interface and see the inventory.

3. Paying in spot requires the asset to have an EVM twin

168 of the 495 HyperCore spot tokens have a linked EVM contract (checked against spotMeta). That link is what makes billing possible: the engine buys the asset on Core, bridges it to the EVM side by spot-sending to the token's system address, and pays lit boards an ordinary ERC-20.

⚠ Two traps here, both real:

• Core counts in 8 decimals; the EVM twin's decimals are weiDecimals + evm_extra_wei_decimals and differ per asset (USDC is 6, most natives are 18). Every crossing has to scale, and dust below one Core wei is refused rather than silently lost.
• An asset with no EVM twin cannot be paid out, only held on Core. Panels are chosen from the linked set, and the choice is committed on chain at deploy.

The panels: chosen for depth, not for glamour

The protocol we are forking pays ten tokenized stocks. On Hyperliquid the equity-flavoured spot markets exist but most of them are empty. Measured today:

Ten equity tickers would look like the original and would not work: an epoch converting into SPY or TSLA would pay 30% of the budget to whoever is standing on the other side of an empty book.

So the ten panels mix the two things Hyperliquid actually has depth in:

1. HYPE — the chain's own asset, and the one everything is quoted in
2. QQQ — the deep tokenized index, the equity flavour of the original
3. GLD — tokenized gold, the second deepest 4–10. seven deep HyperCore natives, chosen at deploy from the live depth scan (today the candidates are PURR, WOW, NEKO, QUANT, BUDDY, USDT0, STABLE).

The rule that matters more than the list: each panel's route is fixed at deploy from a published depth scan, and the scan is re-runnable. A panel whose book dies is a panel that pays badly; it can never be silently repointed, because the destination is immutable.

Each panel holds exactly 400 boards with an identical tier mix, and each receives an equal share of every epoch budget.

The machines

Every board is a real switchboard from the history of the telephone exchange, drawn as the same isometric machine in the brand art. Rarer models carry more billing weight.

4,000 standard + 4 relics = 4,004.

The reroll

Dark boards are draws, not assignments. Crossing down through a whole unit dissolves your most recently received dark board back into the unclaimed pool; crossing back up draws a new one at random from whatever the pool currently holds. Sell 0.1 $SWTCH and buy it back, and you hold a different machine.

The pool is a lazy Fisher–Yates shuffle over the unclaimed ids: a slot whose stored value is zero implicitly holds slot + 1, so 4,004 entries cost no storage until touched. Draws index into it with a hash of the previous block's randomness, the timestamp, the recipient and a nonce.

This is pseudorandomness drawn from block state, and we say so. It is unpredictable enough for a gacha whose prizes share one fee stream, and every draw is auditable after the fact. It is not a commit-reveal lottery and does not claim to be.

⚠ HyperEVM detail: blocks are one second on the small lane and block.prevrandao is available, but a validator building the block still sees the transaction. For a gacha with a shared prize pool that is an acceptable, disclosed weakness; for anything with a jackpot it would not be.

Every patch removes an id from this pool permanently. The reroll pool only ever shrinks.

Patching, the one-way door

Dark boards are liquid: they trade, they reroll, they bill nothing. Patching burns the single $SWTCH backing a board you own. In exchange the board becomes a permanent NFT that can never dissolve, its plugs light, and it starts billing its panel's asset. There is no function in any contract that un-patches a board.

function patch(uint256 id) external {
    if (_ownerOf[id] != msg.sender) revert NotBoardOwner();
    if (isPatched[id]) revert AlreadyPatched();
    if (balanceOf[msg.sender] < UNIT) revert InsufficientBalance();

    balanceOf[msg.sender] -= UNIT;
    totalSupply -= UNIT;                 // real supply reduction
    emit Transfer(msg.sender, address(0), UNIT);

    _removeDark(msg.sender, id);
    isPatched[id] = true;                // never unset, anywhere
    totalPatched += 1;

    mirror.clearApproval(msg.sender, id); // the V1 bug this fork must not repeat
    emit Patched(id, msg.sender);
    billing.onPatch(id, msg.sender);
}

This is not staking. There is no position to unwind and nothing in escrow. The burned token leaves totalSupply whether or not the protocol ever bills another cent.

Each panel's billing accrues from the moment trading opens. Until a panel has its first patched board, its share collects in a pot — and the first board patched on that panel claims the entire pot. Ten panels, ten races.

The 4,004 invariant

/// Liquid tokens plus patched boards: always 4,004.
function units() external view returns (uint256) {
    return totalSupply + totalPatched * UNIT;
}

Every unit is always in exactly one of two states: liquid (tradable, rerolling) or patched (an NFT, permanent, billing). Patching does not destroy value — it moves a unit out of the tradable float into a permanent claim on that float's trading activity.

• The float shrinks. Every patch removes 1.0 from tradable supply forever.
• The reroll pool shrinks. The patched id can never be drawn again.
• The claimant set grows. Each patch adds a permanent biller, so per-board yield dilutes as commitment rises. Patching is most attractive early on each panel and self-limits as panels fill.

The fee stream is generated by the liquid float and consumed by the patched set, and every patch moves one unit from the generating side to the consuming side. That tension is the design.

Where every unit of volume goes

The permanent base fee is 3% of the WHYPE side, taken by the token inside the transfer, not by the pool. The carve is fixed in the fee library as parts per 240:

Each retained stream accrues in a destination-locked pot: only the billing sink can pull the billing pot, only the burn vault can pull the burn pot, only the LP vault can pull the LP pot. 🔴 There is no arbitrary sweep function anywhere. That is the lesson from every treasury emptied last cycle, and it is enforced by absence rather than by policy.

This is a swap fee, not a transfer tax. Wallet-to-wallet $SWTCH transfers and NFT transfers pay nothing. The 3% applies only when the trade settles against the canonical pool.

Epochs: how WHYPE becomes spot

Fees queue as WHYPE in the billing pot on HyperEVM. An epoch is one batch that turns them into the ten panel assets. It runs entirely through Hyperliquid's own machinery:

1. Bridge. The engine unwraps WHYPE and sends native HYPE to 0x2222…2222, crediting its own HyperCore spot balance. ⚠ 8 decimals: anything under 1e10 wei is refused, not lost.
2. Convert. For each panel, CoreWriter places a limit order on that panel's HyperCore spot market. Ten sealed routes, fixed at deploy, one order each.
3. Bring home. Each bought asset is spot-sent to its own system address, arriving on HyperEVM as the linked ERC-20.
4. Allocate. The engine credits each panel's accumulator by live billing weight, and lit boards claim whenever they like.

Bounds, so an epoch cannot be used as a toy: it opens only above a floor, is capped, and needs a minimum interval between openings. The converter can send assets only to the billing contract — the destination is immutable.

⚠ The honest part: conversion is keeper-initiated. Fees accrue safely in destination-locked pots if operations stop, but payouts require the keeper to run epochs. That is a disclosed trust assumption, not decentralisation.

How the project is organised on Hyperliquid

Two layers, and it matters which piece lives where.

On HyperEVM (chain 999) — everything with a balance a user touches:

• Switchboard404 — the ERC-404 core: token, dark-board bookkeeping, the pool, the draw, the fee, the routing lock, patch().
• SwitchboardMirror — the ERC-721 collection. Clears each token's individual approval on every ownership or state change, including patching. The protocol we are forking was paused because an approval survived a burn-and-rematerialise cycle; this fork closes that by construction.
• BillingEngine — the accumulator, one per panel, paying the linked ERC-20s.
• EpochConverter — bridges, orders on Core, brings home. Holds a HyperCore account at its own address.
• LpVault, BurnVault — destination-locked pots.

On HyperCore — the inventory and the books:

• the converter's own spot account, visible to anyone in the Hyperliquid interface;
• the ten panel markets, chosen for depth and committed on chain.

Deployment order, which is not negotiable because half of it is one-way:

1. token + mirror, wired to each other
2. billing engine and vaults, pointed at the token
3. converter, with the ten routes sealed in its constructor
4. the canonical pool created and seeded in one run — an initialised pool with no liquidity has a stored price anyone can walk
5. launch() — opens trading and freezes the metadata base URIs, one way

Operational constraints that will bite if ignored:

• ⚠ Big blocks. HyperEVM has two lanes: small blocks are 2M gas, big blocks 30M and one per minute. The ERC-404 core will not fit in a small block, and creating the v3 pool costs ~4.3M on its own. The deployer has to be flagged with the L1 action {"type":"evmUserModify","usingBigBlocks": true} and must already exist on HyperCore — send it 1 HYPE through 0x2222…2222 first, or the action is refused with "user does not exist". Switch back to small blocks the moment the deploy is done: one transaction a minute is the wrong lane to be in when you need to act.
• ⚠ The public RPC rate limits and prunes. Use https://rpc.hypurrscan.io for deploys and verification; keep rpc.hyperliquid.xyz/evm as a second opinion.
• ⚠ Verification goes through the Etherscan v2 multichain API with chainid=999.
• ⚠ cast send exits 0 on a reverted transaction. Every script reads the receipt status.

Repos: switchboard404-contracts (foundry, fork tests against the live chain) and switchboard404-app (Next.js, viem, no backend). The docs on the site are this file.

What is true today

• Nothing is deployed. This is a specification.
• There is no v4 on HyperEVM, so the fee is enforced by the token against one registered v3 pool, not by a hook. The guarantee is strictly weaker against a novel AMM contract and strictly simpler everywhere else.
• The equity panels are thin. QQQ and GLD have books; SPY, TSLA, META and HOOD do not. The panel list is chosen from a live depth scan and published with it.
• Conversion and epochs are keeper-initiated. Pots are destination-locked, payouts are not automatic.
• Patching is irreversible. The burned token is gone whether or not the protocol ever bills another cent.
• Billing is a promotional reward for taking part in the protocol. It is not a dividend, not investment income, and confers no equity or share of profits in anything.