How we select the five tokens
Every 30 minutes FANOUT has to pick five coins out of the thousands born in that window, and spend real money on them. This is the whole method: what gets thrown out before we even rank, what we rank by and why it is not volume, why three of the five slots work differently from the other two, how the money is divided, and — the part most projects skip — what this method cannot do.
The problemThousands of coins, five slots, thirty minutes
Argus is busy. Counting TokenCreated events on Portal #7 directly from
the chain, here is what a selection window actually looks like:
| Window | Launches | Source |
|---|---|---|
| Last 30 minutes | 2,794 | measured on Arc |
| Last hour | 5,888 | measured on Arc |
| Last 6 hours | 28,637 | measured on Arc |
| Last 24 hours | 53,354 | measured on Arc |
So the job is to keep about 1 coin in 560. That ratio is the reason this page exists. A selector that picks badly does not lose a little — it parks the entire treasury in tokens that are dead within the hour. With only five slots, each pick carries a fifth of the round — there is nowhere for a bad one to hide.
These were taken on Arc's official mainnet launch day, and the rate is still climbing — it roughly doubled between two measurements eleven hours apart on that same day. This is launch traffic, not a steady state, and it can fall by an order of magnitude once the novelty passes. We re-measure at 7 and 30 days, and the engine's parameters are sized against the quiet case, not this one. Every figure on this page carries the date it was measured for exactly this reason.
Step 1The screen: what is disqualified before anything is ranked
Ranking thousands of things is only useful if the obvious garbage is gone first. Five filters run before any ordering happens. A coin failing any one of them is not ranked low — it is removed.
| Filter | Rejects | Why |
|---|---|---|
MIN_VOLUME_USD |
Coins with almost no trading in the window | A coin nobody traded has no signal in it at all — it is noise, not a candidate. |
MIN_UNIQUE_BUYERS |
Coins bought by fewer than 3 distinct addresses | One address trading with itself produces volume and tells you nothing. |
MIN_LIQUIDITY_USD |
Pools too thin to buy into | Buying into an empty pool means paying any price the pool asks. |
MAX_SELL_RATIO |
Coins being sold far harder than bought | An exit in progress. Volume looks healthy on the way down too. |
MAX_SINGLE_BUYER_SHARE |
Coins where one wallet is most of the buying | That is one person's position, not a market. When they leave, so does the price. |
To be calibrated — and a warning about tightening them. A screen is not free. The single-buyer limit is the clearest example: dropping it from 0.70 to 0.50 sounds obviously safer, but concentrated early buying is also what a genuine winner looks like in its first minutes. Tuned too hard, that filter throws away the winners along with the manipulation. Every one of these five values is being fixed against Argus data, and none of them gets tightened on intuition.
Step 2The ranking key: net inflow, not volume
The obvious way to rank new coins is by volume. We do not, and the reason is simple: volume is the easiest number on a chain to fake. One wallet buying and selling the same coin all afternoon produces a large, real, completely meaningless volume figure. Any competitor ranking by volume can be fed whatever ranking someone is willing to pay gas for.
FANOUT ranks by net inflow: USDC that went in minus USDC that came out, across the window. To move up that ranking you cannot round-trip — you have to actually leave money in the pool and keep it there. Wash trading nets to approximately zero by construction.
There is also a tell worth watching for. When a volume figure is honest, more of it should mean a better coin, consistently. When ranking by volume stops behaving that way — when a middle band of volume outperforms the band above it — that is the signature of a number with manipulation mixed into it. We check the ranking key for exactly that behaviour on Argus data, and we publish which key the engine is using.
Uniswap v4 — which Argus is built on — signs swap amounts from the
swapper's side, the opposite of v3. A buy of the token reads
amount < 0 under v3's convention and amount > 0
under v4's.
Read it the wrong way and net inflow inverts: the engine would systematically buy the coins being dumped hardest. And nothing would look wrong — volume uses absolute values, so it would still tally correctly, the tests would pass, and this page would show plausible numbers. It would only surface in the treasury, months later.
This is why the sign convention is verified against real Arc swap logs and pinned by a dedicated test, before the selector is trusted with money.
Step 3Up to three core, the rest fillers
A round is always five coins, and the five are not equal. At most three slots go to the core tier and the remaining ones to fillers, and which tier a coin lands in is decided by two floors it either clears or does not:
Three is a ceiling, not a quota. The floors are strict, so most windows produce one or two core picks, and some produce none — then the round is all fillers and spends only the filler share. The live table on the front page shows how many cleared in the round you are looking at.
- Price progress. Is the coin's price at selection time meaningfully above its launch price? A coin that has not moved up has not convinced anyone yet.
- Late volume. Did it keep trading after its own first few minutes? Launch-minute excitement is worth little; a coin still being bought twenty minutes later is a different animal.
| Tier | Slots | Definition | What it means |
|---|---|---|---|
| core | 3 | Cleared both floors | The real picks. Most of the money goes here. |
| filler | 2 | Passed the screen, missed a floor | Cheap tickets, funded deliberately small. |
If six coins clear both floors in a window, the round still buys three of them. The other two slots go to fillers — coins that qualified for less. That is a deliberate trade: it keeps a fixed exposure to the cheap-lottery bucket instead of concentrating every round in whatever the floors happened to admit.
It cuts the other way too. When only one coin clears, fillers take the slack and the round is still five — just a weaker one. You will see that on the front page, round by round, because every pick carries its tier. A round that is mostly filler means the window was poor, and we would rather show you a poor window than dress it up.
To be calibrated. The exact height of those two floors is the most market-specific number in the whole method. A value fitted to one launchpad does not carry to another — the pace, the sizes and the crowd are all different. Both floors are being derived from Argus launches before the engine spends anything, and the values will be published here with the date they were measured.
Step 4How the money is split
Before anything is bought, the money splits in two. 80% of every fee the treasury claims buys the five coins and goes to holders. The other 20% stays in the treasury to run the project — gas, infrastructure, and the reserve that keeps a cycle from stalling halfway through a delivery.
That 20% is set aside at the moment of the claim and tracked as a running balance. It never re-enters a buying budget, so the same dollar cannot be counted twice.
| Of every trade | Goes to |
|---|---|
| 4.00% | what a trader pays, on every buy and every sell |
| 1.00% | the pool fee — it never reaches the project |
| 3.00% | the project's tax, the only part we ever see |
| 0.30% | Argus (10% of that tax, fixed by the launchpad) |
| 2.16% | the holders' share |
| 0.54% | the treasury, to run the project |
Argus takes its tax out of whatever leaves the pool: USDC on a sell, $FANOUT on a buy. That would leave half the fee in a form that cannot buy anything — except the launchpad's splitter converts the $FANOUT side into USDC itself, before it is ever credited to the project.
MEASURED across five consecutive distributions on a live token: the splitter sold the token side into the pool every time and not one unit of the project's own token ever reached the project wallet. The practical consequence is the one that matters to a holder — the project never has to sell its own token to fund a round, because it is never holding any to sell.
The 80% that does the buying is then split across the five, and not evenly:
- The core picks take the large majority, weighted by net inflow — the same quantity the ranking uses — however many of them there are.
- No single core pick may exceed a capped share of that money, however good it looks. One coin is never allowed to become the round.
- The fillers split the remainder equally. They are lottery tickets and are funded like lottery tickets.
- If nothing clears the floors, the round spends only the filler share and holds the rest for the next window. A window with nothing in it is not a reason to buy five things anyway.
What each holder receives is their share of the supply, applied to every coin: hold 2% of $FANOUT and you receive 2% of each of the five. The more you hold, the bigger the slice — and the arithmetic rounds down, so the treasury never promises more than it has and the last transfer in a round never fails for being a unit short.
Step 5The traps between "picked" and "in your wallet"
A correct selection still loses money if the buying and delivery are naive. Four hazards are handled explicitly.
The snipe tax
Argus taxes the first three seconds of a coin's life on a sliding scale that starts near 99%. Buy into that window and almost the entire order is confiscated. FANOUT only ever buys coins that are minutes old, so it never touches the window — but the engine refuses to buy inside it as a hard rule, not as a side effect of timing.
A pick with no way in
A coin can rank first and still have no pool with enough liquidity to route into. An engine that simply trusts its own ranking sends that round out with four coins instead of five, and nothing says why. So the engine probes the route before committing the five and refills the slot from the ranking when a pick turns out to be unreachable.
Sent is not bought
A transaction that has been broadcast has not necessarily succeeded. Read the balance straight after sending and you will happily record coins you do not own yet, then try to deliver them. The engine waits for the receipt, rejects reverted buys, and only counts a coin as held once the chain says it is.
Debt written before delivery
Once coins are paid for, holders are owed them. That debt is written to disk before any transfer can leave, and each holder paid is recorded as it happens. If the process dies halfway through a round — an RPC outage mid-delivery is the realistic case — the next round pays what is still owed before buying anything new, and nobody is paid twice.
HonestyWhat this method cannot do
Every selection method has a shape of winner it structurally cannot catch. Ours has three.
- It misses the fastest winners entirely. A coin that runs its whole course inside its first few minutes is finished before a 30-minute selector ever looks at it, and those launches are given up on entirely, by construction. Catching them is a different product — buy in the first seconds, accept the snipe tax — and it is not this one.
- Most picks will die. That is the design. Newly launched memecoins fail at overwhelming rates on every chain that has ever run a launchpad. Five at a time instead of one is not optimism; it is the only sane response to a hit rate that low. A round where four of the five go to zero and one does not is a normal round — and with five slots rather than a wider basket, the rounds where none of them runs will be more common, not less.
- Thresholds found by searching past data get worse on new data. Any cutoff picked because it looked good on a sample is partly fitted to that sample, and the honest expectation is that it performs worse live than it did on the page. That is why the method ships first and the constants get earned — and why the ones on this page will carry the date they were measured.
The front page publishes each round's picks with their tier, their age at purchase and their net inflow, plus the buy transaction and every delivery transfer. Nothing on this site is an estimate — if a number here disagrees with the Arc explorer, the explorer is right and we have a bug to fix.