The Chromia Token Bridge allows users to transfer tokens between EVM-compatible chains and Chromia using a Lock & Mint model for L1 to L2 transfers and a Burn & Release model for L2 to L1. Chromia monitors token deposits for L1 to L2 transfers, while L2 to L1 transfers require submitting a Merkle Proof on L1 to confirm tokens were burned on L2. Token withdrawals include a holding period, allowing the contract owner to flag and deny suspicious transactions before execution. A key feature is the _mass exit_, which the bridge owner can trigger if Chromia Validators are compromised. During a mass exit, normal bridging is halted, and users can only withdraw their token balances based on a Chromia node snapshot. Pending withdrawals are allowed if they predate the _mass exit block_—the last valid block before the compromise, as determined by the owner. While the core functionality of the EVM bridge contracts was robust, the mass exit feature suffered from many issues. In the ideal scenario, the integrity of the validators is maintained and a mass exit is never triggered. However, should a mass exit occur, all parties have a means of draining the contract. The compromised validators will still be able to forge blocks (CHR-4). Given that the withdrawal snapshots are not validated against the mass exit block, any user can forge their snapshots as well (CHR-1). If the contract is ever paused as a precautionary measure, the token bridge owner can withdraw all tokens for themselves (CHR-2). The ability for the token bridge owner to trigger and revert a mass exit at will allows them to extract the contract's liquidity (CHR-3). Regarding the Rell files, the current mapping of snapshots may send funds to the wrong chain in a mass exit for contracts with the same address (CHR-6). The signature format for linking EVM accounts to FT4 accounts allows for an attacker to steal a deposit if they get ahold of the signature (CHR-7). The attack surface can also be further reduced by more strictly determining the origins of deposits (CHR-14). The Chromia team was in communication and helped answer all of our questions throughout the audit. The documentation was helpful, though the codebase could benefit from more in-line comments and NatSpec. The test suite was missing tests on the new validator contracts as well as the snapshot withdrawal logic. We were unable to assess the code coverage of the rell test suite. We strongly recommend that tests be written for all features before deployment. **Fix-Review Update:** The Chromia team has addressed or acknowledged all of the listed vulnerabilities.
Low | Medium | High | Critical | Total | |
---|---|---|---|---|---|
Not fixed | 4 | 1 | - | - | 5 |
Fixed | 6 | 4 | 1 | - | 11 |
Total | 10 | 5 | 1 | 0 | 16 |
# | File Name |
---|---|
1 | postchain-eif-rell/rell/src/** |
2 | postchain-eif-contracts/** |