Orange Bridge audit
A private security review of Orange (cross-chain bridge), conducted with Three Sigma and completed on 15th July 2024 over 3 days. 0xSimao disclosed 17 findings: 3 high severity, 1 medium, 6 low and 7 informational.
What Orange is
Orange Bridge moves tokens between Bitcoin's BRC-20 world and Ethereum's ERC-20 world: a smart contract burns and mints ERC-20 representations while event listeners on each chain observe transfers and a signer set authorises the crossings.
Scope
The review concentrated on fee accounting, receiver validation for BRC-20 addresses, the domain separator's fork-safety and the ownership and signer-management procedures.
High severity findings
- Balance check in Vault::withdraw() does not take fees into account
- address.transfer is used in the codebase, which could lead to stuck funds
- Equality check should be performed for fees, not >= as it can lead to users sending more fees than supposed
Medium severity findings
Low severity findings
- Ownership in BRC20Factory could be transferred using a 2 step procedure, similarly to Vault
- Token addresses are not validated in BRC20Factory and Vault, so users can use incorrect tokens
- BRC20Factory::burn() could validate the receiver length
- BRC20Factory::addSigner() and Vault::addSigner() must not allow adding the zero address as a signer
- Fee event is missing in the constructors of BRC20Factory and Vault
- BRC20Factory constructor is missing a duplicate check
Informational findings
- Checks effects interactions pattern is now always followed
- BRC20Factory and Vault do different checks when removing signers
- Storage variables can be cached to save gas
- BRC20 parameters should be passed as arguments to the constructor of BRC20 to save gas
- Signer duplicate check can be performed by requiring signers being sent ordered
- authorized mapping is not required if the indexes mapping stores the indexes + 1
- Reentrancy guard can be implemented with a uint256 to save gas
The report