Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

Based on this protocol logic, the state variable `chainToken` should be the address of `WETH` contract. This contract interacts with the third-party `WETH` protocol as the underlying entity. The scope of the audit treats the third-party entity as a black box and assumes that it functions correctly. However, in the real world, third parties can be compromised, which can lead to the loss or theft of assets. In addition, third-party upgrades may have serious implications such as increased third-party fees, migration to a new LP pool, etc.

Third Party Dependencies

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

In the contract `IHub` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/b31b954cd9be489b8ec45a8e031eb5bf/diagrams/centralization-IHub-_owner.svg)

In the contract `IHub` the role `custodian` has authority over the functions shown in the diagram below.

Any compromise to the `custodian` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/b31b954cd9be489b8ec45a8e031eb5bf/diagrams/centralization-IHub-custodian.svg)

In the contract `IHub` the role `custodians` has authority over the functions shown in the diagram below.

Any compromise to the `custodians` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/b31b954cd9be489b8ec45a8e031eb5bf/diagrams/centralization-IHub-custodians.svg)

In the contract `IHub` the role `relayers` has authority over the functions shown in the diagram below.

Any compromise to the `relayers` account may allow the hacker to take advantage of this authority and [fixme, describe what hacker can do and the impact].

![](https://accelerator-tasks-prod.s3.amazonaws.com/b31b954cd9be489b8ec45a8e031eb5bf/diagrams/centralization-IHub-relayers.svg)

In the contract `IHub` the role `riskControl` has authority over the functions shown in the diagram below.

Any compromise to the `riskControl` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/b31b954cd9be489b8ec45a8e031eb5bf/diagrams/centralization-IHub-riskControl.svg)

Centralization Risk in IHub.sol

iSwap 7

IHub.sol

In the program `i_bridge_solana_program`, the role `governor` has authority over the following functions:

- `change_governor()` will assign a new account as `governor`. 
- `change_treasury()` will assign a new account as `treasury`.
- `change_custodian()` will assign a new account as `custodian`.
- `change_risk_control()` will assign a new account as `risk_control`.
- `change_relayer()` will assign a new account as `relayer`.
- `add_support_token()` will add supported token.
- `set_support_token_min_amount` will set min amount for one supported token.


Any compromise to the `governor` account may allow the hacker to take advantage of this and result in unexpected loss.

Centralization Related Risks

To transfer tokens to another chain, users need to deposit tokens to the vault token account and treasury token account. However, those tokens can be withdrawn by privileged roles.
- The `relayer` can withdraw an arbitrary amount of tokens from the vault token account via the function `refund_token` and `cross_chain_token_confirm`.
- The `custodian` can withdraw an arbitrary amount of tokens from the vault token account via function `withdrawal`.
- The `risk_control` can withdraw an arbitrary amount of tokens from the vault token account via function `withdrawal_punish`.
- The `treasury` role is the owner of the treasury token account, it can withdraw tokens from the treasury token account.

The concern is, if those privileged accounts are compromised, it could lead to the asset being stolen and thus introducing centralization risk,

Centralization Related Risks - Token Withdrawal

To transfer tokens to another blockchain, users need to deposit a certain amount of tokens to the vault account via the function `cross_chain_token`. However, this function lacks basic verifications for users' input, thus increasing the attack vector. 
```rust=86
    pub fn cross_chain_token(
        ctx: Context<CrossChainToken>,
        order_id: u64,
        amount: u64,
        cross_chain_fee: u64,
        gas_fee: u64,
        rewards: u64,
        dst_chain_id: u64,
        channel: String,
    ) -> ProgramResult {
```
The function `cross_chain_token` takes `order_id`, `cross_chain_fee`, `gas_fee` and `rewards` as inputs, and does not verify their validity.
- `order_id`\
This input value `order_id` would be emitted in the Event as a notification to the relayer. As there is no validation for the `order_id`, the `order_id` can be forged (e.g., input a previous `order_id` that deposits a great number of tokens). If the relayer's verification process fails, the attacker might claim others' orders.
- `cross_chain_fee`\
`cross_chain_fee` is the amount of fee that is required by the project. However, the user can input `cross_chain_fee` as 0 to bypass the charging of the fee.
- `gas_fee`\
`gas_fee` is the amount of gas fee that is required by the project. However, the user can input `gas_fee` as 0 to bypass the charging of the fee.
- `rewards`\
`rewards` will be emitted in the Event as a notification, which specified the amount of reward that can be claimed in the target chain. The attacker can input `rewards` as a big number to get a great number of rewards in the target chain.



Missing Input Validation

In Anchor framework, instruction’s arguments can be accessed with the `#[instruction(..)]` attribute,  with the same order as in the instruction, and arguments after the last needed argument can be omitted.

In instruction `cross_chain_token`, arguments are `order_id:u64`, `amount:u64`, `cross_chain_fee:u64`, `gas_fee:u64`, `rewards:u64`, `dst_chain_id:u64`, `channel:String` in order. And in `#[instruction(..)]` attribute, only the first u64 needed as `amount`, but it refers to `order_id:u64`.

In instruction `cross_chain_token_confirm`, arguments are `order_id:u64`, `amount:u64`, `rewards:u64` in order. And in `#[instruction(..)]` attribute, only the first u64 needed as `amount`, but it refers to `order_id:u64`.

In instruction `refund_token`, arguments are `order_id:u64`, `amount:u64`, `gas_fee:u64` in order. And in `#[instruction(..)]` attribute, only the first u64 needed as `amount`, but it refers to `order_id:u64`.

This finding may cause chaos during instruction execution, for example, when `order_id` is a large number and the amount for `token_valut` is small, will lead the instruction to fail.


Reference: [instruction-attribute](https://docs.rs/anchor-lang/latest/anchor_lang/derive.Accounts.html#instruction-attribute)

Incorrect Parameters Deserialize

In function `cross_chain_token`, the `cross_chain_fee` is limited by a upper-bound `amount * DENOMINATOR / CROSS_CHAIN_FEE_RATIO`, but there is no lower-bound for `cross_chain_fee`, which means the user can set fee to 0, this may cause the fee loss.

Incomplete `cross_chain_fee` check

The mathematic operation in L96 has the potential to lead to overflow issues during runtime as the expression uses raw arithmetic "*" and "/".
```rust=96
        if cross_chain_fee > (amount * DENOMINATOR / CROSS_CHAIN_FEE_RATIO) {
```

Potential Overflow

According to the Rust doc for `anchor-lang`, the constraint `mut` is used for checking the given account is mutable and makes anchor persist any state changes.

The following accounts' states are changing but lack the `mut` constraint:
- struct `Initialize`
  - `user` will be the payer for `meta_account`.

Reference:
- [https://docs.rs/anchor-lang/latest/anchor_lang/derive.Accounts.html](https://docs.rs/anchor-lang/latest/anchor_lang/derive.Accounts.html)

Lack of `mut` Constraint

The contract is serving as the underlying entity to interact with the **relayer** component. The scope of the audit treats the **relayer** as black boxes and assumes their functional correctness. Additionally, the core verification process that validates the message from the other chain is implemented in the **relayer**. The **relayer** is responsible for the verification and proper invocation of functions `cross_chain_token_confirm` and `refund_token`. 


```rust=96
        if cross_chain_fee > (amount * DENOMINATOR / CROSS_CHAIN_FEE_RATIO) {
            return Err(ErrorCode::ExceedTheCrossChainFeeLimit.into());
        }
```
According to the above calculation in the `if` branch, there are two typos in the const `DENOMINATOR` and `CROSS_CHAIN_FEE_RATIO`, the const `DENOMINATOR` and `CROSS_CHAIN_FEE_RATIO` should be renamed as `CROSS_CHAIN_FEE_RATIO` and `DENOMINATOR`.

Typo

The functions that affect the status of sensitive variables should be able to emit events.
- `initialize`
- `change_governor`
- `change_treasury`
- `change_custodian`
- `change_risk_control`
- `change_relayer`
- `add_support_token`
- `set_support_token_min_amount`

iSwap 7  

lib.rs

Cargo.toml

Financial Models 

Unlocked compiler version

Improper usage of `public` and `external` type

iSwap VI-1

ISwapArbitrumBridge.sol

ISwapBaseStorage.sol

ISwapEthBridge.sol

ISwapBaseBridge.sol

ISwapOecBridge.sol

ISwapHecoBridge.sol

ISwapBaseBridgeOptimization.sol

ISwapBscBridge.sol

ISwapPolygonBridge.sol

ISwapAvaxBridge.sol

ISwapFtmBridge.sol

Fees specified by the caller

Lack of Input Validation

Financial Models

Centralization Risk

iSwap V

Priviledged Ownership

Redundant code

Unsupported API

Lack of input validation

iSwap IV

BridgeMember.sol

HGSwapBaseBridge.sol

HGSwapBaseStorage.sol

BridgeFeeModelV2.sol

HGSwapBaseRelayer.sol

This report has been prepared for iSwap to discover issues and vulnerabilities in the source code of the iSwap project as well as any contract dependencies that were not part of an officially recognized library. A comprehensive examination has been performed, utilizing Manual Review and Static Analysis techniques.

iSwap

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

3

0

3

0

0