Smart contract pre-procurement security checklist

40 items you can use in an internal review before a formal audit.

Available in Japanese only: this checklist is currently published in Japanese only. The overview below is in English, but the full 40-item checklist with commentary has not yet been translated.

This resource brings together, in a 40-item checklist, the security points a company should check internally before placing a smart contract development order, across four areas: design, tokenomics, infrastructure/operations, and audit/legal. It works backward from past hacking incidents in DeFi, NFTs, and RWA.

Each item includes commentary on background, what to check, and recommended countermeasures, so that even a point that is hard to judge from the title alone becomes understandable.

How this resource is organized

• Section 2: Design-layer checks (10 items)
• Section 3: Tokenomics-design checks (10 items)
• Section 4: Infrastructure & operations checks (10 items)
• Section 5: Audit & legal checks (10 items)

Section 2: Design-layer checks (10 items)

Points to confirm at the smart contract design stage — upgrade approach, access control, and function visibility, focused on the parts that are hard to fix once deployed.

• The upgrade approach (Proxy / Diamond / Immutable) has a stated rationale
• Access control (onlyOwner / role-based) follows the principle of least privilege
• Function visibility (public / external / internal) is kept to the minimum needed
• Reentrancy protection (the checks-effects-interactions pattern / ReentrancyGuard) is built in
• Gas limits and the possibility of unbounded loops have been ruled out
• Overflow protection for numeric calculations (SafeMath / Solidity 0.8+) is in place
• Events are emitted whenever an important state change occurs
• The storage layout avoids slot collisions across upgrades
• Meta-transaction replay protection (nonce / chainId) is built in
• Return values from external contract calls are always checked

Section 3: Tokenomics-design checks (10 items)

Points around token economics, liquidity, oracle references, and governance — the structures attackers exploit for economic gain.

• Oracle price references use multiple oracles (e.g. Chainlink)
• A TWAP (time-weighted average price) is built in for manipulation resistance
• Collateral ratios are set conservatively, accounting for flash-loan resistance
• A minimum liquidity floor (minimum pool TVL) is set
• Governance proposals go through a timelock rather than executing immediately
• The design prevents instant voting power gained via a flash-loaned governance token
• The incentive design (burn, staking, distribution) is internally consistent
• Economic-attack simulation has been carried out, or is planned
• Emergency-pause authority and its activation conditions are clearly defined
• The fee model and token distribution are transparent

Section 4: Infrastructure & operations checks (10 items)

Points around key management, multi-sig, the frontend, and monitoring — the operational foundation outside the contract itself.

• The multi-sig threshold (M of N) is set conservatively
• An HSM or hardware wallet is used
• Private-key custody is geographically and organizationally distributed
• Access to the frontend infrastructure (DNS / CDN / Cloudflare) is minimized
• Environment variables and API keys are securely protected
• Deployment authority is limited to the people who need it
• A logging and monitoring platform is running, with anomaly detection
• An incident-response runbook is in place (emergency stop, asset protection, disclosure)
• Backup and recovery procedures are documented and tested regularly
• The upgrade procedure is tested, with a staged-deployment mechanism

Section 5: Audit & legal checks (10 items)

Points around third-party audits, bounty programs, and regulatory/legal compliance.

• Audit-firm selection criteria (track record, specialty, cost) are clear
• Critical vulnerabilities are planned to be confirmed by at least two audit firms
• A bug-bounty program (e.g. via Immunefi) has an operating policy in place
• A response process for critical audit findings is defined in advance
• A relationship with a law firm is in place
• Regulatory points (Financial Instruments and Exchange Act, Payment Services Act) have been worked through
• KYC/AML arrangements (where needed) have been designed
• The terms of service and privacy policy have had legal review
• Insurance protocols (e.g. Nexus Mutual) have been considered
• A disclosure policy (vulnerability disclosure / emergency disclosure) has been decided

How to use the scoring sheet

32+ items marked Yes

You are ready to engage an audit firm and place an order — proceed to a formal audit request.

24–31 items marked Yes

The main issues are covered — organize the remaining unconfirmed items internally before considering an order.

Fewer than 24 items marked Yes

Design-stage organization is still incomplete — internal discussion or consulting to structure the issues is recommended.

Design lessons from past incidents

Each item in this checklist is worked backward from a real hacking incident. Representative cases and the checklist items they map to:

Talk to Netsujo

This checklist can be used entirely on your own, or with Netsujo's pre-procurement internal review support. If many items are "Not yet confirmed" and you are not sure where to start, a free 30-minute first consultation can help work through the issues together. Our standard scope of support includes:

• Internal interviews and structuring for each checklist item (consulting)
• Smart contract design review
• Coordination with an external audit firm (pre-audit preparation, interpreting findings)
• Support responding to critical audit findings
• Ongoing quarterly review during operation