With no new trade, the market signal decays and the fly falls back toward a loose baseline sway. Nothing is generated just to make the page look busy.
Buy → reward + motor drive. Large buy → stronger reward surge and a more explosive dance. Sell → aversion + caution. Large sell → rejection spike and a defensive kickback. The mapping is fixed; only the real trade stream chooses when and how strongly it happens.
DANCE FLY is one simulated fruit-fly brain connected to one live crypto market. Every buy and sell becomes a stimulus. Reward, aversion, motor and rejection signals rise and decay according to real trading activity, changing how the fly moves.
A buy raises the reward and motor-drive channels. A sell raises aversion and rejection. Each trade is given a relative intensity based on its size compared with that token's recent trade distribution. That intensity changes the amplitude, speed, wing motion, leg motion and recovery time of the dance.
The fly does not trade. It does not own the token. It does not make decisions. It only responds to market activity.
The browser first checks Robinhood Chain directly for a Pons V2 launch. If it finds one, it reads CurveBuy and CurveSell events directly from that token's bonding-curve contract. For other tokens, or after indexed liquidity is available, it can fall back to the token's most liquid GeckoTerminal pool. Existing trades are seeded as history so old transactions do not replay as new inputs.
Pons V2 tokens use direct on-chain event polling for fast reactions. The generic GeckoTerminal fallback is real-data driven but may lag because its public API is cached and rate-limited. No simulated trades are generated when either feed is quiet.