Vaults that put your trading fees to work.

What problem this solves

When a pons token launches, the trading fees earned by its liquidity position accrue to a creator. That is good for the creator and neutral at best for everyone else: the value leaves the token the moment it is claimed.

A vault changes the destination. Instead of paying a wallet, the fees pay a contract with one job — the job you picked when you launched. That might be buying the token back and burning it, funding a prize pool, or paying stakers who lock up the token. The result is a launch where the rules are enforced by code rather than by the founder's word.

Contracts

Everything PonsVault does happens in these contracts, on Robinhood Chain (4663). They are deployed once and reused by every launch — the only thing created per token is a small vault of your chosen template. The rest of this page explains what they do and why.

Your own vault's address is shown on your token's page, and is also readable from the launcher by calling vaultOf with your token address. The source for all of them is on GitHub.

What we build on

These belong to pons and the chain. PonsVault calls them and cannot change them.

How a vault earns

Every pons launch has its liquidity position held by a locker contract. The locker tracks a per-token feeRedirect address and pays the creator share of collected fees there, after deducting the pons protocol share.

Attaching a vault means setting that redirect to the vault's address. From then on, collected fees arrive at the vault as WETH — an ordinary ERC-20 transfer, not native ETH. When the pool has also accrued fees on the token side, the vault receives some of your token too.

That much is the same for every template. What happens next is the part you choose. Buyback & Burn, one of the two templates available today, runs this cycle:

// Buyback & Burn — one template, when triggered
1. sweep pending fees out of the pons locker
2. split the WETH by the configured burn share
3. swap the burn share for your token
4. send every token it holds to 0x…dEaD
5. forward any remainder to the treasury

Who can trigger it

This is the part worth understanding, because it explains why PonsVault performs your launch for you rather than bolting a vault onto it afterwards.

Receiving fees and collectingthem are two different permissions on the pons locker. The payout follows the fee redirect, but the call that sweeps fees out of the locker is only accepted from the token's on-chain deployeror from pons's own protocol fee recipient. A redirect target is not authorised — even though it is exactly where the money lands.

So a vault can receive fees but can never sweep them by itself. PonsVault closes that gap by launching the token through its own launcher contract, which therefore becomes the deployer. The launcher exposes an open sweep function, and that is what lets the whole cycle run without any privileged operator.

In practice you should not have to press anything. PonsVault runs a bot that checks every live vault every few minutes and triggers a run once the accrued fees clear your minimum and are worth more than the gas. It is a convenience, not a dependency: it has no special permission, and if it stopped tomorrow any holder could keep the vault running from the button on your token's page.

Templates

A template is a vault contract with one job. You choose one at launch and configure it; the configuration is then fixed for the life of the vault.

Buyback & Burn — available now

Spends a fixed share of incoming fees on a market buy and burns the result immediately, forwarding the remainder to a treasury address you nominate. Set the burn share to 100% and there is no treasury at all.

Staking — available now

Pays incoming fees out to holders who stake the token, in proportion to how much each has staked. Rewards are WETH the pool actually earned, so nothing is minted and no supply is burned — and because staked tokens sit in the vault, supply leaves circulation for as long as people keep earning on it.

Staking is a deliberate deposit rather than an automatic dividend to every holder. Paying holders passively would need the token to notify the vault on every transfer, and pons tokens are plain ERC-20s whose fees come from the Uniswap pool rather than a transfer tax, so no such hook exists. Requiring a deposit is what makes the payout computable without one.

The creator may set a lock period at launch, counted from each staker's most recent deposit. It applies to principal only: rewards can be claimed at any time, lock or no lock. Like every other parameter, it cannot be changed afterwards.

Lottery — in development

Accumulates fees into a prize pool and pays a holder chosen at random each round. Still being designed — picking a winner fairly on-chain is harder than it sounds when anyone can trigger the draw.

RWA Tax — in development

ETH is reserved for tokenized-stock purchases. Keepers sell supported RWA assets to the vault, and holders can claim RWA dividends.

Parameters

Every template exposes its own settings, named here as they appear in the launch form. They are written once, when the vault is created. None of them has a setter, so none of them can be changed later — not by you, and not by us.

Buyback & Burn

Staking

Security model

Making the trigger public is what makes a vault credible, and it is also what makes it attackable. Any template that trades on demand is an invitation to move the pool first and sell into it. Using Buyback & Burn as the worked example, here is exactly where that leaves you.

• The buyback has no price check. It buys at whatever the pool quotes in that block, with no average to compare against and no floor of its own. A buyback that lands alongside a large trade — including one placed deliberately to bait it — will buy at that price.
• A caller-supplied floor, if you want one. Whoever triggers the run may pass a minimum number of tokens the swap must return, which aborts the whole run instead of accepting a bad fill. This site and our bot pass none.
• A bounded loss. A run can only ever spend fees that have actually accrued, so the most at stake in any single run is one batch of fees — never the treasury, and never the liquidity.

Your harvest minimum is therefore doing double duty: it sets how much of a target each run represents. A larger minimum means fewer, larger buybacks, and a larger prize for anyone willing to try for it.

Beyond the swap itself, the vault never takes custody of anything it can misdirect. It holds no launch funds, cannot touch the liquidity position, and has no function that transfers assets to an address you did not configure at creation.

Upgrades

Vaults are deployed behind a shared beacon, so a defect can be fixed for every existing vault at once without asking anyone to migrate. That is real power, and it is deliberately removable: the beacon's owner can renounce control permanently, after which no vault can ever be changed again.

Limits & caveats

Things worth knowing before you launch, including a few sharp edges we found while testing against the live chain.

• A buyback moves the price it buys at. On a thin pool, spending a batch of fees in one swap pushes the price up as it fills, so the tokens burned are worth less than the WETH spent. Larger, less frequent runs feel efficient but suffer this more, not less.
• Burning is a two-step move.In Buyback & Burn, pons tokens reject a swap that delivers straight to the burn address, so the vault buys into itself first and then transfers out. The end state is identical; it just costs slightly more gas.
• Fresh launches have trading limits. pons applies per-transaction and per-wallet caps for a window after launch. Very early buybacks can bounce off those caps until the window closes.
• A vault is not a price guarantee. Burning supply does not create demand, and neither does a prize pool. Whichever template you pick, it is funded by trading — if nothing trades, no fees accrue and the vault does nothing.
• Audit status. The vault contracts are tested against live chain state but have not yet completed a third-party audit. Treat early launches accordingly.

Next steps

PonsVault is an independent interface and contract layer built on pons. It is not affiliated with or endorsed by Pons Labs. Nothing here is financial advice — review every contract address and transaction before signing.