SUSHIHUB / METHODS & DATA

What this is, and what it is not.

Sushihub is a demonstration interface for a narrative-market product: a ranked board of themed baskets, a detail page per basket, a swap panel, and a shared controller working the counter. It is a front end and nothing else. This page documents every number you can see and where it comes from, so that no part of the interface has to be taken on trust.

Scope

There is no exchange, no order book, no router, no custody, no settlement, no counterparty and no token. No page here can create, sign or broadcast a transaction, and none of them read a wallet. The buttons labelled Trade, Give me trades, Connect wallet and Sign in are deliberately inert and say so when pressed.

Company names appear as the stated composition of simulated baskets. They describe what a basket is about; they do not represent holdings, and they imply no relationship with or endorsement by those companies. Nothing on this site is investment advice.

Return series

Every percentage and every line on the site is generated in your own browser. There is no price feed, no oracle, no index provider and no historical dataset.

Time is divided into five-minute buckets counted from a fixed epoch, 2026-09-01T00:00:00Z. For a set with seed s, the increment at bucket k is a function of (s, k) alone:

increment(s,k) = normal(s, k+7) × 0.055
               + sin(k/190 + φ(s)) × 0.030      slow regime
               + drift(s)                        small persistent tilt

level(s,k)     = Σ increment(s,i) for i = 0…k
return(window) = level(s, k_now) − level(s, k_now − window)

Two consequences matter. First, the past is fixed: because an increment depends only on its own bucket index, reloading the page never redraws history — it only extends the right-hand edge. Second, the series is the same for everyone: two people opening the board in the same five-minute window see identical figures, because both compute the same sum.

The board ranks sets by their simulated window return, recomputed on load and every thirty seconds. The today figure beside each set is the same construction over a 24-hour window with a different seed.

The controller

Itamae is an eight-state population controller. Eight continuous rates in [0,1] advance on fixed 20 ms Euler steps:

u_i  = clip(drive_i + 0.10 · r_i)
r_i' = clip(r_i + Δt/τ_i · (u_i − r_i))

Input is a 32 × 16 synthetic field built from the bearing and distance of the active station, using a Gaussian contrast profile. Contrast is summed over each half of the field and over a central strip, giving left, right and centre features. The controller reads nothing else: not the board, not a price, not the page.

g      = 1 − 0.7·C                      approach gate
drive0 = L                drive1 = R
drive2 = 0.50·r0          drive3 = 0.50·r1
drive4 = 0.45·(r0 + r1)
drive5 = g·r0 + 0.12·r2 + 0.08·r4
drive6 = g·r1 + 0.12·r3 + 0.08·r4
drive7 = 0.55·(r5 + r6)

turn  ω = 3.2·(r6 − r5) rad/s
speed v = 0.15·r7 counter units/s

A controller that steers by bearing alone does not come to a dead stop; it settles into a small orbit around whatever it is approaching. Arrival is therefore measured as range rather than as a halt. A plate is recorded when three conditions hold together for 0.6 continuous model seconds: range to the active station below 0.07 counter units, knife rate above 0.02, and central contrast above 0.05. A plate then has a three-model-second cooldown, and the next station is drawn from the run seed. These are hand-set thresholds, not learned behaviour, and the controller has no view on the set whose name the plate is logged against — that name comes from a seeded rotation.

How sharing works

The usual way to show everyone the same live agent is a server process plus a websocket. Sushihub does not have one. Instead, service is divided into three-minute runs counted from the same fixed epoch, and the controller is fully deterministic: given a run index, the seed, the station order and every subsequent step follow with no free parameters.

So your browser does not receive the run — it recomputes it. Opening the page simulates from the start of the current run to the present moment: up to 9,000 model steps, which takes on the order of a fifth of a second, after which it continues in real time. Anyone else watching computes the same thing and sees the same chef in the same place. Closing the tab does not stop anything, because there was never anything running anywhere except the clock.

Because the field only covers what is in front of the chef, a controller that turns past its station receives no input at all, and with no input every rate decays to zero and it stops permanently. A small one-sided bias below an acquisition threshold makes it sweep until the station returns to view. Over forty consecutive simulated runs this produces between 1 and 16 plates per three-minute run and no stalls.

The trade-off is honest and worth stating: this is a shared computation, not a shared process. Nothing an observer does can influence it, there is no history beyond the current run, and a browser with a badly wrong system clock will be looking at a different run.

Swap panel

Token prices in the swap panel are smooth deterministic functions of the current five-minute bucket — two sine components per token over a fixed base. Price impact is an illustrative function of order size, the fee is a flat 0.30% of notional, and the network fee and route are generated for display. None of these figures correspond to a real pool, a real route or a real cost.

Token record

No token exists for Sushihub. Nothing has been deployed, on Robinhood Chain or anywhere else. There is no contract address to copy, no launch transaction and no supply.

This section is the launch record, and it stays in this state until a real contract exists. If one is ever deployed, this is where the chain, the chain ID, the contract address, the deploying transaction, the block and the timestamp will be recorded, along with a plain statement of who launched it. The machine-readable twin of this section lives at data/token.json.

The $SUSHIHUB mark in the header is a placeholder for that record and links here. It is not an announcement, a presale, an allocation or an offer.

Limits

• Simulated series are not forecasts, backtests or historical performance. They contain no information about any real asset.
• The controller is eight coupled scalars. It is not an agent, it does not reason, and it has no view on any set. Set names attached to plates come from a seeded rotation, not from analysis.
• Coefficients throughout are hand-set design parameters. Nothing has been fitted to anything.
• There is no persistence: no accounts, no positions, no server-side state, and no record of a run once it ends. The export button writes the current run only.
• Everything runs client-side, so a modified browser can produce different numbers locally. There is no authority to check them against, by design.

Credits & licence

The shared-deterministic-controller idea and the shape of the eight-state rate equations are adapted from the open-source Zebrafish Neural project (MIT), which in turn credits FLYBRAIN. No code, weights or data were copied from either; the equations here are reimplemented with different coefficients, a different input encoding and a different task.

The board and set-detail layout follow the pattern set by Pountain, and the swap panel follows the conventions of SushiSwap. Sushihub is not affiliated with, endorsed by or connected to any of them.

Built as plain HTML, CSS and ES modules with no build step, no framework and no runtime dependencies. Fonts are Inter and IBM Plex Mono.