Chapter 9

Call lifecycle

A call is created once and then lives for months. This chapter is what happens in between: how a peak is verified before it counts, how a dead call is put on a slow sweep instead of being deleted, and what the ledger does when it fills up.

9.1Peak verification

The win rate is only worth reading if the peaks behind it are real. Market data is noisy — a thin pool, a bad tick, a provider disagreeing with itself — and a single wrong reading can mint a 40x that never happened. Four rules stand between a reading and a recorded high.

Rule	What it does
Entry is the floor	A call's peak can never be below the market cap it was called at. The post-call high starts at 1.00x, never lower.
A big jump needs a second look	A reading far above the current peak is not written on the strength of one tick. It is held as a pending peak; the next refresh either corroborates it — and the lower of the two readings is recorded — or the pending value is discarded.
Lifetime ATH ceiling	A reading meaningfully above the token's known lifetime all-time high is rejected outright. A token cannot quietly exceed its own record on a single tick.
Retroactive audit	When a lifetime-ATH figure arrives later, existing peaks are re-checked against it and clamped down if they are impossible.

Unverified peaks

A peak that has not cleared these checks is marked unverified, and the card says so: a $1.2M peak is held pending verification — not counted. While unverified:

The call is credited with its current market cap instead, never the disputed figure.
It cannot count as a win.
It raises no milestone or new-high alerts.
It is excluded from the backtest entirely.

This is deliberately the pessimistic direction. An unverified peak makes the scanner look worse than it might be, which is the only safe way to be wrong about your own track record.

Where a peak came from

Every recorded peak carries its provenance:

Source	Meaning
entry	Still at the market cap it was called at — it has never made a new high.
live	A normal reading inside the jump tolerance.
confirmed	A large jump corroborated by a second reading.
clamped	An impossible peak pulled back to the lifetime ATH.
gmgn	A lifetime-ATH figure that arrived from the provider and exceeded what was recorded.

9.2Dormancy and re-signalling

Most calls die. Re-pricing a dead call as often as a live one is wasted effort, but deleting it would erase evidence — so calls fall asleep instead.

Transition	Trigger
Goes dormant	The call has fallen well below its entry and is past its first hour. The grace period exists so a call that dips hard in its opening minutes is not written off.
Stays dormant	Refreshed on a slow sweep instead of every cycle. The card shows a dormant badge and ·30m beside its Now figure, so you can see the number is not live.
Wakes	The price recovers back above that line. Normal cadence resumes and a waking alert fires.
Re-signals	The scanner tiers the token STRONG BUY again. The dormant call wakes and is stamped re-signalled — no second call is created.

Why re-signalling is not a new callA second call at a lower entry would hand the ledger a cheap win: the same token, credited twice, the second time from a better price. One token, one entry, one grade. The re-signal badge tells you the scanner would call it again today, which is useful information — but it does not reset the record.

Dormant calls stay in every statistic. They are the losers, and a win rate that quietly stopped counting its losers would not be a win rate.

9.3Losing the pair

When a refresh finds no trading pair for a call, that is counted as a miss. Several consecutive misses and the call is flagged no live pair: the card switches its Now label to Last seen, and an alert fires once.

One miss is usually a provider hiccup, which is why a single one never flags a call. A run of them usually means the token rugged or was delisted. One successful reading clears the flag and resets the counter.

The board footer summarises this across the ledger: Market-cap status · 12 dormant skipped · 3 no live pair · 1 feed failure · 2 peaks under review. Feed failures are the provider failing, not the token — those are not counted as misses.

9.4Retention and retired calls

A ledger holds up to 1,000 calls. Past that, room has to be made, and the rules for who goes are narrow on purpose.

Only dormant calls are eligible. An active call is never evicted, and neither is a fresh loser still inside its dormancy grace hour.
Wins are permanent. A call that reached 2x is never evicted, however dead it is now — a call that ran to 5x and gave it all back is a win sitting at 0.1x, not dead weight.
Second chances go first. Among dormant calls, ones that already re-signalled and went dormant again are evicted before ones that never got a second chance; after that, oldest first.

The retired counter

Evicted calls still happened, so their totals are kept: how many there were, how many were wins, and the sum of their peak multiples. Those figures are folded back into the win rate and average ATH shown on the board, and the Calls stat notes +n retired.

Why the denominator is protectedOnly non-performers are ever evicted. If their records simply vanished, every eviction would nudge your hit rate upward — the ledger would grow more flattering the longer you used it. Keeping the totals is what stops that. The note is hidden when a chain filter or search is active, because retired totals have no per-chain breakdown and would be compared against the wrong population.

9.5Dismissing, clearing and allowing again

Three controls remove calls, and all three do something more than delete — they retire the token, so a later scan does not immediately log the same call again.

Control	Does	Requires
Dismiss (✕ on a card)	Removes that one call and retires its token.	Pro / Edge
Clear	Removes every call, and retires every token that was in your ledger plus every token currently on the board — otherwise the next scan would refill the ledger within seconds.	Pro / Edge
Allow them again	Clears the entire retired list. Any of those tokens that still signals a Strong Buy can be logged as a new call.	Pro / Edge

The footer keeps the count visible — 14 tokens retired by dismissal or Clear — so a suspiciously quiet ledger always has a stated reason. Both destructive actions confirm first.

9.6The free-plan ledger

Public visitors and Lens (free) users share the same browser-local ledger. Nothing is stored on the server; the calls live in that browser's own storage and are sent up only to be priced, never to be kept.

Behaviour	Free (Lens)	Pro / Edge
Where calls live	this browser only	your account
Capacity	30	1,000
When full	oldest dormant call is dropped; if none are dormant, new calls are missed	eviction rules in 9.4
Peak verification, dormancy, re-signal	yes	yes
Dismiss · Clear · retire	no	yes
Alerts persisted between sessions	no	yes
Backtest and band hit rates	no	yes

The consequences worth knowing: clearing your browser data erases the ledger, a second device has its own separate one, and with all 30 slots active a genuine Strong Buy can be missed entirely. See Chapter 11.

AlgoLens user manualChapter 9 · Call lifecycle