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.