Documentation
Methodology
Germanus measures on-chain state of Solana tokens and archives every measurement permanently. Each analysis is a snapshot: what the chain said at that moment. Snapshots of the same contract form a timeline; the cockpit places them side by side so change becomes visible. Nothing is ever revised after the fact.
How a scan works
A deep scan resolves the token's authority surface, the top 100 holders (exchange and AMM wallets separated out), their funding origins, trading history and profit/loss, plus liquidity across pools. It takes 1 to 3 minutes and up to 1,200 data-provider calls. The result is stored as structured values that feed the cockpit grid, the holder table and the funder graph. Scans up to 25 August 2026 additionally carry a full prose report; the archive keeps those readable, newer scans do not add one.
The analysis, step by step
Eleven stages run in order. Each one states what it measures, where the data comes from, and where it stops. The stage names describe the effect; the implementing function is named after each one so a claim can be traced to code.
01
Holder resolution and owner aggregation
WhatReads every token account of the mint, then aggregates accounts belonging to the same owner into one wallet. AMM pool accounts and known exchange accounts are separated out so the list describes traders, not infrastructure.
SourceHelius RPC (token accounts, owners), program and address maps for pool and exchange detection.
LimitThe fetch has a cap. If a mint has more token accounts than the cap allows, the holder base is incomplete and the scan states this instead of implying completeness.
phase4_holder_structure_intelligence
02
Market and liquidity reality
WhatResolves trading pairs, pooled liquidity in USD, pool count and the price the pairs report at scan time.
SourceDexscreener (pairs, liquidity, price), Jupiter and Raydium (pool data).
LimitLiquidity is a reading at one moment, not an average. Pools too small to be listed by the aggregator do not appear.
phase5_market_liquidity_reality
03
Authority surface: mint, freeze, liquidity
WhatChecks whether mint authority and freeze authority still exist or are revoked, and how the liquidity position is held.
SourceHelius RPC (mint account state), pool accounts for the liquidity side.
LimitReports the state at scan time. An authority that is present can be revoked a minute later, and an LP state can change with one transaction.
phase6_token_authority_control_surface, phase8_authority_metrics
04
Transaction records per wallet
WhatCollects the transaction history of each analysed wallet as far as needed for its trading facts.
SourceHelius (signatures and parsed transactions), Solscan Pro (transfers and account activity).
LimitBounded per wallet by a sample size. Very active wallets can exceed it; the row then carries the sample as truncated and the affected trade cells stay n/a.
phase7_collect_tx_records
05
Instruction and route decoding
WhatDecodes the instructions of each transaction to tell an actual swap from a plain transfer, and follows routed swaps across several programs.
SourceParsed instruction data from Helius, program map for known DEX and router programs.
LimitPrograms outside the map stay unclassified. A transfer that economically was a purchase cannot be priced as a trade, and is reported as a transfer.
phase7_instruction_decode_layer, phase7_route_execution_simulator
06
Entity and label layer
WhatAssigns accounts to categories: centralised exchange, program, liquidity pool, router, or an ordinary wallet.
SourceSolscan Pro account labels, on-chain classification of the account owner, curated address maps.
LimitA missing label is a gap in the label source, not proof that an account is not an exchange. Both cases read differently and are kept apart.
phase7_entity_label_layer
07
Funder tracing and clusters
WhatTraces which address funded a wallet with SOL before it started trading, and groups wallets that share a funder into clusters.
SourceHelius (earliest inbound SOL transfers), Solscan Pro (transfer history), entity layer to stop at exchange withdrawals.
LimitTracing has a depth and a per-scan funder budget. Wallets funded through several hops beyond the depth keep an n/a funder. A shared funder is a measured link, never an accusation.
build_funder_cluster_map, MBIT_FX_ORIGIN_TRACE
08
Pricing and profit or loss
WhatValues each buy and sell in USD at the time it happened, then derives buy cost, sell proceeds, realised and unrealised result, and the current value of the position.
SourceThe swap instruction itself where the counter asset is SOL or a stablecoin, Birdeye historical pricing otherwise.
LimitFour pricing modes are reported openly: SOL_USD, STABLE_USD, ZERO_BASIS and UNPRICED. UNPRICED means no reliable price existed for that trade, so no result is invented for it.
Birdeye pricing layer, holder PnL model
09
Change against the previous scan
WhatCompares the current snapshot with the stored previous one and reports the difference per data point.
SourceThe archived snapshot of the same contract.
LimitNeeds at least two scans. The first scan of a contract states that there is nothing to compare yet instead of showing a zero change.
phase8_build_prev_input, phase8_data_reliability_change
10
Coverage accounting
WhatCounts, for every holder row, how many of eleven documented cells actually carry a value, and publishes the result as a percentage.
SourceThe assembled holder row itself; no extra source.
LimitCells that cannot exist for a row leave the denominator instead of lowering the number, and the row records which ones. See the list below.
holder_table_row_coverage
11
Archive mirroring
WhatWrites the finished analysis into the permanent archive: the full report, the structured values, the holder table and the change metrics.
SourceThe scan result itself.
LimitThe working table behind a scan is transient and is pruned. Only what the mirror writes survives, which is why the archive is the reference and the working table never is.
on_scan_persisted
What coverage means
The coverage percentage on a holder row is not an opinion about data quality. It counts how many of exactly eleven cells carry a value. Cells that cannot exist for that row leave the denominator instead of lowering the number: a liquidity pool has no investor profit, so asking for it would punish the row for being a pool. Which cells were excluded is recorded per row.
The eleven cells
11 cellstoken_count
IsTokens held by the wallet at scan time.
Gap whenRead directly from the token accounts; present whenever the wallet is in the list.
holder_pct
IsShare of the circulating supply the wallet holds.
Gap whenDerived from token_count and supply.
buy_usd
IsUSD spent acquiring the position.
Gap whenNeeds at least one priced buy. Stays n/a when every acquisition was an unpriced transfer.
sell_usd
IsUSD received from sales.
Gap whenZero is a value, not a gap: it means nothing was sold.
net_usd
IsRealised plus unrealised result, by average cost (AVG_COST).
Gap whenNeeds both parts. Where nothing was sold, the realised part is zero by fact, and the net equals the unrealised part. Two bases exist: priced swap records, or, where the index knows no priced swap for that wallet, the USD values carried by its token transfers. The second is marked t in the table. Both use average cost, so the figure agrees with the wallet trace.
first_trade_ts
IsTime of the first trade of this wallet in this token.
Gap whenA wallet that received the token instead of buying it has no first trade; the first acquisition is reported in its place and marked as such.
sol_balance
IsSOL balance of the wallet.
Gap whenOne RPC read; present unless the account query failed.
total_balance_usd
IsTotal USD value across the assets of the wallet.
Gap whenComes from a provider with a per-scan budget. Once that budget is spent, further ranks cannot be fetched at all and the cell is treated as structurally unavailable.
funding_address
IsAddress that funded the wallet with SOL.
Gap whenNeeds the funder trace to reach an origin within its depth.
funding_amount
IsAmount of that funding in SOL.
Gap whenComes with the funder address; missing together with it.
wallet_age_days
IsAge of the wallet in days.
Gap whenFrom the first signature of the account.
Archive-first & the freshness probe
FRESHNESS THRESHOLD10 % LIQUIDITY DRIFT
A scan never ages "well" or "badly". Below the threshold the stored answer is served unchanged; above it, a real scan runs.Requesting a contract shows the stored dossier immediately. "Rescan" first runs a single-call probe against current market data: if total liquidity moved less than 10% versus the stored value, the archive answer is served and your scan window is not consumed. The unchanged reading is itself information. Only real movement (or an operator override) triggers a fresh deep scan.
The 15-minute window
Anyone may start one deep scan per 15 minutes (enforced per anonymised IP hash). Reading the archive is never limited. Archive answers do not consume the window.
Coverage & n/a
Every value states how much data supports it: "n=2 of 30" means two of thirty wallets could be priced. Where nothing was recorded, Germanus shows n/a, never a substitute and never zero. An n/a in an older scan usually means the data point did not exist in that scan version yet.
Why no verdicts
"Direction is a fact, not a judgment."
GUIDING PRINCIPLE. APPLIES TO UI, COPY AND DATA.
No buy or sell callsNo scores or ratingsNo price predictionsNo red, no green
Germanus does not label tokens safe or dangerous and does not compute a public risk score. Measured state, with sources, is the product: top-10 concentration versus the platform median says more than a traffic light, and it stays true when circumstances change. The same rule applies to community observations, which must describe and link evidence, not judge.
Holder-table lenses
The holder table offers preset views (“lenses”). A lens only filters and highlights — no column is removed and no value changes. Marked cells carry their reason as plain text with the measured number and its reference. Every rule below is a measurable condition; none is a judgment. Thresholds in brackets are operator-adjustable; the current values are always shown on the mark itself. Two reading aids keep the table quiet: a rule that hits more than [25 %] of the table is a fact about the whole table, not about single wallets — it is stated once in the lens header and produces no cell dots. And where wallets belong together (one funder, one time cohort, one signature), the lens sorts them into blocks with a small header line instead of scattering marks across the ranking. A finding shows as a lightly tinted cell; hovering (or long-pressing) the cell names the rule, the measured number and its reference. Locked positions (Streamflow and other lock programs) appear as their own green block above the ranking — display only: they count into no rank, no concentration figure and no lens. Double-clicking (or tapping) a tinted cell opens the finding as a small card in place. A “Funding origin” line above the table counts wallets funded by exchanges, by private wallets, and with no resolved funder. The table has two levels: Pro (default and recommended) shows every column, each one toggleable in the left rail; Easy lets the active view pre-select its columns — any hidden column comes back with one click, and columns carrying findings are never hidden automatically.
Lens rules
37 rulesShared funder (R1)
Ruletwo or more table wallets received their first SOL from the same address; exchange wallets do not count — they fund thousands of unrelated users
Time cohort (R2)
Rulethree or more first trades, each within [240 s] of the previous
Fresh, shared funder (R3)
Rulewallet age at most [7 days] and rule R1 applies
Unclear cost basis (R4)
Ruleno net result computable while holding at least 1 % of supply
Oversized holder (R5)
Ruleheld share exceeds [2.5×] the platform median for the same rank AND is at least [0.5 %] of supply; the comparison basis is named on the mark
Young top wallet (R6)
Rulewallet at most [3 days] old sitting in the top 20
Instant buyer (R7)
Rulefirst trade within [120 s] after the pool opened (recorded per scan; older scans lack it)
Unknown funder (R8)
Ruleno funder resolved while holding at least 1 %
Coverage gap (R9)
Ruleless than [60 %] of a top-30 row’s cells resolved
One-way buyer (R10)
Rulebought, never sold, and rule R1 applies
Equal balances (R11)
Rulethree or more wallets whose token balances match within [0.5 %]
Gas dust (R12)
RuleSOL below [0.002] while still holding tokens
Equal buy-ins (R13)
Rulethree or more wallets whose USD buy-ins match within [1 %]
Clockwork entries (R14)
Rulefour or more first trades at near-constant intervals (variance under 15 %)
Holder funds holder (R15)
Rulea wallet’s funder is itself a holder in this table
Younger than the token (R16)
Rulewallet age below the token’s own age while in the top 30 (skipped when the age is only a lower bound)
Early in, fully out (R17)
Ruleearly-buyer cohort member that sold down to zero
Equal SOL (R18)
Rulethree or more wallets whose SOL balances match within [2 %]
Group weight (R19)
Ruleone funder group holds at least [10 %] combined
Single-purpose wallet (R20)
Rulethis token makes up more than [95 %] of the wallet’s tracked worth
New at the top (R22)
Rulein the top 20 now, absent from the table in the previous scan of this token
Quiet unwind (R23)
Ruleposition cut by at least [2 pp] since the previous scan while still holding the rest
Rotation pair (R24)
Ruleone wallet loses about what another gains between scans (within [5 %]), and the two share a funder or a transfer edge
Shared counterparty (R25)
Ruletransfers meet at one counterparty shared with three or more holders
Out and back (R26)
Ruletokens moved to another wallet and back again
Pre-launch funding (R27)
Rulewallet funded within [24 h] before the pool opened (recorded per scan; older scans lack the pool start)
Back to the funder (R28)
Rulea holder sent funds back to its own funding source
Serial funder (R29)
Rulethe group’s private funder also feeds groups of two or more holders in other scanned tokens; the mark names how many, and the index size is the comparison basis
Conviction holder (T1)
Ruleearly buyer, never sold, still holding
Profit taker (T2)
Rulerealised profit while still holding a position
Loss seller (T3)
Rulesold below its own cost basis
Returning wallet (T4)
Rulein the top 30 of at least [2] other scanned tokens; the mark names how many were net positive and how many tokens the index covers
Outsized exit (T6)
Ruletook out at least [10×] the buy cost and at least [1000 USD] — covers sells with no priced buy cost
Repeat buyer (T5)
Ruleat least [3] separate priced buys over time (sample-based; recorded per scan, older scans lack the count)
Swarm signature (M1)
Rule[5+] wallets matching [2+] of the rules R1, R2, R11, R13, R18 at once — only rules that are not majority facts of the table count; shown as a card, never as a verdict
Launch seating (M2)
Rulethree or more wallets that both bought within [120 s] of pool start (R7) and share a funder (R1) — shown as a card, never as a verdict
Redistribution (M3)
Rulea position vanishes between scans and reappears in similar size (within [5 %]) split across two or more new wallets of the same funder group — shown as a card, never as a verdict
The raid campaign
A reward campaign that runs in the Germanus Telegram group and ends with the payout in October 2026. It is documented here because it pays in $GERMANUS: rules that decide who gets paid should be readable without joining anything first. It is separate from the scanner in every direction. It reads no scan data, it writes none, and no analysis point on this page changes because of it.
Telegram group onlyEnds 16 October 2026Does not touch scan dataLaunch week pays USDC on top
How the campaign works
12 rulesOpening a raid
WhatA member sends the bot a link to their own post on X. The bot opens the raid, announces it in the group and pins it until it is done or cancelled.
SourceThe X account is connected once beforehand, by posting a one-time code. The bot compares the author of the post against the connected account.
LimitOne raid per person at a time. A post that is a near-copy of a raid already running is refused.
The goals
WhatEvery raid carries goals on likes and replies, and all of them must be met before anything is paid.
SourceBoth numbers are read from the post itself, against the counts recorded when the raid was opened.
LimitA raid counts exactly one post, your own. Nobody can add a second, so there is no goal on the number of posts.
Five at a time
WhatFive raids run concurrently. Everything beyond that enters a queue, and a freed slot promotes the entry that has waited longest.
SourcePosition is arrival order alone.
LimitThe queue holds up to 250 entries. When it is full the bot refuses instead of promising a place it does not have.
While a post waits
WhatThe starting counts are taken the moment a post enters the queue, so every like and reply it collects while waiting counts in full.
SourceWaiting posts are re-checked in rotation, and once more in the moment before a post goes live.
LimitA post deleted while waiting drops out. It never reaches the group, and it never takes a slot.
Settlement
WhatA raid is settled when it leaves the queue and meets its goals. Reaching the goals while still waiting is enough; the booking then happens at the moment of promotion.
SourceCounted from the post, against the starting counts taken at queue time.
LimitNothing is booked before the goals are met. A raid that misses them pays nothing and leaves every other raid untouched.
What a raid pays
WhatThe base reward goes to the person whose own raid reached its goals: 500 $GERMANUS, rising with completed raids to 650, 800 and 1,000. Supporting another raid pays per like on your own post.
SourceCompleted raids are counted from your own history in the bot.
LimitThe per-like amount is capped, and can never exceed the base reward. Reach must not pay more than work.
The bonus pot
WhatOne pot per 48-hour period, shared among everyone whose raid closed inside that period. The pot grows with how busy the period was.
SourceCounted from the closing time of each raid.
LimitOne pot per period, not per raid. A quiet period pays a small pot; it does not pay nothing.
The 72-hour check
WhatThree days after a reward is booked, the post is checked once more. If it is gone, both the $GERMANUS and the USDC are reversed.
SourceThe reversal appears as a counter-entry in your own history, never as a silently changed balance. The reversed USDC goes back into the pot.
LimitThe check starts only once a reward exists. Before that there is nothing to reverse.
The launch bonus
WhatFor the first week there is a second reward on top, paid in USDC: a fixed amount for every raid of yours that reaches its goals.
SourceIt comes from a separate pot of 300 USDC, held in its own wallet. The remaining pot is readable in the bot at any time.
LimitTime-boxed to seven days and capped by the pot, whichever ends first. It never touches the $GERMANUS contingent.
The holding window
WhatEvery USDC reward is held for the length of the 72-hour check before it can be cashed out.
SourceYour balance shows both numbers: what you have, and what is already free. The bot names the time of the next unlock.
LimitIt is the same window in which a deleted post is reversed. Once USDC has left the chain it cannot come back, so it may not leave before that question is settled.
Cashing out the bonus
WhatThe unlocked USDC collects on your account. One button pays it out to your wallet, and it arrives within a minute.
SourceThis is the one place where the bot signs by itself. The wallet it signs from holds only the launch pot.
LimitThere is a minimum, and it applies to the unlocked part: creating a USDC account for a wallet that has none costs about 0.20 USD in rent, so collecting first leaves more in the pot for everyone.
Payout
What40,000,000 $GERMANUS are reserved for the campaign. Balances are earned now and paid from 15 October 2026, with one automatic run on 16 October 2026 to the wallet you stored.
SourceThe remaining contingent is readable in the bot at any time.
LimitThe bot holds no keys and signs nothing. A payout is calculated by the bot, sent by a person, and confirmed afterwards.
What X does not expose sets the outer limit of all of this, and it is worth stating plainly: view counts, repost counts, who liked or reposted a post, follower counts and account age are not readable, and neither is whether a post was flagged as spam. Germanus counts likes and replies because those are the two numbers that can actually be read. A deleted post is the one thing that reads unambiguously, and that is what the checks above are built on.
Data sources
Helius (RPC, holders, transactions), Birdeye (historical USD pricing behind the PnL layer), Solscan Pro (account labels, transfers), Dexscreener (pairs, liquidity, the freshness probe), Jupiter and Raydium (pool data). Reports link the sources per section.
Dynamic rows
Two cockpit groups are dynamic: "Market reality" mirrors the market-structure rows of the stored scan, "Authority surface" mirrors the authority fields. Their rows follow the scan content; every value is stored, none is fetched live.
Removal procedure
IMMUTABLE BY DEFAULT
The archive is not edited on request. Removal happens only where a rights violation is substantiated, through the review below. Nothing is deleted quietly.
The archive is immutable by default. Substantiated notices of a rights violation go to support@germanus.app and are reviewed; see the privacy policy.
Analysis point reference
Every point below is live: it renders from stored scan data. Points that a given scan did not record show n/a in the cockpit.
Market
4 pointsLiquidity
WhatTotal USD liquidity across all detected pools.
SourceDexscreener pairs at scan time.
LimitPools created after the scan are not included.
Volume 24h
WhatTrading volume in the 24h before the scan.
SourceDexscreener pair data.
LimitWash trading is not filtered here.
Pools
WhatNumber of top liquidity pools recorded.
SourceDexscreener, capped at the top pools.
LimitMicro pools below the cap are not counted.
Top pool liquidity
WhatLiquidity of the deepest single pool.
SourceDexscreener.
LimitSnapshot value; pool depth moves constantly.
Distribution
11 pointsHolders on-chain
WhatTotal holder accounts on-chain.
SourceHelius RPC / Birdeye counter.
LimitIncludes dust accounts.
Holders analysed
WhatHolders that entered the deep analysis.
SourceScan pipeline (top holders ex-AMM).
LimitA sample of the largest, not all holders.
Holder table rows
WhatRows recorded in the holder table.
SourceStored holder table.
LimitUp to 100 rows per scan.
Top 5
WhatSupply share of the 5 largest non-AMM holders.
SourceDerived from the stored holder table.
LimitBasis is the top-100 ex-AMM sample.
Top 10
WhatSupply share of the 10 largest non-AMM holders.
SourceScan pipeline.
LimitExchange custody wallets are separated out where known.
Top 20
WhatSupply share of the 20 largest non-AMM holders.
SourceScan pipeline.
LimitSame basis as Top 10.
Top 50
WhatSupply share of the 50 largest non-AMM holders.
SourceDerived from the stored holder table.
LimitBasis is the top-100 ex-AMM sample.
Largest holder
WhatShare of the single largest holder.
SourceScan pipeline.
LimitOne wallet is not necessarily one owner.
Wallets > 1%
WhatWallets holding more than 1% of supply.
SourceDerived from the stored holder table.
LimitTop-100 basis.
Concentration
WhatConcentration index (sum of squared shares × 10,000).
SourceDerived from the stored holder table.
LimitComputed over the top-100 sample, not all holders.
PnL / Movement
7 pointsAvg PnL top 30
WhatAverage net PnL of the top-30 wallets.
SourceBirdeye-priced trade history.
LimitCoverage shown as n of 30; unpriced wallets excluded.
Sum realized
WhatSum of realized PnL across priced holder rows.
SourceDerived from the stored holder table.
LimitOnly wallets with priced history count.
Sum unrealized
WhatSum of unrealized PnL across priced holder rows.
SourceDerived from the stored holder table.
LimitPosition value depends on the price at scan time.
Wallets in profit
WhatShare of priced wallets currently in profit.
SourceDerived from the stored holder table.
LimitCoverage shown; unpriced wallets excluded.
Top 15 in profit
WhatHow many of the top-15 wallets are in profit.
SourceScan pipeline.
LimitSubject to the same pricing coverage.
Top 15 PnL coverage
WhatPricing coverage of the top-15 PnL read.
SourceScan pipeline.
LimitLow coverage weakens every PnL statement.
Top 15 unrealized
WhatUnrealized PnL of the top-15 wallets.
SourceScan pipeline.
LimitPaper value, not exit value.
Control
7 pointsMint authority
WhatWhether new tokens can still be minted.
SourceOn-chain mint account.
LimitStates the standard authority; program-based mints differ.
Freeze authority
WhatWhether accounts can be frozen.
SourceOn-chain mint account.
LimitStandard authority only.
LP status
WhatState of the liquidity pool tokens.
SourceLock providers and on-chain checks.
Limitunknown means no provider confirmed a lock.
Lock provider
WhatWhich service locked the LP, if any.
SourceLock provider APIs.
LimitOnly known providers are detected.
Locked supply
WhatShare of supply verifiably locked.
SourceLock provider data.
LimitUnlocked does not equal about-to-sell.
Lock check
WhatWhether the lock check completed.
SourceScan pipeline.
Limitnot_checked means the probe did not run, not that no lock exists.
Lock expiry
WhatWhen a detected lock expires.
SourceLock provider data.
LimitExtension after the scan is possible.
Provenance
5 pointsDirect funder share
WhatSupply held by wallets funded from one common source.
SourceFunding-graph analysis.
LimitIndicates coordination capability, not proven intent.
Funder cluster
WhatLargest funding cluster among top holders.
SourceFunding-graph analysis.
LimitSame-source funding can also be an exchange pattern.
Distinct funders
WhatDistinct direct funders of top holders.
SourceFunding-graph analysis.
LimitDepth-limited traversal.
CEX funders
WhatFunders identified as exchange wallets.
SourceKnown-wallet labels.
LimitUnlabelled exchange wallets are not counted.
Avg wallet age
WhatAverage age of holder wallets in days.
SourceDerived from the stored holder table.
LimitLower-bound ages where history is truncated.