Audit math precision
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 calculationsFrom its SKILL.md
npx -y skills add auditmos/skills --skill audit-math-precisionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.8 KB, as published. Nobody here has run it
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,uncheckedblocks - Focus: fee calculations, reward distributions, token conversions, oracle price usage
- Search:
-
Check against vulnerability patterns
- Reference
reference.mdfor complete checklist - Compare code against
example.md
- Reference
-
Validate findings
- Check access control first - grep for
onlyOwner|onlyAdmin|onlyGovernancemodifiers - 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
- Check access control first - grep for
-
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