hashfriend.eth
hashfriend.eth

The Singularity Finance DynaVault Hack

An onchain record of the dynBaseUSDCv3 drain and of everything Singularity Finance has done since, while the post-mortem it promised remains unpublished.

On 25 April 2026, an attacker drained dynBaseUSDCv3 on Base and walked away with 413,132 USDC plus residual yield tokens. The vault held roughly $450,000 before the attack. Its oracle accepted prices from empty pools created by the attacker, reducing its reported value to $100. The attacker then bought almost all the vault’s shares and redeemed them for its reserves.

Singularity Finance promised a post-mortem the next day. As of 14 October, nearly six months after the exploit, the report remains unpublished. During that time, the team replaced the oracles, reopened withdrawals and launched more vaults.

I lost money in the drained vault. I have been documenting the transactions and asking the team to explain what happened.

Timeline

Between 13 September and 17 December 2025, fee tier 42 first appears in two transactions, then in twenty-four more routes and another fourteen. The initial configuration had used real tiers. By the end of the year the oracle carries 40 invalid direct routes. Other pricing paths can still supply values.

On 19 January 2026, someone at Singularity Finance registers six yield-token routes against USDC on the vault’s oracle, one setUniV3fee transaction per token, all at tier 42. No pool can exist at that disabled tier. The invalid settings remain through the exploit.

On 25 April 2026, the attacker creates five empty token/WETH pools with extreme prices, which the oracle uses as fallback routes, then drains dynBaseUSDCv3. A 100,000 USDC flash loan from Morpho Blue buys 99.9% of the shares against a vault priced at $100. The attacker redeems them against its reserves, repays the loan and sends 413,132 USDC plus residual yield tokens to the payout address.

On 26 April 2026, the team announces the exploit in Telegram, attributes it to an attacker who “used a flashloan on Morpho to manipulate oracle price”, promises a post-mortem and disables deposits and withdrawals on the seven other Base DynaVaults. Its X post is later deleted.

On 27 April 2026, DefimonAlerts and DarkNavy publish accounts of the drain. Neither identifies the attacker’s pool-creation transaction.

Between May and July 2026, the team privately concedes that the oracle “was the cause of the exploit” but will not confirm it publicly. It says the post-mortem must wait while it is “strengthening the oracles” because publishing could “expose other areas to risk”, then cites its lean team. By July it refuses to discuss the onchain evidence with me.

On 18 and 19 July 2026, the team deploys a new oracle stack and repoints all eight original Base vaults to it. A new Uniswap V3 oracle uses enabled fee tiers. An attempt to point dynBaseWETHv2 at the USDC oracle reverts; a later transaction sets the WETH reference oracle. The old oracle and its 46 invalid direct routes remain. None of this is announced.

Between 20 and 22 July 2026, the governance account switches the permission check off on all eight original Base vaults. Withdrawals resume for the first time since the exploit. People whose money had been locked since April can withdraw it, and nobody tells them.

On 24 July 2026, a new vault, dynBaseUSDCv4, begins operating. It remains in permissioned mode. Its whitelist is granted the same morning to thirteen wallets, plus the team’s own accounts.

On 30 and 31 July 2026, the team gives four different accounts of the reopening and says it withheld the announcement until the post-mortem. It promises the report for early the following week, the first publication window given in three months.

On 2 August 2026, a user in the project’s unofficial price channel asks when the vaults will open again. Withdrawals began resuming thirteen days earlier. The team confirms the reopening there and again promises the post-mortem for early that week. It also says a replacement vault has to be ready for the drained one.

By 10 August 2026, both promised publication windows have passed. The team has published neither a post-mortem nor a general reopening announcement, and has not answered the four questions.

On 14 August 2026, the team drops the dates and waits for “the Eng team to give the green light”. My four questions are forwarded again rather than answered. Meanwhile, the dApp lists six new DynaVaults in beta on three new chains.

On 15 August 2026, the team moves governance on both USDC vault managers to a Gnosis Safe with two owners and a threshold of one. The guardian and oracle admin roles remain where they were. This is not announced either.

On 18 and 19 August 2026, the team moves admin of the oracle registry and USDC reference oracle to the Safe, but leaves the new Uniswap oracle under the same ordinary account. It then opens dynBnbUSDC and dynBnbBTCB to everyone. None of this is announced.

On 21 August 2026, the team again leaves the questions unanswered. It now says a third-party investigator has to approve the post-mortem alongside the engineering team, the first outside party mentioned since April.

On 23 August 2026, pressed by a community member, the team mentions a recovery-fund plan. When asked whether it will arrive before year-end, it answers yes and says “soon”. No details or an actual announcement follow.

On 24 August 2026, the governance Safe adds a third owner and raises its threshold from one to two on Base and BNB Chain. Vaults governed by the Safe now need two of three signatures. The guardian and Uniswap oracle admin remain single accounts. This is not announced either.

On 31 August 2026, the onchain registries contain 18 production DynaVault contracts: nine on Base, three on Ethereum, two on Arbitrum and four on BNB Chain. The management account is still swapping and reporting.

By 8 September 2026, a new gold vault, dynBnbGold, has brought the registered total to 19. Its permission check was disabled on 5 September.

On 16 September 2026, the same admin account opens dynBnbBNB by disabling its whitelist. The team continues opening vaults while announcing nothing.

On 19 and 20 September 2026, a separate exploit hits the ASI token-conversion and bridge infrastructure. The ASI Alliance reports roughly $1.56 million in FET withdrawn from the converter. Fetch.ai identifies a compromised signing key, and SingularityNET says the attacker used access to its cloud infrastructure to mint tokens and withdraw assets. PeckShield links the same attacker to unauthorized minting of 408.5 million NTX and 260 million AGIX and 53.838 million WMTx. No direct connection to April’s DynaVault drain has been established. The recurring security concern is critical powers entrusted to individual keys.

On 21 September 2026, the registries still contain 19 production DynaVaults: nine on Base, three on Ethereum, two on Arbitrum and five on BNB Chain. At midday, thirteen have their whitelist disabled. That afternoon, the wallet that set fee tier 42 opens two Ethereum and both Arbitrum vaults, leaving only two of the 19 permissioned. The same wallet still governs eight of them directly rather than through the Safe: the five on Ethereum and Arbitrum, plus dynBnbUSDT, dynBnbBNB and dynBnbGold.

On 22 September 2026, the team announces its gold vault in Telegram as “in beta/preview mode” and coming soon to the community. It is the first DynaVault-related announcement since the exploit. Its permission check has been off since 5 September, so anyone could already deposit.

On 23 September 2026, after I ask the four questions again, the team publicly confirms that fee tier 42 was “part of the failure that enabled the exploit”. It says the tier was used to keep certain Uniswap pools from pricing vault assets, that this protection “proved incomplete” and that the oracle also “failed to handle the missing price correctly”. The post-mortem, which will include the recovery plan, is in internal review and has no date. The team says the gold vault and a few other BNB Chain vaults are open “for external non-whitelisted testing”, which is why an ordinary wallet governs them. It advises waiting until they are public and governed by a multisig. Five hours later, the same wallet hands the gold vault’s governance to the Safe.

Between 23 September and 6 October 2026, the wallet hands governance of six more DynaVaults to the Safe on Ethereum, Arbitrum and BNB Chain, leaving only dynMainUSDCv3 under its direct control. It remains guardian of all 19. None of this is announced.

On 13 October 2026, a deposit circuit breaker on dynMainUSDCv3 halts deposits when one of its positions loses 0.13% of its reference value, and the team replaces that position’s oracle the same evening. The eight original Base vaults, including the drained one, run the older manager code without this breaker.

The Exploit

The vault held five funded positions in yield tokens and 100 idle USDC. To calculate the vault’s value, its oracle needed prices for those tokens.

A Uniswap V3 pool is identified by its two tokens and a fee tier. On 19 January, the project’s admin account configured six direct token-to-USDC routes with fee tier 42, including this route. That tier was not enabled on Base’s Uniswap V3 factory, so the pools those routes specified could not exist. The oracle looked up any route without a fee at tier 3000, so leaving a route unset did not switch it off.

The oracle could still obtain prices through other paths. The January settings alone did not reduce the vault’s reported value to $100.

On 25 April, the attacker created five token-to-WETH pools at tier 3000. No fee was set for those fallback routes, so the oracle looked them up at that default tier. The attacker initialized the pools with extreme prices and added no liquidity.

The oracle’s minimum liquidity threshold was zero. Once the pools had the required 60 seconds of price history, the oracle accepted their prices. Those prices rounded the value of the five funded positions to zero. The vault’s totalAssets() calculation then counted only the 100 idle USDC.

Vault shares represent a claim on the assets held by the vault. New depositors receive shares according to the value the vault reports. Because the vault now reported just $100, the attacker’s 100,000 USDC deposit bought about 99.9% of its shares.

The attacker then called redeemProportional(). That function also runs the accounting code, but it calculates the payout from the share ratio and the quantities of tokens held. The attacker could therefore redeem the newly minted shares for almost all the actual reserves.

A Morpho Blue flash loan funded the deposit. After repaying it, the attacker sent 413,132 USDC and residual yield tokens to the payout address. The price manipulation had happened in the earlier pool-creation transaction.

The invalid fee settings extended beyond this vault. The indexed history records 46 successful calls setting distinct routes to tier 42 between September 2025 and January 2026. All came from the same admin account, following 14 configurations that used enabled tiers.

Each invalid setting broke a direct route. Other pricing paths could still work. Changing the fee alone would not necessarily have fixed every route either. At the block before the drain, PUSDCHY had no direct USDC pool at any of the six enabled tiers checked.

The Team’s Response

The team was right that the attacker manipulated oracle prices. The team’s description was wrong about the flash loan, which funded the deposit after the attacker had changed the prices. My earlier account omitted the pool-creation transaction and treated the $100 valuation as a result of the configuration alone.

DefimonAlerts identified the zero-liquidity WETH fallback pools but did not identify the attacker as their creator. It labelled its account preliminary. DarkNavy also noted those pools, but incorrectly said the oracle returned zero prices with zero timestamps. The saved reads show zero prices with nonzero timestamps after the pools had enough observation history. The oracle accepted the attacker’s prices.

By July, the team was refusing to discuss the onchain evidence with me.

I’ve answered the exploit questions in the past, will not debate your interpretation of how it happened for various reasons.

Calling the findings my “interpretation” left the recorded transactions and oracle settings unexplained. The team could identify an error in my account or explain its own decisions. It did neither.

The team said publishing the post-mortem could “expose other areas to risk”. That concern could explain withholding details of an unresolved flaw. It does not explain why the team could not acknowledge the configuration already visible onchain, describe the completed changes or tell depositors what remained unresolved.

The team also described the drained vault as high risk. That label does not explain why its own oracle used an invalid fee tier or accepted prices from empty pools. Several vaults shared pricing infrastructure, and routes against WETH, cbBTC and EURC also used tier 42. Before the exploit, I repeatedly asked the team to document what its risk tiers meant. It did not provide that explanation.

Recovering stolen funds and reimbursing depositors are separate questions. Gnosis Pay and Hinkal suffered exploits in the same period and made users whole despite being unable to recover the stolen funds. Singularity Finance has not said whether it will use project funds or collected fees to cover the loss.

The Silent Reopening

The team announced the freeze but did not announce that withdrawals had resumed. A depositor who checked in May and found their funds locked had no reason to know that anything had changed.

When asked about the reopening, the team gave four explanations.

Its first reply described whitelisted wallets testing the oracles. But the relevant permission grant went to the team’s own zapper, and governance then removed the restriction for every holder.

Its next reply pointed to dynBaseUSDCv4. That was a new vault with a separate whitelist. It held none of the funds frozen in April, and the reply itself said its whitelist was unrelated to reopening the other vaults.

Later replies cited beta testing and frontend fixes. I cannot verify when the closed-source frontend began allowing withdrawals. In the same exchange, the team dismissed users who interact with the contracts directly.

We’re not catering in particular to users who interact with our contracts on-chain. We provide a UI for users to interact with our products. […] Source

The contracts hold users’ money and decide who can withdraw it. Direct access lets depositors use those contracts even when the team’s frontend fails. The team’s focus on its frontend does not excuse withholding news that the contracts were open for withdrawals.

Yes, we’ve delayed the announcement about the reopening of the other Vaults a bit, as we intend to make it on the same day we share the exploit postmortem […]. Source

The team also said a replacement for the drained vault had to be ready. Neither the report nor the replacement vault was needed for holders to withdraw from the other vaults.

By 14 October, twelve weeks had passed since withdrawals began resuming. The promised post-mortem was still unpublished.

Decentralization Theater

The account that set fee tier 42 is an ordinary wallet, rather than a contract requiring multiple signatures. It still holds admin control of the replacement Uniswap oracle and the guardian role across the production vaults.

Those powers matter separately. The guardian can halt the vaults. The Uniswap oracle admin can change the fee tiers used to price the Base vaults. Its setUniV3fee function still accepts a uint24 without checking whether the factory has enabled that tier.

Requiring two signatures for governance does not change either of those separate powers. Since 6 October, the Safe governs every production DynaVault except dynMainUSDCv3, which this wallet still governs alone.

The team points to documentation that does not describe the deployed DynaVaults. Its 2023 posts describe separate strategy contracts, technical audits and community votes. As of 21 September, none of the 19 production DynaVaults has a configured strategy. The sdao.eth voting history contains no proposal approving these deployed vaults or their strategies. The documentation at docs.singularityfinance.ai describes vaults on SFI L2, where these DynaVaults do not run.

The deployed contracts show that the caller of swapAndReport() supplies the trade. That function executes the trade and updates the vault’s accounting. Through 20 August, one management account sent 575 of 751 successful direct swap calls in dynBaseUSDCv3’s indexed history and 184 of 218 in dynBaseUSDCv4’s. These counts identify the account executing the trades. They do not establish whether a person or software chose each trade.

I asked the team what made the vaults automated.

SFI has automated on-chain execution (one ex. being SwapAndReport that moves assets and updates the vault accounting), though yes, they are not yet autonomous nor do we claim they are. Source

An offchain server can automate those calls. That does not establish that the vaults use the strategy contracts described in the 2023 posts. The team still needs to document how the vaults holding users’ money actually work.

The Four Questions

I have asked the team these questions in Telegram, most more than once.

  1. Was the fee tier set on 19 January the cause?
  2. Why was the fee tier set to 42, and by whom?
  3. When will the post-mortem be published?
  4. Will affected accounts be reimbursed from project funds or from the collected fees?

My onchain investigation has since shown how the January settings contributed to the drain, as explained in The Exploit. The team’s 23 September reply answered the first question and gave a reason for tier 42. It still has not said who chose the tier, when the report will be published or where reimbursement money will come from.

Why I Care

I have spent years in the SingularityNET ecosystem. I built tools to help people follow the ASI token migration, including a Dune dashboard I paid to run. I invested in the DynaVaults because I wanted automated onchain vault strategies to work.

When I could not find enough documentation, I asked the team to explain the products. I also built dynafriend to give depositors a better interface and made it public.

Then one of the vaults I used was drained, and I lost a substantial amount.

I kept asking how the products worked and what the team would do next. Some community members treated those questions as attacks and called them FUD. I still need the answers to understand why my money was lost and whether any of it will be repaid.

References

The research notebook contains the saved traces, dated contract reads and verified sources.

Last updated: