Sonic Gateway Security Smart Contract Audit

Summary

In this audit, Quantstamp reviewed the smart contracts responsible for managing the bridging of ERC-20 Tokens to the Sonic Network from Ethereum, and back. This bridge includes an emergency withdrawal mechanism that enables users to withdraw their funds on Ethereum if either the bridge or the Sonic chain becomes non-functional for more than 14 days. If the bridge were to die, it could not be revived. The bridge follows a classic design, in which tokens to be bridged are locked on the one chain, and minted on another. When withdrawing the assets from a network, they are burned, and unlocked from the deposit contract on the other chain, being transferred back to the depositor. Bridging relies on two core communication channels. One channel is untrusted, and used to communicate proofs between chains, done by the users. The other channel is trusted, and managed by the validators of the Sonic Network itself. These validators periodically update the state root of the other chain, i.e. the state root of Sonic Network is updated on the `StateOracle` contract on Ethereum. Before receiving assets on the destination chain, users must provide a proof, that shows their deposit on Ethereum is present in the trusted state root of that chain. We assume the Sonic Network to operate as intended. Specifically, we trust that the validators responsible for communicating the state roots act according to network specifications, including slashing enforcements and minimum staking requirements. We also assume that contracts will be deployed with expected configurations, such as the `TokenDeposit` contract being deployed with the `UpdateManager` as the owner. We discovered a high severity vulnerability that has the potential to halt the bridge operations if both the `updateVerifier` address and `newValidators` are being update in a single call to `UpdateManager.update()`. One medium severity issues reported highlight potential issues that can occur in the case of the bridge becoming inoperative. The other medium severity issue highlights the front-running risk associated with the `update()` function. Beyond that, we highlight lower severity issues, and include Auditor Suggestions for further improvement of the codebase. We thank the Sonic team for their collaboration throughout the audit. The team provided thorough documentation which proved helpful. The test suite is thorough and has good coverage. **Fix Review Update** The Sonic Bridge team provided fixes to the issues presented in the original report or acknowledged them with sufficient reasoning. During the fix review, we identified a medium severity issue (SONIC-9) that could result in the loss of user funds to the bridge if the `exitAdministrator` were never assigned and the bridge were to go offline. This issue has since been addressed. There were some new features included during the fix review. Users should be aware that the Sonic Bridge team now has the power to unregister tokens that are supported by the bridge and they require trust to honor all funds moving through this bridge. There is now more robust management for the situation where the number of validators participating in the bridge may decrease to a point below what is needed to reach a quorum and therefore be unable to verify updates to the state oracles. Previously, in order for a state oracle update to be verified, validators had to always exceed a 2/3 quorum of staking weight. If there wasn't an update within 2 weeks, the bridge would be dead forever. Now, instead of holding the quorum constant, it is implemented as a piecewise function, where over the period of 200 days, the quorum needed changes depending on how long it has been since the last state update. Specifically, if the bridge hasn't been updated after five days, the quorum required will decrease from 66.67% to 55% at a constant rate over two days. If there still hasn't been an update after the 7th day, the quorum will remain constant at 55% until 182 days have passed. Then, there will be a constant rate decrease from 55% to 25% quorum on days 182-189, after which the 25% quorum will remain from day 189-200, after which the bridge will be completely dead. We emphasize here that this is only in place for emergency situations such as technical errors. There is no intent or plan to ever let the quorum reach 25% by the Sonic Bridge team, but they make the option possible after long periods of no state update. In the case of such emergency, we note that users may have to wait for funds to be received for extended periods of time, 200 days in the absolute worst scenario. Again, this is a failsafe and not part of the intended normal functioning of the bridge. We again thank the Sonic team for their commitment to security and collaboration throughout this audit.

Project