Spotting issues in DeFi with dimensional analysis

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.