Inside
Fly Town.

Twelve residents, each with a job, a wallet, and somewhere to be. The Undergrowth: a natural forest floor of moss cushions, winding roots, mushrooms, fruit and a small dew pool.

Fly Town combines a shared town simulation with twelve independent neural models running on published fly connectivity. Residents move between jobs, deliver resources and maintain their habitat. The browser displays the host’s current world state and measured neural activity.

Watch a day unfold.

1. Choose a resident. Click a fly or choose a name in the Residents list. On smaller screens, open the Residents button.
2. Follow a flight. Select Follow. Drag to orbit around the subject; scroll to zoom. The home button returns to an overview.
3. Read the inspector. Mind & activity shows measured controller spikes and the current decision. Work & life shows the resident’s role, route, earnings, needs, and task priorities.
4. Visit a place. The expanded flight routes now cross a continuous mossy forest floor. Residents and buildings keep their original size. Click a place label. The Banana Bazaar opens the market; other places show their purpose and associated residents.
5. Host controls. On the local owner page, the community priority gives matching jobs a higher score when residents choose what to do next.

The host PC controls pause, priorities and job assignments. Public visitors share the same running town and can inspect any resident. Pause stops new world and neural steps; an already computing neural window may finish. Speed changes town time to 1×, 3×, or 10×; neural compute speed is independent. Trails show recent paths.

Small jobs. Real dependencies.

Each completed task changes the shared supplies or the condition of the town. Work with missing inputs waits for a delivery. Assign a different job from Work & life; a resident carrying goods finishes that delivery first.

Food is represented by a common provisioning stock: nectar and cultivated food replenish it, and the shop displays purchasable banana portions. This abstraction keeps the town’s resource loop readable.

Meet at the banana stall.

Hungry residents buy a banana portion; thirsty residents buy a dew drop. A purchase checks available stock and the buyer’s wallet before consuming supplies or moving credits. A resident who cannot afford the price returns to work before trying again.

Prices update every twelve simulation seconds. Lower stock and recent purchases increase the banana price; a fuller shelf and quieter demand reduce it. Prices stay within defined bounds. The merchant announces significant changes in a speech bubble.

The shop shows current stock, prices, and a ledger naming the buyer, seller, item, and amount. These are town-credit transfers inside the simulation. They are not cryptocurrency transactions.

Published wiring. Live neural computation.

Fly Town uses the MaleCNS v1.0 connectome from the Google Research, HHMI Janelia, Cambridge and MRC LMB collaboration. The imported graph retains 164,506 neurons with non-null type annotations and 25,135,616 connections between those neurons. These are Fly Town’s imported subset counts: the importer keeps annotated cells with non-null types and edges whose endpoints both remain. The source dataset contains additional cells. Official dataset files ↗

The connectome supplies anatomical connectivity. Fly Town supplies its own leaky integrate-and-fire dynamics, input mappings, and behavioral adapter. Google and the research collaborators contributed the anatomical reconstruction. Fly Town implements the dynamics and town integration; the project does not use a Google-published executable town AI. Twelve independent neural states run on the host PC’s GPU; their fixed connectivity is shared. Google’s account of the research ↗

What the display measures

The cell-body atlas redraws when a new measured window arrives. It shows 1,430 deterministically sampled cells at their published soma coordinates. It includes the central brain, optic lobes and nerve cord. The dots represent cell bodies, not reconstructed neuron branches or individual synapses. Bright dots identify cells that fired during the most recently completed 50 ms model window. All 22 anatomical annotation classes have measured population means, including quiet classes at zero.

Population activity is reported in Hz per neuron; the headline value is the neuron-count-weighted mean. The history chart shows the last 70 received windows and scales to their observed range. Atlas and telemetry checksums must agree before activity is displayed.

How the model affects a resident

Distance and bearing to the market, hunger, light, and gusts produce four bounded inputs: left odor, right odor, looming, and light. These stimulate mapped cell populations. The model uses a 1 ms integration step, a 20 ms membrane time constant, 5 ms current decay, 3 ms refractory period, and two-step recurrent delay.

Mapped descending-cell motor readouts and central-brain sensory activity modestly adjust travel speed and the work score. This engineered adapter does not interpret every neural circuit. Destinations, collision avoidance, food needs, jobs and resource constraints remain explicit town rules. A quiet motor readout stays zero in the model; the town does not invent neural spikes to animate it.

Weights derive from anatomical synapse counts with normalization and provisional transmitter signs: GABA, glutamate and histamine are treated as inhibitory; other and unknown labels as excitatory. These modeling choices simplify physiology. There is no fitted learning, physiological validation, or claim that the town reproduces natural fly society.

Model time and wall time

Each neural update computes 50 ms of model time. Actual compute time depends on the PC and is shown alongside the window. A short rest between neural windows leaves GPU capacity available for the town display. All twelve neural models continue to run. The town advances in wall time between updates using the latest completed neural readout. This is live, ongoing computation at a slower neural timescale, not a promise of biological real-time emulation.

Brief simulated dialogue

Residents occasionally display an intent, trade message or nearby exchange, based on their current task. Text comes from explicit rules and is labeled simulated. It is not a translation of neural signals, a language model, or evidence of human reasoning. Per-resident cooldowns keep the conversation infrequent, and no more than two bubbles are shown at once.

Official MaleCNS data and attribution ↗
Google Research’s project description ↗

Fees fund the reserve. Work circulates it.

The intended funding source is creator fees from the planned coin. The town reserve pays residents when they finish deliveries or work. Purchases circulate credits between residents and the reserve.

The reserve and all resident wallets start at zero. There are no automatic fee pulses or starting credit grants. Residents continue flying, working and producing resources while fee funding is inactive. Wages do not accrue while funding is pending, and purchases require funded credits. Once funding is configured, if the reserve cannot fund a full wage, only the available amount is paid, and the unfunded amount is reported. Balances cannot become negative.

Income is conserved: the reserve plus all resident wallets equals the credits introduced into that session. Shop trades redistribute existing credits. They do not create money.

Fee funding has not started. Once active, accepted receipts will add credits at a published conversion rate. Pausing or reconnecting the reader will preserve funded balances. The treasury is an observation view: visitors can inspect balances and receipts, while the operator manages funding privately. The reset control cannot erase a funded ledger.

Funding through verified fees.

The planned funding source is Pons V2 creator fees on Robinhood Chain. This integration is not active. The operator manages it privately; visitors observe the town treasury, resident balances and accepted receipts.

The source currently includes a read-only ERC-20 transfer reader prototype. Production fee funding still requires coin-specific attribution, a verified payout adapter and durable receipt recovery. The prototype is not enabled as a funding source.

Pons documents quote-asset fee escrow and separate credit and claim events. An escrow credit is distinct from funds received in the town wallet. A recipient’s fee balance can combine multiple launches, so attribution must identify which receipts belong to this project. Pons V2 fee documentation ↗

The planned observer reads on-chain receipts without private keys, transaction signing or fund transfers. Network credentials remain on the host and are not published to visitors. Existing town checkpoints preserve accepted credits and recent receipts; the complete production recovery path is still pending. The public interface reports actual recorded balances, including zero when nothing has been received.

Robinhood Chain network documentation ↗
Alchemy event-log documentation ↗

Hosted on the owner’s PC.

A single Node server owns the residents, prices, inventories and balances. A separate Python worker computes the twelve connectome states on the GPU. Visitors receive current snapshots several times per second through a read-only HTTPS connection. Their browsers render the 3D scene and do not run separate town simulations. A 1.05-second motion buffer interpolates between received positions so movement, the follow camera, cargo and speech share one smooth visual timeline. It does not predict motion beyond the latest snapshot. Takeoff and landing speeds are bounded to avoid abrupt vertical bursts. The scene batches static geometry by material, uses a bounded rendering resolution, and avoids live shadow passes. Motion snapshots preserve full-precision balances and measured activity while compacting only display coordinates and trail samples. Hidden tabs request updates less often.

The town continues when a visitor closes the page, provided the host PC, neural worker and tunnel remain running. Sleep, shutdown, an internet outage or stopped services make the live feed unavailable. Visitors then see the last received state labeled offline. With no previous state, they see a waiting screen. There is no synthetic activity fallback.

World checkpoints are saved every ten seconds and on a normal shutdown. They preserve jobs, supplies, balances, market history and positions. Neural states start afresh when the server restarts; they are not currently checkpointed. The static website is deployed on Vercel. Live state reaches it through a temporary Cloudflare tunnel from the host PC. This initial hosting setup depends on the PC remaining awake and online; restarting the tunnel changes its address. The provided startup command republishes the new address to Vercel.

Public endpoints expose snapshots and health only. Pause, speed and job assignment are restricted to the local owner page on the PC. Funding is managed privately by the operator. Visitors can still choose, follow and inspect every resident, orbit the scene, and open the market or guide.

The nursery, shelter condition and exploration score are town-management values. The town has twelve residents. Birth, death, reproduction, calibrated aerodynamics and biological learning are not modeled. Town credits are internal ledger balances and do not confer a claim on the fee wallet.

The source includes the shared server, neural worker, bounded graph importer, procedural town, economic rules and checks. Official graph data and local runtime packages are downloaded separately; private settings and runtime checkpoints are excluded.

Trace the data. Inspect the implementation.

The research sources below establish the anatomical data and its provenance. The Fly Town source and checks describe how this project imports that data and runs its own model. Neither source type establishes biological validity for jobs, dialogue or a fly economy.

Research and data

1. MaleCNS project overview — the official collaboration, reconstruction scope and release information.
2. MaleCNS v1.0 downloads — the annotation, connectivity-weight and neurotransmitter-prediction files used by the importer.
3. MaleCNS research publication in Cell — the primary publication associated with the reconstruction.
4. Google Research’s project article — Google’s contribution to the anatomical mapping effort.

What you can verify in Fly Town

The downloadable source includes the importer, neural dynamics, worker, town model and checks. The import manifest records source URLs, raw-file SHA-256 hashes, the retained subset and the generated graph checksum. These project-generated records identify the data used by this build; they are reproducibility evidence, not an independent evaluation.

Imported graph: 164,506 retained neurons, 25,135,616 weighted connections, representing 122,318,556 anatomical synapses. The number of weighted edges differs from the synapse count because an edge can aggregate multiple anatomical synapses.

Chain integration references

The Pons public source repository ↗ provides the corresponding implementation reference.

1. Pons V2 contracts and fee escrow — reference for the planned creator-fee integration; the project’s fee funding is not active.
2. Robinhood Chain connection documentation — the network configuration and supported RPC access.
3. Alchemy Robinhood Chain log API — the read-only event retrieval method used by the receipt-reader prototype.

Sources reviewed for this documentation on 10 September 2026. Integration status is shown separately in the town treasury; links to launchpad documentation are not evidence of received funds or a deployed Fly Town coin.