Frequently asked questions

When a token launches, all 1,000,000,000 tokens are deposited into a PancakeSwap Infinity concentrated-liquidity pool as one to seven price ranges that sit entirely above the starting price. Because those ranges are above the current price they hold only the new token and no quote token, so nobody has to seed the pool with BNB or USDT.

The first buyer pays quote tokens into the pool and receives tokens, which pushes the price up through the ranges. The price follows ordinary AMM maths from the first trade. There is no presale and no curve contract in between.

Every coin uses the Fair layout and starts at a market cap of about $20k. Fair puts a thin band of supply near the starting price followed by deeper ranges, so a sniper buying early gets much less supply for the same money.

Bonding-curve launchpads hold your funds in a curve contract and later migrate them to a DEX pool. Most launchpad exploits so far have happened at that migration step, or in the pre-launch state around it: pools pre-created at an attacker's price, migrations front-run, and funds stuck in curve contracts.

zk-pad skips the curve. Every token trades in its final PancakeSwap pool from the first block, with real price discovery, and it works with any Infinity-compatible router or aggregator. With nothing to migrate there is no migration to attack. As a rough guide, the “graduation” point on other launchpads corresponds to a Fair-preset token reaching 10–25× its starting market cap.

Yes. The positions are minted by and owned by the ZkPadLpLocker contract, which has no function that removes liquidity. Nobody can withdraw it, including the creator, the protocol team and the beneficiary. The hook also rejects any attempt to add liquidity that does not come from the locker, so nobody can attach their own position to the pool either.

The locker can only collect trading fees, and it sends them to the FeeVault for the token's beneficiary. Collecting is permissionless.

No. Every token is a plain OpenZeppelin ERC-20 (with Permit and Burnable) that mints exactly 1,000,000,000 tokens once, at deployment, into the pool. There is no mint function, no transfer tax, no blacklist and no pause. Holders can burn their own tokens, which can only reduce supply.

The token admin, usually the creator, can do exactly three things:

• update the image and metadata, which are cosmetic;
• lower the buy and/or sell fee, never below 1% and never upward;
• hand the admin role to someone else, or renounce it.

The admin cannot touch balances, liquidity or the beneficiary, and cannot raise fees. The fee recipient (the beneficiary id) is fixed when the token launches.

A creator can turn on a descending fee for the first moments of trading. The fee starts high, at most 80%, and decays quadratically to the normal fee F within at most 120 seconds. Timing is based on timestamps rather than blocks, because BSC produces blocks every 0.45 s and orders them through block builders.

The surcharge is not kept by the creator. It is split 25% protocol / 75% beneficiary like every other zk-pad fee. A sniper who rushes in therefore mostly funds the cause. See Fees → anti-snipe.

Every launch credits an opaque beneficiary id (a bytes32) in the FeeVault. For a private beneficiary, the creator's browser generates a fresh stealth key and packs it into a claim link (/claim#…) and a downloadable claim kit. The creator then hands these to the beneficiary out of band.

1. The beneficiary opens the link. The key sits in the URL fragment, which browsers never send to any server. The app removes it from the address bar straight away.
2. The app downloads the indexer's complete list of beneficiary balances and finds its own id locally, so the server never learns which id was checked.
3. The beneficiary signs an EIP-712 message in the browser with the stealth key and chooses a destination: a fresh address, or a Railgun 0zk address (the default). A relayer submits the transaction and is paid a small fee out of the claimed amount, so the beneficiary needs no gas and never connects a wallet.

Anyone holding the claim link can claim, so treat it like cash. Rotating the key to a new one is possible at any time from the claim portal.

A creator can name a social account (an X, GitHub, Telegram, Farcaster or Discord account) as the beneficiary without that person being involved yet. The escrow id commits to the platform's immutable numeric user id together with secret randomness. It does not commit to the handle, because handles can be resold or renamed. A salted commitment cannot be reversed by guessing handles. The creator enters that numeric id for free, or pays $0.03 USDT (x402, from their wallet, public on chain) for an attestor to look up an X, GitHub or Farcaster handle.

Coming soon: no attestors are running yet, so social escrows cannot be created or bound today. Use a private claim kit instead. The flow below describes how binds will work once attestors are online.

1. The account owner opens the bind portal and logs in through k independent attestors (one OAuth login, or one Sign In With Farcaster approval, per attestor). Each attestor checks the account and signs a BindOwner message that binds the escrow to a key generated in the owner's browser.
2. Once k signatures are collected, a timelock of 1 to 30 days starts. Re-binding an account that is already bound takes twice as long.
3. During the timelock the guardian or any single attestor can veto, and the current owner of an already-bound account can cancel. When the timelock ends without a veto the bind is final and the owner gets a normal claim kit.

Be aware that the coin's name and image often announce the account anyway. The commitment hides the wallet that eventually receives the money, and escrows that were never advertised.

At launch a creator can commit an optional fallback recipient, such as an NGO's address, and a delay of at least 180 days. Both values are hashed into the beneficiary id, so nobody can attach a different fallback later.

If the beneficiary shows no activity (no claim, ping, key rotation or bind) for longer than that delay, anyone can sweep the balances to the fallback recipient. A beneficiary who wants to keep the funds parked can ping from the claim portal to reset the clock. Without a fallback, funds wait in the vault indefinitely.

Fees are credited in the asset they were collected in, which is the token's quote token (WBNB, USDT, BTCB, XAUt…). Sell-side fees are converted to the quote token when they are collected. Small balances spread across many assets are hard to exit privately: each Railgun shield of an unusual token is easy to trace, and holding gas in many tokens is impractical.

zk-pad therefore uses USDT (BSC-USD) as the single settlement asset. Consolidation happens on demand:

• the beneficiary triggers it with a signature that carries their own minimum output; or
• the creator of a launch credited to that id can trigger it, bounded by an on-chain oracle (Chainlink or a reference pool). The USDT can only go to one of the beneficiary's pre-registered single-use Railgun shield templates, or else stays in the vault. The creator can never choose where it goes.

Railgun is an on-chain privacy system. Shielding sends USDT into a private balance owned by your 0zk… address, and nobody watching the chain can see which 0zk address received it. zk-pad supports USDT only for Railgun exits, and the shield fee is about 0.25%.

On BSC, newly shielded funds go through Private Proofs of Innocence (PPOI), a screening step against a sanctions list. For about one hour the funds show as pending in your Railgun wallet and can only be returned to where they came from. After that they are spendable privately. The screening looks at the address that submitted the transaction (our relayer), not at you.

BSC's Railgun anonymity set is small. Wait before you move funds, split amounts, and avoid unshielding exactly the amount you shielded.

No. There is no creator share: 75% of every fee goes to the beneficiary and 25% to the protocol. A creator can pick “myself” as the beneficiary. Onlookers then see only an opaque id, but the way you claim can still link it back to you. To launch for a cause, a friend, or a public figure, send them a private claim kit (social escrows are coming soon).

Lost: no one, including zk-pad, can recover a lost stealth key. Keep the claim kit file somewhere safe. If a fallback recipient was set, the funds go there after the inactivity delay.

Leaked: open the link at once and rotate the key, or claim everything. Whoever acts first wins, so act quickly.

Quote tokens come from an on-chain QuoteRegistry. The initial mainnet list is WBNB (default), USDT, USDC, USD1, FDUSD, BTCB, ETH, CAKE and XAUt (tokenized gold, the first real-world-asset pair). Every quote is a plain ERC-20. Fee-on-transfer, rebasing and KYC-gated tokens are rejected because they would break the pool, the locker or the vault.

Tier 1 quotes are curated. Tier 2 quotes are admitted once they have a registered route to USDT and pass admission checks. Disabling a quote only stops new launches; existing pools keep trading.

The issuers of XAUt, USD1 and FDUSD can pause or blacklist addresses, and these tokens (and Binance-Peg USDC) can be upgraded by their issuers. These are issuer risks that zk-pad accepts and marks with a badge:

• If an issuer freezes a pool, trading in every launch paired with that quote stops. The liquidity is locked forever by design, so there is nothing to migrate to.
• If an issuer freezes the FeeVault, every beneficiary's balance in that asset is stuck. Balances in other assets are unaffected because each asset has its own ledger.
• An upgrade could add transfer fees or hooks. The contracts use balance-delta accounting so that this fails safely, but existing pools cannot be protected.

Pick WBNB or USDT unless you have a specific reason not to. They also give beneficiaries the best privacy exits.

Anyone can deploy a look-alike token. Before buying, check:

1. The token was created by the zk-pad factory: its TokenLaunched event exists, and the token's factory() returns the factory address published for this network.
2. Its pool's hook is ZkPadHook, and the pool uses the dynamic-fee flag with tick spacing 200. The token page shows the pool id; compare it on BscScan.
3. Total supply is exactly 1,000,000,000 and the liquidity positions belong to ZkPadLpLocker.
4. The token contract's verified source matches ZkPadToken, so the admin can only change the image and metadata.
5. The quote token is on the registry list, and you understand its tier. Check the badge on the token card.

Read the description with care: claims about who the beneficiary is are written by the creator and are not verified by zk-pad.

No. zk-pad guarantees that 75% of fees are credited to the committed beneficiary id. It cannot guarantee that the person or organisation in the coin's name actually holds the claim link. For social escrows, only the real account owner can bind after k attestors agree and the timelock passes. For private claim kits, you are trusting the creator to have handed the link to the person they say.