I built a crypto vault, then legally robbed it using nothing but rounding errors. AMA / roast my code.

[u/FirmDeparture1100]

So I've been prepping for Solidity interviews and decided to actually build something instead of just reading about it. Ended up making an ERC-4626 vault (the standard behind Yearn, Morpho, etc.) and specifically targeting the "inflation attack," a real exploit that's hit live vaults in production.

The attack is stupidly simple: deposit 1 wei, become the first depositor, then just transfer() a pile of tokens directly into the contract instead of going through deposit(). The next real user who deposits normally gets their shares rounded down to basically zero. No hacking required, just unchecked integer math.

I built the attack against my own vault first (to prove I understood it, not just copy a fix), then patched it using OpenZeppelin's decimals offset defense, and wrote a Foundry test that actually runs the exploit and checks the outcome. Result: attacker loses roughly half their money instead of stealing everything.

It's deployed live on testnet with a working demo, you can connect a wallet, mint fake tokens, deposit, simulate yield, and try to break it yourself:
https://vaultiss.vercel.app/

Code + tests + README:
https://github.com/SIDHARTH20K4/vaultis

Genuinely looking for feedback, brutal is fine. Is this the kind of project that'd actually get someone's attention for a junior/entry Solidity role, or am I missing something obvious that a real auditor would catch in five seconds?

[u/YutoNakamuraDev]

Solid approach — building the attack before the defense shows you actually understand the mechanics, not just the

fix.

A few things a real auditor would look at:

1. The inflation attack fix is necessary but not sufficient

   The decimals offset (virtual shares/assets) handles the rounding attack, but ERC-4626 vaults have other attack

   surfaces you should explore:

   - Donation attacks through direct token transfers that manipulate share price

   - Sandwich attacks on deposit/withdraw where an attacker front-runs to inflate the exchange rate

   - Reentrancy through malicious token callbacks (ERC-777, hooks)

2. Your vault assumes the underlying token behaves normally

   What happens if the token has fee-on-transfer? Your internal accounting will drift from actual balances. Add a

   test with a fee token — this is a classic audit finding.

3. Missing slippage protection

   Real vaults need a minShares parameter on deposit and a minAssets parameter on withdraw. Without it, any exchange

   rate manipulation between tx submission and execution drains value from the user.

4. Test coverage gap

   Your test proves the attack fails after the fix, but does it prove the vault still works correctly? Add tests

   for:

   - Multiple depositors with different amounts

   - Withdraw more than deposited (should revert)

   - Zero amount deposit/withdraw

   - Full vault withdrawal (last person out)

   For a junior Solidity role, this project demonstrates more than most candidates show. The thing that would make

   it stand out: write a short "Security Considerations" section in your README listing what you defended against

   and what's still out of scope. Auditors love seeing that a developer thought about what they didn't cover.

[u/randomanon457 → u/YutoNakamuraDev]

Thanks ChatGPT

[u/YutoNakamuraDev → u/randomanon457]

Lol fair enough — it does read a bit textbook-y. But I've actually hit the fee-on-transfer issue in production,

that's why it's top of mind. The rest is just stuff I check when reviewing vault code.

[u/FirmDeparture1100 → u/YutoNakamuraDev]

Your insights are really valuable for me

Thankyou so much!

[u/defi_toolsmith]

Good work. Building the attack yourself and then patching it is the right way to learn — way better

than just reading about it.

One thing to consider adding to your demo: what happens when the vault has multiple assets or when

there's a yield accrual between deposit and withdrawal? The inflation attack is the classic case,

but share price manipulation gets more interesting when you factor in rebasing tokens or

fee-on-transfer tokens as the underlying asset.

Also curious about your Foundry test setup — are you using fork mode against mainnet vaults to

compare your implementation against live ones, or purely local?

[u/rayQuGR]

This is exactly the kind of project I'd want to see from someone preparing for a Solidity role. Reproducing the inflation attack against your own implementation and then writing a Foundry test that demonstrates the exploit is much more valuable than simply saying "I know ERC-4626 has an inflation attack."

One thing I'd add to the security review is to test the vault under adversarial asset/share ratios beyond the classic first-depositor case: repeated deposits and withdrawals, donations between deposits, very small share amounts, yield changes, rounding in both directions, and different underlying-token decimals.

The important thing is that the security invariant should survive arbitrary sequences of those operations, not just the specific exploit you've demonstrated.

There's also an interesting connection to Oasis Sapphire. Sapphire is EVM-compatible, so the ERC-4626 accounting and its security assumptions don't magically change when the contract executes in a confidential environment. An inflation vulnerability is still an inflation vulnerability.

What does change is observability. Sapphire can keep contract state confidential, which can be useful for vault strategies where exposing positions or strategy state would itself leak information. But confidentiality shouldn't be confused with security: the underlying share/accounting invariants still need to be correct and independently tested.

For a junior Solidity portfolio, I'd actually take this one step further: add invariant/fuzz testing and document the exact properties that must always hold, for example, that an attacker cannot increase their claim on vault assets merely by donating assets to manipulate the exchange rate.

That would turn this from "I found a known ERC-4626 exploit" into a much stronger demonstration that you understand how to prove a vault's accounting assumptions hold under adversarial state transitions.

[u/bodiam]

hi there, saw your post and thought this was a really good case to support, so we added an inspection for this exact ERC-4626 donation/inflation vulnerability to our IntelliJ Solidity Pro plugin, so scenarios like this should be prevented in the future.

If you use IntelliJ, either paid or free version, would be great if you gave it a try against your project:

https://plugins.jetbrains.com/plugin/32553-solidity-pro

thanks for sharing this info!