Spotting issues in DeFi with dimensional analysis
The article introduces dimensional analysis as a methodology for identifying arithmetic and logic vulnerabilities in DeFi smart contracts. By ensuring that variables representing different tokens, prices, or liquidity shares are not erroneously combined, developers can prevent severe financial logic flaws. The post highlights real-world examples of dimensional bugs and advocates for explicit unit documentation in Solidity codebases.
Key Takeaways
- Dimensional analysis from physics can be applied to DeFi smart contracts to identify arithmetic and logic bugs.
- Adding or subtracting quantities with different dimensions (e.g., Token A and Token B) is generally a flaw, except in specific cases like stable pools.
- A real-world vulnerability (TOB-CAP-17) in CAP Labs involved passing decimals instead of asset amounts to an ERC-4626 convertToAssets function.
- Reserve Protocol demonstrates best practices by explicitly documenting dimensions and numeric scales (e.g., D27{UoA/tok}) in comments.
- Trail of Bits is developing a Claude plugin and suggests future static analysis tools (like Slither) to automate dimensional checking in Solidity.
Affected Systems
- DeFi Smart Contracts
- Solidity
- Automated Market Makers (AMMs)
- ERC-4626 Vaults
Attack Chain
Vulnerabilities arise when smart contract developers write arithmetic formulas that combine incompatible dimensions, such as adding different token balances or dividing by incorrect units. In a real-world example (TOB-CAP-17), a contract incorrectly passed token decimals instead of asset amounts to an ERC-4626 vault function. Attackers can exploit these logical flaws to manipulate price calculations, extract excess value, or break protocol invariants. Because Solidity lacks native dimensional safety, these bugs often deploy to mainnet undetected unless caught during manual audits.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No specific detection rules are provided; the article focuses on manual code review and upcoming static analysis tooling (Claude plugin/Slither) for dimensional checking.
Detection Engineering Assessment
EDR Visibility: None — EDR tools monitor operating system events and cannot inspect smart contract logic or blockchain state. Network Visibility: None — Network telemetry cannot inspect on-chain smart contract arithmetic or logic flaws. Detection Difficulty: Hard — Requires deep semantic understanding of the smart contract's financial logic, token dimensions, and intended arithmetic invariants.
Required Log Sources
- Smart Contract Source Code
- Blockchain Transaction Logs
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Smart contracts may contain arithmetic vulnerabilities if variables representing different token dimensions or scales are added, subtracted, or improperly divided. | Smart Contract Source Code | Execution | Medium |
Control Gaps
- Lack of native dimensional safety in Solidity
- Absence of automated static analysis tools for unit checking
Key Behavioral Indicators
- Mismatched variable dimensions in arithmetic operations
- Incorrect parameter types passed to standard interfaces (e.g., decimals instead of asset amounts)
False Positive Assessment
- Low
Recommendations
Immediate Mitigation
- Review existing smart contract formulas for dimensional homogeneity.
- Verify that standard interface calls (like ERC-4626 convertToAssets) receive the correct unit types (assets vs. decimals).
Infrastructure Hardening
- Implement strict naming conventions and inline comments for all state variables, inputs, and outputs to define their dimensions and fixed-point scales (e.g., D18, D27).
User Protection
- N/A
Security Awareness
- Train smart contract developers on dimensional analysis to prevent arithmetic logic bugs.
- Adopt documentation standards similar to Reserve Protocol to explicitly track units of measure across the codebase.
