product updates: march 17, 2026

five major areas today: a new watchlist tab showing what the agent is considering before it trades, CoinGecko WebSocket integration for real-time trade flow data, a complete scanner overhaul fixing sorting and deduplication, critical entry price accuracy fixes, and a reorganized agent dashboard. here's everything.

---

watchlist tab: see what the agent is thinking

the agent card now has a watchlist tab showing every token that scored high enough to be considered for a trade. previously this data was invisible — the agent scanned tokens, scored them, and either traded or moved on. you never saw the "almost" tokens.

now you do.

each watchlist entry shows:

the watchlist updates every scan cycle. click any token to open the chart view. the data is ephemeral — it resets each session to keep things fast.

this makes the agent's decision process transparent. you can see the pipeline: scanner (raw tokens) → watchlist (scored candidates) → positions (traded).

---

coingecko websocket integration: real-time prices and trade flow

parasol now connects to CoinGecko's WebSocket API for two real-time data streams.

G1: OnchainSimpleTokenPrice — secondary price source

CoinGecko's G1 channel streams real-time price, market cap, 24h volume, and 24h price change per token. it sits between Birdeye (primary) and Jupiter (fallback) in the price hierarchy:

if Birdeye misses a price update, CoinGecko catches it. if both are down, Jupiter polling takes over. three layers of redundancy for position pricing.

G2: OnchainTrade — live buy/sell trade flow

this is the bigger one. CoinGecko's G2 channel streams every individual buy and sell transaction for a pool in real-time (as fast as 0.1s updates).

parasol subscribes to G2 for all open position pools. every trade is accumulated in a 5-minute rolling window and summarized as:

this data is surfaced in the watchlist tab as a trade flow bar — a visual green/red ratio showing buy vs sell pressure in real time. no more relying on stale hourly buy ratios from static API snapshots.

the integration is graceful: without a CoinGecko Pro API key, everything works exactly as before. add NEXT_PUBLIC_CG_PRO_API_KEY to activate it.

---

scanner overhaul: sorting, deduplication, and performance

the token scanner had three compounding bugs that made it appear broken. all three are fixed.

duplicate tokens from dual-scan merge

agents like Sienna run a dual-scan: PumpFun sources and DexScreener sources in parallel, then merge the results. the merge was concatenating both token lists without deduplication. the same token appearing in both scans would show up twice (or more) in the scanner — "GORK" appearing 4 times, "Gany" appearing 6 times.

fix: tokens are now deduplicated by address when merging. a secondary dedup in the store catches any edge cases that slip through.

stale data persisted in localStorage

lastScanTokens was being saved to localStorage. old duplicated data from before the dedup fix survived page refreshes, mixing old (broken) scan data with new (clean) scan data. this made sorting appear even more broken — the table was rendering tokens from multiple sessions.

fix: scan tokens are no longer persisted to localStorage. they're ephemeral data that refreshes each session. a store version migration clears the stale data on first load for existing users.

NaN values breaking sort comparisons

some tokens had null or undefined values for market cap, volume, or price changes. JavaScript's Array.sort() produces inconsistent results when comparing NaN values. combined with an unstable useMemo dependency (a new {} object created every render for the livePrices default), the sort was re-computing and flickering unpredictably.

fix: all sort comparison values are now sanitized through a toNum() helper that returns 0 for any non-finite value. the livePrices default is a stable module-level constant. the scanner object is memoized to prevent unnecessary re-renders.

---

critical entry price accuracy fix

entry prices on the chart were not matching the actual trade execution price. this was causing false stop-loss triggers and incorrect P&L display. the root cause chain was:

1. SOL price was wrong on the server

getSolPriceEstimate() only tried Jupiter's API. when that failed (rate limits, missing key), it fell back to a hardcoded $150 — but SOL was trading at ~$93. every USD-based calculation was inflated by ~60%.

a trade of 0.0765 SOL would show as $11.47 (at $150/SOL) instead of the real $7.18 (at $93/SOL). this inflated positionSizeUsd, which inflated the calculated fill price, which triggered immediate false stop-loss exits.

fix: getSolPriceEstimate now tries Jupiter, CoinGecko, and Binance in sequence, with a Supabase cache fallback and a conservative $100 hardcoded last resort (down from $150).

2. Jito bundle IDs were used as transaction signatures

PumpFun trades via Jito bundles return a bundle ID, not a Solana transaction signature. the fill price calculator was trying to look up this bundle ID as a transaction — which always failed, forcing a fallback to stale scan-time prices.

fix: Jito bundle IDs are now resolved to actual transaction signatures. the fill price calculator parses the confirmed transaction's pre/post token balances for exact fill amounts.

3. token decimals were hardcoded

the balance-check fallback assumed all tokens had 6 decimals. tokens with 9 decimals (most SPL tokens) got their balance divided by 1,000x too little, producing absurd fill prices.

fix: actual token decimals are now fetched from on-chain mint data.

4. client-side safety net

even with all server-side fixes, a client-side safety check now rejects any server fill price that's more than 50% off the scan price. if triggered, it falls back to the scan price and logs the discrepancy.

---

agent dashboard reorganized

the tab order in the agent card now follows the natural decision flow:

positions → watchlist → scanner → history → activity

previously: positions, history, activity, scanner. the new order puts the most frequently checked data first and the least-used data last.

---

sienna quality filter rebalanced

after the last update lowered Sienna's entry thresholds to help her find more setups in quiet markets, she started opening rugs. the filter was too loose.

the original thresholds were strict — minCompositeScore: 0.16 and minBuyRatio: 0.62. these filtered out nearly everything in quiet markets. we dropped them to 0.12 and 0.55, which found setups but also let low-quality tokens through.

the new values split the difference:

composite score 0.14 — tokens need a reasonably strong combined signal across momentum, volume, and technical indicators. not as demanding as 0.16, but enough to weed out the rugs that slipped through at 0.12.

buy ratio 0.58 — requires that ~58% of recent transactions are buys. at 0.55 too many tokens with near-neutral or manipulated flow were getting through. 0.58 requires meaningful buying conviction without demanding near-perfect pressure.

these thresholds are easy to nudge. 0.15/0.60 if she's still catching rugs. 0.13/0.56 if she's filtering too aggressively. the new watchlist tab makes this visible — you can see exactly what she's considering vs what she's filtering out.

---

summary

15 commits. 5 bug fixes. 3 new features. 1 tuning adjustment. the agent is now more transparent, more accurate, and better filtered.