How buying works, whichever app you use

Buying through peg.fun's swap UI or any external router — 1inch, CowSwap, ParaSwap, Uniswap v3, Universal Router, or the official Uniswap widget — mints your glyphs once a token has graduated, up to 700 tokens per transaction. Above that the swap fails outright instead of silently shorting you. Before graduation there is no external route to worry about: peg.fun's own interface is the only path there is.

The short version

Once a token has graduated, buying PEG through any router — peg.fun's own swap UI, 1inch, CowSwap, ParaSwap, Uniswap v3, Universal Router, or the official Uniswap widget — mints you glyphs. There is one limit: up to 700 tokens per transaction. Above that, the swap fails outright rather than silently shorting you of art you paid for.

Before a token graduates, there is no external route to worry about at all. Pool liquidity doesn't exist yet, no aggregator has anything to route against, so peg.fun's own interface is the only path there is — and always was.

What this page used to say

Before the v28 cohort (September 2026), this page told a different story: aggregator and v3-router buys silently lost their glyph mint, permanently and without recourse, because minting required a router-specific pre-registration call that only peg.fun's own router made. That mechanism is gone from the contract entirely, not merely deprecated in place. If you read an older cached copy of this page, or a third-party writeup that quotes the old claim, it is describing a version of peg.fun that no longer exists.

The 700-token limit, in plain words

The limit is denominated in PEG tokens, not dollars. On an expensive token a large ETH buy comfortably clears 700 tokens; on a cheap token, a large purchase in dollar terms can still hit the 700-token ceiling and need a second (or third) transaction to fill the rest — that ceiling is double what it was before this phase, so it now takes roughly twice the dollar size of a purchase to reach it. This isn't a new rule invented for this page — it's the same per-transaction bound peg.fun's own swap UI has clamped against since before graduation existed, now stated for every router rather than left for one to discover by reverting.

Through peg.fun's own swap UI, you will never see this limit — the interface sizes your order under the cap automatically and refunds anything left over, so an oversized buy fills partially rather than failing.

Through any other router, an order that would mint more than 700 tokens in one transaction reverts. Nothing is taken, you only pay gas. Size the order down, or split it across transactions.

If your router takes two hops

Some routers (a common aggregator shape) take the tokens to their own address first, then forward them to you in a second transfer. That's fine — the glyphs follow the balance to your wallet on the forwarding hop, same as any other transfer. The one thing worth knowing: your glyphs inherit the router's arrival timestamp, not the moment you receive them from the router. In practice this is the correct cohort to inherit — it's when the tokens actually left the pool — but it can look surprising if you're watching the clock closely.

Why this works for every router now

The glyph mint fires when PEG arrives at a wallet directly from the Uniswap v4 pool, whichever contract happened to route the swap there. It no longer depends on the router having pre-registered the recipient. That's what makes "any router" true rather than a claim resting on a specific integration — there is nothing for a router to integrate.

Can I get a refund?

If you bought PEG and didn't get the glyphs you expected, first check whether your buy exceeded 700 tokens in one transaction — the fill amount (not the requested amount) determines the mint count. Outside of that, the contract has no refund mechanism; you can always sell PEG back through peg.fun's swap interface to recover ETH at the current price.

For aggregators and integrators

Routing PEG requires no partnership, no allowlist, and no special integration — any contract or EOA can buy through the pool like any other Uniswap v4 token, and the mint follows automatically. This section covers the two things worth knowing before you quote a fill.

peg.fun's own router: DirectSwap.buyExactInFor

You don't need to use DirectSwap — any route into the pool mints correctly now. But if you want the same clamp-and-refund sizing peg.fun's own UI gets (rather than a hard revert above the cap), DirectSwap exposes a pass-through entry point:

function buyExactInFor(
    address hook,          // the token's PegHook (one per collection)
    address recipient,     // the END USER — objects and tokens both land here
    uint256 minTokensOut,  // ERC-20 slippage guard
    uint256 minObjects     // OBJECT guard — see below
) external payable;

ETH comes from msg.sender; tokens and glyphs both go to recipient, and any leftover ETH (including the refund from an oversized order clamped to the cap) goes to recipient rather than the caller, so an integrating router stays a clean pass-through.

Set minObjects — it is a glyph-level slippage guard

minObjects reverts the transaction if fewer glyphs than expected are minted. Treat it like minTokensOut: it's the difference between "the swap succeeded" and "the swap succeeded and the user actually received their art."

Two things determine how many glyphs a buy mints:

  1. A sub-1-token buy CAN mint a glyph — held credit accumulates across transactions. peg.fun tracks each wallet's accumulated hook-routed purchase amount (hookCredit, a public getter on the token contract) separately from its ERC-20 balance. A wallet that buys 0.3 tokens four times through the pool mints its first glyph on the fourth buy, not zero forever. Read hookCredit(address) before the buy to predict the count: newPegs = floor((hookCredit(recipient) + expectedTokensOut) / 1e18).
  2. The mint follows the recipient's whole-token count. If your router takes tokens to itself and forwards them in a second transfer, the glyphs still arrive with the tokens on that forwarding hop (see "If your router takes two hops" above) — but held credit for a not-yet-whole balance accrues to whichever address is currently holding it, so a router that splits a single user's buy across multiple of its own internal hops can produce a different rounding outcome than a direct buy would. Passing the end user as recipient on a direct hook-routed call avoids the question entirely.

Fee, for your quote math: the pre-graduation curve and the post-graduation Uniswap v4 pool both charge 2.5% each way (buy and sell) — 2.25% hook-dispatched plus the pool's native 0.25% post-graduation.

The 700-token cap applies to every router, without exception

One transaction may mint at most 700 objects — pre- and post-graduation, through any router, with no allowlist or identity check. This is the one thing most likely to make an integration's quote disagree with its fill.

  • Through DirectSwap — your order is clamped, not rejected. The router sizes the swap to the cap before unlocking the pool, buys that much, and refunds the remainder to recipient. A 10 ETH order on a fresh curve does not fail — it fills partially and the rest lands with the end user.
  • Through any other router, pre-graduation — the swap reverts with MintCapExceeded(uint256 requestedPegs, uint256 capPegs). Nothing is taken, you pay gas.
  • Through any other router, post-graduation — the swap reverts the same way. This is new as of the v28 cohort: the cap used to apply only to DirectSwap-sized buys after graduation; it now applies identically to every caller, checked against the tokens actually leaving the pool rather than any router's declared intent.

Everything you need to compute the ceiling yourself is public on the hook.

Pre-graduation:

reserveToken = R_tok_v()   - realTokensOut()
reserveEth   = R_eth_v()   + realEthCollected()

if (reserveToken <= 700e18) -> no bound applies

netForCap = 700e18 * reserveEth / (reserveToken - 700e18)
maxGrossEth = netForCap * 10_000 / (10_000 - 250)     // add back the 2.5% fee

A threshold-crossing buy is bounded a second time, by the ETH still needed to reach migrationThreshold() — take the smaller of the two ceilings.

Post-graduation the ceiling comes from the pool rather than the curve: read slot0.sqrtPriceX96 and getLiquidity() for poolKey().toId(), then solve for the ETH that moves the price by 700e18 of currency1 and gross it up by the same 2.5%. Pool liquidity is full-range and constant across ticks, so the single-range v4 formulas are exact here rather than an approximation.

Why a cap exists at all: minting is the leg nearest the chain's 32,000,000 per-transaction gas cap. Without the bound, an oversized buy would die with an out-of-gas revert that nothing on chain explained. A named error and a clamped fill (through DirectSwap) are both strictly better failures.

Chain support

peg.fun runs on Robinhood Chain (Arbitrum Orbit L2; mainnet chain id 4663, testnet 46630). A router that does not index this chain cannot list peg.fun tokens at all — chain support comes first, routing second.

Why peg.fun still ships DirectSwap

If any router works now, why does DirectSwap still exist? Two reasons: it's the clamp-and-refund behavior peg.fun's own UI relies on so a user's oversized buy fills instead of reverting, and it's a stable, permissionless, no-owner entry point any integrator can build against without depending on Uniswap's own router surface staying identical release to release. It isn't a gate anymore, it's a convenience.