Math Precision Auditor
When to Use
- Auditing Solidity contracts for arithmetic vulnerabilities
- User mentions: precision, decimals, rounding, overflow, downcasting, division, multiplication, fees, rewards
- Analyzing token protocols, DeFi systems, AMMs, lending protocols
- Reviewing calculations involving multiple tokens with different decimals
Audit Workflow
IMPORTANT: Announce skill usage at the start of analysis
Begin with: "I'm using the audit-math-precision skill to analyze this contract for arithmetic and precision vulnerabilities..."
Scan for arithmetic operations
- Search:
* / % ** operators, type casting, unchecked blocks
- Focus: fee calculations, reward distributions, token conversions, oracle price usage
Check against vulnerability patterns
- Reference
reference.md for complete checklist
- Compare code against
example.md
Validate findings
- Check access control first - grep for
onlyOwner|onlyAdmin|onlyGovernance modifiers
- Verify exploitability by non-privileged actors (not just style issues)
- Calculate impact (% loss or USD value)
- Check for compensating protections
- Downgrade severity if admin-only unless severe impact
Generate report
- Use deliverable template below
- Include PoC for each finding
- Rank by severity
Core Vulnerability Patterns
See reference.md for full checklist. Key patterns:
- Division before multiplication → precision loss
- Small amounts round to zero → fee bypass
- Token decimal mismatches → magnitude errors
- Unsafe downcasting → truncation
- Wrong rounding direction → protocol value leak
- Inverted oracle pairs → incorrect calculations
- Hardcoded decimal assumptions → breaks with different tokens
- Time unit confusion → interest calculation errors
- Unchecked arithmetic → silent overflows
- Exponentiation precision loss → compound calculation errors
Code examples: See example.md
Severity Criteria
Critical: Direct fund extraction, >10% value loss, no preconditions required
High: 1-10% value leakage, specific but achievable conditions, affects protocol solvency, MUST be exploitable by non-privileged actors
Medium: <1% precision loss in edge cases, requires privileged actors or specific conditions
Low: Gas inefficiency, view function issues, admin-only precision issues, no security impact
IMPORTANT: Admin-only functions (onlyOwner, onlyAdmin, onlyGovernance) with precision issues are LOW severity unless:
- Precision loss is severe (>10% of intended value)
- Function is called frequently in normal operations
- Error cascades to affect user funds directly
False Positives - Do NOT Flag
- Division-before-multiplication in view functions (display only)
- Zero-rounding with explicit
require(fee > 0, ...)
- Different decimals in isolated modules (no cross-interaction)
- Downcasts with explicit bounds check:
require(value <= type(uint96).max)
- Documented "favor user" rounding policies
- Admin-only functions (onlyOwner, onlyAdmin, onlyGovernance modifiers) with minor precision issues
- Setter functions with division-before-multiplication where values are large enough to avoid practical loss
- One-time initialization functions with precision quirks (not called in normal operations)
Deliverable Format
MANDATORY: Before deliverable, verify each checklist.md item against codebase. Flag violations as findings.
Use template: templates/report-template.md
Each finding includes: severity, pattern #, file/lines, description, vulnerable code, impact analysis, PoC, remediation, gas impact.
Key Principles
- Multiply first, divide last - minimize truncation impact
- Protocol-favoring rounding - round fees up, withdrawals down
- Explicit decimals - never assume 18 decimals
- Validate minimums - prevent rounding-to-zero attacks
Output Guidelines
DO:
- Reference specific lines and functions
- Provide executable PoCs
- Quantify potential loss
- Group similar issues
DON'T:
- Report style issues
- Flag intentional designs without exploit path
- Use vague terms ("might be vulnerable")
- Ignore context
1---2name: audit-math-precision3description: Audits Solidity smart contracts for arithmetic precision vulnerabilities including division-before-multiplication causing value loss, small amounts rounding to zero enabling fee bypass, token decimal mismatches in multi-asset pools, unsafe downcasts truncating storage values, incorrect rounding direction leaking protocol fees, inverted oracle price pairs, hardcoded decimal assumptions, and time unit confusion in interest calculations4license: MIT5---67# Math Precision Auditor89## When to Use10- Auditing Solidity contracts for arithmetic vulnerabilities11- User mentions: precision, decimals, rounding, overflow, downcasting, division, multiplication, fees, rewards12- Analyzing token protocols, DeFi systems, AMMs, lending protocols13- Reviewing calculations involving multiple tokens with different decimals1415## Audit Workflow1617**IMPORTANT: Announce skill usage at the start of analysis**1819Begin with: "I'm using the **audit-math-precision** skill to analyze this contract for arithmetic and precision vulnerabilities..."20211. **Scan for arithmetic operations**22 - Search: `* / % **` operators, type casting, `unchecked` blocks23 - Focus: fee calculations, reward distributions, token conversions, oracle price usage24252. **Check against vulnerability patterns**26 - Reference `reference.md` for complete checklist27 - Compare code against `example.md`28293. **Validate findings**30 - **Check access control first** - grep for `onlyOwner|onlyAdmin|onlyGovernance` modifiers31 - Verify exploitability by non-privileged actors (not just style issues)32 - Calculate impact (% loss or USD value)33 - Check for compensating protections34 - Downgrade severity if admin-only unless severe impact35364. **Generate report**37 - Use deliverable template below38 - Include PoC for each finding39 - Rank by severity4041## Core Vulnerability Patterns4243See `reference.md` for full checklist. Key patterns:44451. Division before multiplication → precision loss462. Small amounts round to zero → fee bypass473. Token decimal mismatches → magnitude errors484. Unsafe downcasting → truncation495. Wrong rounding direction → protocol value leak506. Inverted oracle pairs → incorrect calculations517. Hardcoded decimal assumptions → breaks with different tokens528. Time unit confusion → interest calculation errors539. Unchecked arithmetic → silent overflows5410. Exponentiation precision loss → compound calculation errors5556**Code examples:** See `example.md`5758## Severity Criteria5960**Critical:** Direct fund extraction, >10% value loss, no preconditions required61**High:** 1-10% value leakage, specific but achievable conditions, affects protocol solvency, **MUST be exploitable by non-privileged actors**62**Medium:** <1% precision loss in edge cases, requires privileged actors or specific conditions63**Low:** Gas inefficiency, view function issues, admin-only precision issues, no security impact6465**IMPORTANT:** Admin-only functions (onlyOwner, onlyAdmin, onlyGovernance) with precision issues are **LOW severity** unless:66- Precision loss is severe (>10% of intended value)67- Function is called frequently in normal operations68- Error cascades to affect user funds directly6970## False Positives - Do NOT Flag7172- Division-before-multiplication in view functions (display only)73- Zero-rounding with explicit `require(fee > 0, ...)`74- Different decimals in isolated modules (no cross-interaction)75- Downcasts with explicit bounds check: `require(value <= type(uint96).max)`76- Documented "favor user" rounding policies77- **Admin-only functions** (onlyOwner, onlyAdmin, onlyGovernance modifiers) with minor precision issues78- Setter functions with division-before-multiplication where values are large enough to avoid practical loss79- One-time initialization functions with precision quirks (not called in normal operations)8081## Deliverable Format8283**MANDATORY:** Before deliverable, verify each `checklist.md` item against codebase. Flag violations as findings.8485Use template: `templates/report-template.md`8687Each finding includes: severity, pattern #, file/lines, description, vulnerable code, impact analysis, PoC, remediation, gas impact.8889## Key Principles9091- **Multiply first, divide last** - minimize truncation impact92- **Protocol-favoring rounding** - round fees up, withdrawals down93- **Explicit decimals** - never assume 18 decimals94- **Validate minimums** - prevent rounding-to-zero attacks9596## Output Guidelines9798**DO:**99- Reference specific lines and functions100- Provide executable PoCs101- Quantify potential loss102- Group similar issues103104**DON'T:**105- Report style issues106- Flag intentional designs without exploit path107- Use vague terms ("might be vulnerable")108- Ignore context