The security process implemented by the Denaria team consisted of two external audit cycles, each preceded by an internal audit. Both external audits were carried out in collaboration with the Consensys Diligence team.
The final external audit resulted in the following report produced by the auditors on September 26, 2025:
https://diligence.security/audits/2025/09/denaria-2/
Following the auditors’ recommendations, the team continued working on:
adversarial testing
rigorous invariant checks
codebase simplification
internal audits
additional security measures (Phylax assertion)
The protocol was deployed on mainnet on December 15th for internal testing:
https://lineascan.build/address/0xd07822ee341c11a193869034d7e5f583c4a94872#code
Following the completion of the second external audit, during subsequent internal codebase reviews, the team identified an accounting issue related to the accumulator A(t) (as defined in formula (17) of the whitepaper). Due to its strictly increasing nature, this accumulator could eventually lead to an overflow over time. Whitepaper 0.1 reference:
https://docs.denaria.finance/protocol-whitepaper/#LP%20shares
To address this, a refactor was implemented, as reflected in the updated version of the whitepaper. As a result, this refactor was carried out after the completion of the collaboration with the external auditing team. Whitepaper 0.2 reference:
https://github.com/denaria-finance/dynAMM/blob/main/whitepaper.pdf
The new approach shifted from abstract share tracking to direct balance tracking, ensuring that:
each LP’s balances (vStable and vAsset) remain bounded by total pool balances.
the overflow risk is naturally constrained.
Following this implementation, the team decided to conduct another internal audit. However, this change introduced a logical flaw, which was later exploited.
This refactor was deployed in a subsequent release on March 3rd:
https://lineascan.build/address/0xb68396dd4230253d27589e2004ac37389836ae17#code
These latest contracts, deployed on Linea mainnet, were the ones targeted in the attack.
Following this deployment, the team also began collaborating with Phylax to introduce transaction-level assertions at the sequencer level. The goal was to proactively block any transaction that violated predefined safety conditions before execution. In production, an assertion was implemented enforcing the following rule (invariant): “Any user cannot cause bad debt to himself as a result of his transaction.”
Unfortunately, this safeguard was not involved to prevent the exploit because no bad debt was generated during the attacker’s operations.
It is important to note that the exploit did not involve any asset price manipulation, or in general any malfunction or misuse of the Chainlink Data Streams service.
Based on the analysis conducted by the Linea security team and the Consensys Diligence team, the attack resulted in a loss of approximately $165,618 USDC and was executed in a single transaction.
Attack Tx: https://lineascan.build/tx/0xcb0744a0d453e5556f162608fae8275dabd14292bffbfcd8394af4610c606447
The attacker:
used a AAVE flash loan as the initial capital
deployed multiple helper contracts (acting as LPs and traders)
executed two identical exploit rounds within the same transaction
Each round followed this sequence:
Provide one-sided liquidity as an LP (only vUSD)
Execute a trade
Withdraw profit via realizePnL
Due to a flaw in the accounting logic, the attacker’s LP position was credited with the entire asset side of the pool, allowing them to drain all available liquidity. The parameters of the attack were deliberately chosen to force the system into generating the error.
The root cause of the exploit lies in the interaction between two issues.
The first is a rounding asymmetry in the matrix-based accounting system. During trade execution, numerical precision effects caused one of the computed components of the LP balance to become slightly negative, even though in theory it should have been zero or very close to it. This type of deviation is subtle and emerges from the combination of rounding during updates and truncation during subsequent calculations.
The second issue is related to how this value was handled in the code. The negative result was cast directly from a signed integer (int256) to an unsigned integer (uint256) without any validation. In Solidity, this operation does not revert but instead wraps the value to a very large number. This effectively transformed a small negative value into an extremely large positive balance.
A subsequent safeguard in the logic capped balances to the total pool liquidity. However, instead of mitigating the issue, this cap effectively converted the inflated value into a claim over the entire pool. As a result, the attacker’s LP position was credited with almost 100% of the available virtual assets, resulting in an inflated PnL. This PnL was converted to the total amount of USDC collateral in the Vault and withdrawn.
Individually, neither of these issues would have led to a critical failure. The rounding alone would only introduce minor inaccuracies, and the casting issue would not be exploitable without a negative value. It is their combination that made the exploit possible.
The assertion implementation was not involved in this process, as no bad debt was generated during the attacker’s operations.
The attacker collected the funds into this address on Linea:
https://lineascan.build/address/0x8d6778d7fae00ad2e0bc12194cf03b756fed9db3
These were the subsequent movements:
Funds were bridged to Ethereum via Across Protocol.
Assets were converted into ETH in the bridging process
Funds were transferred to this EOA: https://etherscan.io/address/0xccf16a13b7607489cce35e6c0c0a7225b2dc052d
The team promptly reached out to the attacker through an onchain message, proposing the return of funds within 48 hours in exchange for a 25,600 USDC (15% of total stolen amount) bounty and a commitment not to pursue legal action:
https://etherscan.io/idm?addresses=0x191933dfd97040a305e70fd0409cbb3bd716505f%2c0xccf16a13b7607489cce35e6c0c0a7225b2dc052d&type=1
Following the message, the attacker began interacting with Tornado Cash, splitting the funds across multiple transactions of 10 ETH and 1 ETH. The interaction of these funds with Tornado Cash suggests that the attacker has no intention of returning the funds, and is instead attempting to obfuscate their trail.
At the same time, the team immediately disabled the two user interfaces (mobile and desktop) interacting with the affected contracts, preventing any further user activity and ensuring that no additional funds could be deposited into the exploited system from the official project UIs.
At the time of writing, the funds have not been returned and the 48-hour deadline has expired. The team is actively pursuing legal actions to protect the Foundation supporting the project and is continuing its onchain investigation efforts to identify the attacker.
The team refunded all users who had open trading positions and had funds deposited in the vault. Refund details:
https://gov.denaria.finance/t/denaria-exploit-official-update-on-current-status/21
The mobile interface has been re-enabled to allow users to manage the USDC funds deposited in their smart accounts. Trading functionality is currently unavailable.
The team is currently working on designing a comprehensive plan to bring the product back online in a fully fixed and secure state. Further updates and official communications will follow.