No-rug guarantees
These properties are enforced by contract code, not by promises. They still depend on the code being correct, and it has not yet been audited.
Fixed supply
- Every coin has exactly 1,000,000,000 tokens (18 decimals), minted once, at launch, to the factory and placed in the pool.
- There is no mint function. Anyone can burn their own tokens (
ERC20Burnable), which can only reduce supply. - The token is a plain OpenZeppelin ERC20 with
ERC20Permit. There is no transfer tax, no blacklist, no pause and no max-wallet.
Liquidity locked forever
- 100% of the supply goes into positions owned by the
ZkPadLpLocker. - The positions live directly in the PancakeSwap Infinity pool manager. There is no position NFT to transfer.
- The locker has no remove-liquidity code path and no owner withdraw function.
- Only the locker can add liquidity to a zk-pad pool.
No owner powers over balances
| Role | What it can do | What it cannot do |
|---|---|---|
| Token admin (chosen by the creator, can be renounced) | Update the image and metadata; lower the fee (never below 1%); hand over or renounce the role | Mint, burn others' tokens, pause, blacklist, raise the fee, touch liquidity or fees |
| Factory owner (currently a single EOA; a multisig is planned) | Enable/disable hooks, lockers, MEV modules and quote tokens for new launches (quote tokens also via delegated quote-token admins); set the treasury; deprecate the factory (stops new launches) | Change any existing coin, its pool, its fee or its beneficiary |
| FeeVault owner (currently a single EOA; a multisig is planned) | Allow withdrawal adapters and attestors; set the guardian, bind delay, shield adapter and minimum creator shield; replace the consolidation registry (USDT and the launch factory are set once); recover tokens sent to the vault outside deposit | Move any beneficiary's balance on the beneficiary-signed path; redirect a beneficiary; redirect a registered shield template. Caveat: the owner configures the price bound of creator-triggered consolidations, so a malicious owner working with a creator could drain launch-credited balances (see trust assumptions) |
The full list, and the current single-key administration, is in trust assumptions.
No one can redirect the beneficiary
The beneficiary id is fixed at launch and recorded in the locker. Neither the creator nor the protocol can change it. Only the beneficiary's own key can claim. For social-account escrows, the only way to assign an owner is the timelocked, vetoable attestor bind.
What can still go wrong
"No rug" is about the contracts. It does not protect you from:
- the coin's price going to zero;
- the creator or early buyers selling;
- a frozen quote token, a PancakeSwap Infinity pause, or a bug.
See the risk disclosure.