TL;DR

BescPad's factory deploys from a fixed standard contract template. Only the parameters change between launches — the same bytecode runs every token, so buyers can verify any BescPad-deployed token uses the canonical template by comparing its bytecode against another. Builders get an integrated LP locker, the standard fee envelope (see below), a one-click renounce ownership button, and a dedicated tax-free LP helper that exempts only itself, not arbitrary contracts. Presales auto-refund if soft cap fails. Buyers can verify everything on-chain in under a minute.

The five common rug vectors — and what BescPad does about them

1. The team withdraws LP from the DEX pair

The single most common rug. The team holds the LP tokens that represent ownership of the DEX trading pair; they call removeLiquidity() on the router, take the BESC out, and leave holders with worthless tokens.

BescPad's protection: the LP Locker at /locker. The team transfers LP tokens into a time-locked vault on-chain. While locked, no one — not the team, not BescPad — can withdraw them. Anyone can read the lock state directly from the explorer.

For maximum trust, the LP can be burned instead of locked — sent to 0x000…dead. That's permanent and irreversible. We support both.

2. The owner changes fees to 100% (effective honeypot)

If a token's owner can update fees, they can set sell fee to 99% after launch — sellers receive ~nothing, the team pockets the difference.

BescPad's protection: two layers. First, every standard launch follows BescPad's official fee envelope — buy fee maximum 10%, sell fee maximum 15%. Those are the platform's standard parameters; a deployer can set anything from 0% up to those limits but can never go above. Second, the Renounce Ownership button in the factory permanently sets the owner to address(0). Once renounced, no owner-only function (including fee changes) can ever be called again. It's the strongest non-revocable trust signal a team can ship. Projects that need fees outside the standard envelope go through a separate custom-launch process and are clearly identifiable on-chain as non-standard.

3. Hidden mint function

A token's contract includes a privileged mint() that the owner can call to print more supply, diluting holders.

BescPad's protection: the factory template has no post-deployment mint function. Total supply is set at deployment and is fixed forever — you can verify this on the explorer by reading the contract source. Because every BescPad token uses the same template, anyone can compare bytecode to confirm.

4. Honeypot — you can buy but can't sell

The contract has logic that lets the deployer (and a whitelist) trade freely while reverting all other sells. Looks great in the wallet, impossible to exit.

BescPad's protection: the template's transfer function is symmetric — the same code path runs whether you're buying or selling. There's no privileged-address whitelist that gets free transfers. You can simulate a sell on the explorer before buying to confirm.

5. Privileged transfer / blacklist function

The owner can blacklist arbitrary addresses, preventing them from selling. Used to lock holders out one-by-one.

BescPad's protection: the template does not include blacklisting. The only address-level control is the tax-free LP helper exemption, and that exempts only one specific contract from the trade tax (the helper itself) — not from selling. No address can be prevented from transacting.

What BescPad ships by default

The factory and supporting tools are designed so the safe path is the easy path:

• Standard contract template — every BescPad token deploys the same bytecode, just parameterized. Buyers can verify any token uses the canonical template by comparing bytecode against another BescPad-deployed token on the explorer.
• Standard fee envelope — every BescPad standard launch follows the same fee rules: buy fee 0–10%, sell fee 0–15%, transfer fee 0–5%. The deployer picks any value within that range; the contract template prevents going above. Individual fee components (marketing, liquidity, burn) each have their own minimums and maximums inside the envelope. Custom-launch deployments outside the standard envelope are a separate product (see /services) and are clearly distinguishable on-chain.
• Anti-whale guards — optional max-transaction and max-wallet limits, with enforced minimums (typically ≥ 0.5% of supply) so misconfigurations can't make the token unusable.
• One-click renounce ownership — the factory's deployment success screen has a dedicated button that calls renounceOwnership(). Once clicked, no owner-only function can ever fire.
• LP Locker — integrated UI at /locker for time-locked LP vaults. Anyone can verify a lock's status, unlock date, and beneficiary on-chain.
• Tax-free LP helper — the dedicated tool at /tax-free-lp uses a signed exemption tied to one specific contract address. Adding LP through any other DEX still pays the trade tax, so the tax-free behavior can't be abused by arbitrary contracts.
• Presale auto-refund — the presale contract enforces refunds at the protocol level if soft cap isn't reached. No team intervention, no support tickets, no "trust me" — the code runs automatically.
• Atomic listing — when a presale succeeds, the contract auto-creates the LP and auto-locks it in the same transaction. There's no gap during which the team could "forget" to list or rug.

Buyer's checklist — before you commit

Whatever the team says, verify on-chain. It takes under a minute:

1. Is the LP locked or burned? — open /locker, search the token. A genuine lock shows the LP amount, beneficiary, and unlock date with an explorer link. If "LP locked" is claimed but doesn't appear in the locker, that's a hard stop.
2. Is ownership renounced? — open the explorer for the contract address. The owner field should read 0x0000…0000. If a real address is still listed as owner, the team can change fees at will.
3. Do the on-chain fees match what's advertised? — the contract exposes buyFee(), sellFee(), and maxWalletAmount() as public getters. Read them on the explorer. The advertised numbers should match.
4. How is supply distributed? — the explorer's "Holders" tab shows the top wallets. One wallet holding 50%+ is a centralization risk; the team's own marketing wallet should be clearly labeled.
5. Is the contract verified? — verified source code means anyone can read it. An unverified contract is a black box.
6. Does the BescPad page show the token in its registry? — tokens with at least $100 of pivot-paired liquidity appear in /swap's picker. Absence from the registry usually means the LP is thin or the team hasn't paired against a hub token.

Red flags to walk away from

• Unlocked LP after launch. Locking is so cheap and easy that not doing it is a deliberate choice. Walk away.
• Owner still has full powers, days into trading. Renounce is one click. If they haven't, they're keeping the option to change things.
• Buy works, sell reverts. Test with a tiny amount. If the sell quote doesn't compute (or fails on execution), it's a honeypot. The error itself is a tell.
• Contract source not verified. Means you can't read what the code actually does. Hard pass.
• Liquidity is wildly mismatched with the marketing. A token with 5,000 holders but $200 in LP cannot support normal trading. Either holders are airdropped junk, or the LP got rugged earlier.
• Top holder concentration. One wallet with 30%+ is a market risk; one wallet with 50%+ can move the price unilaterally.
• "Anti-bot" that's actually a blacklist. Some templates include setBot(address, bool) — the owner can flag any address as a bot and prevent them from selling. BescPad's template does not include this.

What we can't protect against

BescPad's tools defend against on-chain exploits and the standard rug patterns. They cannot defend against:

• Abandonment. The team can lock LP, renounce ownership, then disappear. The token will still trade, but the project itself is dead. Locking + renouncing is necessary but not sufficient evidence of a real project.
• Bad project management. Token economics that look fine on day one but unravel under market pressure. No contract can fix a flawed business model.
• Social engineering. Phishing sites, fake Telegram admins asking you to "verify" your wallet, fake bridge UIs. Always check the URL bar.
• Wallet / device compromises. If your seed phrase leaks, no on-chain protection helps.
• Outright fraud disguised as legitimacy. A team that locks LP, renounces ownership, then runs an unrelated rug on social media to dump their own tokens. The on-chain mechanics are fine; the marketing was the rug.

Treat the on-chain checklist as a necessary minimum, not a guarantee.

FAQ

What's a rug pull, exactly?

The team drains the project's own liquidity pool, leaving holders with tokens they cannot sell at any meaningful price. The most common technique is the team withdrawing LP tokens from the DEX pair using removeLiquidity(). Locking LP for a fixed duration makes this provably impossible until the lock expires.

How do I check if a token has locked LP on BescPad?

Open /locker and search by token address or pair address. A real lock displays the locked LP amount, the beneficiary wallet, and the unlock date, with a link to the on-chain vault contract that anyone can verify.

What does "renounced ownership" mean?

It sets the contract's owner to address(0), which means no transaction signed by any wallet can ever call an onlyOwner function. Fees, limits, trading status — everything ownerable becomes immutable. It's permanent and irreversible.

How do I know a BescPad-deployed token uses the real factory template?

The factory deploys a fixed standard contract template — the same code across every deployment, only parameters (name, fees, supply) differ. Anyone can verify a token uses the canonical bytecode by comparing it against another BescPad-deployed token on the explorer. Consistent bytecode + the platform's built-in protections are how a standard launch establishes trust.

What if a presale doesn't reach its soft cap?

Every contributor gets a full automatic refund at the protocol level. There's no team action required, no support tickets, no waiting. The presale contract holds the BESC in escrow and releases it back proportionally when the soft cap fails.

Can a token's owner blacklist my wallet?

Not on a BescPad-template token. The template does not include any address-level blacklisting or trade-prevention functions. The only on-chain address control is the tax-free LP helper exemption, which excludes a single contract (the helper itself) from the trade tax. No wallet can be prevented from buying, holding, or selling.

How is the tax-free LP helper safe?

Participating tokens whitelist only the helper contract's address as exempt from the trade tax. Any other contract or DEX still pays the tax. Because the exemption is bound to a specific contract address (not a wallet or role), arbitrary addresses can never be granted tax-free transfer rights.

Are locks reversible?

No. The lock contract enforces the unlock date on-chain. Even BescPad cannot release locked LP before the date the locker recorded.