ACryptoS reportedly lost about $665,000 after attackers exploited a flaw in its vault accounting system across 77 vaults on five blockchain networks.
The attack did not require a large initial deposit.
Instead, attackers were allegedly able to deposit a small amount of one token into vaults that were designed to account for multiple assets. Because the deposit function failed to validate the full token list correctly, the vault could issue far more shares than the attacker’s contribution should have received.
Those newly created shares could then be redeemed against the real assets already sitting inside the vault.
For users, the most important point is that ACryptoS reportedly kept withdrawals open after disabling deposits. But an open withdrawal function only allows users to claim whatever assets remain in their specific vault. Recovering stolen funds is a separate process.
ACryptoS reportedly lost about $665,000 across five chains
Security firm SlowMist estimated losses of approximately $665,429 from the November 8 exploit.
The incident affected 77 vaults deployed across:
- Arbitrum
- BNB Chain
- Polygon
- Base
- Optimism
The multi-chain impact appears to stem from vulnerable vault logic being reused across several deployments.
Once the exploit method became visible on one chain, similar contracts on other networks could potentially be tested using the same technique.
The exploit targeted ACryptoS’s depositMulti function
SlowMist attributed the problem to missing input validation in a function called depositMulti.
ACryptoS vaults can hold strategies involving more than one token.
When a user deposits assets, the protocol needs to calculate how much that contribution is worth relative to the assets already backing existing vault shares.
The reported flaw allowed an attacker to provide a shorter list of token amounts than the function expected.
That could cause the vault’s accounting logic to leave out part of its existing assets when calculating how many new shares to mint.
A small deposit could receive far too many shares
Vault shares represent a user’s proportional claim on the assets controlled by the strategy.
Under normal conditions, a small deposit should receive only a small percentage of the total shares.
The exploit reportedly broke that relationship.
For example, imagine a vault contains assets worth $100,000 and has 100 shares outstanding.
A normal $10 deposit should receive only a tiny fraction of a share.
But if a bug causes the vault to mistakenly value its existing assets at only $10, the attacker’s $10 contribution can appear equal to the entire vault.
The contract might then issue the attacker an enormous portion of the total share supply.
The numbers are illustrative, but they show how a tiny deposit can create a claim on a much larger pool.
The attacker could then redeem against the real vault balance
The problem became financially damaging when the newly issued shares were redeemed.
The deposit calculation underestimated the existing vault assets.
The withdrawal logic, however, reportedly honored the attacker’s shares against the actual assets held by the vault.
That created a mismatch.
The attacker contributed very little but received shares representing a large portion of the vault.
Redeeming those shares allowed the attacker to withdraw assets originally belonging to existing depositors.
Existing users could keep the same share count and still lose value
One of the more confusing aspects of vault exploits is that users may still see the same number of shares in their wallets.
That does not mean their position is unchanged.
If the attacker receives a huge number of newly minted shares, every existing user’s percentage ownership falls.
Then, once the attacker redeems and removes assets from the vault, the remaining shares are backed by a smaller pool.
A wallet might still show 100 vault shares, but those shares may now be redeemable for much less than before the exploit.
A share balance is not the same as the underlying value
This is why simply checking the number of vault tokens in a wallet does not reveal the full impact.
The important relationship is:
Vault assets ÷ total shares outstanding
That determines how much backing each share represents.
If the assets fall while a user’s share count stays unchanged, the economic value of those shares still declines.
Users need to look at what the vault can actually redeem, not just the token balance shown in a wallet interface.
Why the exploit affected multiple chains
The same accounting logic appears to have been deployed across several networks.
A smart contract bug does not disappear because the contract exists on another blockchain.
If identical or similar vulnerable code is deployed on Arbitrum, Base, Polygon, Optimism and BNB Chain, the same exploit technique can potentially be repeated against each deployment.
The attacker does not necessarily need to bridge assets to cause the loss on another network.
Each vault can be exploited locally.
Bridges matter after the theft, not necessarily during it
Cross-chain bridges become relevant when stolen funds are moved after the exploit.
For example, an attacker might drain a vault on Base and later bridge the proceeds to Ethereum.
The bridge transaction helps investigators trace where the assets went.
But it does not explain how the original Base vault was drained.
That happened through the vulnerable contract on Base itself.
This distinction helps separate the exploit mechanism from the later movement of the proceeds.
ACryptoS disabled deposits but reportedly left withdrawals open
Following the incident, ACryptoS reportedly stopped accepting new deposits.
That is a logical emergency response because disabling deposits can prevent attackers from repeatedly using the vulnerable share-minting path.
Withdrawals remained available.
That gives existing users a route to redeem whatever assets are still controlled by their vault.
But the amount recoverable can vary dramatically from one vault to another.
An open withdrawal route does not mean users are fully protected
Two users can see the same withdrawal button and have very different outcomes.
One user may be in a vault that was never exploited and could potentially withdraw nearly everything.
Another may be in a heavily drained vault where each remaining share is backed by much less than before.
A third vault may still hold assets inside another DeFi position that needs to be unwound before users can receive them.
The availability of withdrawals therefore does not tell users how much they will actually get back.
The completed withdrawal matters more than the interface estimate
A website may display an estimated redemption amount.
That estimate can be useful, but after an exploit it should not be treated as definitive.
A completed transaction provides stronger evidence.
The user can inspect the actual token transfers received from the vault.
This becomes particularly important if ACryptoS is deprecating the interface or no longer maintaining it actively.
ACryptoS reportedly moved toward deprecating the protocol
Incident trackers indicate that ACryptoS began winding down or deprecating the affected service after the exploit.
Deprecation can mean new deposits are disabled while existing users are encouraged to withdraw.
However, the underlying smart contracts may continue to exist even after the website changes.
Users should identify the correct contract and interface associated with their specific vault.
Older ACryptoS positions may belong to different generations of contracts or interfaces.
Users should identify their exact vault and chain
The reported $665,429 loss is an aggregate across many vaults.
It does not tell an individual depositor how much they lost.
To understand a specific position, users need to identify:
- The blockchain
- The vault contract
- Their original deposit
- The number of shares received
- The vault’s assets before the exploit
- The share supply before and after the exploit
- Their eventual withdrawal amount
Those records provide a much clearer picture than the protocol-wide loss estimate.
The $665,000 figure combines several different tokens
The headline loss is expressed in dollars.
But the attackers took actual cryptocurrency tokens.
Those tokens may have changed in price after the exploit.
A precise reconstruction would therefore list the amounts taken in their original units and specify the timestamp used to calculate their dollar value.
Different pricing times can produce different loss estimates even when everyone agrees on how many tokens were stolen.
Not every affected vault necessarily lost the same amount
The count of 77 vaults does not show how losses were distributed.
One vault might have lost only a small amount.
Another could represent a large portion of the total.
The same bug can produce different outcomes depending on:
- The size of the vault
- The two tokens it holds
- The proportion held in each token
- The timing of the exploit
- The existing share supply
This means the number of affected vaults should not be used as a proxy for the number of affected users or the amount lost per vault.
Why omitting one token mattered
A multi-token deposit function needs to know which amount corresponds to each asset.
Imagine a vault supports Token A and Token B.
A correctly formatted deposit could look conceptually like:
- Token A: 10
- Token B: 0
Even though the user is not adding Token B, the zero keeps the second token’s position in the input list.
A shorter list containing only Token A can behave differently if the contract mistakenly uses the list length to determine which assets it should value.
Missing and zero are not the same input
This is the technical heart of the exploit.
A zero amount tells the contract:
“This token exists, but the user is depositing none of it.”
A missing entry can accidentally tell flawed code:
“Do not include this token in the calculation at all.”
If the omitted token represents a large share of the vault’s existing value, the contract can dramatically underestimate the vault.
That can cause excessive share issuance.
The exploit can be reconstructed in three steps
A useful onchain reconstruction follows three events.
First, look at the attacker’s incoming deposit.
That shows how little value they actually contributed.
Second, inspect the share mint.
That shows how much ownership the vault gave them.
Third, inspect the redemption.
That shows how much of the vault’s underlying assets the attacker received.
Looking only at the final withdrawal can make the transaction appear like a legitimate redemption.
The exploit is visible when the withdrawal is connected to the disproportionate share issuance that came before it.
Existing depositors were diluted before assets even left
The economic damage begins as soon as the vault issues too many shares.
Suppose existing users collectively own 100 shares.
If an attacker receives another 900 shares for a negligible deposit, existing users immediately go from owning 100% of the vault to just 10%.
Even before the attacker redeems, the original depositors’ percentage ownership has been diluted.
Once the attacker withdraws, the asset backing falls as well.
Vault bugs are different from underlying liquidity pool bugs
ACryptoS vaults may deploy assets into liquidity pools or other DeFi protocols.
That does not mean those underlying pools were necessarily compromised.
The vulnerable logic can exist entirely inside the vault.
The underlying decentralized exchange may continue working normally while ACryptoS incorrectly calculates how many shares a depositor deserves.
Users who interacted directly with the underlying pool therefore have different exposure from users who deposited through the ACryptoS vault.
The project reportedly offered a 10% bounty
Incident trackers said ACryptoS offered a 10% bounty for the return of stolen funds.
A bounty gives attackers or other holders of the proceeds a financial incentive to return assets.
However, an offer is not the same as a recovery.
Users should look for an actual onchain transaction returning funds to a publicly identified recovery address.
Until that occurs, the bounty does not change what depositors can currently withdraw.
Returned funds would still need a distribution plan
Even if the attackers return assets, another question immediately appears:
Who receives the recovered money?
The project would need to explain how losses are calculated and how recoveries are allocated.
Possible approaches include:
- Vault-by-vault reimbursement
- Chain-by-chain reimbursement
- Protocol-wide loss sharing
- Proportional repayment based on each user’s shortfall
Different methods could produce very different outcomes for depositors.
Snapshot timing could affect eligibility
A recovery plan would also need to define who qualifies.
Some users may have withdrawn the remaining assets immediately after the exploit.
They could still have suffered a significant loss.
Other users may have acquired vault shares after the incident at a reduced price.
Treating both groups identically could create fairness problems.
The project would need a snapshot or another accounting method that reconstructs who actually bore the loss.
Token-based and dollar-based compensation can differ
Another decision involves the denomination of losses.
Suppose a user lost 10 ETH.
A token-based recovery could aim to return 10 ETH.
A dollar-based recovery might reimburse the dollar value of 10 ETH at a specific historical timestamp.
If ETH’s price changes substantially, those two approaches can produce very different outcomes.
The project would need to disclose which method it uses.
Recovering funds is separate from withdrawing what remains
This is one of the most important points for affected users.
There are two different processes.
Current withdrawal:
Redeeming whatever assets are still inside the vault.
Future recovery:
Receiving part of any funds later returned by attackers, frozen by third parties, or contributed by the project.
A user may complete the first process and still have a claim under the second.
The two should not be confused.
Address labels can help trace stolen assets
Publicly identifying attacker addresses can help exchanges, stablecoin issuers and other services detect the stolen funds.
If assets reach a centralized exchange, the platform may be able to restrict withdrawals depending on its policies and legal obligations.
Some centralized token issuers may also be able to freeze their own tokens.
However, identifying an address does not automatically give ACryptoS control over the funds.
Tracing and recovering are separate stages.
Swapping stolen tokens can reduce freeze options
If an attacker holds a token whose issuer has freeze controls, the issuer may potentially restrict it.
But if the attacker swaps that token into a native asset such as ETH, the original issuer’s control no longer applies to the new asset.
This is why the timing of recovery efforts matters.
The longer stolen funds remain movable, the more opportunities attackers have to change their form or move them across networks.
Depositors should keep their records
Affected users should preserve records related to their position.
Useful information includes:
- Deposit transaction
- Vault address
- Chain
- Number of shares received
- Wallet address
- Withdrawal transaction
- Tokens received
- Any later claims documentation
These records can become important if ACryptoS announces a reimbursement process.
They also make it easier to compare the user’s position before and after the exploit.
TVL decline does not equal the exploit loss
Users may see ACryptoS total value locked fall significantly after the incident.
That decline should not automatically be treated as the amount stolen.
TVL can fall because:
- Users withdraw voluntarily
- Asset prices decline
- Vaults are deprecated
- Liquidity positions change
- Exploited funds leave
The exploit loss must be reconstructed from the specific malicious transactions, not simply from the protocol’s overall TVL change.
What users can still withdraw
The immediate answer depends on the specific vault.
If withdrawals remain available, users can generally redeem against the assets that the vault still controls.
That may be close to the original position in an unaffected vault.
It may be much less in a drained vault.
And some strategies may need time to unwind positions before assets can be paid out.
The only reliable answer for an individual user comes from their specific vault state and eventual withdrawal transaction.
What users should watch next
The most important developments are:
- Vault-level balances
- Successful user withdrawals
- Official deprecation instructions
- Any attacker fund returns
- A publicly identified recovery wallet
- A claims or reimbursement plan
An actual return transaction would be the first clear sign that the recovery position has improved.
A formal distribution plan would then explain whether and how that recovery reaches affected users.
Final thoughts
The ACryptoS exploit shows how a small accounting error can have an outsized financial impact in a vault system.
Attackers reportedly exploited missing input validation to deposit a small amount of one token, receive disproportionately large vault shares and then redeem those shares against assets belonging to existing depositors.
The result was approximately $665,000 in reported losses across 77 vaults on five networks.
For users, the most important distinction is between what remains in the vault and what may eventually be recovered.
Open withdrawals can return only the assets the vault still controls.
A bounty, fund recovery or future reimbursement would be a separate process.
The next meaningful evidence for depositors will therefore come from two places: completed withdrawal transactions showing what each vault can still pay, and any confirmed return of stolen funds followed by a transparent distribution plan.
