How the queue is built

Every number below is imported from the same configuration the snapshot writer and the verification tool run on, so the thresholds here cannot drift from the code. Back to the queue.

What shell.capital is

Trading fees fund a treasury that buys the smallest verified tokens on Solana, smallest first, using market caps recomputed from effective supply rather than the raw number screeners trust.

The page renders one published snapshot and computes nothing. The one exception is the verification tool, a server route that runs the snapshot's own reconciliation for a single mint when asked.

Verified cap

verified_cap = price × (total_supply − burned − locked − frozen)

Total supply, decimals, authorities and Token-2022 extensions are read from the mint account on-chain. Burned is the balance of every token account owned by the burn addresses. Locked and frozen are measured over the accounts that are inspected individually: the largest holder accounts from the holder index plus every registered locker account. Locked is what those inspected accounts hold under locker or vesting programs; frozen is what they hold in accounts whose state is frozen. Supply in smaller accounts below the inspected set is not classified, and the confidence factor records how much of the supply was inspected. Tokens held by liquidity pools stay in effective supply because they can trade.

Price, liquidity, 24h volume and the screener cap come from the highest-liquidity pool on DexScreener whose quote side is SOL, USDC or USDT. Divergence is that screener cap divided by the verified cap; anything at or above 2× is highlighted.

Universe

Jupiter's community verified list, minus the quote assets themselves (SOL, USDC, USDT) and minus tokens Jupiter tags as tokenized stocks, equities and pre-IPO shares, commodities, other real-world-asset or Ondo securities, liquid staking tokens and stablecoins, whose caps reflect a backing asset rather than a float. Tokens outside the universe are not scanned for the queue and do not appear in the rejected list. The verification tool still checks any mint you paste and reports it as not on Jupiter's community verified list or as the asset class that excludes it.

Filters, in order

A token must pass every one. The rejected tab shows the first criterion each token failed, in the wording below. The first pass uses Jupiter's own figures for cap, liquidity and holder count so that on-chain work is only spent on plausible candidates; the screener and on-chain passes then re-check cap, liquidity and holders with their own sources.

• Jupiter marks the token deprecated or duplicaterejected
• Cap ceiling (Jupiter's figure, then the screener's)$10,000,000
• Cap floor (Jupiter's figure, then the screener's)$10,000
• Minimum liquidity (Jupiter's figure, then the screener's)$15,000
• Minimum holders (Jupiter's count, then the on-chain index)250
• Minimum age of first pool30 days
• A SOL, USDC or USDT market on DexScreenerrequired
• Minimum 24h volume$2,000
• Maximum 24h volume relative to liquidity (wash pattern)30×
• Mint authoritymust be revoked
• Freeze authoritymust be revoked
• Token-2022 extensionsno permanent delegate, transfer hook, transfer fee, non-transferable flag or default-frozen state
• Holder index marks the token as ruggedrejected
• Verified cap floor$10,000
• Verified cap ceiling$5,000,000
• Largest single non-pool wallet, share of effective supply≤ 25%
• Creator wallet, share of effective supply≤ 15%
• Liquidity as a share of verified cap2% to 60%

Tokens that pass everything are ranked by verified cap, smallest first. The queue holds 25 slots; tokens that pass but rank below slot 25 are listed as rejected with that reason, and would enter as smaller tokens leave. Two further reasons can appear in the rejected list that are not filters: a token whose on-chain reconciliation failed during the run, and a token that fell outside the run's deep-verification budget; both are retried on the next snapshot.

Score

The score is informational; the queue order is by verified cap alone. Six factors, each 0 to 100, weighted as follows.

• Cap: smaller verified cap scores higher, on a log scale25%
• Liquidity: liquidity relative to verified cap20%
• Holders: concentration of the ten largest non-pool wallets, adjusted for holder count20%
• Authority: mint, freeze and metadata authorities, extensions10%
• Deployer: creator's remaining stake and how many tokens the deployer has minted10%
• Confidence: share of supply inspected account by account, reduced when an unrecognised program holds supply or the holder index disagrees with the chain on total supply15%

Score colours are presentation only: green at 80 and above, amber at 60 and above, red below.

Days to build

Assumes a $2,500 position absorbing 5% of 24h volume per day, and ignores market impact, slippage and fees.

Verification tool

Paste any mint and the server runs the same reconciliation and filters, then places the token against the current queue. Checks are limited to 10 per minute per address and results are cached for 5 minutes. Submitting a token does not add it to the queue; nobody reviews submissions.

Data delivery

The page fetches the published snapshot on the server and refreshes it every 30 seconds. A snapshot older than 2 hours, a failed fetch or a malformed file raises a persistent banner; nothing is ever shown silently stale.

Front-running

The queue is public and the next target is always visible. Buys are executed at a randomised point within each window; anyone can see what is next and trade ahead of it.

Disclaimer

Nothing here is investment advice. Holders of the token have no claim on treasury assets. Simulated position figures ignore market impact, slippage and fees.