Vanity addresses

An address is normally whatever the chain hands you. A vanity address is found by searching: try candidate after candidate until one produces an address matching your pattern. Because each extra character multiplies the search, short patterns are quick and long ones are effectively impossible - the same physics on both chains, even though what gets searched differs.

The whole search runs in your browser, spread across your CPU cores in background workers. Nothing is sent to a server, and the feature is off by default.

On Robinhood Chain, BSC, Base, Ethereum and Arc, the launcher deploys your token with CREATE2, which means the address is fully determined before deployment by a number called the salt:

address = last20( keccak256( 0xff ++ launcher ++ salt ++ initCodeHash ) )

• You choose a hex prefix and/or suffix (characters 0-9, a-f, after the 0x).
• The grinder tries millions of salts locally - no RPC call per candidate - until one yields an address matching your pattern, then hands that winning salt to the launch transaction. The predicted address is shown in the form before you sign, so you can announce it early.
• The address depends on your token’s name, ticker and supply (and on the pair asset for a custom-pair launch), so you fix those first; changing them afterwards would change the address.
• The init-code hash is read live from the launcher you are about to call, so a launcher redeploy can never make the form predict one address and deploy another.

It lives in the launch form’s address section and is Live for direct launches on Robinhood Chain, BSC (both liquidity venues), Base, Ethereum and Arc, whether the token is quoted in the native coin or a custom pair.

A predicted address is only worth announcing if nobody else can claim it first. With an ordinary CREATE2 launcher, anyone who sees your announced address and salt could in principle race you and deploy at it. BSC's PancakeSwap Infinity launcher closes that door: it binds every non-zero salt to the creator.

• The first 20 bytes of the salt must equal the connected wallet's address; otherwise the launch reverts with SaltNotOwned. Nobody else can deploy at a salt that carries your address in it, so a pre-announced vanity address cannot be hijacked by front-running.
• The grinder therefore grinds only the remaining 96 bits of the salt - still far more candidates than any pattern this form allows will ever need. The predicted-address formula is unchanged.
• Salt 0 means “no vanity”: the launcher derives its own address as before.
• Switching wallets re-grinds. A salt ground under one wallet carries that wallet's address, so the form discards it and searches again for the new one. If a stale salt ever reaches the chain, the wallet shows: “The custom address salt was generated for a different venue or wallet - re-generate it under PancakeSwap Infinity (or turn the custom address off) and launch again.”

The Uniswap V4 launchers - on Robinhood Chain, Base, Ethereum, Arc and BSC's Uniswap V4 venue - accept any salt as before; the binding is an Infinity-only rule, adopted from the Infinity self-audit (finding B-L1). See Security.

Solana has no CREATE2. A token’s address is a public key, so a vanity mint is found by generating keypairs until one’s public key matches your pattern - the exact same mechanism that gives pump.fun’s own tokens their …pump ending.

• You choose a base58 prefix and/or suffix, optionally case-insensitive (so PUMP also accepts pump, Pump, …).
• Because the bundle already mints the token in your browser, the winning keypair is used right there at creation and never leaves the page.

Each additional character multiplies the work by the alphabet size (16 for hex, 58 for base58), so cost is exponential in pattern length. The grinder caps the combined prefix + suffix length and warns before you commit to something slow:

A four-character base58 suffix like pump is about the practical browser limit; a fifth character can take a long time, and the form tells you so rather than letting you wait blindly.