$1.8B lost to exploits in 2024 alone. The difference between projects that survive and projects that become cautionary tales? Security wasn't treated as optional.
With $10B in TVL on Base, the stakes are real. This is the complete security checklist -- every item actionable, every item verifiable on-chain. Skip none of them.
Smart contract audits: who, when, and how much
When to audit
Before mainnet. Not after. Not "soon." Before users deposit a single dollar.
The timeline: weeks 1-4 development and internal testing, weeks 4-6 internal security review plus automated tools (Slither, Mythril), weeks 6-10 professional audit, weeks 10-11 fix findings, weeks 11-12 auditor re-review, week 12 deploy.
Deploying unaudited contracts with user funds at risk is gambling with other people's money.
Who to hire
Top tier firms (Trail of Bits, OpenZeppelin, Consensys Diligence) cost $100K-500K+ with 4-8 week timelines. Best for high-value protocols and complex DeFi.
Mid tier firms (Cyfrin, Peckshield, Halborn, Sherlock contests) cost $30K-100K with 2-4 week timelines. Best for most DeFi projects.
Competitive audits (Code4rena, Sherlock, Hats Finance) cost $20K-80K as bounty pools with 1-3 week timelines. Broad coverage from many eyes.
Solo auditors (independent researchers) cost $5K-30K with 1-2 week timelines. Good for smaller contracts and supplements.
How to choose
For a new protocol with under $5M TVL expected: one mid-tier audit ($30-60K) plus one competitive audit ($20-40K). Total $50-100K. This gets you both depth and breadth.
For protocols expecting over $10M TVL: one top-tier audit plus one competitive audit. Consider ongoing monitoring.
Red flags in audit firms: guaranteed "pass" before reviewing code, no public audit reports, turnaround faster than 1 week, no named auditors or track record.
After the audit
Publish the full report. Not a summary. The full report. Projects that hide audit reports are projects with something to hide.
Multisig setup with Safe
A single private key controlling protocol funds is a single point of failure. One compromised key means everything is gone.
Safe setup guide
Pre-launch: 2/3 multisig (founding team) for fast decisions with basic protection. Post-launch under $1M TVL: 3/5 multisig. Growth phase $1-10M TVL: 4/7 multisig with external signers. Mature over $10M TVL: 5/9 or higher with timelock.
Good signers: team members in different geographic locations, trusted community members or advisors, other protocol founders. Bad signers: all in the same office, anonymous accounts with no reputation, anyone who doesn't understand what they're signing.
Creating the Safe
- Go to app.safe.global
- Select Base network
- Connect wallet
- Add signer addresses (verify each address twice)
- Set threshold (e.g., 3 of 5)
- Deploy the Safe contract
Transfer contract ownership to the Safe address. Transfer treasury funds to the Safe. Update all admin functions to require Safe approval. Verify on-chain that the Safe is the actual owner.
Operational security
Hardware wallets only (Ledger, Trezor) for signers. Never sign a transaction you don't fully understand. Verify transaction data on hardware wallet screen, not just browser. Communicate signing requests through a secondary channel. Regular signer rotation plan (quarterly review).
Timelock contracts
A timelock adds a mandatory delay between when a transaction is proposed and when it can execute. This gives users time to see changes coming and exit if they disagree.
Without a timelock, a compromised multisig can drain the treasury instantly, change critical parameters without warning, or upgrade contracts to malicious code.
With a 48-hour timelock, the community has 48 hours to evaluate pending transactions and exit if needed.
Configuration
Emergency pause: 0 delay (immediate, needed to stop exploits). Parameter changes (fees, rates): 24-48 hours. Contract upgrades: 48-72 hours. Treasury transfers over 10%: 72 hours. Ownership changes: 7 days.
Implementation
Use OpenZeppelin's TimelockController with minDelay of 172800 (48 hours in seconds), proposers and executors set to the Safe address, and admin role renounced to address(0) to prevent bypassing.
Critical: renounce the admin role on the timelock after setup. If the admin role exists, the timelock can be bypassed, defeating its purpose.
Common vulnerabilities
Reentrancy
An attacker calls back into your contract before the first execution finishes, draining funds repeatedly.
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract MyContract is ReentrancyGuard {
function withdraw() external nonReentrant {
// Safe from reentrancy
}
}
Also follow the checks-effects-interactions pattern: update state before making external calls.
Front-running and sandwich attacks
An attacker sees your pending transaction in the mempool, places a transaction before and after yours, profiting from price movement.
For protocols: implement commit-reveal schemes, use private mempools for deployment, set maximum slippage parameters. For users: use DEX aggregators with MEV protection, set tight slippage tolerance.
Oracle manipulation
Attacker manipulates the price oracle your protocol relies on. Use Chainlink or Pyth oracles (not spot DEX prices). Implement TWAP over meaningful periods. Add circuit breakers for extreme price movements. Never rely on a single oracle source.
Access control failures
Functions that should be admin-only are callable by anyone. Use OpenZeppelin's AccessControl or Ownable. For every external/public function, ask: "What happens if anyone can call this?"
Upgradability risks
Upgradeable contracts let you fix bugs but also let you introduce them or rug. If you must use them: proxy upgrades behind timelock plus multisig, publish upgrade code before execution, consider making contracts immutable once stable, document which contracts are upgradeable and why.
Incident response plan
Every project needs a plan before something goes wrong. During an exploit, you won't think clearly.
Template
For a critical incident (active exploit): at T+0, trigger emergency pause and alert all multisig signers via Signal/Telegram. Do not post details publicly yet. At T+15 minutes, assess scope and contact white-hat groups (SEAL 911, Immunefi emergency). At T+1 hour, first public acknowledgment: "We're aware of an issue and investigating." Contact affected users and exchanges. At T+4 hours, detailed post-mortem draft, recovery plan, and compensation plan. At T+24 hours, full public post-mortem, fix deployed, compensation timeline announced.
Communication channels in order: X/Twitter (fastest reach), Discord announcement channel, Telegram, on-site banner, email to known users.
Pre-position your response: draft template announcements now, set up a war room channel, establish communication chain, practice a tabletop exercise quarterly.
Bug bounty program
A bug bounty incentivizes white-hat hackers to find vulnerabilities and report them instead of exploiting them.
Setting up on Immunefi
Critical bugs: $50K-$500K+ (or 10% of funds at risk). High: $10K-$50K. Medium: $1K-$10K. Low: $500-$1K.
Rule of thumb: your maximum bounty should be at least 10% of the maximum exploitable value. If someone can steal $5M, a $10K bounty isn't enough incentive to report vs. exploit.
The rug-proof checklist
This is what your community will use to evaluate your project.
Contract security
- Contracts audited by reputable firm(s)
- Audit report published publicly
- Bug bounty program live
- Source code verified on Basescan
Ownership and control
- Multisig controls all admin functions (not an EOA)
- Signer addresses publicly known
- Timelock on critical operations
- Contract ownership renounced or behind multisig plus timelock
Liquidity
- LP tokens locked or burned (with proof)
- Lock duration publicly verifiable
- Protocol-owned liquidity clearly separated from team funds
- No hidden mint functions that could create unlimited tokens
Transparency
- Team identifiable (doxxed or reputation-staked)
- Treasury wallet publicly tracked
- All token allocations documented
- Vesting schedules verifiable on-chain
Monitoring
- On-chain monitoring for suspicious transactions
- Alert system for large transfers, LP removals, ownership changes
- Community can independently verify all claims
Set up Sonarbot to monitor your protocol's contracts -- track admin transactions, large transfers, and LP changes. Your community should be able to verify your security claims independently, and real-time alerts mean issues get caught before they escalate. Checkr provides additional real-time token insights.
Security by stage
Pre-launch
Internal code review (minimum 2 developers review every line). Automated scanning (Slither, Mythril, Aderyn). Professional audit. Fix all critical and high findings. Deploy multisig. Set up timelock.
Launch week
Lock or burn LP tokens (share proof). Verify all contracts on Basescan. Publish audit report. Launch bug bounty. Set up monitoring alerts.
Post-launch (ongoing)
Monitor contract interactions daily. Review multisig transactions with community. Regular security reviews (quarterly minimum). Update dependencies (OpenZeppelin upgrades). Maintain incident response readiness.
Base-specific security considerations
Base as a Stage 1 Rollup has its own security properties. The 7-day withdrawal window for the official bridge is a security feature, not a limitation. Your contracts benefit from Ethereum's security guarantees for finality.
For token launches via Bankr, Clanker, or Doppler directly, the deployment is handled by the platform -- but you should still verify the deployed contract code on Basescan and understand what permissions exist. Doppler's bonding curve contracts have specific parameters (market cap ranges, vesting schedules, treasury allocation) that you should review. Social-first launches don't exempt you from security diligence.
For DeFi integrations with Aerodrome, Morpho, or Aave on Base, ensure you're interacting with the correct canonical contract addresses. Verify on Basescan before hardcoding any address.
The trust formula
Trust in crypto is built through verifiable actions, not promises. Every item on this checklist is something your community can independently verify on-chain.
An audit without a multisig is incomplete. A multisig without a timelock still allows instant rug. Locked LP without verified contracts doesn't prove the contract can't mint new tokens.
Do all of them. Verify all of them publicly. Let your community confirm them independently.
The projects that last on Base aren't the ones that promised security -- they're the ones that proved it on-chain. For the full picture on building trust through tokenomics, see the sustainable tokenomics guide. For liquidity locking specifics, see the liquidity strategies guide.