How small deposits drained 77 ACryptoS vaults and what users can still withdraw

The payment rail for your crypto. One card. Every chain. No KYC. Spend with Apple Pay or Google Pay in 180+ countries.

ACryptoS reportedly lost about $665,000 across five chains after its vaults issued attackers shares out of proportion to what they deposited. The yield aggregator stopped accepting deposits and urged users to withdraw the assets still available. For affected depositors, the amount left in their vault is a separate question from whether the project can recover funds taken from it.

Summary

Security firm SlowMist recorded approximately $665,000 in losses from an 8 November ACryptoS exploit affecting 77 vaults across Arbitrum, BNB Chain, Polygon, Base and Optimism.
A missing input check in the multi-token deposit function reportedly let an attacker submit an amount for one token in a vault that accounted for two, distorting the share calculation.
Attackers could redeem the newly minted shares against both assets. Existing shares could still appear in a wallet even after the underlying assets available to their holders had fallen.
Incident trackers say ACryptoS disabled deposits, kept withdrawals open and subsequently moved to deprecate the protocol. An open withdrawal route only allows a user to redeem against what the vault can still pay.
The project reportedly offered a 10% bounty for funds returned. The offer leaves several questions open, including whether money reaches a recovery address and how it would be distributed to affected depositors.

The first transaction a depositor makes in a vault determines how much of the pool they can claim later. At ACryptoS, that calculation could apparently be thrown off by leaving out an entry in a list submitted to the deposit function. The deposit was small. The claim the vault handed back could cover most of the assets already inside it.

SlowMist’s incident record attributes the 8 November losses to missing input validation in a function called depositMulti. It puts the loss at $665,429 and says the flaw was used against 77 vaults across five networks. That is a reported aggregate. An exact account for any depositor would require the records for the specific vault and the block at which its balances changed.

The response has left users with two issues to follow. They may still have a way to withdraw assets left in a vault. Recovering anything taken by the attackers would involve a separate process, beginning with an identifiable return of funds.

The deposit that counted for too much

ACryptoS’s strategy documentation describes vault shares as the tokens users receive when they deposit into a strategy. The shares represent a claim on that strategy’s assets. A vault can hold positions involving two tokens, and the amount it issues to a new depositor depends on how their contribution compares with the assets backing the existing shares.

The reported weakness arose because the contract accepted a list shorter than the number of tokens it was supposed to consider. SlowMist says an attacker could submit a small amount of a single token and mint the vast majority of the shares. The withdrawal side then honoured the shares against both underlying assets. The mismatch between what the deposit counted and what the withdrawal paid is what made the trade profitable.

An illustration shows where the loss lands. Suppose a vault holds assets worth £100,000 and has 100 shares outstanding. If the vault mistakenly values its existing holdings at £10 during a deposit, a contribution of £10 can look as large as all the assets already in the vault. A formula that mints 100 new shares on that basis would give the depositor half the shares for £10. If redemption pays out against the real balance, half the assets could leave. The numbers are illustrative and do not reproduce a particular ACryptoS transaction.

For an existing depositor, the problem can start before the attacker withdraws. The depositor still holds their original number of shares, but those shares represent a smaller percentage of the supply. Once the attacker redeems, the shares that remain sit against a depleted pool. Checking the share count in a wallet alone cannot show the loss.

How one error reached five chains

The incident tracker lists Arbitrum, BNB Chain, Polygon, Base and Optimism as the affected networks. That footprint is consistent with an error in vault logic shared across deployments. A transaction that uses a faulty contract on one chain gives other actors a pattern they can try against versions of that contract elsewhere.

The distinction matters when reconstructing the incident. For each chain, the relevant trail begins with the vault address and the calls that minted and redeemed shares. A later bridge transfer can be relevant to the destination of proceeds, but a bridge is not required to explain the original loss on a second chain. The source of that loss is the local vault paying out assets against shares it had just issued.

The headline figure also combines balances valued in dollars. A reconciliation would need to list what actually left each vault in token units, when it left and the price used in the estimate. A later quote for the same assets can produce a different total without changing the number of tokens taken.

What the withdrawal window can deliver

SlowMist says deposits were disabled and withdrawals remained open. A deposit halt can block the call used to create the disproportionate shares. The withdrawal path has a different job. It lets existing holders redeem for the assets the vault still controls, subject to the state of the particular deployment.

That can produce very different outcomes for depositors using the same interface. One may have shares in a vault that was never drained. Another may see a withdrawal quote far below the value shown before the attack. A third may still hold a position in a strategy whose assets have to be unwound before the contract can pay. The project’s broad statement about withdrawals does not determine the amount each holder can receive.

The project’sinterface documentation distinguishes the tokens a user is estimated to receive from the vault position itself. For incident reporting, a completed withdrawal and the resulting token transfers are stronger evidence than a displayed estimate. The distinction becomes more important if a deprecated interface is no longer regularly updated.

A bounty offer leaves the claims question open

Incident trackers say the project offered a 10% bounty for returned funds. An offer can give an address holder a reason to negotiate. Its practical effect can be measured only after a return transaction, ideally to a publicly identified address. The chain can show that funds arrived there. A distribution plan would still be needed to establish what individual depositors receive.

That plan would have to decide whether to reconcile losses by vault, by chain or at the protocol level. It would also need a snapshot or another accounting method to identify people whose economic claims were diluted. A person who withdrew the remainder before a recovery plan was published may still have suffered a loss. A person who acquired shares later presents a different accounting question.

The available incident records establish a reported mechanism, loss estimate and response. They do not yet establish a recovery or reimbursement timetable. The next evidence that changes the depositor’s position is a confirmed withdrawal of remaining assets or an onchain return followed by a documented allocation.

What the vault actually owned

ACryptoS’s concentrated-liquidity strategies manage positions in pools that assign liquidity to price ranges. The positions can contain different amounts of the two tokens as the market moves or as the strategy changes where it supplies liquidity. A vault holding relatively little of one token can therefore still have substantial value.

The user holds shares in the strategy. The shares give the holder a proportionate claim on the assets the vault controls. The user’s wallet does not need to show the underlying position directly for the claim to exist. The share supply and the vault’s assets determine what the user can redeem.

That relationship changes with every deposit. If a vault receives an amount equal to 1% of its prior value, the new share issuance should be proportionate to the contribution. Existing holders will own a smaller percentage, but the total assets have grown to support the new claim.

An excessive issuance produces a different outcome. The percentage held by existing depositors drops while the backing grows by very little. If the new shares are then redeemed, the remaining share supply sits against a smaller pool of assets. The change reaches a depositor even if they took no action during the incident.

The distinction also separates a flaw in the vault from one in the liquidity pool underneath it. The pool can continue to handle trades under its own rules while the vault makes an error in valuing its claim on that pool. Users who interacted directly with the pool and users who bought the vault’s shares have different contract exposure.

A missing entry and an amount of zero are different inputs

A deposit function that accepts several tokens needs to know which amount corresponds to each token. A two-item list can include a zero to indicate that the user is not adding the second asset. The zero still preserves the second token’s place in the input.

A one-item list can behave differently if the code uses its length to decide what it will value. The list can end before the contract reaches the second asset. If the vault also uses that shortened list to calculate what it already owns, it can exclude assets that still back the existing shares.

That is the reported problem in ACryptoS’s depositMulti function. The issue was the relationship between the input and the share calculation. A strategy may legitimately support deposits made with one token, but the calculation still has to value the entire vault before it decides how much of the supply the new depositor should own.

The more value the omitted token represented, the larger the gap could be. A vault with most of its assets in the counted token would be less exposed to the same input than one whose value sat largely in the omitted token. This helps explain why the same kind of call need not extract the same percentage from every deployment.

A useful reconstruction follows the incoming token transfer, the share mint and the outgoing redemption. The incoming transfer gives the actual contribution. The mint shows the new claim. The outgoing transfers show what the contract paid when that claim was exercised.

Looking only at the last step can make the exploit resemble a withdrawal by an ordinary holder. The contract had issued the shares and accepted them when they were presented. The reason the payment was disproportionate sits earlier in the sequence.

A comparable distinction appeared in the Yearn yETH incident, where an older contract reportedly allowed excessive issuance before assets left. The code and the amount taken differed. Both cases show why the asset transfer has to be read with the transaction that created the claim.

How a shared flaw can spread between deployments

A transaction discloses its inputs and the calls it makes. Once the first successful exploit appears, someone observing the chain can study the route it used and look for similar contracts. A second actor can then attempt to reproduce the sequence against a different vault.

The second vault does not need to hold the same assets. If it uses the same faulty accounting, the relevant question is how it responds to the short input list and how much of its own value is excluded. Its current balance can make the result larger or smaller even when the deposit calls look similar.

A different chain adds another contract address and a separate history. It does not prevent a copied call if the vault uses the same vulnerable logic. Each local mint and redemption can take assets from that local vault without the first attacker needing to move proceeds there.

Bridges become relevant when money moves between chains after the withdrawal. The source transaction shows where the funds left, while the destination transaction shows where the bridged value arrived. Reading those records together helps separate a follow-on transfer from a new attack on another deployment.

The address that carried out a transaction is also distinct from the person behind it. One actor can control several addresses. Several actors can reproduce a sequence after seeing it onchain. Similar calls can establish a common technique without establishing that the same person executed them.

Crypto.news reported a separate sequence after the Premia Labs exploit on Arbitrum, where funds went through swapping services after vault collateral was withdrawn. Tracking those later movements answered where the proceeds went. The calls into the vault answered how they were taken.

What goes into the $665,429 estimate

The reported dollar total combines assets taken from several vaults across five networks. It is useful for comparing the scale of the incident with other losses. A depositor needs a more specific comparison to find out what happened to their own position.

The first step is to identify the vault contract and the chain on which it sits. The balance immediately before exploitation shows what was backing its shares. The balance after the exploit shows what remained after the relevant withdrawals, subject to any other activity in the same period.

A loss estimate also needs the supply of shares at those points. If the attacker minted shares and burned them during redemption, the supply after the event could be closer to its earlier level than at the height of the exploit. The final supply can look familiar while the assets per share have fallen.

You might also like: Bitcoin price drops toward $74K as crypto liquidations top $1 billion

The dollar value adds a separate calculation. Assets can be priced when they left, at a common time after the incident or when the project reports the total. The resulting sums can differ even if everyone agrees on the tokens taken. A reconciliation is easier when it lists both token quantities and the time used for their valuation.

The count of affected vaults does not show how losses were distributed. A small vault and a large vault each add one to the count, even if one accounts for far more money. The number of vaults also does not establish the number of depositors. One address can hold shares in several deployments, and one contract can represent positions held for multiple users.

There is also a difference between the vaults in which someone used the bug and the vaults subject to a response. A team may disable a function across an entire contract family to prevent later attempts. A user whose vault was not drained can still receive instructions to exit if the operator is deprecating the service.

What a deposit halt protects

Disabling deposits can stop the creation of new shares through the vulnerable route. Leaving withdrawals open preserves a way for existing shareholders to redeem what their particular vault still controls. The two controls address different sides of the contract.

For an untouched vault, an open withdrawal route can let holders exit before the project winds down its interface. For a depleted vault, the same route can return less than the pre-attack value. A successful withdrawal tells a user what the vault could pay at that moment.

A wallet can show a share balance without showing the full economic impact of the exploit. The number of shares owned by an account can remain unchanged as the backing per share falls. The redemption estimate and the eventual transaction receipts give more direct evidence of what those shares can return.

Some positions may need the underlying liquidity to be unwound before the vault can pay. The outcome depends on the strategy and its current state. A single statement that withdrawals remain open does not establish that each position will settle immediately or return the same mix of assets as it did before.

An exchange or a service that held shares for customers may have another layer of accounting. The onchain vault pays the address that presents the shares. The service then has to determine how that payment is reflected in customer balances. The onchain receipt and the customer’s statement cover different steps.

Emergency controls can also restrict users even when the reason is external. Crypto.news reported that Aave restricted reserves after the Binance attack because of exposure created through its markets. At ACryptoS, the reported intervention addressed the deposit function itself. In either case, the details of the restriction determine which actions users can still take.

When an address label can help recover funds

A public list of addresses can help services spot proceeds that arrive later. It does not give the project control of the addresses or establish how much remains in them. Balances can change after swaps, transfers or bridges.

A freeze depends on who can control the asset or account at the point it is found. An issuer may have controls over certain tokens. Its ability to restrict a balance depends on which token an address still holds. If the value has already been converted to a native asset, a power to freeze the original token does not extend to that asset.

A centralised exchange can have a different kind of control when money reaches an account there. It may be able to restrict withdrawals subject to its policies and legal obligations. A request for action, an actual freeze and a transfer back to the project are separate events that need separate evidence.

A bridge can help identify the destination without having custody indefinitely. Once value reaches the destination address, the operator may no longer control it. The transfer can still be traced using the records of the source order and the destination payout.

Finding the defect is a different stage from getting funds back. After a separate exploit, Balancer identified rounding logic as the cause. That explained how its pools paid out assets. Recovery depended on what could be secured or returned after those transactions.

How recovered money could be divided

The 10% bounty is an offer tied to the return of proceeds. A comparable percentage appeared in Solv Protocol’s recovery offer after a different incident. The figure sets the terms for the party that might return funds. It says little about what any single depositor receives.

A return transaction would establish what arrived at the destination and in which assets. A distribution plan would have to connect that balance to the vaults and holders that suffered the loss. That connection may be straightforward if the returned assets can be traced to one vault, or more complicated if proceeds from several chains were combined.

One approach could calculate each vault’s shortfall and allocate returns in proportion to those losses. Another could treat all affected vaults as a group. The choice can change the result for users whose original vault had a different recovery rate from the overall incident.

The snapshot date matters because shares can move after the exploit. Someone who redeemed the remaining assets may still have lost money. Someone who acquired shares later may have bought them at a price that already accounted for the loss. A distribution would have to say how it treats both cases.

Asset denomination can change the allocation as well. A token-based calculation preserves the amount lost in the original units. A dollar-based calculation needs a reference time and pricing method. The distinction becomes relevant when recoveries arrive in a different token or after prices have moved.

Any reimbursement from the project’s treasury would add a different source of funds. The project would need to describe the amount, the conditions and the recipients before users could tell whether it covered the entire loss. The bounty itself supplies no such financing commitment.

What remains when the interface is deprecated

ACryptoS’s documentation on security identifies contract flaws as one of the risks of the service. Deprecation introduces a question about the support that remains for the contracts and the interface users rely on to find them.

A contract can continue to exist after the project stops maintaining a website. A route to withdraw can remain active while deposit links are removed. A strategy can also depend on other components whose operation matters to holders even after the team stops opening new positions.

ACryptoS’s support guide distinguishes current, deprecated and legacy interfaces. A user who deposited at a different point in the project’s history may have a position under a different contract family. An exit notice needs to identify the route that corresponds to that deployment.

A familiar underlying pool is only one part of that position. The vault adds its own rules for deposits, issuance and redemption. An application can use a well-known exchange for liquidity and still expose users to the code that decides how much of that liquidity their shares represent.

The amount a vault pays is the most immediate record a depositor can obtain. If the project later recovers proceeds, the return transaction and its distribution terms will establish a separate claim. The two events belong to different parts of the incident even when they affect the same person.

How to reconcile an individual vault position

An affected depositor can have records in several places. Their deposit receipt shows what they supplied and the shares they received. The vault’s later balances and share supply show what was backing those shares before the exploit. The withdrawal receipt shows which assets the contract ultimately paid.

Those records can disagree with an account’s apparent dollar value for reasons unrelated to missing assets. The two tokens can change price, and the strategy can shift its exposure while the user holds the same number of shares. The exploit is the change that can be tied to the disproportionate issuance and the transfers it enabled.

A token-by-token comparison also matters when the vault held most of its value in one asset. A withdrawal might return almost all of one token and very little of the other. The amount of one token alone would not show the full effect of the incident on the claim.

A protocol-wide TVL figure cannot supply that detail. It can include several strategies, including vaults the exploit never reached. It can also change because users withdraw normally after a deprecation notice. The fall in the protocol’s TVL over a day would therefore be a different number from the total removed through the attack.

A user who keeps the vault address, chain and withdrawal receipt can link any later distribution to the original position. If a claims process is announced, the useful detail will be whether it counts the amount the holder was able to withdraw and how it reconstructs the position before the exploit.

For now, the withdrawal route addresses the assets still controlled by the vaults. The bounty addresses assets already transferred out. The amount shown in a recovery wallet and the terms of a distribution would be the next records that could change a depositor’s remaining claim.

What to Watch

Vault-level balances: Token balances and share supply before and after the exploit can show how much backing each affected vault lost.
Withdrawal execution: Successful redemptions can show what users receive from specific vaults after deposits were disabled.
Recovery transfers: Transactions to a publicly identified address can establish how much the project actually recovered.
Depositor accounting: A claims proposal should explain how losses are measured and which holders qualify for any distribution.
Deprecation notices: Project updates should specify which interfaces and contracts will remain available as the service winds down.

FAQs

How much did ACryptoS reportedly lose?

SlowMist recorded $665,429 across 77 vaults. The figure is a reported dollar estimate and should be distinguished from a token-by-token reconciliation.

Which chains were affected?

The incident trackers list Arbitrum, BNB Chain, Polygon, Base and Optimism. Each affected vault has its own balances and transaction history. The five-chain estimate combines losses from those deployments, while the amount left for an individual holder depends on their vault.

What was wrong with the deposit function?

The function reportedly accepted an array of amounts shorter than the vault’s expected list of tokens. That allowed a small deposit to produce a much larger share of the vault than it should have.

Why could the attacker withdraw two assets after depositing one?

The shares represented a claim on both assets held by the vault. Once the deposit function had issued the shares, the withdrawal function redeemed them against the vault’s backing.

Can users still withdraw?

Incident trackers say withdrawals remained open after deposits were disabled. The amount a user can receive depends on the assets and shares in their individual vault.

Does seeing the same share balance mean the funds are safe?

A wallet’s share count does not measure its share of the underlying assets on its own. An increase in total shares and a reduction in vault balances can both lower what those shares redeem for.

Does the bounty mean ACryptoS has recovered funds?

The reported 10% bounty is an offer to parties that return funds. A transfer to a recognised recovery address would establish what came back. The project would then need to decide how to allocate the returned assets across vaults and depositors.

Who receives any money recovered later?

The available incident reports do not set out a distribution plan. A plan would need to define eligible losses, relevant snapshots and the allocation across affected vaults.

US crypto regulation hub

Crypto mining in the US: federal rules and the state map

Crypto kiosk rules by state: bans, licenses and the fraud data

Crypto ETF rules in the US: how a fund gets listed now

Crypto banking access in the US: master accounts, the chokepoint, and what changed

CFTC and crypto in 2026: what the agency now governs

Is crypto legal in the US? Yes, and here is the structure

Crypto executive orders: what the White House has actually ordered

SEC crypto enforcement in 2026: from registration war to fraud beat

IRS crypto tax rules in 2026: what actually gets taxed

The OCC and crypto: national trust charters, explained

View all