Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Take a value-handling contract (e.g. a vault, a staking pool, or an auction) and harden it like a professional, DEFENSIVELY. Produce: (1) the contract using secure patterns — checks-effects-interactions ordering, a reentrancy guard, pull-over-push payments, and role-based access control (OpenZeppelin); (2) a written THREAT MODEL enumerating the relevant vulnerability classes (reentrancy, access control, oracle/price manipulation, integer issues, front-running/MEV) and how your design PREVENTS each; (3) an extensive test suite including adversarial/negative tests and fuzzing (Foundry) that demonstrates the guards hold; and (4) a self-audit checklist and notes on what a professional audit would still add. Defensive only — document prevention, not exploits. Testnet only.
Checks-effects-interactions + reentrancy guard, pull-over-push, proper access control; no known-pattern vulnerabilities; 0.8+ checked math.
Relevant vulnerability classes enumerated with concrete, correct prevention for each; defensive framing (no exploit instructions).
Negative/adversarial tests and fuzzing demonstrate the guards hold; reverts on attack attempts proven in tests.
Self-audit checklist; acknowledges limits and the value of a professional audit before holding real value; testnet only.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A security-audited contract with a threat model ## Goal Take a value-handling contract (e.g. a vault, a staking pool, or an auction) and harden it like a professional, DEFENSIVELY. Produce: (1) the contract using secure patterns — checks-effects-interactions ordering, a reentrancy guard, pull-over-push payments, and role-based access control (OpenZeppelin); (2) a written THREAT MODEL enumerating the relevant vulnerability classes (reentrancy, access control, oracle/price manipulation, integer issues, front-running/MEV) and how your design PREVENTS each; (3) an extensive test suite including adversarial/negative tests and fuzzing (Foundry) that demonstrates the guards hold; and (4) a self-audit checklist and notes on what a professional audit would still add. Defensive only — document prevention, not exploits. Testnet only. ## Acceptance criteria - [ ] Secure design: Checks-effects-interactions + reentrancy guard, pull-over-push, proper access control; no known-pattern vulnerabilities; 0.8+ checked math. - [ ] Threat model: Relevant vulnerability classes enumerated with concrete, correct prevention for each; defensive framing (no exploit instructions). - [ ] Adversarial testing: Negative/adversarial tests and fuzzing demonstrate the guards hold; reverts on attack attempts proven in tests. - [ ] Audit discipline: Self-audit checklist; acknowledges limits and the value of a professional audit before holding real value; testnet only. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.