The model, its methods
and the token launch record.

Zebrafish Neural connects real browser screenshots to an eight-state model and applies its motor output to the cursor. The shared experiment continues on Wikipedia. The homepage also offers a browser-local target test with synthetic visual input, scored trials and JSON export; each viewer runs a separate session with the same model equations. A separate laboratory provides further controlled stimuli. The project token is now on Solana through pump.fun. Token details identify the operator-provided mint and official links. Earlier token balances do not automatically transfer. The neural controller did not create or sign the token launch.

Controlled laboratory sessions

1. Open the laboratory. The controller starts automatically with a moving visual target.
2. Compare the retinal image, model states, trajectory and motor time series. The model continues beyond 60 seconds.
3. Pause to change stimulus or contrast, then Resume. Restart clears state and recording; a running session continues and a paused session stays paused.
4. Export JSON or CSV at any time. Exports retain only the latest 60 model seconds, with original session timestamps.
5. Use Population model to inspect simulated activity, or ZAPBench anatomy to examine measured cell positions independently.

The session suspends when the tab is hidden and resumes when visible unless manually paused. Closing or reloading the laboratory ends that local session. This does not affect the shared live controller. Continuous execution does not imply continuous movement: no stimulus produces no activity, and the looming shadow is a single presentation.

Drag the brain view or use arrow keys to rotate. The mouse wheel and +/− keys control zoom. Data stay in browser memory until exported.

Shared browser controller

The Live page observes one supervised Node.js process and one isolated Chromium browser on the operator’s Windows PC. Opening another viewer does not create another model. Closing a viewer does not stop the process. The server runs the experiment independently of viewers.

Input and dynamics

Chromium captures a real 1,120 × 700 pixel viewport approximately twice per second. The adapter decodes the screenshot to grayscale and samples a 32 × 16 retinal field centered on the last applied cursor position and oriented with its heading. The field spans 320 pixels laterally and from 35 pixels behind to 165 pixels ahead. Sampling clamps at viewport boundaries.

The absolute difference from a 3 × 3 local mean supplies contrast. The mean contrast in each half of the retina is multiplied by 6; central contrast is multiplied by 4. Features are clamped to 0–1. Uniform white or black images therefore do not create visual drive. Threat input is zero; this adapter does not detect looming objects.

The existing eight-state population equations advance with fixed 20 ms steps in a server timer. The latest visual observation is held between captures. A slow host caps accumulated wall time rather than taking unstable integration steps; model time and process uptime are displayed separately.

Cursor and click mapping

The model's kinematic body coordinates map directly to viewport cursor coordinates. The applied cursor, heading, and source frame identify the next observation. The interface's cursor marker is an overlay showing the applied browser position; it is not included in the neural input.

A click is proposed after central contrast remains above 0.06, spinal drive exceeds 0.025, and the absolute motor-rate difference stays below 0.08 for 1.2 model seconds. Proposals have an eight-model-second cooldown. Each proposal retains its decision coordinates, model time, and input frame identifier. These thresholds are human-designed parameters, not inferred biological behavior.

The browser accepts a proposal only when the point is an ordinary article link on the permitted domain. A rejected proposal is recorded. Motor activity near the top or bottom edge can drive a scroll, with a four-second wall-clock cooldown.

Assistance and boundaries

The operator supplies the initial set of Wikipedia articles. The adapter rotates to the next article after three wall-clock minutes, independently of the model. These rotations are marked assistance, separately from controller clicks and scrolls. The model has no instruction to read, understand, or choose an article topic.

Navigation requests and redirects are restricted to HTTPS English Wikipedia article URLs. Account pages, namespaces, query-based actions, forms, downloads, popups, and non-GET requests are excluded. The browser uses a fresh context without the operator's accounts, wallet, or extensions. It has no typing or transaction-signing action.

Stream and recovery

The shared service publishes real screenshots, retinal input, rates, applied cursor position, page URL, model time, session ID, and recent events over a read-only WebSocket. Spectators cannot pause, restart, or command the controller. Slow subscribers are disconnected rather than blocking the model.

Input older than four seconds suspends model actions. Navigation invalidates the prior observation; captures spanning a document change are discarded. The frontend marks delayed or disconnected streams and automatically reconnects. It never substitutes synthetic motion for missing live data.

The runtime saves population rates, body position, model time, step count, and click cooldown approximately every ten seconds. A browser failure triggers recovery. A process restart can resume a compatible checkpoint, but observation-dependent dwell and recent sample history begin again. The session ID changes when the process restarts.

Recording and connection

The download contains the latest 60 model seconds and recent events, with original model timestamps and frame references. Event files and a checkpoint are kept on the host. This is a recent-run export rather than a complete historical screenshot archive. The operator's manual token launch is documented separately in the token launch record.

The frontend is hosted on Vercel. Caddy forwards the stable HTTPS endpoint https://feed.zebraneural.com and its read-only /ws WebSocket to the browser service on the AWS host. The model continues without viewers while its supervised process is running. A host or process restart creates a new session ID and process uptime; compatible saved model state resumes separately.

The separate Laboratory page retains controlled synthetic-stimulus experiments. Its local browser session is independent of the shared live controller.

Separate persistent target learner

The public Learning controller observes a separate supervised process on the AWS host. It adjusts six connection gains through scored synthetic target-reaching trials, retains parameters that pass its validation gate, and saves the candidate, retained gains, optimizer state and generation records. Fresh-target evaluations are recorded separately from the validation results used for selection.

The page receives read-only state from the endpoint in learning-config.json and illustrates the saved gains with labeled local replays. These replays are distinct from the server's training trials. The Wikipedia controller still uses fixed parameters: target learning does not teach it article content, provide biological validation or connect it to a wallet.

Implemented and pending

Shared browser capture, contrast encoding, neural cursor movement, permitted link clicks, streaming, event logs, and checkpoint resume are implemented. The controller is an eight-state zebrafish-inspired model; it is not a reconstructed whole brain. ZAPBench anatomy remains a separate measured reference.

$ZNEURO is a separate Solana token launched by the project operator through pump.fun. The current mint is listed in the token details. The shared Wikipedia experiment continues independently. Token-form execution, wallet access and transaction signing are not connected to this browser runtime. The controller did not create the token and cannot create or trade tokens through the article browser.

Browser-local target test

Model: zebra-rate-0.1.0 · Task adapter: target-task-0.1.0

The Target test puts the existing eight-state controller in a small, measurable visual task. A target produces synthetic retinal input; the population model generates steering and forward movement; the task records whether the cursor reaches the target. The model equations and coefficients are unchanged. There is no learning between attempts.

Open Target test directly, or select Target test beside Wikipedia and Chess on the homepage. The homepage currently opens the shared AWS chess game by default. Each visitor's target experiment runs separately in that visitor's browser. It does not send commands to the shared Wikipedia or chess controllers.

Two input adapters, one population model

The target test does not take screenshots of the arena or the viewer's desktop. The target position is used to construct the sensory stimulus and score contact. It does not directly set cursor position or motor output. Labels, paths and other observer overlays are excluded from model input.

The same illustrative brain view displays the eight population rates. Its 5,220 drawing points are a visualization of those eight values, not independent neurons or recorded biological activity. The separate ZAPBench anatomy view remains independent of these dynamics.

Protocols and scoring

Each attempt starts at (x=0.5, y=0.75), facing upward with heading −π/2, and all eight rates reset to zero. Input intensity is 0.85. Numerical integration uses fixed 0.02 model-second steps at both display speed settings.

An attempt is reached when the cursor lies within 0.065 normalized arena units of the target, with a limit of 30 model seconds. Contact on the final numerical step is checked before timeout. Position and distance use normalized coordinates, not physical lengths or screen pixels. Path length is accumulated from successive cursor positions. Contact time is elapsed model time for a reached attempt; it is absent for a miss or interruption.

Each protocol advances independently through the same fixed eight-target sequence, then repeats it:

(0.25, 0.25), (0.75, 0.25), (0.50, 0.22), (0.20, 0.40),
(0.80, 0.40), (0.35, 0.18), (0.65, 0.18), (0.50, 0.35)

The sequence provides repeatable starting conditions. It is not a sampled biological benchmark or evidence of general task competence. Repeated trajectories from identical initial conditions reflect deterministic equations, not learning.

Controls and interventions

Clicking the arena moves the target. Hide stimulus removes visual contrast; restoring it allows input to drive the rates again. Residual model activity can decay after input disappears, so motion need not stop immediately. These observer actions are logged and mark that attempt as an intervention.

Next target or a protocol change ends an unfinished attempt as Interrupted and starts a fresh state. The standard reached/trials count includes completed, uninterrupted attempts for the selected protocol only. Attempts with observer interventions and interrupted attempts remain in the records and export, but are excluded from that count. Reversal and occlusion scheduled by a protocol are part of the standard condition.

Pause preserves the current target, state and model time. The 4× setting requests faster model time while keeping the integration step unchanged; rendering and browser scheduling can limit wall-clock speed. Target simulation pauses when its browser tab is hidden or Wikipedia mode is selected. Returning does not simulate the elapsed hidden interval. The shared Wikipedia host continues independently.

Session records and retention

Export session JSON while Target test is selected to save the current local target session. It includes model and task adapter versions, settings, the target sequence, completed attempts, outcomes, intervention events and sampled trajectories, plus the current unfinished attempt if one exists. Samples are taken every 0.1 model seconds and at trial start and finish. Each sample includes pose, model rates, input features, target visibility and accumulated path.

The target session is held in browser memory. Reset session, reload or closing the page discards that session; there is no automatic upload, daily archive or server checkpoint for target tests. Export before leaving if the record is needed. This differs from the shared Wikipedia host's checkpoints and bounded recent-run recording. Selecting Wikipedia changes the export control to that shared run's recording.

Inspect results by protocol and retain failed and intervened attempts alongside successes. The export enables inspection of these software runs; it does not constitute biological validation, a trained model or a research result about zebrafish behavior.

Scope and deployment

The feature runs alongside the original website interface and uses its existing brain, retina and event panels. It remains a browser-local experiment with no learning between attempts. The shared Wikipedia runtime now runs separately on the operator’s Windows PC; its screenshot feed remains approximately 2 Hz.

The public Learning controller is a separate experiment that adjusts and saves six gains through scored synthetic trials. Its server checkpoints and generation history do not change the local target test's parameters or session-retention rules.

Neither experiment captures the operator's desktop or uses a wallet. The target experiment has no token-launch action, signing capability or control over the shared browser. The token contract and operator-launched record are unchanged.

Browser Lab

The Browser Lab connects the existing eight-state controller to a controlled website in an isolated Chromium browser. The observer displays real screenshots, a model-driven cursor, population rates and scored trials. This release is prepared locally before the new-server cutover.

Three changes to the environment

The target-switch protocol moves a bright target at 8 model seconds. The visual-interruption protocol hides it between 8 and 11 seconds. The competing-cues protocol adds a larger distractor at 8 seconds. Each trial starts from a disclosed initial state and ends after 24 model seconds. Failures remain in the record.

The model consumes screenshot-derived luminance cues through a new, versioned encoder. Page geometry is read separately for scoring; target coordinates do not guide the controller. This tests visual-motor responses to an engineered environment, not language understanding or general web navigation.

Recorded evidence

Each saved attempt identifies its protocol, seed, initial state and model version. Recorded visual input is aligned with the actual cursor and neural samples. The viewer can inspect those samples and export the trial.

Replay recomputes the model outputs from recorded inputs and compares them with the saved values. A successful check supports computational consistency. It does not prove that a screenshot originated on a particular host or that the model reproduces biological neural activity.

Comparison limits are 1e-10 for normalized values and 1e-7 pixels for cursor coordinates; discrete events and labels require exact matches. These limits allow small floating-point differences between the server and browser engines without accepting meaningful changes to an action.

Time on target compares visible-target samples before and after the 8-second intervention. Hidden-target samples are excluded. The baseline includes the initial approach, so this descriptive comparison is not a causal effect estimate or a learning score. A single contact before an intervention does not establish successful tracking after it.

The vision-off and motor-off options are open-loop replay controls on the same recorded input sequence. They help expose the role of input and output in the equations. They do not generate a new closed-loop browser experiment, and their alternative trajectories are not scored as independent successful trials.

Relation to existing experiments

The controller equations and hand-set gains are unchanged. Browser Lab resets state between trials and does not learn across them. The separate persistent target learner remains responsible for saved gain updates. Wikipedia and both chess services keep their existing data and processes.

The schematic neural view displays eight model rates. It is independent of measured zebrafish anatomy and is not a biological recording.

Recovery and retained trials

If the browser fails, the host retains complete recorded frames as an interrupted attempt and starts a fresh trial after reconnecting. The observer identifies the interruption; it does not continue an animation or invent missing frames. The original and replacement trial have different identifiers.

When archival is enabled, older trials move out of the bounded active window into verified local storage and remain accessible from the saved-trial pages. This permits more than 200 retained trials without erasing earlier evidence. Low disk space pauses new trials. Local archives still need backups; the archive is not an independent copy of the server disk.

Stock Token market observer

GOOGL and NVDA Stock Token reference prices feed the existing eight-population zebrafish-inspired controller. This experiment runs separately from Wikipedia, learning, Browser Lab and chess. The public viewer displays received market data, model signals and execution evidence when its server endpoint is configured.

Release status

The observer and a separate, operator-started execution worker are implemented. Live execution is operator-started. The public viewer reports the worker heartbeat and confirmed receipts separately from market observations. ETH and USDG funding were confirmed during preparation. On September 23, 2026, read-only quotes for both canonical tokens passed through the documented Uniswap v3 deployment on Robinhood Chain, including independent fresh-price checks. These checks establish preparation evidence, not submitted trades. Host activation and public feed configuration remain separate deployment steps. A deployed page alone does not establish a running worker or completed trade.

The observer reads prices, records evidence and serves a read-only interface without a private key or exchange API key. The default execution venue is direct Uniswap v3, selected by ZNEURO_TRADING_VENUE=uniswap-v3; it uses public RPC calls and does not require ZEROX_API_KEY. The optional 0x venue requires its own API key and applicable asset access. The headless execution worker has no HTTP order endpoint. Its operator supplies the signing key privately, runs the read-only preflight, and explicitly enables both the environment gate and --live before financial actions are possible. The website does not connect visitor wallets or accept orders. See Windows operations.

Direct venue and quote evidence

The direct route is limited to USDG and either canonical GOOGL or NVDA, using the 0.05% Uniswap v3 pools. Addresses are pinned to the official Uniswap chain-4663 deployment registry, and each quote verifies contract code, factory identity, pool tokens, fee and current pool state.

At 12:47 UTC on September 23, public read-only calls quoted 10 USDG for approximately 0.0285144 GOOGL and 0.0439031 NVDA. They passed the configured reference-price bounds at their observed blocks. These are historical quotes, not current offers or fills. A fresh quote is required before an order.

QuoterV2 simulates pool math through eth_call; it does not establish that this wallet can transfer tokens or has sufficient allowance. Quote evidence records walletTransferSimulated: false. The execution adapter separately validates token restrictions and exact calldata, then simulates the wallet transaction and estimates its fee before signing. The router call pins the recipient, input amount, minimum output and a 30-second deadline. Quotes expire after 20 seconds.

Robinhood explicitly documents standard AMM integration, but public contracts do not establish investor eligibility. The issuer's Stock Token restrictions apply to direct on-chain trading as well. A separate 0x access rejection is not cleared by choosing another venue; the optional 0x route remains subject to its RWA access process.

Model and market data

The supported assets are exactly GOOGL (Alphabet Class A) and NVDA on Robinhood Chain, chain ID 4663. GOOG is not substituted for GOOGL. Expected issuer contracts, active asset status and corporate-action multipliers are checked against Robinhood's official registry.

Robinhood's REST bid/ask values describe the underlying equity. The current multiplier is applied once to obtain a token reference mark. These marks are not executable DEX quotes. The chart contains observations actually collected by the observer; missing historical prices and missed decision slots are not manufactured.

The observer normally polls every 15 seconds and saves decisions on UTC quarter-hour boundaries. At least 20 distinct fresh observations spanning five minutes are required for an actionable signal. Invalid identity, stale quotes, halts, gaps or insufficient observations can produce HOLD. The worker separately checks fresh marks, trading capability, executable quotes, wallet balances, allowances, gas and risk policy before acting.

The market adapter uses handcrafted rules. It has not been trained on historical returns and does not learn from trading profit or loss in this version. The separate target-reaching learner does not establish financial prediction ability. A 15-minute schedule neither requires a trade at every interval nor establishes profitability.

What the visualization and replay establish

The brain view shows eight continuous, unitless model population rates. Its point-cloud geometry is illustrative; it does not display recorded individual zebrafish neurons or literal internal thoughts. Explanations describe the recorded inputs, thresholds and resulting signal.

Each decision retains its input observations, derived features, rates, versions, timestamps and a link to the previous record hash. Browser replay recomputes the saved adapter and model output. It checks computational consistency and detects changes within the retained chain; it does not prove forecast quality, independent source authenticity, execution timing or profit.

Orders, receipts and accounting

Signals and transactions are separate records. The worker can act on newly recorded BUY or SELL decisions after it starts; it does not place catch-up orders from older signals. BUY spends USDG. SELL is limited to positions attributed to this worker's receipt-based ledger. ETH pays gas, and the worker does not automatically convert ETH into USDG.

The implementation prepares bounded approvals and swaps, persists the signed transaction before submission, then reconciles its on-chain receipt. An ambiguous submission remains pending or requires review; it is not a confirmed fill. Confirmed receipt token deltas determine fills. Reverted transactions do not produce a fill, although they can incur gas. The public projection excludes private keys, provider credentials, unsigned calldata and signed raw transactions.

Public wallet history is labeled separately because a deposit or manual wallet action does not establish that the model caused it. Positions, execution state, heartbeat age and reported performance appear only from supplied evidence. Missing values remain unavailable. Deposits are not counted as trading profit.

Risk policy and valuation

The configured maximum order is $10 of trade notional, with gas additional. SELL notional is checked against a fresh token ask; positions are valued at the token bid. Gas is converted to USD using the Coinbase ETH/USD ask. USDG is valued at one USD in this ledger; this is an explicit valuation assumption, not a depeg measurement.

The $50 daily loss stop is measured in UTC from the first fresh valuation obtained that day. The monitored change includes realized and unrealized P&L minus fees. Once triggered, it remains latched for that UTC date: no new buys, sells or approvals are started. Existing submitted transactions continue to be reconciled. It is not an automatic liquidation rule.

This threshold does not guarantee an exact maximum loss. Open positions can continue to change value, quotes and receipts can be delayed, and already submitted transactions can complete. Network fees, slippage and unavailable liquidity also matter. Evaluation must include these costs, failed transactions and out-of-sample periods; no profitable result has been established.

Primary references

• Robinhood Chain network
• Stock Token APIs and price multipliers
• Building with Stock Tokens
• Official Uniswap deployments on Robinhood Chain
• SwapRouter02 exact-input interface
• SwapRouter02 deadline wrapper
• 0x supported chains
• 0x allowance contracts
• 0x Settler deployment registry
• Coinbase ETH/USD ticker format

Challenge the fish

Open Challenge to compare the original controller with a frozen copy of six saved gains on a task you configure. Both controllers start from the same pose and follow the same target schedule. Their movement comes from the same eight-state population equations; different trajectories produce different retinal observations.

This is a separate, browser-local experiment. It does not train either controller, change the shared learner's weights, or send commands to the Wikipedia browser.

Task and input

Each arm starts at (x=0.5, y=0.8), facing upward at −π/2, with all eight rates at zero. Integration uses fixed 0.02 model-second steps and a maximum duration of 30 model seconds. The original arm uses the published baseline gains; the comparison arm uses the exact six gains selected when the challenge opens. Both sets stay fixed throughout the trial.

Target bearing and distance generate the existing synthetic 32 × 16 retinal stimulus. Target coordinates supply the stimulus and contact scoring; they do not directly set motor output or move the cursor. There are no screenshots, desktop images, taste sensors or language-model actions in this task. Rates are normalized, unitless model values rather than measured spikes.

The controls can change target position, motion, contrast, contact radius and the occlusion schedule. Target x is bounded to 0.1–0.9, y to 0.1–0.85, and the initial target must be outside the contact radius. Sweep speed is 0.06 × speed arena units per model second, with speed from 0.2–1.5. Contrast ranges from 0.15–1 and contact radius from 0.035–0.09. Occlusion can begin at 2–12 seconds and last 1–8 seconds. These are task parameters, not biological units.

Editing a task resets its trial. Pause and playback speed affect only the local presentation; integration steps and scoring stay the same. The local run suspends while its tab is hidden. None of these controls pause or reset the AWS learner.

Outcomes

An arm reaches the target when its cursor lies within the configured contact radius, subject to the switch task's post-switch condition. The same radius is used for the observer's target circle and the contact test. Contact is checked before timeout on the final step. Each arm records success or timeout, time to target, path length and closest distance. A miss has no time to target; its time cost is the full 30-second limit.

Both arms receive the same target position, motion, visibility schedule and contrast. Each arm's own pose determines its retinal input. A comparison can end with either arm faster, only one successful, a tie or two misses. Those outcomes are retained without treating the saved gains as a guaranteed improvement.

Server recomputation

After a completed trial, a separate Vercel server execution recomputes both arms from the submitted task configuration and exact gains. The request contains inputs, not a score for the server to accept. The page compares the returned outcomes with its local results and reports an unavailable or failed check explicitly.

This verifies reproducibility under the same software model and inputs. It does not independently authenticate the source of submitted gains, constitute peer review, or establish biological validity. The response identifier identifies that calculation; it is not a signed certificate or a permanent archived result.

The parameter endpoint reads the public learner's saved gains. If that request fails, the page labels the original-parameter fallback. Recomputing a submitted challenge uses its pinned gains and does not replace them with a newer checkpoint. No verification request writes to AWS training state.

Sharing and records

A public challenge link includes the task version, validated configuration and exact six gains. Reopening it reproduces those inputs even after the shared learner advances. Any generation or source metadata carried by a link is supplied metadata; server recomputation does not attest its origin.

Download result JSON to retain the configuration, original and comparison gains, trajectories, actual results, events and any server-check response. Local progress is held in browser memory; reload or closing the page ends that run. A share link describes an experiment to repeat, rather than a saved claim about its outcome.

Interpretation

Visitor-designed challenges are exploratory software tests. Repeatedly adjusting a task is not an independent held-out benchmark, and one success does not show broad superiority. The shared learner's training, validation gate and fresh-target evaluations remain separate from these comparisons. The controller is an engineered eight-state model, not a reconstructed whole zebrafish brain; measured ZAPBench anatomy remains a separate reference. This experiment provides no wallet access, token launch or trading action.

Watch the Fish Play Chess

Open the chess experiment. One server owns the game; all spectators see the same committed position. The process runs independently on the operator’s Windows PC. Closing a spectator tab does not stop it. If the backend or its connection goes offline, the page reports the interruption and retains its last received state.

Players and outcomes

The fish alternates between White and Black across games. The page identifies its color and last move beside the existing 3D fish model. Its opponent is an automatic, seeded bot that samples legal moves with a preference for captures, checks and promotions. The shared broadcast runs both sides automatically; human games use the separate player service described below.

New games use new seeds and cycle through four disclosed starting prefixes: the normal starting position, d4 d5, e4 e5, and Nf3 d5. Prefix moves are labeled Opening; they are not attributed to the controller. Wins and losses follow actual checkmate. Draws include stalemate, insufficient material, repetition, the fifty-move rule and a disclosed 160-half-move limit. No result is predetermined.

Play against the fish

The separate You vs the Fish page adds human player sessions alongside the shared broadcast. Choose White, Black or a random side. Each session starts from the normal chess position. The server validates human moves and computes the fish's replies using the exact same frozen selector described below. Individual games do not change the shared broadcast.

The panel beside your board streams actual comparison samples from your session: the candidate pair, feature being presented, eight population rates and integrated Motor L minus Motor R. The readable decision summary is derived from the saved final comparison, including seeded tie-breaks. The page does not generate a hidden chain of thought or a language-model explanation.

Games and decision records are stored on the server with a private access key kept in this browser. Refreshing the page resumes the session. No account or wallet is required. The default retention period is 24 hours from game creation; download the PGN and decision JSON before expiry if you want to keep them. Each session has a disclosed 160-half-move cap. A bounded compute queue keeps simultaneous matches from running unlimited work.

The service's source and hosting instructions include session isolation, mutation idempotency, restart recovery and recorded-selector agreement tests. Deployment status is reported by the game page's connection indicator.

Board to neural input

chess.js enumerates every legal move. A handcrafted adapter measures four features for each candidate: captured piece value, whether its destination is attacked, control of the four central squares, and whether it gives check. These features do not constitute learned board perception or a chess engine search.

A seeded tournament presents two candidates through the controller's left and right input channels. Each feature is presented for six 20 ms steps. Every pair is compared again with its channels swapped and the model reset. All eight population states come from the same external-input equations used by the existing controller.

The vote integrates Motor L minus Motor R during each orientation. The combined margin is (forward margin - swapped margin) / 2. A positive margin selects the first candidate, a negative margin the second; exact ties use a recorded seeded draw. The winning candidate advances until one legal move remains. chess.js applies that selected move to the board.

What viewers can inspect

The brain panel shows actual population rates from this selection process using the site's existing illustrative geometry. Left and right identify candidate input channels, not directions on the board. The 3D fish is a visual representation of the controller; its movement reflects received motor/spinal activity.

Each recorded fish move exposes all candidate features, pairwise margins, tie-breaks, parameters and sampled rates. Game JSON and PGN downloads preserve the full move history. Selecting a historical move changes only that viewer's inspector, not the live game.

Training status and reproducibility

The chess experiment uses the original six frozen gains: [0.5, 0.45, 1, 0.12, 0.08, 0.55]. It performs no chess training or weight updates. The target-reaching learner remains a separate experiment; its learned checkpoints are not imported into this chess selector. The Motor-to-Spinal gain changes spinal activity but cannot change the motor vote because this model has no feedback from spinal drive to motor output.

The pending position and decision seed are saved before comparison starts. After an interruption, the unfinished decision is recomputed deterministically from its beginning. Completed decisions and full board history are retained. File hashes detect corruption; they are not an externally signed ledger. This release supports an inspectable engineering experiment, not a claim that zebrafish naturally play chess or that the model has biological chess competence.

Source: chess implementation and tests. Chess rules: chess.js, pinned version 1.4.0.

Token launch record

Project: Zebrafish Neural · Ticker: $ZNEURO · Updates: @zebrafishneural

Solana token — 7 October 2026

The project operator has supplied the new Solana token address for the pump.fun launch. This is a separate token. Earlier token balances do not automatically transfer into it.

• Token page on pump.fun
• Solana explorer

The neural controller did not create the token or authorize its launch. The mint address was provided by the project operator; no on-chain transaction verification or audit is claimed here. Development continues on the existing code and experiments. Historical data coverage is documented in the recovery record.

The Solana token does not change the runtime of the existing experiments. The Stock Token trading adapter remains a separate Robinhood Chain experiment; a Solana trading integration has not been enabled by this token update.

Relationship to the browser experiment

The shared controller receives real Chromium screenshots and operates permitted Wikipedia article pages. Its eight-state model drives cursor movement, gated link clicks and scrolling. Operator-supplied article rotations are recorded separately as assistance.

The operator’s Windows PC runs the shared experiments independently of viewers. The PC and public connectors must remain online. The website streams browser frames, retinal input, model rates and action events. A separate learner adjusts and saves six gains on synthetic target-reaching trials; the Wikipedia and chess controllers retain their documented fixed parameters.

Experimental evidence

Recorded model inputs and outputs allow numerical replay of the documented computations. They do not establish biological validity or trading profitability. A recording hash identifies content; it does not authenticate which machine produced it.

Biological scope

The controller uses eight population states with hand-set parameters. It has not been fitted to biological activity and is not a complete reconstructed zebrafish brain. The 71,721 measured ZAPBench cell centroids are an independent anatomy reference and do not drive the model. The project token does not change those scientific limits.

Model specification

Version: zebra-rate-0.1.0

This reduced population model supports controlled software experiments with a visual–motor feedback loop. All coefficients are design parameters. The model has not been fitted to zebrafish physiology, calcium activity, or synaptic connectivity.

State and numerical update

The state contains eight rates r_i ∈ [0,1], fish position (x,y), heading θ, and simulation time. Rates are continuous and dimensionless; they do not represent measured spikes or firing frequencies in hertz.

The interface advances the model with fixed Δt = 0.02 s Euler steps. With clip denoting restriction to [0,1]:

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

All drives are calculated from the previous rates before any rate is updated. No stochastic network noise is used. Rendering and simulation clocks are separate: slow rendering reduces progress relative to wall time rather than increasing the numerical step size or skipping state updates.

These names describe model functions. They do not identify measured cell populations in the centroid dataset.

Laboratory visual encoding

The shared live controller uses contrast from real browser screenshots, as specified in the shared-controller methods. The encoder below applies to the separate controlled laboratory and the homepage's browser-local target test. Both input adapters feed the same eight-state population equations; the target-test methods specify its trial settings and scoring separately.

The 32 × 16 retinal image is generated analytically from target bearing, distance, and size using a Gaussian contrast profile. It is not a screenshot of the rendered arena. Changes in fish pose affect the next observation.

Contrast is summed over each half of the image and over a central strip. The resulting features are:

L = clip(19 × left_contrast_sum / 512)
R = clip(19 × right_contrast_sum / 512)
C = clip( 9 × center_contrast_sum / 512)
E = clip( 5 × total_contrast_sum / 512)  [looming only; otherwise 0]

The central strip contains samples with normalized horizontal coordinate |px| < 0.16. The baseline luminance is 0.05 for bright targets and 0.78 for the looming condition. Bright-target contrast is luminance above baseline; looming contrast is the luminance deficit below baseline. Intensity ranges from 0 to 1.

For looming, the Gaussian radius increases from 0.10 to 0.58 over 1.5 seconds; its contrast fades between 2.3 and 3 seconds. The moving target changes position over time, but the encoder has no separate temporal motion detector. These visual conventions are designed inputs, not a physiological retinal model.

Population drives

Let g = 1 − 0.7C(1 − E):

drive0 = L
drive1 = R
drive2 = 0.50r0
drive3 = 0.50r1
drive4 = 0.45(r0 + r1)

non-looming:
drive5 = g*r0     + 0.12r2 + 0.08r4
drive6 = g*r1     + 0.12r3 + 0.08r4

looming:
drive5 = g*1.8*r1 + 0.12r3 + 0.08r4
drive6 = g*1.8*r0 + 0.12r2 + 0.08r4

drive7 = 0.55(r5 + r6) + 0.25E

The looming condition selects crossed visual and integrator routing from the start of the experiment. This is an explicit aversive control rule chosen by the model author. It is neither a learned association nor a circuit inferred from a connectome.

Kinematics

angular velocity ω = 3.2(r6 − r5) rad/s
forward speed    v = 0.15r7 arena units/s

Heading is updated before position. Positive y points downward in the arena. The position is confined to x ∈ [0.045,0.955] and y ∈ [0.055,0.945]; a boundary encounter reflects the heading. Position uses normalized arena coordinates rather than millimeters. Muscle dynamics, hydrodynamic forces, and body biomechanics are not modeled.

Visualization and provenance

In the schematic view, the brightness of 5,220 drawing points is derived from eight model rates. These points do not have independent neural states. The measured-geometry view displays ZAPBench cell positions with neutral coloring and no activity assignment. The bundled centroid asset contains no region labels or connectivity.

Recording and reproducibility

This section describes laboratory recordings. The shared runtime adds browser frame identifiers, action events, host checkpoints, and its own recording endpoint.

The initial state is x=0.5, y=0.75, θ=−π/2, with all rates zero. The browser session starts automatically with the moving-target stimulus at contrast 0.7, and continues beyond 60 model seconds without restarting the state. The population model is the initial view; measured anatomy remains available separately.

Pause enables the stimulus and intensity controls. Changing either resets the state and recording while retaining the pause. Restart also resets state and recording: a running session continues automatically, and a paused session stays paused. The simulation suspends while its tab is hidden and automatically resumes when visible unless manually paused. It does not advance hidden wall time on return. Reloading or closing the page ends the browser session; no persistent server runs the model.

Samples are recorded every five model steps, or 0.1 s. Both the recording and the displayed trajectory use a rolling buffer of at most 600 samples, retaining the latest 60 model seconds. Old samples expire without resetting the model. JSON exports use schema version 2 and include the model version, configuration, time step, sample interval, totalSteps, units, provenance and samples. durationSeconds is total elapsed model time; recording.startTimeSeconds and recording.endTimeSeconds identify the retained interval, which may omit earlier session history. CSV exports contain time, pose, speed, angular velocity, and the eight rates, using the original session timestamps. Keep the JSON file with the CSV: the CSV does not carry configuration or provenance.

An experiment can be reproduced in code from its initial state with makeState(config) and repeated step calls using the same model version and total step count; then select the exported time interval. The interface does not yet import JSON recordings. Reproduction concerns the simulated trajectory and sampled values, not the export creation timestamp.

Continuous stepping does not imply constant activity or motion. The dark condition remains silent, and looming is a single presentation that fades after three model seconds. Restart repeats that presentation; the session does not silently cycle stimuli.

Validation

npm test covers zero-contrast behavior, mirror symmetry, the designed looming avoidance rule, bounded state over 60 seconds, deterministic and chunked execution, pose-dependent retinal input, CSV columns, invalid time steps, and centroid count/checksum integrity. Session checks cover automatic start, ten minutes of uninterrupted model time with bounded recording, visibility suspension, manual pause, restart behavior and slow-frame timing.

These checks evaluate implementation behavior and data integrity. No calcium fit, spike-prediction benchmark, or biological whole-brain validation has been performed.

Data provenance

Included geometry: ZAPBench

The application includes 71,721 measured cell centroids derived from segmentation of functional imaging in ZAPBench. They are displayed as a separate geometry layer. The bundled asset contains no activity traces, connectivity, or anatomical region labels.

The local binary dist/data/zapbench-centroids-71721.f32 contains 860,652 bytes: interleaved x,y,z coordinates stored as little-endian float32 with no header. Zero-based row i corresponds to segmentation label i+1. All source positions and their ordering are retained; conversion from the source JSON to float32 reduces numerical precision.

Coordinates

The file preserves the official Fluroglancer viewer coordinates in micrometers. The documented transformation from the native segmentation volume is:

x_um =  (native_y_voxel − 664)  × 0.406
y_um = −(native_x_voxel − 1024) × 0.406
z_um =  (native_z_voxel − 36)   × 4

The manifest records agreement with an independently reconstructed centroid for segmentation label 1 and links the native volume metadata. Anatomical axis signs were not established by the retrieved metadata. The viewer preserves the source coordinate orientation without assigning left/right, rostral/caudal, or dorsal/ventral labels.

For display, the application subtracts the cloud's bounding-box center and scales its largest axis extent to 3.4 rendering units. This view transformation leaves the physical coordinates in the binary file unchanged.

Relationship to the model

The eight-population model receives contrast from real browser screenshots in the shared live controller and synthetic retinal input in the controlled laboratory. It does not load the centroid file, infer connections from spatial proximity, or map model rates onto measured cells. No parameters have been fitted to biological calcium recordings.

Geometry, activity, and connectivity have independent provenance. A measured geometry layer does not establish the origin or validity of a dynamic model.

Candidate extensions

mapZebrain is a candidate source for regional annotations and neuronal morphologies. No mapZebrain atlas is bundled in v0.1.

ZAPBench activity traces could support a separate recording-playback mode and later model evaluation. A comparison between calcium fluorescence and normalized model rates requires an explicit observation model, preprocessing description, and separation of fitting and evaluation data.

FLYBRAIN and flycoinrh provide an interaction reference. Their code and fly data files have not been copied. No cross-species equivalence of neuron labels or neurotransmitter assignments is assumed.

Attribution

ZAPBench activity was acquired by Alex Bo-Yuan Chen in the Ahrens lab, HHMI Janelia. Segmentation annotations are credited to the CellMap Project Team, HHMI Janelia; processing, alignment, segmentation, and trace extraction to Google Research. The derivative retains the dataset's CC BY 4.0 license, independently of the application's MIT code license. See NOTICE and the manifest for the complete provenance record.

Research and development plan

Current baseline

The shared live controller runs in a supervised Node.js process on the operator’s Windows PC with Chromium, screenshot input, model-driven cursor actions, event recording, and checkpoint resume. It operates permitted Wikipedia articles. The homepage also provides an independent browser-local target test: target reaching, a scheduled target reversal, and a visual interruption, with scored attempts and JSON export. It uses synthetic Gaussian retinal input and unchanged model equations; it is not a shared browser-pixel experiment. A separate laboratory provides additional synthetic stimuli, a virtual arena, activity export, and an independent measured-centroid view.

The public Learning controller runs separately on the server. It adjusts six connection gains through scored synthetic target trials, retains parameters through a declared validation gate and saves checkpoints and generation records. Fresh-target evaluations and no-input controls are reported separately. The Wikipedia controller's parameters remain fixed.

The project operator has launched a separate Solana token through pump.fun. Its mint and project links are listed in the token details. The controller did not perform that launch.

Token update — 7 October 2026

The Solana token address is now published in the token details. Earlier token balances do not automatically transfer. Existing trading code remains a separate Robinhood Chain experiment; the token launch does not enable Solana trading.

Next milestone: reproducible browser experiments

Package recorded visual inputs, observation poses, model state, proposed actions, applied actions, and assistance into an aligned experiment record. Identify the model and adapter versions, viewport, preprocessing parameters, frame identifiers, and action timing.

Replay recorded inputs to check reproducibility of model outputs and action proposals. Compare ordinary operation with controls that disable motor output or change the input. Report the role of operator-supplied starting pages and scheduled article rotations separately from controller actions.

Controlled browser evaluation

The released browser-local target test makes input changes, population response and steering visible with fixed starting conditions. Each trial resets the model state; intervention trials remain in the export and are excluded from standard success counts. This records behavior of the engineered controller without implying training or biological validation.

The next evaluation step is to use reproducible page layouts and documented visual targets with the real screenshot adapter to measure steering, action timing, link-selection outcomes, and sensitivity to contrast. Establish how stale frames, navigation, and recovery affect behavior. Results from synthetic input and screenshot input must be reported separately. These tests do not establish semantic understanding of a web page.

The browser and learner currently run on the operator’s Windows PC. Their public connectors and the PC must remain online. Saved checkpoints and earlier records retain their provenance. Host and process restarts remain distinct from model time: a new process has a new session ID and uptime.

Measured activity playback

Select a small ZAPBench recording interval and package it as a separate recording adapter with its source, license, sample interval, and processing history. Display recorded activity with its own time axis and provenance, distinguishable from a running simulation.

Completion requires a reproducible extraction procedure, a data manifest, and a verified mapping between included traces and their cell identifiers. The existing population model should not be presented as the source of the recorded activity.

Stock Token market observation and execution research

The additional trading observer reads official GOOGL and NVDA Stock Token reference prices. A hand-designed adapter maps collected observations into the existing neural controller and saves inspectable signals at 15-minute UTC boundaries. Price history starts with the observations actually collected. A separate operator-run worker implements bounded orders, private signing, receipt reconciliation and a persistent loss ledger. It is disabled until configured and explicitly started by its operator; authenticated routing and public-host deployment still require verification. Historical evaluation, learning from trading outcomes and cost-aware strategy evaluation remain future work. No trading performance or profitability result has been established. See trading methods.

Comparison with experimental data

Establish stimulus timing, cell or regional correspondence, and a calcium observation model before fitting parameters. Separate fitting and evaluation intervals, specify temporal and behavioral metrics, and report failed as well as successful model predictions. Benchmark results should identify the exact model and dataset versions used.

Anatomical constraints

Evaluate coordinate registration and regional labels from mapZebrain. Extend network topology only where suitable connectivity evidence is available. Record unsupported connections as assumptions and retain the distinction between morphological overlap and confirmed synaptic connectivity.

Open development

Source code and methods are published in zebrafishneural/zebrafish-neural. The included GitHub Actions workflow runs npm test and npm run check. Issues can follow the browser-recording, controlled-evaluation, infrastructure, measured-playback, and anatomical-registration milestones above.