Pons volume bot: how to route real volume into a Pons pair

What a Pons volume bot actually does

A Pons volume bot is a scheduler with a wallet fleet behind it. You give it a contract address and a target, it funds a batch of maker wallets, and it places ordinary buy and sell orders into your token's pool over a window you choose. Every one of those orders is a normal Robinhood Chain transaction. There's no private orderbook, no simulated print, and nothing that only exists inside a dashboard.

Visibility is the reason anyone wants it. Screeners, trending lists and the "recently active" surfaces people actually browse are sorted by activity, not by conviction. A pair with two trades a day is invisible to those surfaces no matter how good the project is. A pair with a steady tape gets looked at. Blunt version: you're buying attention, not demand.

Scheduling separates a usable bot from a liability. Anyone can loop a swap function. Making the resulting record look like ordinary trading, rather than a cron job with a wallet, is the hard part, and it's where most of the engineering goes.

How pons pools are built, and why it matters

Most launchpad guides describe a bonding curve that later migrates into a DEX pool. pons doesn't work that way, and if you plan a run on the wrong mental model you'll size it badly.

On pons, creating a launch deploys the token and its trading pool in a single transaction. The pool is a Uniswap V3 pool quoted against WETH, the pool fee is 1%, and the liquidity is locked automatically at launch. Supply is fixed at 1,000,000,000 and nothing is minted afterwards, so market cap and FDV are the same number. There's no curve to graduate off and no migration event to wait for.

Graduation on pons means one specific thing: the principal paired inside that locked pool has reached 4.2 ETH. When it does, the progress line fills and trading carries on in exactly the same pool. Nothing moves. That's the whole event.

Two consequences follow for anyone planning a run. First, there's only ever one venue, so there's no depth to split across and no fallback pool to fail over to. Whatever pool address sits on the token contract, that's where orders go. Second, the pool you're trading into is small by design in the early days, which is why order sizing matters far more here than it does on a chain where pairs launch with six figures of liquidity.

What you need before the first run

Short list, and none of it involves signing up for anything.

Running a Pons volume bot, step by step

Four steps and one signature. There's no account to create and nothing to install.

1. 1

   Paste the contract

   Open the desk and paste your token address. Name, symbol, decimals, supply and the pool address are read directly from the contract, so nothing depends on a third-party index being awake. If the address resolves, you'll see the token card fill in within a block or two.

2. 2

   Shape the run

   Choose a target volume and a window between 2 and 72 hours, then set the maker count and the buy pressure band. The statement on the right prices everything while you drag, including the delivered volume after the tier bonus and the number of individual fills the schedule will produce.

3. 3

   Sign one transfer

   You pay the desk fee to the receiving address shown on screen. That's the only transaction you sign. No approval, no spending allowance, no function call against your token. Nothing in that flow can drain anything, even in principle.

4. 4

   Watch it land

   The router waits for your payment to confirm, provisions the wallet batch, and starts filling. Every order is readable on Blockscout under your pair, and at the close of the window the delivered figure is reconciled against the explorer.

Sizing a run against pool depth

Here sits the difference between a run that reads well and one that leaves a scar on the chart. Mostly it comes down to arithmetic.

Every fill moves the price a little. In a Uniswap V3 pool the size of that move scales with the ratio between your order and the liquidity sitting in front of the current price. A pool holding a couple of ETH will absorb a 0.01 ETH clip without anyone noticing and will jump visibly on a 0.5 ETH one. Ask it backwards, then: not how much volume you can buy, but how small each fill can be while still adding up to your target.

Solving for that is why the desk derives the maker count from your target instead of asking you to guess it. A 100 ETH run spread across 1,200 wallets at six fills each produces 7,200 individual orders averaging under 0.014 ETH. Each one is a rounding error against the pool; the sum is the number you paid for.

Window length is the second lever. The same volume across 72 hours reads completely differently from the same volume across two. A short window concentrates the fills and makes the tape look frantic, which is occasionally what you want around a specific event and almost never what you want as a default. Steady, across five hours or more, is the setting most runs should use.

Buy pressure comes third. A buy-weighted run pushes WETH into the pool, which also moves the graduation progress line, so if you're close to the 4.2 ETH threshold a buy-heavy band does two jobs at once. A sell-weighted run does the opposite. The ratio drifts inside the band you set rather than sitting on one flat number, because a fixed ratio across thousands of fills is itself a fingerprint.

The average fill stays constant because the wallet count scales with the target. What changes is how long the fleet needs and how much of the pool it turns over. Delivered volume includes the tier bonus.

The rates ladder on the home page shows how the delivered figure changes as the target grows, and the simulator there redraws the schedule for whichever size you pick.

What a run costs, and what comes back

You pay a flat 1% of the volume you order, once, in ETH, before anything starts. A 10 ETH run costs 0.10 ETH. There's no subscription, no per-fill charge and nothing taken afterwards.

On top of that, larger targets earn delivered volume rather than a discount. The ladder starts at +15% and reaches +55%, applied automatically at the tier you cross, so a 100 ETH order delivers 140 ETH of routed volume and a 500 ETH order delivers 775 ETH.

One number gets missed almost every time. Every trade in your pool pays the 1% pool fee, and pons splits that fee between the creator and the protocol, 70% of it in the creator's favour for tokens launched through the current factory. Fees accrue in both the token and WETH inside the locked position, and you claim them from the pons interface whenever you like. Put plainly: volume routed through your pool also earns you creator fees.

Finally, the shortfall policy. At the close of the window the delivered figure is reconciled against Blockscout. If it lands under what you contracted for, the difference goes back to the address that paid, without a support ticket.

What separates a paced tape from a script

If you look at a naive bot for thirty seconds you'll see it: identical gaps between prints, identical clip sizes, and a buy ratio that never moves. It's a metronome with a wallet. Anyone reading the chart carefully, and every screener that scores for organic activity, treats that as noise.

A paced run breaks all three patterns deliberately.

There's a side-by-side of both tapes in the comparison on the home page, drawn from the same distributions the pacer uses.

What routed volume cannot do

Any guide that only lists benefits is a brochure with page numbers. Below is the boundary as we understand it.

Routed volume changes how visible a pair is. It does not create buyers, it does not guarantee a price direction, and it does not get a token listed anywhere. If the underlying project has nothing behind it, a busy chart buys you a slightly larger audience for the same disappointment, and you'll have paid for the privilege.

It also isn't a substitute for liquidity. A pool that's too thin to absorb a normal-sized buy will still be too thin after a run; volume passes through a pool, it doesn't deepen it. If your problem is depth rather than attention, add liquidity first and route volume afterwards.

And it's visible. Every fill sits on the explorer with a timestamp, an amount and an address. Pacing doesn't try to hide activity, which would be impossible on a public chain. It makes the record read like ordinary trading instead of an obvious loop. Anyone telling you their bot is undetectable is either lying or doesn't understand where the data lives.

Questions people ask before their first run