L
What this page is: Actionable requirements and tasks for each of the 25 protocol functions. Must Have = non-negotiable requirements. Must Do = actions you must take before or during evaluation.
Scope: Guidelines apply to the functions relevant to your project type (Crypto/Web3, SaaS, E-commerce, Business). See Protocol for scope mapping.
CORE LOGIC (F01–F08)
Code correctness, reentrancy, overflow/underflow, storage ordering. OWASP Smart Contract Top 10 alignment.
MUST HAVE
- Reentrancy guards on all state-changing external calls (checks-effects-interactions pattern or OpenZeppelin ReentrancyGuard)
- Overflow/underflow protection (Solidity 0.8+ or OpenZeppelin SafeMath for legacy)
- No uninitialized storage variables or dangerous delegatecall
- Storage write ordering documented; no reentrancy via cross-contract calls
- Use of audited libraries (OpenZeppelin, Solmate) where applicable; no untested custom crypto
MUST DO
- Run Slither, Mythril or similar static analysis; address critical/high findings
- Map all external/public entry points and trace privilege flows
- Verify unchecked blocks are safe; document any intentional use
- Provide evidence of manual code review or third-party audit
RBAC, modifiers, init security, privilege escalation, arbitrary call prevention.
MUST HAVE
- Role-based access control (or equivalent) for privileged functions
- Modifiers on every function that requires authorization; no reliance on implicit checks
- Init/constructor functions protected; no re-initialization vulnerability
- No arbitrary external calls from admin (or timelock on such calls)
- Least-privilege: roles grant minimum necessary permissions
MUST DO
- Document all roles and their capabilities
- Verify no privilege escalation path (e.g. user → admin)
- Test init functions cannot be called twice or by unauthorised parties
- Provide access control matrix (role × function)
Liquidity lock mechanics, duration, bypass prevention, slippage. Required for DeFi/token projects.
MUST HAVE
- LP tokens locked in audited locker (Team Finance, Unicrypt, or equivalent) or custom timelock contract
- Minimum lock duration of 12 months (365 days) for fair launch; longer preferred
- On-chain verification: lock contract address and lock expiry visible on block explorer
- No withdrawal bypass; no backdoor to release LP before expiry
- Slippage protection when locking/unlocking; no sandwich vulnerability on lock creation
MUST DO
- Provide lock transaction hash and locker contract address
- Verify lock duration and expiry date on-chain
- Document who holds lock keys (if multi-sig) and revocation process
- Confirm no team/dev wallet can withdraw LP before lock expiry
Admin keys, multisig, centralization risk. Single-owner = SPOF = DENIED.
MUST HAVE
- Multisig for admin ops: minimum 2-of-3, preferred 3-of-5 or (N/2)+1 threshold
- Never M=1 (single key) or M=N (one lost key locks all) for production
- Keys distributed across different signers, hardware vendors, geographies
- For assets >$1M: 7+ signers recommended
- No single EOA as owner of critical contracts
MUST DO
- Provide multisig configuration (M-of-N) and signer list (roles, not keys)
- Document key storage (HSM, hardware wallet, vault)
- Implement key rotation schedule (e.g. quarterly); document last rotation
- If single owner exists for non-critical ops, document and justify; critical = multisig only
Math precision, slippage, flash loans, rounding, token edge cases.
MUST HAVE
- Correct decimal scaling for all financial calculations; no precision loss in critical paths
- Slippage protection (minOut, deadline) on swaps and LP operations
- Flash loan resistance where applicable (or explicit acceptance of flash loan risk)
- Rounding/truncation documented; no token donation attack vectors
- Handle fee-on-transfer, rebasing, and non-standard ERC20 tokens if integrated
MUST DO
- Trace all math paths; document rounding direction and impact
- Test with extreme inputs (tiny amounts, huge amounts, fee-on-transfer tokens)
- Verify flash loan scenarios cannot drain protocol
- Provide unit tests for business logic edge cases
Price feed staleness, manipulation vectors, TWAP vs spot.
MUST HAVE
- Staleness check on price feeds; reject stale data (e.g. >1 heartbeat)
- Use TWAP or equivalent where manipulation is a concern; not spot-only for large positions
- Document oracle source and update frequency
- Cross-chain: validate message origin and sequencer; no outdated data
MUST DO
- Document oracle architecture and trust assumptions
- Verify manipulation cost exceeds attack gain where critical
- Test with stale/invalid oracle response; ensure graceful handling
- Provide oracle documentation (Chainlink, Pyth, custom) and parameters
Access proof, documentation aligned with implementation, no hidden paths.
MUST HAVE
- Documentation that matches deployed implementation; no material discrepancy
- Access proof: evidence you control the systems under evaluation
- No hidden admin paths, backdoors or undeclared upgrade capabilities
- All privileged capabilities documented; no "we forgot to mention" findings
MUST DO
- Provide source code, deployment addresses, verification links
- Demonstrate access (read-only or guided) to infra, repos, admin panels
- Declare all upgrade paths, proxy patterns, timelocks
- Reconcile docs vs implementation before evaluation starts
Proxy init, storage layout, upgrade path, no uninitialized proxies.
MUST HAVE
- Proxy initialization protected; no re-initialization attack
- Storage layout preserved across upgrades; no slot collision
- Upgrade path (if any) uses timelock or governance; no instant upgrade by single key
- No uninitialized proxy pointing at implementation
MUST DO
- Document proxy architecture (UUPS, Transparent, Beacon)
- Verify init function cannot be re-called
- Provide storage layout diff between versions if upgradeable
- Test upgrade flow in staging; document rollback procedure
OPERATIONAL STABILITY (F09–F17)
RTO/RPO defined, restore tested, backup procedures.
MUST HAVE
- Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined per workload
- Backup procedures documented and automated where possible
- Restore capability tested at least annually
- Backups stored in geographically separate location; no single-region dependency
MUST DO
- Document RTO/RPO for critical systems
- Perform restore test and document result
- Provide backup schedule, retention, and verification process
- Confirm backup encryption and access control
Alerting, anomaly detection, visibility, log retention.
MUST HAVE
- Alerts on critical failures (availability, errors, security events)
- Visibility into critical paths (API latency, error rates, auth failures)
- Log retention sufficient for incident investigation (min. 30 days, 90+ for compliance)
- 24/7 alert response or defined on-call
MUST DO
- Provide monitoring architecture diagram
- Document alert thresholds and escalation path
- Demonstrate anomaly detection or equivalent (e.g. unusual tx volume)
- Confirm log storage and access controls
Runbooks, escalation, contact chain. Detect → Analyze → Contain → Eradicate → Recover.
MUST HAVE
- Incident response runbooks for critical scenarios (breach, outage, exploit)
- Defined escalation path with contact information
- Roles and responsibilities documented
- Runbooks updated regularly; living documents not shelfware
MUST DO
- Provide runbook index and at least one full runbook (e.g. "Security Incident")
- Document Detect → Analyze → Contain → Eradicate → Recover flow
- Define severity levels and response SLA
- Conduct tabletop or drill annually; document outcome
Auth, JWT, key storage, signing flow security.
MUST HAVE
- Secure auth mechanism (OAuth2, JWT with proper validation, or equivalent)
- Session timeout and invalidation on logout
- No keys or secrets in client-side code or logs
- Signing flows protected; no downgrade or replay attacks
MUST DO
- Document auth flow and session lifecycle
- Verify JWT validation (signature, expiry, issuer)
- Confirm key storage (HSM, vault, env) and access control
- Test session fixation and hijacking scenarios
Abuse prevention, DDoS mitigation, API limits.
MUST HAVE
- Rate limiting on public APIs and auth endpoints
- DDoS mitigation (WAF, CDN, or cloud-native)
- Resource exhaustion protection (timeouts, connection limits)
- No unbounded operations that can be abused at scale
MUST DO
- Document rate limits per endpoint or user
- Verify DDoS controls in place
- Test abuse scenarios (rapid requests, large payloads)
- Provide WAF/CDN config or equivalent evidence
Libs assessed, CVEs addressed, SBOM, version pinning.
MUST HAVE
- Software Bill of Materials (SBOM) or dependency list with versions
- No known critical/high CVEs in production dependencies
- Version pinning (lockfile) for reproducible builds
- Audit of direct and transitive dependencies; trust boundaries documented
MUST DO
- Run npm audit / pip audit / OWASP dep-scan (or equivalent) and remediate critical/high
- Provide SBOM (SPDX or CycloneDX) or dependency report
- Document process for dependency updates and CVE monitoring
- Integrate vulnerability scanning in CI/CD
Proxy safety, storage layout, rollback, no destructive upgrades.
MUST HAVE
- Storage layout compatibility across upgrades; no slot collision
- Rollback procedure documented and tested
- No upgrade that destroys user data or funds without migration path
- Timelock or governance on upgrade execution
MUST DO
- Document upgrade process and approval flow
- Provide storage layout diff for upgradeable contracts
- Test upgrade in staging; verify no data loss
- Document rollback steps and last successful rollback test
Delay on sensitive ops, no instant-rug capability.
MUST HAVE
- Time delay on sensitive admin operations (upgrade, pause, parameter change)
- Minimum 24–48h delay for critical ops; 7+ days for governance-heavy changes
- Community or multisig oversight where applicable
- No single key can execute destructive ops without delay
MUST DO
- Document timelock duration per operation type
- Verify delay is enforced on-chain
- Provide governance flowchart if applicable
- Confirm no bypass for "emergency" without equivalent oversight
Runbooks, architecture, handover, change management.
MUST HAVE
- Architecture diagram(s) showing components and data flows
- Runbooks for common ops (deploy, scale, recover)
- Change management process (even minimal)
- Handover documentation if team changes
MUST DO
- Provide architecture documentation
- List runbooks and last update date
- Document how changes are tested and deployed
- Confirm docs are accessible to ops team
RESILIENCE LAYER (F18–F25)
Cryptographic inventory, migration path, NIST PQC alignment.
MUST HAVE
- Cryptographic inventory (CBOM): where crypto is used (TLS, signing, storage)
- Identification of quantum-vulnerable algorithms (RSA, ECC, DSA, DH)
- Migration roadmap or documented acceptance of current state
- For long-lived data (10+ years): PQC migration plan with timeline
MUST DO
- Provide crypto inventory: algorithms, libraries, use cases
- Assess data lifespan; prioritise PQC for long-term sensitive data
- Document migration plan or rationale for deferral
- Track NIST PQC standardisation; test hybrid TLS where feasible
Pause/kill switch, emergency controls. No blind execution.
MUST HAVE
- Pause or emergency stop mechanism for smart contracts handling user funds
- Pause restricted to authorised role (multisig); not single key
- Critical functions (withdraw, swap, mint) respect pause state
- Unpause path documented; no permanent lock without recovery
MUST DO
- Document pause/unpause flow and who can trigger
- Verify pause modifier on all critical functions
- Test pause scenario; confirm user withdrawals possible if implemented
- Provide recovery procedure if pause is triggered by mistake
Single points of failure identified, mitigated or accepted.
MUST HAVE
- SPOF analysis: admin keys, oracles, infra, key person
- Mitigation for each identified SPOF (multisig, redundancy, documentation)
- If SPOF accepted: explicit documentation and risk acknowledgment
- No single EOA as critical path without documented justification
MUST DO
- Provide SPOF matrix: component, risk, mitigation
- Document any accepted SPOFs and business rationale
- Verify multisig/redundancy where claimed
- Review on major changes; update SPOF doc
Key rotation, secure storage, recovery, no hardcoded secrets.
MUST HAVE
- Keys stored in HSM, hardware wallet, or vault (not in code or plain config)
- Key rotation procedure; quarterly for admin keys recommended
- Recovery procedure documented; no single-point loss
- No secrets in repos, logs, or client bundles
MUST DO
- Document key storage and access control
- Provide rotation schedule and last rotation date
- Verify no hardcoded secrets (scan repos)
- Document key recovery and backup (split-key, geographic dispersal)
DR plan, failover tested, geographic redundancy.
MUST HAVE
- Disaster recovery plan documented
- Failover tested at least annually
- Geographic redundancy for critical infra where applicable
- RTO/RPO aligned with business requirements
MUST DO
- Provide DR plan summary
- Document last failover test and result
- Verify redundancy design (multi-AZ, multi-region)
- Define escalation for DR activation
Data portability, vendor lock-in assessment, exit path.
MUST HAVE
- Data export capability for user data
- Vendor lock-in assessment for critical dependencies
- Exit path defined: what happens if vendor/platform fails
- Migration path for major upgrades or platform change
MUST DO
- Document data export process and format
- List critical vendors and lock-in risk
- Provide exit plan for top 3 dependencies
- Define migration procedure for PQC or infra change
Vendor SLAs, integration security, dependency failure impact.
MUST HAVE
- Vendor SLAs documented for critical services
- Integration security: auth, encryption, rate limits
- Failure impact assessment: what breaks if vendor is down
- Monitoring of third-party availability and performance
MUST DO
- List critical vendors and their SLAs
- Document integration security (API keys, mTLS, etc.)
- Provide failure scenario analysis
- Define fallback or degradation path for key dependencies
Graceful shutdown, user migration, no orphaned users.
MUST HAVE
- Sunset plan if project is discontinued
- User migration path: how users extract value or data
- No orphaned users: communication plan, deadline, support
- Contract pause or migration path for on-chain assets
MUST DO
- Document sunset procedure (even if not planned)
- Define user notification and extraction process
- Provide timeline for graceful wind-down
- Verify no permanent lock of user funds without recovery path
BEFORE YOU REQUEST
Use this page as a preparation checklist. Map your project to the relevant functions (Protocol scope mapping), then satisfy Must Have and Must Do for each. Missing items will result in CONDITIONAL or DENIED. No negotiation. No shortcuts.