Ponzhood V2

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.

Everything PONZHOOD 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.

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.

What we build on

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

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 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

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

Receiving fees and collecting them 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 deployer, or 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. PONZHOOD 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. A keeper 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 holds no special permission, and if it stopped tomorrow any holder could keep the vault running from the button on your token’s page.

Attaching a vault to an existing token

Possible, but not fully automatic. The token’s original deployer can point the redirect at a vault, and the vault will still distribute permissionlessly — but the sweep itself will keep needing that deployer’s signature.

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.

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.

Separate from bonding-curve launches. Each series is an NFT collection plus its own fuel $TOKEN, with a shop, activation, a fee pot, and loans. The product UI is at /seats.

• Seat NFT — a numbered collectible; uploaded art is the NFT image.
• Seat wallet — one per NFT. Rewards land there and move with the NFT on sale. Its address is fixed from the moment the series exists; the wallet contract is deployed the first time the owner spends from it.
• Fuel $TOKEN — an ERC-20 for buying seats and paying activation, never ETH. Every series launches its own on a bonding curve in the same transaction that creates the series, so the series has a real market from the first block.
• Shop — a fixed $TOKEN price per seat, and the only contract that can mint one. Seats sold back are resold before any new one is minted.

Everything you set at launch is stamped into the vault and cannot be edited afterwards — not by you, and not by us. There is no upgrade path and no admin key on a deployed vault.

• Pairing asset — the quote the curve prices in and the asset creator fees arrive in.
• Trading tax — 0% to 10%, on top of the protocol's 1.00%. Paid on every buy and every sell.
• Template — one of the vaults above.
• Payout floor — how much has to accrue before a run is worth the gas. 0.1 in the pairing asset is the floor.
• Payout asset — RWA Dividend only, chosen from a short list and fixed forever.
• Lock period — Staking only, counted from each staker's most recent deposit. Principal only: rewards can be claimed at any time, lock or no lock.

• No admin key on a deployed vault. Parameters are constructor arguments, not storage anyone can write.
• No privileged trigger. The sweep is open; the keeper is one caller among all possible callers.
• The lottery operator can commit and reveal a draw but cannot choose the winner, and it is stamped at deployment so a creator cannot substitute themselves.
• Funds never sit with us. Fees go from the locker to your vault, and from your vault to holders. There is no treasury in the middle that we control.
• The contracts are not audited. Read them before you trust them.