Fomi

Most trading dashboards show you an outcome, a balance, a chart, a list of fills, and ask you to trust it. Fomi is built the opposite way round. Every stage of the pipeline publishes its intermediate state, so the reasoning that produced a position is visible alongside the position itself. When the agent declines an opportunity, that judgement is recorded with the same weight as a decision to act.

The system runs a continuous loop. A market-wide scanner surfaces candidates. A data layer resolves each candidate into a normalised set of market metrics, an analysis engine screens those metrics against hard constraints, a reasoning model forms a thesis on what survives, a risk framework decides whether and how much to commit, and an execution layer routes any resulting order across Solana liquidity venues. Portfolio state is then reconciled directly against the chain.

  ┌──────────────────────────────────────────────────────────────┐
  │  DISCOVERY                                                   │
  │  Program-level websocket  →  instruction decode  →  mint      │
  └───────────────────────────────┬──────────────────────────────┘
                                  │  candidate stream
  ┌───────────────────────────────▼──────────────────────────────┐
  │  MARKET DATA                                                 │
  │  Momentum ranking · depth · flow · holder distribution        │
  └───────────────────────────────┬──────────────────────────────┘
                                  │  normalised metrics
  ┌───────────────────────────────▼──────────────────────────────┐
  │  ANALYSIS          structural screen → survivors              │
  │  REASONING         thesis · conviction · tags                 │
  │  RISK              sizing · concentration · exposure caps      │
  └───────────────────────────────┬──────────────────────────────┘
                                  │  intent
  ┌───────────────────────────────▼──────────────────────────────┐
  │  EXECUTION         route discovery → best path → settlement   │
  └───────────────────────────────┬──────────────────────────────┘
                                  │  confirmed fills
  ┌───────────────────────────────▼──────────────────────────────┐
  │  ACCOUNTING        positions · cost basis · realised P&L      │
  └───────────────────────────────┬──────────────────────────────┘
                                  │
                          event bus  →  live clients

Each layer is replaceable in isolation. The discovery layer emits a mint address and nothing else; the market data layer neither knows nor cares how a candidate was found. The reasoning model receives a flat set of metrics with no reference to their source. This separation is what allows the discovery transport to be swapped, between a decoded instruction stream and a raw log subscription, without a single change downstream.

A listings API tells you a token exists after someone has already indexed it. Fomi subscribes directly to the launchpad program on Solana and reacts to the instruction that creates the market, which puts detection ahead of every downstream index.

1. 01

   Program subscription

   A persistent websocket subscribes to the token launch program. The connection carries a watchdog on the initial handshake, exponential reconnect backoff to a 30-second ceiling, and an application-level keepalive on transports that require one.

2. 02

   Instruction decode

   The creation instruction carries the token's name, symbol and metadata URI in its own Borsh-encoded payload. Reading them directly off the instruction avoids a metadata round-trip per launch and makes the identity available in the same tick as the mint.

3. 03

   Mint resolution

   The mint address is resolved from the token program's initialise instruction, covering both the classic token program and Token-2022. Where the parsed transaction omits it, the address is taken from the creation instruction's own account list, so no launch is silently dropped.

4. 04

   Metadata enrichment

   Off-chain metadata, artwork and any social attestations, resolves asynchronously and patches the record in place. The candidate is published on first sight rather than waiting for content-addressed storage to respond, so nothing is delayed by a slow gateway.

5. 05

   Deduplication

   Mints are deduplicated in-process against a bounded working set, and again at the storage layer, which is keyed by address. A launch can be observed twice and recorded once.

The analysis engine reasons over a fixed schema. Whether a candidate arrived from the launch stream or from the momentum ranking, it is reduced to the same fields before anything looks at it. This is what makes decisions comparable across sources.

Rate discipline

Market data is drawn under a strict request budget. All calls pass through a single serialised queue paced beneath the provider ceiling, with the queue parking on the provider's own reset timestamp if a limit is reached rather than retrying blindly. Batch endpoints are preferred wherever one request can answer for a hundred tokens. Expensive per-token calls are reserved for candidates that have already survived screening.

The practical effect is that load shed under pressure degrades into slower rather than wrong: a saturated window defers enrichment to the next pass instead of returning a partial or stale metric set into a decision.

Reasoning is expensive and should not be spent on candidates that fail on arithmetic. The screen removes anything that cannot be traded well regardless of narrative, and it runs first.

Candidate selection

Survivors are drawn from the top of the market-wide momentum ranking. Selection within that pool is randomised rather than ordinal: walking the ranks in order would produce a stream dominated by whatever sits at the top for hours at a time. Randomised sampling across the pool, combined with the per-token cooldown, gives broad coverage of the active market.

Position events take priority over the sampling loop. When the portfolio changes, the affected token jumps the queue and is analysed in the context of the position just taken, the agent accounts for its own exposure before it looks for new ideas.

Screened candidates are passed to Claude Opus 5. The output is constrained to a schema, so the response is a typed verdict rather than prose to be parsed, and the structural screen ahead of it means the model only ever sees candidates worth the call.

{
  thought      string    the written thesis, in the agent's own voice
  decision     buy | watch | skip
  confidence   number    0 to 1, conviction in the call
  size_sol     number    intended commitment, denominated in SOL
  tags         string[]  the factors that drove the decision
}

Grounding

The model is instructed to reason strictly from the metrics supplied and never to introduce a figure it was not given. Every thesis is stored alongside the exact market capitalisation, liquidity and volume that were on the table at the moment of the call. A thesis can therefore be audited against its own inputs after the fact, the record shows not only what the agent concluded, but what it knew.

Tags

Each verdict carries a small set of labels naming the factors that actually drove it, thin liquidity, momentum, overextension, early flow. Tags make the reasoning stream queryable in aggregate: patterns in what the agent rewards and what it rejects become visible across hundreds of decisions rather than one at a time.

A verdict is an opinion about a token. It is not, on its own, a decision about the portfolio. The risk layer sits between them and evaluates each intent against the book as a whole.

These are portfolio-level constraints, evaluated at decision time. A high-conviction thesis on a token where the book already carries heavy exposure produces a smaller commitment than the same thesis on an unrepresented name, the framework reasons about marginal risk, not absolute attractiveness.

Solana liquidity is fragmented across dozens of venues, constant product pools, concentrated liquidity ranges, order books and launchpad bonding curves, and the best price for a given size is rarely on a single one of them. Jupiter is the aggregation layer that resolves this: it searches across venues and returns the route that maximises output for a given input.

1. 01

   Route discovery

   The aggregator computes candidate paths between the input and output mint across every integrated venue, including multi-hop routes through intermediate assets where splitting improves the result.

2. 02

   Path selection

   Routes are ranked on output net of price impact and fees. Large orders are frequently split across several pools, because the marginal price on a single pool deteriorates faster than across a set of them.

3. 03

   Slippage bounds

   Every order carries a minimum acceptable output. If the route cannot be filled within that bound the transaction fails rather than settling at an unacceptable price, a bounded failure is preferable to an unbounded fill.

4. 04

   Priority fees

   Orders carry a compute-unit price so they remain competitive for block inclusion under congestion, where a correctly priced order settles and an underpriced one expires.

5. 05

   Settlement & confirmation

   The transaction is submitted and tracked to confirmed commitment. Only confirmed fills enter the accounting layer; an unconfirmed transaction never contributes to reported position or P&L.

The portfolio is not a ledger of what the agent believes it did. It is a reconciliation of what the chain says happened. Balances, fills and marks are read back from on-chain state and the published position is derived from that reading, so an order that partially filled, failed, or settled at a different price than expected is reflected exactly as it occurred.

Cost basis is computed over the entire fill history rather than a recent window. On an account with a long history the two differ substantially, and a basis derived from a truncated window produces a P&L figure that is confidently wrong, the failure mode is silent, which is what makes it worth stating.

Anything that happens at a moment in time, a market being created, a thesis being written, the agent changing state, is pushed to connected clients over a persistent event stream as it occurs. Anything derived from periodic upstream reads is polled on a slow interval, because there is no event to push.

Delivery under load

The dashboard payload is assembled once per interval and shared across every connected viewer, rather than rebuilt per request. Responses are compressed once per build and served pre-encoded, with entity tags allowing an unchanged payload to be revalidated instead of retransmitted. Push-triggered refreshes are jittered so a single market event does not produce a synchronised request spike across all connected clients.

Newly created markets are high-volume and short-lived in relevance: a launch matters for minutes. They are held in an in-memory store with a five-minute expiry and are never persisted , the feed is a live window, not an archive, and it reconstructs itself continuously.

Everything with lasting analytical value, every thesis, every fill, position history and valuation series, is persisted permanently. The reasoning record in particular is append-only: a thesis is never revised after the fact, because a decision record that can be edited is not a record.

Failure behaviour

Every external dependency is treated as unreliable. The discovery websocket reconnects with exponential backoff and a stalled handshake is force-closed rather than left hanging. Market data rate limits defer work to the next pass instead of returning partial metrics. Cache failures degrade to direct reads rather than propagating an error. Background work is held under a lease, so horizontal scaling adds serving capacity without duplicating the agent.

The invariant throughout: a degraded component reduces throughput, never correctness. The system will do less rather than do something wrong.