Following the August 8 farming incident, we have completed a deeper technical investigation into how the exploit occurred, why it was possible, and what needs to change.
Our previous updates focused primarily on the immediate response and asset recovery. With the root cause now confirmed, we want to provide a clearer account of what happened and what comes next.
The vulnerability can be traced back to a farming architecture refactor deployed in December 2024.
At the protocol level, base farming pools and gauge pools serve fundamentally different purposes.
A base pool share represents a user's deposited assets and therefore corresponds to a redeemable claim against assets held in a keeper account.
A gauge share has a different meaning. It is a bbBNC-weighted accounting factor used to determine farming reward allocation. No token is deposited into a gauge pool when this value is created.
Before December 2024, these two pool types were represented separately. The refactor merged gauge pools into the same pool and share-accounting structures used by base pools.
During that process, the gauge pool also inherited the base pool's keeper account.
This created an unintended path in which a gauge accounting value could pass through the same internal share-removal logic as an actual deposit receipt. Once recorded as a withdrawal request, settlement could draw real depositor assets from the base pool keeper.
The vulnerability was also reachable through multiple internal paths. The shared share-removal function could be reached from five call sites, including an interface used by the bbBNC pallet. This meant that the issue existed below the level of a single public farming function and had to be fixed inside the shared internal logic itself.
Although the defect was introduced in December 2024, it initially could not be exploited.
The amounts generated by the gauge-share calculation were far larger than the assets available in keeper accounts. Any attempted withdrawal would therefore fail because of insufficient keeper balance.
In April 2026, a numeric normalization fix changed the magnitude of these values. The change was intended to correct numerical behavior, but it unintentionally compressed the affected values into a range that the keeper could successfully settle.
This transformed an existing dormant defect into an exploitable vulnerability.
We verified this causal relationship through reproduction testing. When the normalization behavior was reverted, the exploit consistently failed because the requested amount exceeded keeper balances. At the production value introduced after normalization, the exploit succeeded.
The April change therefore acted as the trigger that made the defect exploitable.
The attacker appears to have prepared the transaction through extensive offline simulation.
The observed gauge amplification factor was approximately 1003.108682×, determined by a bbBNC position created by the attacker inside the same transaction.
The attack then proceeded through several stages within one atomic transaction:
Each extraction round combined legitimate farming operations with an additional withdrawal request that had no corresponding underlying deposit.
The amounts were also carefully pre-calculated. The final extraction round for each pool was deliberately reduced so that the keeper could be almost emptied without triggering an insufficient-balance error, which would have reverted the entire transaction.
The deployed contract itself performed no arithmetic and did not depend on live chain-state decisions. It primarily replayed values that had already been calculated before the transaction was submitted. This strongly indicates that the exploit had been rehearsed against simulated chain state beforehand.
All required conditions were created inside the same transaction. The attacker did not need to hold the required bbBNC or LP positions in advance.
From preparation to extraction, the entire attack completed in one transaction and one block.
The gauge withdrawal waiting period also defaulted to zero, allowing settlement to occur immediately within that same block. Once execution began, there was effectively no opportunity for manual intervention.
The investigation further confirmed that EVM was not the source of the vulnerability. Although an EVM contract was used during execution, the same exploit logic could have been performed using the chain's atomic batch functionality alone.
The investigation identified several weaknesses that allowed the defect to survive code review, testing, and production deployment.
The most important was the absence of a protocol-level fund invariant.
The farming system did not automatically enforce a condition equivalent to:
Keeper balance ≥ total redeemable depositor claims
Existing tests validated individual farming operations, but they did not continuously verify that the assets held in a keeper remained consistent with all outstanding user claims.
This allowed two values with very different economic meanings, an asset-backed deposit receipt and a gauge accounting weight, to move through the same logic without triggering an invariant violation.
There were additional contributing factors.
Gauge and base pools shared the same ID type and ID space, with insufficient boundary validation between them.
The December 2024 refactor also carried over a keeper field that had previously been harmless because gauge pools had no withdrawal path. Once the pool types were merged, that same field became part of an active payment path.
The April normalization change affected a value consumed across multiple modules, but the review focused primarily on the numeric correction itself. Its downstream interaction with withdrawal settlement was not fully traced.
Monitoring was another major gap.
During the attack, a 99.97% single-block decrease in keeper balance did not trigger an internal alert. The incident was first identified through an external report.
At the same time, our reconstruction confirms that monitoring alone would not have stopped this attack. The attacker created every required position and completed the extraction inside a single block.
This means the primary defense must exist at the protocol level, preventing invalid fund movements from being finalized in the first place, with monitoring acting as an additional layer of protection.
The farming exploit did not affect the DOT reserves backing vDOT.
This distinction is important because the vDOT involved in the farming incident and the underlying reserves backing vDOT are held and managed through separate protocol paths.
The forensic reconstruction confirmed that no unauthorized vDOT minting occurred.
Every asset extracted during the incident can be reconciled directly against decreases in farming keeper balances. The exploit path remained confined to farming keeper sub-accounts and never accessed the vDOT minting mechanism or the underlying staking reserves.
The attacker subsequently sold extracted vDOT on the secondary market, creating temporary price impact in the DOT/vDOT pool. That market imbalance was largely corrected through arbitrage and did not change the protocol-level backing of vDOT.
vDOT therefore remains fully backed by its underlying staked DOT.
The vulnerability has been localized, and the root cause has been confirmed through full attack reproduction.
We have implemented three independent layers of defense, together with a state migration designed to remove vulnerable state and regression tests based directly on the original attack.
Each defense layer has been independently tested by reverting that specific protection and attempting the exploit again. This allows us to verify that each layer directly blocks the identified attack path.
Because the vulnerable behavior could be reached through several call paths, the core fix has been applied inside the shared internal share-removal logic rather than relying only on protections at individual extrinsic entrypoints.
We are also implementing broader security improvements across the farming architecture, including:
Farming services will remain paused while remediation deployment, migration rehearsal, and the broader security review are completed.
Asset recovery also remains ongoing.
The subsequent movement of funds from HitBTC to Binance has provided an important lead for the investigation. We are working with Salus , SlowMist , law enforcement, and the relevant exchange teams to continue tracing the assets and pursue available recovery channels.
For affected users, farming positions and shares will remain recorded on-chain. These records preserve each user's position and will serve as the basis for any subsequent recovery or remediation process.
No action is required from affected users at this time.
We will share further updates as soon as there is confirmed progress.
