Enough that the average order size stays in a band a human would trade, and enough that the maker count reads as a crowd rather than a desk. In practice that is a few hundred wallets on a small session and low thousands on a large one. The number falls out of two things you already decided: the volume you are routing and the order size you want to appear on the tape. Volume divided by target order size gives the order count, and the wallet count is set so that no single wallet is doing an implausible share of it.
Short version
- Wallet count is not a vanity number. It sets maker count, which is a primary ranking input on every board.
- Derive it, do not guess it. Volume divided by order size gives orders; wallets follow from how many orders one address can plausibly place.
- Each new wallet locks 0.00203928 SOL of token account rent. That is a deposit, returned when the account closes.
- More wallets also means more signatures, which is a real but small cost at 0.000005 SOL each.
- Beyond a point extra wallets stop buying anything and only add rent and funding transactions.
What the wallet count is actually buying
One number on the board: distinct makers. Both the Pump.fun feed and the pool statistics on an AMM aggregator separate the volume figure from the number of addresses behind it, and the ratio between them is the fastest read anyone has on whether flow is broad or concentrated.
Four hundred SOL through sixty wallets is an average of nearly seven SOL per address. That is a whale profile, repeated sixty times, in a market where most participants are trading a fraction of a SOL. Four hundred SOL through two thousand wallets is an average of 0.2 SOL per address, which is an ordinary retail size. The volume figure is identical and the two tapes do not look remotely alike.
This is the same argument as the one in does a volume bot get you trending, applied to one setting. The boards are tuned against concentrated paid flow, and concentration is what a low wallet count produces by definition.
Deriving the number
Pick the order size band first
Decide what a single trade should look like on the tape. For a typical launch that is somewhere between 0.05 and 0.5 SOL, with the band wide enough that sizes scatter rather than repeat.
Divide the volume by the midpoint
Target volume divided by the middle of that band gives the approximate number of orders the session will place. 500 SOL against a 0.2 SOL midpoint is about 2,500 orders.
Decide orders per wallet
One to five orders per address stays plausible. Twenty orders from the same address inside an hour does not. Divide the order count by that figure to get the wallet count.
Sanity check against duration
Divide the order count by the session length in minutes. If the result is more trades per minute than the token would plausibly see, the session is too short rather than the wallet count too high.
Check the rent you are locking
Multiply the wallet count by 0.00203928 SOL. That is the deposit sitting in token accounts during the run. It comes back when they close, but it has to be there first.
Run those five steps on the 500 SOL example and you land somewhere near 1,200 wallets, roughly 2.4 SOL of rent, and a session that wants hours rather than minutes. That is a derived number rather than a preference, which is the point.
What more wallets cost
| Wallets | Token account rent held | Funding signatures | Maker profile |
|---|---|---|---|
| 100 | 0.204 SOL | 100 | Concentrated, reads as a desk |
| 500 | 1.02 SOL | 500 | Plausible on a small session |
| 1,000 | 2.04 SOL | 1,000 | Broad, comfortable for mid sizes |
| 2,500 | 5.10 SOL | 2,500 | Retail shaped on a large session |
| 10,000 | 20.4 SOL | 10,000 | Only meaningful on very large volume |
Two things to read out of that table. The rent column is the largest number and it is the one that comes back, provided the accounts are closed at the end. The signature column is real but small: even ten thousand funding transactions at the base fee is a fraction of a SOL. Neither is a reason to run a session narrow.
The actual ceiling is different. Past a certain point each additional wallet places less than one order, which means you paid rent and a funding transaction for an address that appears once and contributes nothing to how the tape reads. The full cost stack is in how much a volume bot costs.
Where wallet count is not the answer
Three symptoms get misdiagnosed as too few wallets. If the trades are landing on a metronome, the problem is spacing, not spread. If every order is the same size, the problem is the band, not the count. If the session is over in fifteen minutes, adding wallets makes the tape denser and more obviously synthetic rather than less.
And the funding pattern matters as much as the count. Two thousand addresses funded in a single block from one source is a single signature to anyone reading the chain, no matter how many addresses it created. Staggered funding across the session is what makes the spread mean anything.
The short answer by session size
| Target volume | Typical wallets | Typical duration | Why |
|---|---|---|---|
| 100 SOL | 300 to 600 | 45 to 90 minutes | Enough spread to avoid a whale profile at small size |
| 300 SOL | 700 to 1,200 | 2 to 4 hours | Retail sized orders without repeat trades per address |
| 500 SOL | 1,000 to 2,000 | 3 to 6 hours | Broad maker count while the curve progresses |
| 1,000 SOL | 2,000 to 4,000 | 5 to 10 hours | Large notional that still has to read as a crowd |
These are starting points and not rules. PumpWave exposes the wallet count and the order band directly rather than hiding them behind a preset, because the right number depends on the token, the hour and what else is launching, and none of those are knowable in advance from a table.
Questions people actually ask
Is more wallets always better?
No, more wallets are not always better. Beyond the point where each address places roughly one order, extra wallets add rent and a funding transaction without changing how the tape reads. The useful range is the one where maker count is broad and each address still trades more than once.
How much SOL do the wallets themselves need?
Each wallet needs enough to cover its orders plus the base signature fee and the associated token account rent. The engine funds them from the session deposit and returns what is left, so the figure to budget is the session total rather than a per wallet amount.
Do the wallets need to be funded from different sources?
Separate funding sources are not practical, and trying to disguise the funding source is not the useful lever. What matters far more is that funding is staggered over the session rather than executed in one block, and that the trading pattern itself has variance in size and spacing.
What happens to the wallets after the session?
The wallets are drained when the session ends, the token accounts are closed so the rent is released, and the remainder goes back to the wallet that funded the session. The keypairs are ephemeral and have no use afterwards.
Can I reuse wallets across sessions?
Reusing wallets across sessions is possible and usually a bad idea. Addresses that appear across several unrelated tokens are the clearest link anyone can draw between launches, and it removes the freshness that makes the maker count read as new participants.
Does wallet count affect the fee?
Wallet count does not change the fee on PumpWave. The fee is a flat 1% of the target volume regardless of how you spread it. Wallet count changes the rent held during the session and the number of signatures, both of which are network costs rather than tool costs.
Run one and watch it land
Paste a mint, shape the session, see the exact fee before you fund anything. Flat 1% from 100 SOL, no install, no seed phrase.
Builds and runs the PumpWave session engine at PumpWave Labs in Estonia. Writes about Solana launch mechanics from the operator side: what settles, what it costs, what the board does with it. Corrections and arguments to support@pumpwave.net.