← All Guides

How BaseBubbles Ranks Tokens

Published 2025-01-01 · Updated 2026-08-10

Every ranking embeds choices, and you deserve to know ours. This page documents exactly how BaseBubbles builds its token universe, where each number on the site comes from, how the risk score is computed factor by factor, how sector tags are assigned, what the bubbles' size and color actually encode, and — just as important — what the system deliberately does not do. Nothing here is secret sauce: the pipeline is a set of engineering decisions, each with trade-offs, and this guide walks through all of them in plain language.

Transparency is the point. Most crypto dashboards ask you to trust a number without telling you how it was made. We think that is backwards, especially on a chain like Base where hundreds of new tokens launch daily and the gap between a healthy market and a trap is often visible only in structural data. When you understand precisely how the bubble map is assembled — which sources feed it, how often it refreshes, what the risk score can and cannot see — you know exactly how much weight each badge, rank, and score should carry in your own process.

One commitment up front, because it colors everything else: no payment of any kind influences the data pipeline. Rankings, risk scores, sector tags, and bubble sizes are computed from public market data only. Sponsor placements on the site are sold separately, rendered separately, and always carry a visible label. DexScreener boosts — paid visibility on a third-party platform — are displayed as a neutral badge and never affect any score or rank.

Where the Data Comes From: Two Layers, Two Jobs

BaseBubbles runs on two upstream sources, each doing the job it is best at. DexScreener's public API supplies the live market layer: trading pairs, prices, liquidity, 24-hour volume, short-horizon price changes, pair creation timestamps, project links, and boost/profile metadata (docs.dexscreener.com). DexScreener indexes decentralized exchanges directly, so its numbers reflect what is actually happening in on-chain liquidity pools right now — which makes it the right backbone for a map that claims to be live.

CoinGecko supplies the reference layer, used only where a token is actually listed there: supply-aware circulating market caps, 7-day, 30-day, and 1-year price change, and a 7-day price sparkline (coingecko.com). CoinGecko maintains human-reviewed supply data per token — which wallets are locked, vested, or treasury-held — something no DEX indexer can know from pool data alone. Where both sources report a market cap, we prefer CoinGecko's, for reasons covered in detail below.

The division of labor matters. Live pool data is fast but shallow: it can tell you the price moved 40% in an hour, but not whether the reported market cap reflects tokens that can actually circulate. Reference data is deep but slower-moving. Combining them — DexScreener for immediacy, CoinGecko for accuracy on caps and longer time windows — gives the map both properties at once. Everything shown on the site can be independently verified: pool data on DexScreener itself, supply and cap data on CoinGecko, and the raw on-chain reality on BaseScan (basescan.org).

What DexScreener's API Actually Provides (and Doesn't)

Understanding our pipeline requires understanding the shape of the upstream API. DexScreener's documented public endpoints include a pair search, batch token lookups (up to 30 addresses per call), per-pair detail, latest and top token-boost feeds, and a token-profiles feed (docs.dexscreener.com). Each pair object carries price in USD, liquidity, volume, buy/sell transaction counts, price change across several timeframes, market cap and fully diluted valuation estimates, the pair's creation timestamp, and — where the project has supplied them — a logo, website, and social links.

Two constraints shape everything we build on top. First, rate limits: the pair and search endpoints allow around 300 requests per minute, while the boost and profile feeds allow about 60 per minute (docs.dexscreener.com). Second, and more fundamentally: DexScreener has no "list every token on a chain" endpoint. You cannot ask it for all Base tokens; you can only search, look up specific addresses, or read its curated feeds. The search endpoint also returns at most 30 results per query (docs.dexscreener.com).

That missing endpoint is the single most important constraint in our architecture. Any site showing "the Base token market" from DexScreener data is necessarily showing a constructed sample, not a census — and the honest question is how that sample gets constructed. The next three sections answer it for BaseBubbles.

Building the Token Universe: ~130 Searches, Not One List

Since no single call returns the Base market, we assemble it. The pipeline fires roughly 130 parallel DexScreener search queries, organized into deliberate tiers. The first tier searches blue-chip and quote-token symbols — WETH, USDC, USDT, DAI, cbBTC, cbETH, EURC, liquid staking tokens, and other major stablecoins. Because nearly every serious Base pair quotes against one of these, this tier surfaces the highest-liquidity markets on the chain almost by definition.

The second tier searches known Base ecosystem names: DEX and lending tokens like AERO and WELL, culture tokens like DEGEN, BRETT, and TOSHI, AI-ecosystem tokens like VIRTUAL and AIXBT, and dozens more established tickers. The third tier covers narrative keywords — meme-culture terms, AI-agent vocabulary, SocialFi and Farcaster-adjacent names. The final tier is generic catch-alls: words like "base", "agent", "pepe", "dog", "moon", "swap", "finance". These deliberately cast a wide, sloppy net; the dedupe stage cleans up afterwards.

The term list is maintained by hand and evolves with the market — when a new narrative takes hold on Base, terms get added so the map catches it. This is a genuine editorial choice and we say so plainly: a token whose name matches no search term, and which never appears in the boost or profile feeds described next, can be invisible to the map even while trading actively. That is the cost of building a universe atop a search API, and it is why we layer a second discovery mechanism on top.

Boost and Profile Feeds: Widening the Net

Search terms find what we thought to look for. To catch what we didn't, the pipeline also reads three DexScreener discovery feeds: latest token boosts, top token boosts, and latest token profiles (docs.dexscreener.com). These list tokens whose teams recently paid for a boost or filled out a profile — which, whatever you think of paid promotion, is a strong signal that a token is newly active and being pushed to traders right now. Exactly the tokens a live map should not miss.

Every Base-chain address appearing in those feeds becomes a candidate. Candidates are batch-resolved through the token lookup endpoint, 30 addresses per call, with the total capped at 300 addresses per cycle so that a spike in the upstream feeds cannot balloon our request volume. The feed results are cached for five minutes — matching their slower rate limit — while search results refresh every minute.

Two things are worth underlining. First, appearing via a boost feed grants no scoring advantage whatsoever: the token enters the same dedupe, the same risk scoring, the same ranking as everything else. Boost status is recorded and shown as a small star badge, nothing more — see What Are DEX Boosts? for why we treat paid visibility as context rather than signal. Second, this mechanism is precisely how brand-new launches reach the new Base tokens page within minutes of their first promoted appearance, without anyone at BaseBubbles adding a search term.

Filtering to Base and Deduplicating by Deepest Liquidity

The searches and batch lookups return a raw pile of pairs from every chain DexScreener indexes — the generic terms especially drag in Solana and Ethereum results. The first filter is strict: only pairs whose chain ID is Base survive. Base is Coinbase's OP Stack Ethereum L2, chain ID 8453 (docs.base.org), and everything on this site is scoped to it exclusively.

The second step handles a subtler problem: one token usually trades in many pools. AERO, for example, trades against WETH, USDC, and other quotes across multiple DEXes; a naive aggregation would show it as five separate bubbles. We deduplicate by base-token contract address, and when multiple pairs exist for the same token, we keep the pair with the deepest liquidity as that token's canonical market. Deepest-liquidity is the right tiebreaker because that pool has the most capital committed to the price, suffers the least slippage, and is the hardest market to manipulate — its price and stats are the most trustworthy single representation of the token. Our guide to reading token liquidity covers why depth matters this much.

After dedupe, tokens with zero recorded liquidity or a missing address are dropped, and the survivors — typically somewhere between 130 and 250 tokens depending on market conditions — form the universe. One honest consequence of canonical-pair selection: the volume and liquidity figures shown for a token describe its deepest pair, not the sum across every pool it trades in. A token with activity fragmented across many small pools will look smaller here than a full cross-pair aggregation would show. On a token's detail page we list all of its Base pairs individually so you can see the full spread.

Caching, Refresh Cadence, and What 'Live' Really Means

The assembled universe is cached in memory for 60 seconds. Any request arriving within that window is served instantly from cache; the first request after expiry triggers a full rebuild — all ~130 searches, the candidate batches, dedupe, scoring, and enrichment. The homepage polls the API on the same 60-second cadence, so the map you watch is never more than about a minute behind the market under normal operation.

Different data ages at different speeds, so different layers get different lifetimes. The boost and profile feeds are cached for five minutes — they change slowly and their rate limit is tighter. Individual token detail lookups cache for 60 seconds. CoinGecko market data caches for five minutes per coin, and the CoinGecko contract-address map refreshes roughly every six hours, since token listings change rarely. Each lifetime is matched to how fast the underlying data actually moves and what the upstream permits.

One more engineering detail worth disclosing because it affects data freshness guarantees: when many users hit the site at the moment a cache expires, only one rebuild runs — concurrent requests for the same expired data share the single in-flight fetch rather than stampeding the upstream APIs with duplicates. This keeps us well inside DexScreener's documented rate limits (docs.dexscreener.com) regardless of traffic, which in turn is what makes the 60-second cadence sustainable. A site that hammers its source gets throttled, and a throttled site silently serves stale data while claiming to be live. Respecting limits is not just politeness; it is what makes the freshness promise honest.

When Upstreams Fail: Stale Cache, Then Labeled Sample Data

Public APIs fail — timeouts, rate-limit responses, outages. The pipeline degrades in two explicit, deliberately ordered stages rather than showing an error page or, worse, quietly presenting old numbers as fresh.

Stage one: serve the most recent successfully built universe, even if its 60-second lifetime has expired. Slightly stale real data is far more useful than no data, and under a brief upstream hiccup this stage is invisible — the map simply carries the last good snapshot until the next rebuild succeeds.

Stage two: if there is no cached universe at all — a cold start during a full upstream outage — the API returns a small built-in sample dataset, and every response carries an explicit sample flag that the frontend surfaces as a visible banner. You will never see placeholder numbers dressed up as live ones. The same discipline applies to individual token pages and the risk scanner: if the live lookup for a specific address fails, we first fall back to that token's entry in the cached universe, and we only ever serve sample data for an address when the sample actually matches that address — the scanner will never report results for a token it did not really find. Silent data-quality failures are how dashboards mislead people; making degradation loud and labeled is a core design rule here.

CoinGecko Enrichment: How Supply-Aware Data Gets Attached

After the universe is built from DexScreener data, and before it is cached, each token is enriched with CoinGecko reference data where possible. The mechanism has three steps, all best-effort by design.

First, contract matching. CoinGecko publishes a full coin list annotated with platform contract addresses; we build a map from lowercase Base contract address to CoinGecko coin ID and cache it for about six hours, since listings change rarely. Matching by contract address rather than by ticker symbol is essential on a chain full of impersonator tokens — anyone can launch a token called "AERO", but only one contract address is the real one. Every token in our universe whose address appears in that map gets linked to its CoinGecko identity; the rest simply skip enrichment.

Second, batched market fetches. Market data for all matched coins is requested in batches of up to 250 coins per call, retrieving current market cap, price change over 1h/24h/7d/30d/1y, and a 7-day hourly sparkline. Third, per-coin caching: results are cached individually per coin for five minutes, not as one blob per request. This matters more than it sounds. The token universe shifts slightly on every rebuild — a token enters, another drops out — and a single cache entry keyed on the exact token set would be invalidated by every such change, forcing constant refetches of unchanged data. Per-coin caching means only genuinely new or expired coins trigger upstream calls, and a token's detail page reuses the exact same cached figures the list view already loaded, so numbers never disagree between views. If any part of enrichment fails, the pipeline logs it and returns the DexScreener data unchanged — enrichment can only add, never break the map. The 7-day sparkline is also downsampled from 168 hourly points to about 48 before it leaves the API, purely to keep page payloads light; the shape of the week is preserved.

Why Supply-Aware Market Cap Beats FDV — and Why Our Numbers Differ From Other Sites

Where CoinGecko reports a market cap for a matched token, it overrides the DexScreener figure on our site. This is the most consequential data decision in the pipeline, so it deserves a full explanation.

Market capitalization is price multiplied by circulating supply — the tokens actually available and trading (coingecko.com). Fully diluted valuation (FDV) is price multiplied by total supply — what the cap would be if every token that will ever exist were circulating today (coingecko.com). For a token where 90% of supply sits locked in team, investor, or treasury allocations, these two numbers differ by an order of magnitude, and the difference is not academic: FDV describes a hypothetical future; circulating market cap describes the market that exists. A DEX indexer computing caps from on-chain pool and supply data cannot reliably tell locked tokens from live ones, so screener-derived caps frequently drift toward FDV-like figures.

CoinGecko addresses this with a human-maintained supply methodology: circulating supply is calculated as total supply minus verified non-circulating wallets — smart-contract lockups, vesting team and investor allocations, and treasury or foundation wallets earmarked for future use (support.coingecko.com). It is not perfect — supply figures partly depend on project disclosure and review lag — but it is systematically closer to economic reality than pool-derived estimates. This is why a token's market cap on BaseBubbles can differ from the same token's cap on a raw screener: we are showing the supply-aware number wherever one exists. Both figures are retained in our data — the token drawer shows market cap and FDV side by side — because the gap between them is itself information: a large FDV-to-cap ratio means substantial future unlock pressure, a structural risk factor discussed in our meme coin risk checklist. Tokens with no CoinGecko listing — most brand-new launches — keep DexScreener's estimate, and their 7-day, 30-day, and 1-year change fields stay empty rather than being filled with guesses.

How Tokens Are Ranked and Paged

The homepage ranks tokens by market capitalization, using the best available figure per token in a fixed preference order: CoinGecko's supply-aware cap first, DexScreener's FDV estimate if there is no cap, and liquidity as a final fallback so unlisted tokens still sort somewhere sensible rather than randomly. Rank answers the question "how big is this token's market?" — deliberately a slow-moving, structural ordering.

The ranked list is split into pages of 100 bubbles. This is a readability decision: a physics-based map stays legible when a bounded number of circles share the screen, and 100 keeps even the smallest bubble on a page large enough to label. Page 1 is roughly the Base top 100 by cap; page 2 the next hundred; and so on, with the page picker showing each page's average price change for your selected time window so you can see at a glance which slice of the market is moving. Filters — sector, gainers/losers, search — apply before ranking, so a filtered view re-ranks and re-pages the matching set. The frontend requests up to 250 tokens per load, which comfortably covers the live universe.

Ranking by cap is not the only ordering on the site, and the distinction is intentional. The trending page orders by 24-hour trading volume — "where is the action right now?" — and the new-tokens view orders by pair creation time — "what just launched?". Gainers and losers views sort by price change. These orderings answer different questions, and we keep them on separate views rather than blending them into one opaque composite score. A single "hotness" number would be easier to market and harder to trust; we would rather show you three honest orderings than one mysterious one.

The Risk Score, Factor by Factor

Every token receives a risk score from 0 to 100, built by adding penalty points for measurable structural warning signs. A token that trips nothing scores 0; the factor weights sum to exactly 100, so a token that trips everything maxes out the scale. Higher scores mean more red flags. On the site, scores of 30 or below display green ("Lower Risk"), 31–60 yellow ("Moderate Risk"), and above 60 red ("Higher Risk"). These are the exact factors and weights as implemented:

The named flags always accompany the number, on the map's token drawer and in the risk scanner, so you can see exactly why a token scored what it did rather than trusting an unexplained figure. Note what the factors have in common: every one is observable, checkable public market structure. There is no sentiment input, no model, no judgment call — which is both the score's strength (it cannot be charmed) and its limit (it cannot read a contract), as the next section spells out.

What the Risk Score Deliberately Ignores

Knowing what a score excludes matters as much as knowing what it includes. Three exclusions are deliberate and worth stating plainly.

The score does not audit code. It never reads a token's contract, so it cannot detect a hidden mint function, a transfer tax, a blacklist, a honeypot that blocks selling, or an owner able to drain the pool. A token can score in the green band here and still be a honeypot — structurally tidy on the outside, malicious on the inside. Contract-level verification requires different tools: reading the verified source on BaseScan (basescan.org) and running dedicated contract checkers, both covered in how to avoid rug pulls on Base and our Base trading tools guide. Presenting a market-structure score as if it were an audit would be the most dangerous kind of false comfort, so we say the opposite loudly: it is not one.

Boosts are never scored. A DexScreener boost is paid visibility — it tells you a budget exists, not whether the project is good or bad. Boosted tokens get a star badge and a "Boosted" informational flag with zero points attached, in either direction. We considered penalizing boosts (paid promotion correlates with pump-and-dump patterns) and rejected it, because legitimate new projects also buy visibility; the badge gives you the fact and leaves the judgment to you.

Nothing off-chain enters the score: no team reputation, no social sentiment, no holder-concentration analysis, no news. Partly this is scope, partly principle — every input we do use is verifiable by you against public sources, and a score you can independently recompute is worth more than a broader one you have to take on faith.

How Sector Tags Are Assigned

The sector filters — Meme, AI Agents, DeFi, SocialFi, Blue Chips, Gaming — come from a two-stage classifier, ordered from most to least reliable.

Stage one is a curated map of known contract addresses. Established Base tokens — the AEROs, VIRTUALs, and DEGENs of the ecosystem — are assigned their sector by exact contract address, which is immune to naming tricks: an impersonator token calling itself "AERO" does not inherit the real AERO's DeFi tag, because its address does not match. This hand-maintained layer is small but covers the tokens people most often filter for.

Stage two handles the long tail with heuristics, checked in a fixed priority order. First, blue-chip symbols (WETH, USDC, cbBTC, and other majors and stables) are tagged Blue Chips. Then AI: a known-symbol list plus keywords like "agent" and "AI" in the name. Then DeFi: protocol symbols plus words like "finance", "swap", "vault", "yield", "stake". Then SocialFi and Gaming symbol lists. Then meme vocabulary — "pepe", "inu", "doge", "cat", "moon", and a few dozen more. Anything unmatched lands in Other. The priority order resolves conflicts sensibly: a token named "AI Swap Finance" hits the AI check before the DeFi one and is tagged once.

Heuristics have edges, and we would rather admit them than pretend precision: names can mislead in both directions — a serious project with a meme-flavored name can get tagged Meme, and meme coins increasingly adopt AI vocabulary precisely to ride the narrative. Treat sector tags as navigation aids for filtering the map, not verdicts on what a project is. Reported misclassifications get fixed in the curated address layer, which permanently overrides the heuristics for that token.

Bubble Size: The Square-Root Rule

Bubble size encodes a metric you choose: percentage move (the default), 24-hour volume, liquidity, or market cap. The mapping from value to size uses a square-root scale, and the reason is perceptual honesty. Humans read a bubble's importance from its area, but a circle's area grows with the square of its radius — so if radius were proportional to value, a token with four times the volume would render with sixteen times the visual weight. Taking the square root of the value first makes area, not radius, track the metric, which is the standard correction in bubble visualization.

Concretely: each token's value is compared to the largest value on the current page, and its radius interpolates between a fixed minimum and maximum — roughly 22 to 66 pixels on desktop, 15 to 46 on mobile — by the square root of that fraction. The guaranteed minimum is itself a design decision: on a linear scale, small tokens would shrink to invisible dots next to a giant, and a map that only shows you what you already know is useless. The floor keeps every token on the page tappable and labeled.

One subtlety for the default % Move sizing: the comparison maximum never drops below a 25% move. On a quiet day when the biggest mover is up 3%, this stops the scale from stretching trivial wobbles into dramatic giant bubbles — a flat market is supposed to look flat. And a thing bubble size never encodes: position. Bubbles drift and collide under a gentle physics simulation purely so they spread out readably without overlapping; where a bubble happens to float carries no information. Size and color are the only visual channels that mean anything.

Bubble Color: Direction, Intensity, and Time Windows

Color carries two dimensions. Hue is direction: green for a positive price change in your selected window, red for negative. Intensity is magnitude: the bubble's border, glow, and fill brightness scale with the size of the move, reaching full intensity at a ±30% change — beyond that, a 60% move looks as saturated as a 35% one, a deliberate ceiling that keeps one violent outlier from making everything else look dead by comparison.

The change window is yours to choose: 1 hour, 6 hours, 24 hours (the default), 7 days, 30 days, or 1 year. The short windows come from DexScreener's live pair data; the 7-day, 30-day, and 1-year windows exist only through CoinGecko enrichment, which is why very new or unlisted tokens show no change — rendered as a neutral zero — on longer windows. Switching windows repaints the whole map and is one of the fastest sanity checks the site offers: a token glowing bright green on 1H but deep red on 7D is a bounce inside a downtrend, and the reverse pattern is a dip inside strength.

Everything else on a bubble is identification, not evaluation: the token's logo where one is available, its ticker, the percentage figure for your window, and the yellow star badge if the token currently holds a DexScreener boost. Tapping a bubble opens the detail drawer with the full numbers — price, market cap, FDV, liquidity, volume, the multi-window changes, the sparkline, risk score with flags, and links out to DexScreener and the project's own site and socials.

What BaseBubbles Deliberately Does Not Do

A methodology page should list its negative space. These are the things the system does not do, each by decision rather than omission.

The common thread: every transformation between raw public data and a pixel on your screen is listed on this page, and anything that cannot be explained here does not ship.

Known Limitations and Data-Quality Caveats

Honest methodology includes failure modes. These are the known ways the map can mislead, and what we do about each.

How to Interpret the Map Responsibly

Everything above compresses into a short usage doctrine.

Use the map as a starting point, never an endpoint. Its job is to compress a few hundred markets into one glance so you notice things worth investigating — a sector turning green in unison, a new bubble with outsized volume, a big cap bleeding for a week. Noticing is where the map's job ends and yours begins: verify the contract on BaseScan (basescan.org), read the pool composition, check who holds the supply, and run the address through the risk scanner and the deeper checks in our risk checklist.

Read the risk score as a cheap first filter with asymmetric meaning. A high score is reliable in what it says — those structural flags are real, measured facts. A low score is weak in what it implies: it means no basic red flags tripped, not that the token is safe, because the deadliest risks (malicious code, concentrated holders, staged liquidity) live outside the score's inputs. "Passes basic structural checks" and "vetted" are different claims; the score only ever makes the first.

Hold the numbers loosely where the caveats bite: caps without CoinGecko backing are estimates, longer-window colors need enrichment to exist, and the universe is a curated sample of a much larger, wilder market. Base itself settles to Ethereum with a Coinbase-operated sequencer (l2beat.com) — even the chain has trust assumptions, and so does every dashboard built on it, this one included. Finally, remember what the site is for: BaseBubbles exists to make public market data legible, not to make decisions. It shows structure at a glance so that whatever you choose to do next, you do it with clearer eyes — the decisions, and the responsibility for them, stay entirely with you.

Frequently Asked Questions

How often does BaseBubbles update its data?

The token universe rebuilds roughly every 60 seconds, and the homepage re-fetches on the same cadence, so the map is normally under a minute behind the live market. Some layers refresh on their own schedules: boost and promotion feeds every five minutes, CoinGecko market caps and multi-day changes about every five minutes per coin, and the contract-listing map a few times a day. If upstream sources fail, the site serves the last good snapshot, and in a full outage it switches to clearly labeled sample data with a visible banner.

Where does BaseBubbles get its data?

Two sources. DexScreener's public API provides the live layer — pairs, prices, liquidity, volume, short-term price changes, pair ages, project links, and boost metadata (docs.dexscreener.com). CoinGecko provides the reference layer for listed tokens — supply-aware market caps, 7-day/30-day/1-year change, and sparklines (coingecko.com). Everything is verifiable against those sources and against on-chain data on BaseScan.

What does the BaseBubbles risk score mean?

It is a 0–100 structural score built by adding penalty points for measurable warning signs: low liquidity (+25), a pair under 24 hours old (+20), no website (+15), no social links (+15), a 24-hour move beyond ±50% (+15), and under $5,000 daily volume (+10). Higher scores mean more red flags; 0–30 displays green, 31–60 yellow, above 60 red, with the specific flags always listed. It reads market structure only — it is not a code audit and a green score is not a safety guarantee.

Why is a token's market cap different here than on other sites?

Because we prefer CoinGecko's supply-aware market cap — price times verified circulating supply, excluding locked, vesting, and treasury tokens (support.coingecko.com) — over screener estimates, which often drift toward fully diluted valuation. For tokens with large locked allocations the two figures can differ enormously. Tokens not listed on CoinGecko keep DexScreener's estimate, and both market cap and FDV are shown in the token drawer so you can see the gap yourself.

Why isn't a token I'm watching shown on the map?

DexScreener has no list-all-tokens endpoint, so the universe is assembled from about 130 targeted searches plus boost and profile feeds, filtered to Base and deduplicated. A token that matches no search term and hasn't appeared in those feeds can be missed even while trading actively, and tokens with zero recorded liquidity are dropped. You can still look up any specific Base contract address directly through the risk scanner, which queries DexScreener live for that token.

Can projects pay for a better rank, bigger bubble, or better score?

No. There is no pay-for-placement anywhere in the data pipeline — ranking is by market cap, sizing by your chosen metric, and the risk score by fixed structural factors. Sponsor slots on the site are sold completely separately and always carry a visible sponsored label. DexScreener boosts, which are paid promotion on that platform, appear only as a neutral star badge and never add or subtract score points.

What do bubble size and color actually mean?

Size encodes your chosen metric — % move, volume, liquidity, or market cap — on a square-root scale so a bubble's area, which is what your eye reads, tracks the value honestly. Color encodes price direction and magnitude for your selected window (1H to 1Y): green for gains, red for losses, brighter with bigger moves up to a ±30% ceiling. Position means nothing — bubbles drift under a physics simulation purely for readability.

Why do some tokens show no 7-day or 30-day change?

Those longer windows come from CoinGecko enrichment, which requires the token's Base contract address to be listed on CoinGecko. Brand-new launches and unlisted tokens have no such listing, so their 7-day, 30-day, and 1-year fields stay empty rather than being filled with estimates. Sparse long-horizon data is usually itself a signal that a token is very new or very small — treat it as a reason for extra checking, not a display bug.

Is the risk score an audit or a safety guarantee?

No, emphatically. The score never reads a token's contract code, so it cannot detect honeypots, hidden mint functions, transfer taxes, or malicious owner privileges, and it doesn't analyze holder concentration or whether liquidity is locked. A token can score well and still be a scam. Use the score as a fast first filter, then verify the contract on BaseScan, check liquidity locks, and run dedicated contract checkers before risking anything.

Sources

Related

Use the Risk Scanner

Before trading any token you discover, use the BaseBubbles Risk Scanner to check for liquidity, honeypot signals, and other risk factors.

More Guides

Disclaimer: This content is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency trading involves significant risk.