How MOAT works

MOAT is a thin layer on top of Pons v2, the token launchpad on Robinhood Chain. Pons does the launching: it deploys the token, runs the bonding curve, and graduates the token into a permanently locked Uniswap v4 pool. MOAT does not fork any of that and does not re-implement its math.

The one thing MOAT changes is where a launch’s creator fees go. Instead of a wallet, they go to a vault deployed for that single token, which has exactly one thing it can do with them: turn them into liquidity in that token’s own pool, permanently.

A launch is one transaction that does five things in order:

1. Compute the vault address. It is a CREATE2 address derived from the MOAT factory and your salt. Because MoatVault takes no constructor arguments, its creation code is a constant and its address is knowable before anything exists.
2. Launch on Pons, naming that address as the creator-fee recipient.
3. Deploy the vault at exactly that address. It reads its configuration back out of the factory during construction, so the token, curve and pair asset are compiled-in immutables rather than storage someone could re-initialise.
4. Verify the result against the Pons record — fee recipient, curve, pair asset, buyback flag — and revert the whole transaction if any of it disagrees.
5. Perform your opening buy, if you asked for one.

Nobody can trade between steps two and three, because it is one transaction and the curve does not exist until step two.

New tokens trade on a Pons constant-product curve priced against a phantom reserve. Buys move the price up, sells move it down, and each trade pays the Pons base fee plus your creator tax. The creator tax accrues inside the curve and reaches the vault when the curve is swept — which any compound does automatically, because Pons lets the creator-fee recipient sweep its own fees, and for a MOAT launch that recipient is the vault.

When the curve’s sellable allocation is bought out, the launch graduates. Pons sweeps the curve, creates a Uniswap v4 pool for the token and its pair asset, and seeds it with the swept reserves as a full-range position which Pons locks. This happens in two permissionless steps so a failed pool seed cannot strand the reserves.

Before graduation a MOAT vault holds fees and pays no bounty, because nothing has been converted. After graduation, compounding is open to anyone.

One token, one vault. What matters about it is mostly what it does not contain:

• No owner, no admin, no roles, no pause.
• No upgradeability, no proxy, no delegatecall.
• No call to modifyLiquidity with a negative delta, anywhere in the contract.
• No arbitrary external call and no arbitrary PoolManager command.
• No position NFT. The liquidity is held directly in the Uniswap v4 PoolManager under the vault’s own address, so there is no transferable object representing it at all.
• No rescue, sweep, or withdrawal of principal.

The only value that ever leaves is a keeper’s bounty, which is credited before any external call and pulled by the keeper itself.

compound(maxSlippageBps) is callable by anyone, forever. It sweeps the curve, claims from the Pons fee escrow, and — once the pool exists — converts roughly half the balance into the token and deposits both sides as full-range liquidity on the same range Pons seeded.

The price-impact bound is a limit, not a minimum-output check. A minimum-output check would revert a compound that is merely too large. A price limit makes Uniswap’s own swap loop stop at the bound and hand back the unspent input, which turns “too large” into a partial compound whose remainder waits for the next call. Value is never forced through the pool.

What that looks like over time is a cross-section of the moat itself, which is the one visualisation worth learning to read:

The caller earns 0.50% of what actually reaches the pool. Not 0.50% of the vault balance — of the amount compounded. That distinction matters: a price-bounded compound defers part of the balance, and charging on the balance would tax the same value once per attempt. The vault reserves the maximum up front and releases the unearned part the moment the real figure is known.

The rate is a constant in the contract with no setter. It cannot be changed by MOAT, by the creator, or by governance, because there is no governance.

Bounties are credited, not sent. You withdraw yours with withdrawBounty(). This is what stops a keeper contract that rejects payment from being able to make everyone else’s compound revert.

A launch trades against native ETH or any ERC-20 Pons has approved. On Robinhood Chain that list currently includes tokenised equities, a stablecoin and wrapped BTC — at 6, 8 and 18 decimals.

This is the part most protocols would leave out. The Pons protocol owner can propose a change to any launch’s creator-fee recipient, and execute it after a three-day timelock, within a three-day window. MOAT cannot prevent this and does not claim to.

The honest version of the guarantee is two separate statements:

1. Liquidity already added by a MOAT vault has no withdrawal path. Not for you, not for us, not for Pons. This is a property of deployed bytecode.
2. Future creator revenue can be routed away from the vault by Pons governance. This is a property of a contract MOAT does not control.

Every token page carries a fee-route panel that reads both the current recipient and any pending override directly from Pons, and shows one of four states: healthy, change pending, route changed, or unverified. It is never hidden in a tooltip, and “unverified” is never rendered as healthy.

MOAT integrates Pons as a caller and holds no privileges over it. Which means MOAT inherits every Pons owner power, including:

• Closing launches to the public, which would stop MOAT launching entirely.
• Changing the launch config: supply, fees, graduation threshold, pool fee tier.
• Changing the launch fee, the maximum creator tax, and the snipe-tax terms.
• Approving and de-approving pair assets.
• The creator-fee-recipient override described above.

MOAT’s defence against the config powers is a pin: the exact economics you were quoted are hashed into your launch transaction, and if they have moved, the launch reverts rather than proceeding on terms you never saw.

Every Pons address above was read out of the deployed Pons factory itself rather than taken from a README, so the graph is self-consistent on chain. The provenance of each one is recorded in config/PROVENANCE.md.

• Tokens are speculative. Deeper liquidity is not a price floor and not a promise. You can lose everything.
• The creator tax raises trading costs. Every buy and sell pays it. That is how the moat fills, and it is a real cost to traders.
• Compounds move the price. A compound buys the token, which pushes the price up momentarily, bounded at 3%.
• Contracts may contain bugs. Ours, Pons’s, or Uniswap’s. A bug in MOAT’s vault could lock value in a way nobody intended, precisely because there is no recovery path.
• Permanent means permanent. If the vault truly has no withdrawal function — and it does not — then liquidity added by mistake is gone too. There is no support line for this.
• Upstream governance matters. See the fee-route and Pons sections above.
• Uniswap v4 dependencies matter. The pool, the PoolManager and the Pons hook are all third-party code MOAT depends on and does not control.