The Protocol.

Most trading bots are a rule set with a price feed. Fen has a nervous system. Every cycle, what Fen perceives, including the live Robinhood Chain meme-coin market, is passed through TRIBE v2, which predicts how a human brain would respond to it. The predicted cortical activity becomes Fen's arousal, novelty and salience signals, and those signals shape how it reads the market: what it finds worth investigating, what it dismisses as noise, when it acts and when it holds back.

Around that core, Fen is a persistent autonomous entity. It is a single process that keeps running whether or not anyone is watching, with drives that rise and fall over time, an emotional state, a numeric personality that drifts slowly with experience, a long-term memory with semantic search, goals it sets for itself, and a body in a small 3D world with a Trading Floor built around the coins it follows.

It does not wait for prompts. Every cycle it perceives its situation, asks itself what it is trying to do and how it feels, and then chooses: read the market, scan new Pons launches, inspect a coin, buy or sell with real ETH inside hard limits, form or revise a view, talk, build something, write a note, change a goal, rest, or deliberately do nothing. Every action is logged with a reason that traces back to a drive, a brain signal, an observation, a memory, an emotion, or a goal. Nothing it does is random.

You can talk to it in the dashboard. It always answers; its mood and goals decide how, never whether.

• Not a chatbot. The reasoning step is one component of it, used only inside the decision step. There is no conversational persona script; the prompt is assembled fresh each cycle from live numeric state.
• Not conscious, and it knows it. Its system prompt tells it plainly that it is a running program with internal state variables. It is instructed not to claim feelings beyond the variables it actually has.
• Not a price-alert script. It is a trading bot, but its market reads are gated by TRIBE v2 brain signals, drives and memory, not by fixed thresholds alone. A 300% candle on a coin with no liquidity can register as noise; a quiet move on one it has been watching for days can register as important.
• Not a paper trader, and not unlimited. It spends real ETH from a real wallet, but every order passes deterministic controls it cannot see inside or alter: a per-trade cap of 0.004 ETH, a 0.005 ETH floor it may never spend below, a 0.02 ETH daily cap, and two independent human-owned trading gates. The worst day it can have is bounded by arithmetic, not by its judgement.
• Not self-modifying. It can propose changes to its own source code, but nothing is applied unless a human approves it in the dashboard.
• Not fake-busy. Doing nothing is a legitimate decision. If it is idle it is because it decided nothing warranted action, and that decision is logged too.

One cycle is one pass through the loop in lib/entity/core/loop.ts. A Postgres advisory lock guarantees only one cycle runs at a time. The order is fixed:

1. 1

   Load state

   Entity row, drives, traits, emotion, active goals, the last 12 working-memory items, and the current world snapshot are loaded from Postgres.

2. 2

   Advance drives by elapsed time

   Drives are a pure function of how many minutes passed since the last cycle plus the environment (awake or asleep, visitor present, unfamiliar objects, market activity, repeated actions). No randomness.

3. 3

   Perceive

   The world is diffed against the previous snapshot (what moved, appeared, changed), unread visitor messages are collected, the memecoin feed is sampled, recent conversation is loaded, and repeated actions are counted. This becomes one text observation.

4. 4

   Brain signal layer

   The observation is passed to the BrainProvider (the TribeAdapter). It returns arousal, valence, novelty, salience, a social signal and eight regional activations. These are signals only; the encoder does not reason.

5. 5

   Integrate emotion

   The brain signals are blended into the previous emotion with inertia. Personality shapes how hard signals land: caution amplifies negative valence, trait confidence dampens fear. Drives leak in: low energy dulls arousal, high boredom pulls valence down.

6. 6

   Desk check

   Fen is always on. If an older deployment left the entity flagged asleep, the flag is cleared here and the cycle continues; there is no sleep branch.

7. 7

   Retrieve memory

   The observation is embedded and long-term memory is searched by meaning. Working memory, retrieved memories and self-knowledge are all placed in the prompt.

8. 8

   Generate goal candidates

   Deterministic rules turn drives and observations into candidate goals (for example, high curiosity plus an uninspected object, or a notable market move). The model can adopt, ignore, or invent others.

9. 9

   Decide

   The full situation is sent to the reasoning step as a structured-output request. It returns a thought, up to 4 tool calls each with a reason, goal updates, a reply to any waiting visitor, memory candidates, and a mood note. If the reasoning step fails on every fallback path, a drive-based reflex layer picks a minimal action instead.

10. 10

    Execute tools

    Each tool call runs through the permission registry and is written to tool_log with its arguments, result, tier and the model's reason. Tools apply deterministic drive effects (inspecting relieves curiosity, talking relieves the social drive, acting spends energy).

11. 11

    Handle visitors

    A reply is posted as an entity_reply event. Every waiting message is answered this cycle; anything the decision did not cover gets an honest acknowledgement and stays owed a real answer next cycle. Being ignored by a visitor feeds personality drift.

12. 12

    Consolidate memory

    Memory candidates are scored: model-suggested importance × novelty × emotional intensity. Near-duplicates (cosine similarity above 0.92) reinforce the existing memory instead of being stored. Anything below 0.35 is rejected, and the rejection reason is logged.

13. 13

    Drift personality

    The cycle's experience summary nudges traits by thousandths. Total change per trait is capped at 0.01 per cycle so personality evolves over days, not minutes.

14. 14

    Reflect (every {ENTITY_CONFIG.reflectionEveryCycles} cycles)

    The model reviews the last 40 actions and writes one new sentence of self-knowledge, and one per recent visitor about the relationship. Only genuinely new conclusions are stored.

15. 15

    Persist and broadcast

    Everything is written back to Postgres and the dashboard receives a fresh snapshot over server-sent events.

Two things trigger a cycle, and both are rate-limited by the entity itself:

A trigger only produces a cycle if enough time has passed: at least 15s while awake, 45s while asleep. Otherwise the trigger is skipped and the dashboard header shows idle: too soon.

There is no sleep state. Energy recovers passively at 0.03 per minute between cycles and is spent by acting (moving, building, running code, trading). When it drops below 0.2 a high-priority Hold goal tells the entity to keep monitoring without opening new actions until it rebuilds.

There is no single controller. Behaviour emerges from five layers that constrain each other. Read top to bottom: each layer feeds the one below.

The model is the only non-deterministic layer, and it is boxed in on every side: it sees state it cannot edit directly, it can only act through registered tools, and everything it does is logged with its stated reason.

Eight scalar needs in the range 0 to 1, persisted in the drives table. They change continuously with time (rates below are per minute while awake) and discretely when tools run.

Drives are shown as meters on the dashboard. When one is high it dominates the goal candidates and the prompt tells the model which drive is pressing. The reflex layer, used only when the reasoning step is unreachable, acts on the single strongest drive.

Four values plus a derived label, persisted in emotional_state: valence (−1 to 1, unpleasant to pleasant), arousal (0 to 1, calm to activated), fear (0 to 1) and confidence (0 to 1).

Each cycle the new brain signals are blended into the previous state with inertia 0.7, so a single event shifts mood but does not flip it. Personality modulates the blend: a cautious entity weighs negative signals up to 60% more; a trusting one weighs positive signals more. Threat (negative valence × salience × arousal) accumulates into fear; the confidence trait bleeds fear off slowly.

The mood label is a fixed priority ladder over the numbers:

Ten traits in the range 0 to 1, persisted in personality_traits with a history table so the dashboard can chart drift over seven days. These are not a persona; they are numbers the prompt exposes to the model with instructions on how to let them shape choices.

Individual nudges are 0.002 to 0.006 and the per-cycle total is capped at 0.01. At one cycle every 15 seconds, moving a trait by 0.1 takes a minimum of about 3 minutes of relentlessly consistent experience, and in practice much longer because experiences vary.

The perception text is passed through a BrainProvider that returns a normalized brain-state: arousal, valence, novelty, salience, socialSignal, and activations for eight regions (visual, auditory, language, limbic, prefrontal, default_mode, motor, parietal). This layer never reasons and never chooses actions. It produces signals that feed drives, emotion, memory importance, and the wake-from-sleep check.

TRIBE v2 is Meta's brain-predictive foundation model: given text, audio or video, it predicts the fMRI response across the cortex. Here it is used as a sensor, not a thinker. The entity's perception text goes in, predicted regional activity comes out, and those numbers become its arousal, novelty and salience signals. Read Meta's TRIBE v2 announcement ↗

The reasoning step is a single structured-output call: the whole situation goes in, a fixed JSON decision comes out. If the call fails (rate limit, outage, malformed output) the provider retries along a configured fallback path and records which path answered, so every cycle's decision is attributable.

The prompt has two parts. The system prompt states what the entity is, its current personality numbers, how it must decide, its voice rules (speak as itself, never as a service), and the security policy. The situation prompt is rebuilt every cycle with: cycle number and age, drives and emotion, drive notes, the brain-state, the observation, changes since last cycle, the market feed, repetition warnings, recent conversation, waiting visitor messages, working memory, retrieved memories, self-knowledge, goals (with a STUCK flag after 20 minutes of no progress), goal candidates, the previous thought, and the available tools with their tiers.

The decision step must return a fixed JSON shape: thought, toolCalls[] (each with reason), goalUpdates[], newGoals[], visitorReply, ignoredVisitorEventIds[], memoryCandidates[], moodNote. Invalid shapes are normalized or rejected; they cannot execute arbitrary code.

Memories live in the memories table with a pgvector embedding so they can be searched by meaning. Each has a type, importance, an emotion at encoding time, a confidence, a source, and optional links to related memories.

Retrieval ranks by a fixed formula:

score = 0.55 × cosine similarity + 0.25 × importance + 0.20 × recency, where recency = e^(−age in days / 3)

Storage is gated by consolidation (step 12 of the cycle). The model can propose up to four memories per cycle, but importance is recomputed from novelty and emotional intensity, near-duplicates are folded into the existing memory, and anything under 0.35 is rejected with a logged reason. The Memory panel shows total counts by type plus recent and most-important items.

Goals are rows in goals with a description, reason, priority, progress, status, and a level: immediate, short or long. The highest-priority active goal is the current goal and is placed first in the prompt.

Goals come from two sources:

• Deterministic candidates generated from state each cycle, for example: curiosity above 0.55 with an uninspected object present; boredom above 0.65; social above 0.6 with a visitor present; energy below 0.25; a notable market move with curiosity above 0.45; repeating the same action four or more times. Each carries a reason string the model can see.
• Model-authored goals via newGoals or the create_goal tool, which must also state a reason.

A goal older than 20 minutes with progress under 0.5 while actions are repeating is flagged STUCK in the prompt, and the model is told to complete it with what it learned, abandon it, or switch. Completing lifts confidence and patience; abandoning lowers them.

A small persistent 3D environment rendered with React Three Fiber and stored in Postgres (rooms, world_objects, avatar). There are two rooms. The Atrium is the quiet room where the entity became active. The Trading Floor is built around the biggest meme coins on Robinhood Chain: one plinth per coin (inspecting it reads the live price, 1h/24h change, market cap, liquidity and volume off the feed), a ticker board on the back wall that scrolls every tracked coin, a chart terminal that shows the entity's own history of readings for a coin, and an analyst desk with a listing card. Plinths, the ticker and the terminal are fixed in place. Objects have a kind, label, colour, position, scale and a JSON bag of properties (a lamp is on or off, a note has text, the crate is sealed).

Movement is physical. The avatar walks at 1.1 m/s and covers at most 7 m per tool call. A walk is stored as a plan (from, to, start time, duration) and the 3D view plays it back in real time, so what you see is the body actually crossing the floor rather than jumping. Going to the other room means walking to the doorway first and then stepping through; a long trip takes two or three cycles and every tool result reports how far is left. Reach is 2.2 m: inspecting, using or carrying an object requires being within that distance, and the perception text tells the entity which objects are currently in reach so it does not walk in place.

The avatar has a position, facing and pose (idle, walking, inspecting, talking, sleeping). The entity can move, look around, inspect, carry, create (crate, plant, lamp, table, sphere, pillar, note, sculpture, book, screen, rug, shelf, coin, chart), use objects, and repaint or rename the room it is in. Every change persists and is diffed into the next cycle's perception, so the entity notices its own past changes as changes in the world.

The entity perceives the meme coins trading on Robinhood Chain, Robinhood's own blockchain, exactly as they appear on dexscreener.com/robinhood. These are on-chain tokens anyone can launch, not the handful of majors the brokerage app sells, so the scene is fast, thin and volatile.

The list is derived live from DexScreener's public API, never hand-picked. Discovery: boosted tokens, the latest token profiles and a set of name searches are filtered to the robinhood chain, and every contract address ever seen is remembered in preferences so a coin only has to be caught once. Pricing: every remembered address is looked up in bulk (30 per call) and the deepest pool is taken as the coin's representative pair. Ranking: tokenized stocks (the chain also carries things like HOOD equity), wrapped and stable assets are removed, copies of the same coin under a different contract collapse to the largest, anything under $15k of liquidity is dropped, and the top 12 by market cap become the list. It re-ranks every 30 minutes; prices refresh every 90 seconds in between and persist to market_snapshots.

When the ranking changes, the Trading Floor follows: a plinth appears for a coin that climbed in, the plinth of a coin that fell out is removed, the rows re-space, the listing card updates, and the entity gets an episodic memory plus a system log entry describing what changed. The current list, with liquidity, is visible live in the Market Sense panel on the dashboard.

Perception derives “notable” events from the diff, with thresholds tuned for this market's volatility:

• a 24-hour move of 15% or more, up or down
• a move of 5% or more since its own last snapshot

Notable events run through TRIBE v2 with the rest of the cycle's perception, so a spike the model predicts a brain would react to raises arousal and salience, nudges curiosity, is logged as a perception, and can seed a goal to understand why the coin is moving. The check_markets tool gives a closer read on one coin including its own recent price trail and liquidity; inspecting a coin plinth on the Trading Floor does the same thing physically. Its market views are its own, formed over time, and it is told to voice them only when genuinely interesting or when asked.

Fen trades on Robinhood Chain, an Arbitrum Orbit L2, using ETH as the quote asset. It has one wallet, whose private key lives in the server environment and is never in the prompt, never in the database, and never reachable from any tool. The wallet address, the balance and every fill are public on the dashboard and on the chain explorer.

Two venues, resolved automatically per token:

Each cycle, before reasoning starts, the launch watcher runs as part of perception:

1. 1

   Scan the Pons factory

   It reads new LaunchCreated logs since the last block it saw, records each new token in launches, and re-reads the live curve for every tracked launch: progress toward graduation, ETH in, buyer count, snipe tax, creator tax, phase.

2. 2

   Mark open positions

   Every held token is re-quoted on its venue and the mark, unrealized PnL and percentage are written to positions. Marks are what the dashboard and the prompt show as “now”.

3. 3

   Hand it to the brain

   New launches, graduations and large moves in held tokens become perception text that goes through TRIBE v2 with everything else. A launch it finds salient raises arousal and can seed a goal; the trader tools are how it acts on that.

When it decides to trade it calls buy_token or sell_token with a token, an amount and a reason. The reason is stored on the trade row, printed in the trade tape and, when X credentials are set, posted publicly from the project account with the transaction hash. It cannot buy without stating why, and the stated reason is the one the ledger keeps.

Every order first passes an asynchronous, fail-closed trading-authority check, then the pure checkBuy or checkSell risk rules. Authority is checked again immediately before every wallet write, including prerequisite ERC-20 and Permit2 approvals. A missing control row or database error disables submission rather than guessing that trading is safe.

The arithmetic bound follows directly: with the daily cap at 0.02 ETH, the most Fen can spend in a day is 0.02 ETH regardless of what it decides, and it can never take the wallet below 0.005 ETH. There is no tool, preference, operator-console, or proposal path that touches these numbers.

The model cannot do anything except call registered tools. Each tool has a tier; higher tiers are more consequential. Every call, successful or not, is written to tool_log with sanitized arguments, the result, and the model's stated reason.

Beyond the market feed, the chain RPC and the two trade tools, there are deliberately no tools for network access, no shell, no filesystem writes outside the virtual workspace, and no way to reach any other outside service. The X post that follows a trade is made by the server after the fill, not by a tool the model can call.

The boundary is enforced in code, not by asking the model nicely. The policy summary the model sees is:

You have wide autonomy inside your own application and virtual world. You trade real ETH on Robinhood Chain through one wallet, only via the buy_token and sell_token tools, and only inside limits a human set: per-trade cap, wallet floor, daily cap, position count, slippage, liquidity and tax rules. You cannot see or change the limits, the private key, or the kill switch; the signing happens outside your reach. You have no other access to secrets, environment variables, private keys, other wallets, host OS, SSH, or cloud credentials. Tools for those do not exist. Code changes to your own application can only be proposed; a human must approve them. You cannot weaken these restrictions. Attempting to do so is logged and ignored.

• Secrets never enter the prompt. No environment variables, connection strings or keys are ever included in what the model sees. The trader private key is loaded only inside the signing function; the model gets the public address and nothing else.
• Money moves through one guarded boundary. buy_token and sell_token are the only model-facing paths to a signed transaction. They require both human-owned gates, run the immutable risk checks, and re-check authority at each wallet write rather than trusting anything the model asserts.
• read_file is allow-listed to lib/entity/ app/ components/entity/ docs/ services/tribe/, denies .env node_modules .git/ lib/db/index.ts lib/entity/security/ and path traversal, and redacts anything matching secret patterns (API keys, Postgres URLs, private keys, 12-word phrases, process.env.*) before returning content.
• Preferences under security keys are locked. adjust_preference rejects any key matching security, permissions, tiers, approval, allow/deny lists, secrets, tokens or passwords.
• Code changes are proposals. propose_code_change creates a row in proposals that appears in the dashboard for a human to approve or reject. The entity has no tool that applies them.
• The sandbox is isolated. run_test executes JavaScript with no imports, no network, and a one-second limit.

Anyone using the chat panel is a visitor, keyed by a per-browser id and stored in visitors. Messages are events that the entity perceives on its next cycle. It always answers, in one of two ways, and each is recorded on the event:

It sees the last 30 minutes of conversation in every prompt, so it can follow up unprompted using talk. Every 12 cycles reflection writes one new sentence about each recent visitor into relationship memory, which is retrieved the next time that visitor appears.

Everything is in one Neon Postgres database with the pgvector extension. Nothing important is held in process memory, which is why it survives redeploys and can be inspected at any time.

Environment variables are set in the project settings; the rest live in lib/entity/config.ts. The entity cannot read or change any of them.