Allbridge mandated Quarkslab to perform an audit of their updated version of Estrela, an automated market maker for Stellar built on Soroban.
Introduction
Last year, Allbridge entrusted us to audit two of their products: Allbridge Core and Allbridge Estrela. While the first lets users bridge stablecoins (i.e., dollar-pegged tokens) from one blockchain to another, the second allows them to swap one stablecoin for another, operating as an Automated Market Maker (AMM).
After our initial audit, Allbridge decided to extend the functionality of their AMM by creating a 3-tokens pool. In doing so, they refactored their code, and wanted to make sure they did not introduce new vulnerabilities, both in the old 2-tokens and in the 3-tokens pool. Their implementation is still based on the StableSwap invariant, which is designed especially for stablecoins AMM by providing lower slippage when the assets have a similar value.
Allbridge is a significant target, as it has now grown to manage over 48 million USD locked across the chains they support. We salute their ongoing commitment to security and their trust in Quarkslab's work. Indeed, we have partnered with the Stellar Development Foundation (SDF) to audit protocols developed on Stellar after our audit of their smart contract platform, Soroban.
Our report is available here.
Scope
We kept the same scope as the last audit, focused on the smart contract of the pools. It is implemented generically in Rust using procedural macros, with a specialized implementation for each pool, for the computation of the invariant.
Two specialized implementations were provided: (i) a 2-tokens implementation, using the same algebraic computation we corrected in our previous audit, and (ii) a 3-tokens implementation, using Newton's method up to the smart contract's precision (3 decimals).
We also audited the supporting factory smart contract, able to deploy new pools for new sets of 2 or 3 stablecoins.
The source for these smart contracts is available on GitHub: allbridge-io/dex-soroban-contracts.
Findings
The table below summarizes the 4 findings of the audit, with a single one ranked low severity.
| ID | Title | Severity | Perimeter |
|---|---|---|---|
| LOW-2 | First deposit can be backrun. | Low | Pool |
| INFO-1 | Centralization risk for the administrator. | Info | All |
| INFO-3 | Token called twice on deposit. | Info | Pool |
| INFO-4 | Generic calc_withdraw_amount() assumes a specific missing index. |
Info | Pool |
Allbridge acknowledged all issues, and said they would fix a code issue (INFO-4). They stated that the backrunning risk was not worth fixing, as it is limited to the first deposit, which is typically small, and because the tokens would need to be very imbalanced to justify an attack. The INFO-3 issue will be kept for code readability. Finally, they indicated that the centralization risk (INFO-1) is already known and accounted for.
Conclusion
Allbridge executed the extension from 2-tokens to 3-tokens well, and did not introduce new severe vulnerabilities to the best of our knowledge.
They maintained the same level of code quality and maturity, and promptly reacted to our findings, responding in a satisfactory manner.