Detect ERC-4626 / Vault Share-Price Inflation and First-Depositor Attacks (CP-122)

[Nanle-code]

Problem Statement

Share-price inflation attacks (also known as "first depositor" or "donation" attacks) against ERC-4626-style vaults and other share-based pooled-asset contracts have been responsible for real losses across DeFi: an attacker deposits a minimal amount to mint the first share, then directly transfers ("donates") assets to the vault contract to inflate the share price before a second depositor's deposit, causing the second depositor's shares to round down to zero or a negligible amount. Neither ChainProof's existing SWC-aligned rules nor its ERC-20/721/1155 compliance checker look for this class of business-logic vulnerability, which is specific to share-accounting math rather than a generic standard-compliance gap.

Proposed Solution

Implement CP-122, a detector targeting vault/share-accounting patterns:

• Identify contracts implementing a deposit/mint/withdraw/redeem share-accounting pattern (via function signature and state-variable heuristics — e.g., a totalSupply/totalAssets-style ratio used to compute shares minted on deposit), whether or not they formally inherit an ERC-4626 interface.
• Flag vaults where: (a) share price is computed as a naive assets * totalSupply / totalAssets ratio without a minimum-liquidity/dead-shares guard on first deposit, (b) the vault's asset balance can be directly inflated by a plain token transfer (i.e., accounting relies on balanceOf(address(this)) rather than an internally tracked, transfer-independent asset ledger), and (c) there is no protection such as virtual shares/assets offset, an internal _totalAssets accounting variable, or a minimum-deposit/donation-resistant initialization step.
• Provide a concrete, contract-specific remediation recommendation (e.g., "mint and burn a fixed dead-share amount to the zero address on first deposit," or "track internal accounting instead of relying on live token balance") rather than a generic warning.
• Severity: high, given the direct fund-loss impact and real-world precedent.

Technical Scope

• New packages/core/src/rules/cp122-vault-inflation.ts using the existing AST visitor pattern, consistent with the plugin API's documented rule template.
• Heuristics for identifying share-accounting contracts should be conservative enough to avoid flagging unrelated ratio math elsewhere in a contract; document the detection heuristic clearly so false positives can be triaged and tuned.
• New fixture contracts under examples/contracts/: a vulnerable vault reproducing the classic first-depositor inflation pattern, and a patched version using dead-shares/virtual-offset mitigation that should scan clean.
• Unit tests covering the vulnerable fixture, the patched fixture, and at least one contract with unrelated ratio-based math that must not trigger a false positive.

Acceptance Criteria

• Flags the vulnerable fixture vault with a high severity finding and a specific, actionable recommendation.
• Does not flag the patched (dead-shares) fixture vault.
• Does not flag an unrelated contract that performs similar-looking ratio arithmetic outside a deposit/withdraw share-accounting context.
• The new rule is documented in the README's Vulnerability Rules table.

Estimated Scope

Approximately 700 lines of new TypeScript across the detector, fixtures, and tests.

[PatrickKish1]

Hi, I would like to work on implementing the CP-122 vault share-price inflation detector.
I will build a rule that identifies deposit/mint share-accounting patterns and flags contracts vulnerable to first-depositor / donation attacks — specifically those relying on a naive assets * totalSupply / totalAssets ratio without dead shares, virtual offsets, or internal asset accounting. The detector will be conservative to avoid false positives on unrelated ratio math and will provide concrete, contract-specific remediation guidance.
I will include vulnerable and patched fixture contracts, unit tests covering both cases plus an unrelated false-positive check, and documentation in the README Vulnerability Rules table.
This will close a real, high-severity gap that current SWC and token-compliance rules do not cover.

[dragoncode-01]

Hi @Nanle-code,

I'd like to work on this issue.

I have experience in smart contract security auditing, Solidity, Foundry, and developing static analysis tooling for blockchain applications. I've researched and validated business-logic vulnerabilities, including accounting flaws, access control issues, and token-standard edge cases. This issue is particularly interesting because it targets a class of vulnerabilities that cannot be detected through simple standards compliance alone.

My implementation plan is to:

• Develop the CP-122 detector using the project's existing AST visitor/plugin architecture.
• Design conservative heuristics to identify ERC-4626 and ERC-4626-like share-accounting patterns without relying solely on interface inheritance.
• Detect vulnerable share-minting logic that relies on live balanceOf(address(this)) accounting and lacks protections such as dead shares, virtual assets/shares, or internal asset accounting.
• Produce actionable, contract-specific remediation guidance instead of generic warnings.
• Create vulnerable and patched fixture contracts demonstrating the classic first-depositor/share-price inflation attack and its mitigations.
• Add comprehensive unit tests covering vulnerable, protected, and false-positive scenarios.
• Update the documentation and vulnerability rules table with the new detector and detection methodology.

I care about building practical security tooling with a strong signal-to-noise ratio, so I'll focus on making the detection accurate, well-tested, and easy to maintain while minimizing false positives.

I'd be happy to contribute this feature.

[grantfox-oss]

🦊 GrantFox — @dragoncode-01 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #67)
2. Your PR will be reviewed by the StellarChainproof maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@dragoncode-01's PR #68 was approved and merged by @Nanle-code.

🏆 @dragoncode-01: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (557 total points). Track your full progress on GrantFox.

👏 Great work, @dragoncode-01! Keep contributing to StellarChainproof.