docs › Memes and narratives (experimental)

Memes and narratives (experimental)

Groups coins by the theme their name and ticker carry, and measures each theme's heat per window. Measured heat, not advice.

A memecoin does not need a real project to run. It moves on a theme: a ticker pun, an animal, a celebrity, an AI-agent craze, a holiday, or simply being a copy of a coin that just ran. The narratives tracker groups coins by that theme and measures how hot each one is right now. It is experimental, keyless and local. It adds no network requests, because it reads the history recorder, and it never calls a model. Everything it shows is measured heat from recorded market data, not advice and not a prediction.

Where to find it#

• The N screen opens the narrative board. Press n to switch between the theme board and the NARRATIVES heat table. enter drills into a narrative's member coins; esc goes back to the table.
• The token screen shows a Narrative row once the tracker has been built (open N then n first), for example ZORP · lifecycle: ignition · rank 3 · #2 of 9.
• dexterm narratives prints the heat table. dexterm narratives detail ID shows one narrative, dexterm narratives of MINT shows the narrative of one coin, and dexterm narratives export --out FILE writes the JSON (dexterm-narratives/1) for your own tools. --at ISO replays up to a past time.
• MCP tools for your analyst or your own agent: narratives_top, narrative_detail, narrative_of (observe tier, read-only). Coin names come back wrapped as untrusted data.
• Watch rules: the field narrative_rank and the tags narrative:ignition / narrative:saturated, so a rule can fire "when the coin's narrative ignites".

How coins are grouped#

1. Normalise the name and ticker (and the description or social handles when the data layer has them): leetspeak (Z0RP), repeated letters (ZOOOORP), camelCase (ZorpWifHat), emoji (🐸 → frog), glued tickers split against a vocabulary learned from other names (BABYZORP → baby + zorp), and copy-cat affixes (BABY, MINI, 2.0, INU, AI) kept as weak words so "Baby X" lands next to X.
2. Embed each coin with a local model. The default is built in: a hashed vector of the meme words, their letter trigrams and the lexicon themes (dogs, politics, ai-agents, holiday-seasonal, …). An optional small open model, all-MiniLM-L6-v2 on CPU through transformers.js, or any local Ollama embedding model, adds meaning links such as kitty to cat (DEXTERM_NARRATIVE_EMBEDDER=minilm or ollama).
3. Cluster incrementally in first-seen order. A coin joins the closest narrative it shares a meme word with (or, with a semantic model, a currently hot one) if it is close enough to that narrative's centre and to the coin that started it. Otherwise it starts a new narrative. Ids are stable (nar_…) and narratives never merge or split afterwards. The label is the most common word or two-word phrase.

What is measured#

Per narrative and window (5 m, 1 h, 6 h, 24 h): coins seen, new coins and the new-coin rate, the narrative's share of all tracked volume, unique traders (1 h, Jupiter) and their growth, the top runner (sellable pool of at least 10k USD) and its drawdown from its peak, how often the same meme word was relaunched in the last hour, and a 0-100 traction score (1 h volume growth, spawn rate, repeated-name velocity, share of new-coin volume, breadth). Rank 1 is the highest score. Cross-coin holder overlap is not recorded, so it is not part of the score (it shows as null, never estimated).

Lifecycle, first rule that matches:

Copy-cat saturation (* in the table): at least 5 coins, at least 3 of them new in 6 h, and the coins after the 3 oldest together hold under 25% of the narrative's 1 h volume. The copies are launching, but they are not getting the volume.

What testing showed#

We replayed 11 days of dexterm's recorded history (219,730 coins) through the tracker in time order, reading each coin's narrative at the first moment a scanner could act on it (point in time: nothing recorded after that moment), and tested it on days that were held back until the end, the same way as dexterm's other entry research.

• It is a useful map of what is running, not an edge. On the held-back days, adding the narrative to a coin's own numbers did not help tell apart the coins that later tripled (ranking quality fell slightly, by 0.022 (95% interval -0.059 to +0.008)) or the ones that drained (fell by 0.033 (-0.052 to -0.015)).
• None of the narrative gates we fixed in advance improved paper results when added to the existing entry rules: joining an igniting narrative early, skipping the 5th or later copy of a saturated narrative, and skipping fading or dead narratives. In the 22 combinations of these gates and rules with at least 20 paper entries, none raised the average result per entry and three lowered it. (One more gate, added after looking at the earlier days, is reported apart; its 5 combinations moved nothing either way.) Every gate also skipped some of the coins that went on to run.
• What it does describe: a coin that is part of a narrative (two or more coins) drained within 6 hours about twice as often as a coin on its own (about 50% against 27% on the held-back days), and also tripled a little more often. Copy-cat waves are where both the runs and the drains happen. The lifecycle states themselves did not sort the outcomes: the share that later tripled was 4% to 6% in every state.
• In a hand-graded sample of 100 narratives, 70 were coherent (one meme and its copies, or one theme) and the label named the theme in 87. The usual mistakes: the same ticker reused for an unrelated coin, and a shared generic word.

Every number above comes with its sample size and a 95% interval in the study; the narratives table is a way to see what is running, and the numbers say it should not be read as a reason to trade.

Limits#

• Name-based: themes that live only on X or Telegram are missed until a coin's name carries them.
• Volume is each source's rolling window at the coin's newest sample; a coin not sampled for 6 h counts as zero.
• Two themes that converge later stay two rows (ids never change).
• The first build of the table reads the last 26 h of recorded history: tens of seconds on a large database (the screen stays live meanwhile).