Near Connector (Rainbow Bridge)
Co-audit with AuditOne of the Aurora Near Connector, a generic ERC-20 / NEP-141 connector for the Rainbow Bridge that enables trustless transfer of ETH and ERC-20 tokens between Ethereum and the NEAR protocol. The two-week manual review covered 4 Solidity contracts and 14 Rust modules spanning the forwarder, factory, controller, and proof-consumer layers. 13 issues were identified (1 Medium, 4 Low, 8 Informational); 4 were fixed and 9 acknowledged.
Total findings
13
4 fixed · 9 acknowledged
Critical
00
High
00
Medium
01
Low + Info
12
02
Scope
20 filesRepository
Initial commit
0b989fa2d252
Final commit
b600af24e2b5
Platform
Near · Ethereum · Solidity + Rust
Methodology
File
forwarder/src/error.rs
forwarder/src/lib.rs
forwarder/src/params.rs
forwarder/src/types/address.rs
forwarder/src/types/promise.rs
forwarder/src/types/mod.rs
forwarder/src/types/account_id.rs
forwarder/src/runtime/io.rs
forwarder/src/runtime/handler.rs
forwarder/src/runtime/env.rs
forwarder/src/runtime/mod.rs
forwarder/src/runtime/sys.rs
fees/src/lib.rs
tests/src/lib.rs
factory/src/lib.rs
controller/src/lib.rs
contracts/BridgeTokenFactory.sol
contracts/BridgeToken.sol
contracts/SelectivePausableUpgradable.sol
contracts/ProofConsumer.sol
03
Findings
click any row for the full write-upSeverity
ID
Finding
Status
04
Key Findings
- Lack of critical check on
nearTokenIdinnewBridgeToken. ThenewBridgeTokenfunction does not validate that thenearTokenIdargument equalsresult.token, allowing an attacker to submit a metadata proof with an incorrectnearTokenIdand causedepositandwithdrawto always revert for that token (Denial of Service against the bridge's token functionalities). - Inconsistent amount type in
withdraw. Thewithdrawfunction declaresamountasuint256but the value is handled asuint128on the NEAR side, creating a risk of integer overflow if the supplied amount exceedstype(uint128).max. - Missing storage gaps on
SelectivePausableUpgradable. The upgradeable contract does not reserve storage gaps for future state variables, which can lead to storage collisions with derived contracts when new variables are added in future upgrades. - Single-step ownership transfer in
BridgeToken.BridgeTokenextendsOwnableUpgradeableand uses single-step ownership transfer; an incorrect address passed totransferOwnershipwould irretrievably lose control over allonlyOwnerprotocol functions. - Silent failure in
add_account_to_whitelist. The Rustadd_account_to_whitelistmethod on thetoken-lockerwhitelist module does not check the return value ofinsert, so callers are not informed whether an account was newly added or was already present. - Uninitialized state in
ProofConsumer. TheProofConsumercontract lacks a constructor or initializer, leavingprover,nearTokenLockerandminBlockAcceptanceHeightas their default zero values; this causes every_parseAndConsumeProofcall to revert and renders the contract unusable in that state.
05
Team & approval
Auditor
Carlos (Vendrell46)
@TheBlockChainer
Auditor
Defec
Auditor
Ubermensch3dot0
06
Disclaimer
This audit is not an endorsement and does not constitute investment advice. Zealynx reviewed the codebase at the commits listed in section 02 over the engagement window. Findings are limited to issues identified within that scope and do not preclude the existence of other vulnerabilities. Subsequent code changes are not covered by this report unless the engagement is explicitly extended.
