1/ Alameda has been a long-standing, loyal security audit client of ours. We also work closely with many projects on Solana, many of which are directly or indirectly affected by FTX’s insolvency.
Here’s our perspective.
2/ Even before FTX filed for bankruptcy, there were some red flags. A few days prior, their Solana USDC Account ran out of funds for withdrawals.
3/ Soon after the confirmed insolvency, suspicious transactions emerged on the FTX side, draining roughly $1B in user funds. A variety of token types were drained over the course of a few hours.
6/ Looking forward, we strongly recommend using multisigs as a safe and secure way to custody assets. Protocols should also switch deployment keys over to a multisig if possible.
7/ Regardless of the recent happenings, we remain committed to ensuring the security of the Web3 ecosystem. The team at Alameda and FTX are some of the most intelligent engineers we’ve worked with, and we wish them the best moving forward.
To clarify, our engagement with Alameda consisted of their onchain programs alone. We were unfortunately, like many others, not involved or aware of the existence of any offchain backdoors.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
We’re continuing to investigate the recent Mango Markets hack.
Let’s clear up some misinformation. 🧵
At a high level,
1. This was not a flashloan attack 2. The attacker addresses were funded 5.5M via FTX 3. It appears the attacker manipulated prices across all exchanges, not just Solana oracles
The attacker created a ~480M MNGO-PERP position and countertraded themself on another account.
They then manipulated the price of MNGO up across a number of exchanges, borrowing against their unrealized MNGO gains to drain the protocol.
@Crema_Finance was recently hacked for over $6M. Unlike previous attacks, this hacker used Solend flashloans to drain the pool. We’re working closely with the Crema team to help resolve this issue.
In the meantime, we’ll be sharing what we know about the exploit 🧵
In order to utilize flashloans, the attacker had to deploy their own onchain program. Unfortunately, this program was quickly closed after the exploit.
We were engaged by the @cega_fi team to perform a security audit of their smart contract code and we’re proud to announce its successful conclusion! Code quality was high, and all vulnerabilities were patched and confirmed.
Deep dive below into interesting technical findings: 🧵
1/ Incorrect withdrawn funds due to missing account reload (OS-CEG-ADV-01):
All withdrawal requests are processed via a withdraw queue, and the amount of USDC tokens to be returned is calculated based on the value of USDC tokens in vault over redeemable mint supply.
2/ When each withdraw request is processed, redeemable tokens get burned in exchange for USDC tokens. This is done through cross program invocation of the token program's burn instruction.
This February, we discovered a critical rounding exploit in the Solana Program Library token-swap implementation. With over $74 M at risk, this was one of the most impactful bugs we’ve reported.
Let’s take a deep dive: 1/
2/ When implementing an arbitrage bot, we came across some unexpected behavior. We were somehow getting tokens out of nothing. In other words, we were able to put in 0 tokens and get out 1 token.
3/ Some further analysis revealed that this only affected stable-swap pairs. Could this be a bug in SPL token-swap? Having read Neodyme’s blog post on a similar issue with spl-lending, we knew rounding issues have been exploited against BTC tokens before.
1/ In our recent audit report on @JetProtocol’s governance program, we listed 13 findings and 4 vulnerabilities. One of these vulnerabilities stand out from the others: OS-JET-ADV-01
Let’s take a deep dive into this rounding error, the implications, as well as its exploitability
2/ In Jet’s original conversion code between tokens and shares, all rounding was done via floor division. This meant that the correctness of the code depended on floor division to not be in favor of the user.
3/ Unfortunately, due to how conversions were done, this was not the case. Users who were supposed to pay 2.5 tokens only had to pay 2. In other words, they could pay up to one less token than they should. Could a pool of staked tokens be extracted through this rounding error?