Install
$ agentstack add skill-omermaksutii-rugproof-erc4626-inflation ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README — it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming — see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps — measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
ERC-4626 inflation attack detection
Background
The classic "donation" or "inflation" attack on share-based vaults. First depositor mints 1 wei share for 1 wei of asset → share price = 1. Attacker then donates large amount directly to the vault (bypassing deposit) → totalAssets balloons → share price massively inflated → next depositor rounds shares to 0.
Has caused real, public losses across many forks of naive ERC-4626.
When this applies
- Any contract inheriting ERC-4626
- Custom vaults with share/asset math
- Yield aggregators
- Lending markets that mint share-tokens
Detection patterns
Naive convertToShares math (CRITICAL)
function convertToShares(uint256 assets) public view returns (uint256) {
if (totalSupply() == 0) return assets;
return assets * totalSupply() / totalAssets();
}
First deposit: 1 share for 1 asset. Donation: totalAssets += 1e30. Next depositor's 1 asset → 1 * 1 / 1e30 = 0 shares. Funds lost.
No virtual-shares defense (HIGH)
Defense: OZ ERC4626 v4.9+ uses _decimalsOffset() to mint "virtual" shares:
function _convertToShares(uint256 assets, Math.Rounding rounding) internal view virtual override returns (uint256) {
return assets.mulDiv(totalSupply() + 10 ** _decimalsOffset(), totalAssets() + 1, rounding);
}
This adds N virtual shares (typically 10**6 — 6 decimals offset) that nobody owns. Donations have far less leverage.
Dead-shares pattern not used (HIGH)
Alternative defense: mint a fixed amount (e.g. 1000 shares) to address(0) or address(this) on first deposit. Locks initial donation impact.
Minimum first deposit not enforced (MEDIUM-HIGH)
If first depositor deposits a large amount (say, 10K USDC), donation impact is bounded.
Read-only deposit pause until seed (HIGH)
Some impls require admin to seed vault before allowing deposits. Acceptable defense; centralized but bounded.
Asymmetric round-direction (HIGH)
ERC-4626 spec: rounding favors the vault.
deposit: shares round DOWN (favor vault)mint: assets round UP (favor vault)withdraw: shares round UP (favor vault)redeem: assets round DOWN (favor vault)
Reversed direction = attacker can extract value via rounding.
Donation accounting after rebase (HIGH)
Vaults holding rebasing tokens (stETH, etc.) — totalAssets() increases via rebase, not via internal accounting. Attack vectors similar but defenseless naive impl.
totalAssets() returns IERC20.balanceOf(address(this)) (HIGH)
Naive implementation that always sums the actual balance is the vulnerable shape. Better: track internally and rebase carefully.
Severity rubric
| Pattern | Severity | |---|---| | Naive share math + no virtual shares + no dead-shares + no min-deposit | Critical | | Naive math + minimum first deposit but very low | High | | Asymmetric round direction (favoring depositor) | High | | totalAssets() = balanceOf(this) with rebasing token, no defense | High | | Virtual shares of 0 decimals offset on 18-decimal asset (insufficient) | High | | Dead-shares but very small (e.g. 1 wei) | High | | OZ ERC4626 v4.9+ with default offset (6) | Info (canonical defense) |
Remediation patterns
- Use OZ
ERC4626Upgradeable≥ 4.9.0 with_decimalsOffset() = 6(or higher for low-decimal assets). - OR: mint 1000+ dead shares to address(0) on first deposit.
- OR: require first deposit ≥ MIN (e.g. 1 unit of underlying).
- OR: admin-seeded vault with no public deposits until seed.
- Always validate round direction matches OZ semantics.
False-positive notes
- A vault using OZ v4.9+ ERC4626 with explicit
_decimalsOffsetreturn is likely safe — verify the offset value is reasonable (6 for 18-decimal underlying is the canonical). - Custom vaults with admin-seeded model are defenseless against admin compromise but not against external donations.
Related
- [[flash-loan-attacks]] §inflation
- [[integer-issues]] §rounding
- [[yield-aggregator-specialist]] (subagent)
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: omermaksutii
- Source: omermaksutii/RugProof
- License: MIT
- Homepage: https://omermaksutii.github.io/RugProof
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.