Axelar Network - banpaleo5's results

Decentralized interoperability network.

General Information

Platform: Code4rena

Start Date: 12/07/2023

Pot Size: $80,000 USDC

Total HM: 11

Participants: 47

Period: 9 days

Judge: berndartmueller

Total Solo HM: 1

Id: 260

League: ETH

Axelar Network

Findings Distribution

Researcher Performance

Rank: 35/47

Findings: 1

Award: $43.33

QA:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

Labels

bug
grade-b
QA (Quality Assurance)
Q-07

Awards

43.3267 USDC - $43.33

External Links

Table of Contents

NumberIssues DetailsCount
[L-1]Incorporating Value Comparison in Set Functions8
[L-2]Possible Front-Running Vulnerability in Initializing Functions2
[N-1]Emitting Events for Significant Parameter Changes8
[N-2]Employing Cast to bytes or bytes32 for Semantic Clarity3
[N-3]Update OpenZeppelin Contract Dependency to Latest Version1
[N-4]Encourage Uniform Naming Convention for Immutables1
[N-5]Events Should Include Emitted Parameters1
[N-6]Excessive Line Length3
[N-7]Removing Empty Blocks or Emitting Relevant Information6

[L-1]</a><a name="L-1"> Incorporating Value Comparison in Set Functions

To enhance the functionality of set functions, it is recommended to incorporate a comparison mechanism to verify that the current value and the new value are distinct.

<details> <summary><i>There are 8 instances of this issue:</i></summary>
File: Operatable.sol
function setOperator(address operator_) external onlyOperator {
        _setOperator(operator_);
    }
}
File: InterchainTokenService.sol
function setPaused(bool paused) external onlyOwner {
        _setPaused(paused);
    }
File: Distributable.sol
function setDistributor(address distr) external onlyDistributor {
        _setDistributor(distr);
    }
}
File: InterchainProposalExecutor.sol
function setWhitelistedProposalSender(
        string calldata sourceChain,
        address sourceSender,
        bool whitelisted
    ) external override onlyOwner {
        whitelistedSenders[sourceChain][sourceSender] = whitelisted;
        emit WhitelistedProposalSenderSet(sourceChain, sourceSender, whitelisted);
    }
File: Pausable.sol
function setPaused(bool paused) external {
        _setPaused(paused);
    }
File: InterchainProposalExecutor.sol
function setWhitelistedProposalCaller(
        string calldata sourceChain,
        address sourceCaller,
        bool whitelisted
    ) external override onlyOwner {
        whitelistedCallers[sourceChain][sourceCaller] = whitelisted;
        emit WhitelistedProposalCallerSet(sourceChain, sourceCaller, whitelisted);
    }
File: Upgradable.sol
function setup(bytes calldata data) external override onlyProxy {
        _setup(data);
    }
File: InterchainTokenService.sol
function setFlowLimit(bytes32[] calldata tokenIds, uint256[] calldata flowLimits) external onlyOperator {
        uint256 length = tokenIds.length;
        if (length != flowLimits.length) revert LengthMismatch();
        for (uint256 i; i < length; ++i) {
            ITokenManager tokenManager = ITokenManager(getValidTokenManagerAddress(tokenIds[i]));
            tokenManager.setFlowLimit(flowLimits[i]);
        }
    }
</details>

[L-2]</a><a name="L-2"> Possible Front-Running Vulnerability in Initializing Functions

<details> <summary><i>There are 2 instances of this issue:</i></summary>
File: ConstAddressDeployer.sol
function deployAndInit(
File: InitProxy.sol
function init(
</details>

[N-1]</a><a name="N-1"> Emitting Events for Significant Parameter Changes

It is important to emit events when modifying state variables to enable effective monitoring using off-chain monitoring tools. Emitting events facilitates the tracking of activities related to critical parameter changes.

<details> <summary><i>There are 8 instances of this issue:</i></summary>
File: AxelarGateway.sol
function setTokenMintLimits(string[] calldata symbols, uint256[] calldata limits) external override onlyMintLimiter {
File: StandardizedToken.sol
function setup(bytes calldata params) external override onlyProxy {
File: TokenManager.sol
function setup(bytes calldata params) external override onlyProxy {
File: FixedProxy.sol
function setup(bytes calldata setupParams) external {}
File: InterchainTokenService.sol
function setFlowLimit(bytes32[] calldata tokenIds, uint256[] calldata flowLimits) external onlyOperator {
File: Distributable.sol
function setDistributor(address distr) external onlyDistributor {
File: Upgradable.sol
function setup(bytes calldata data) external override onlyProxy {
File: InterchainProposalExecutor.sol
function setWhitelistedProposalCaller(
</details>

[N-2]</a><a name="N-2"> Employing Cast to bytes or bytes32 for Semantic Clarity

To provide clearer semantic meaning and reduce reviewer confusion, it is recommended to use a cast to bytes or bytes32 on a single argument rather than using abi.encodePacked(). This approach makes the intended operation more explicit and easier to comprehend.

<details> <summary><i>There are 3 instances of this issue:</i></summary>
File: TokenManagerDeployer.sol
bytes memory bytecode = abi.encodePacked(type(TokenManagerProxy).creationCode, args);
File: AxelarGateway.sol
bytes32 salt = keccak256(abi.encodePacked(symbol));
File: AxelarGateway.sol
bytes32 commandHash = keccak256(abi.encodePacked(commands[i]));
</details>

[N-3]</a><a name="N-3"> Update OpenZeppelin Contract Dependency to Latest Version

<details> <summary><i>There are 1 instances of this issue:</i></summary>
File: package.json
    "@openzeppelin/contracts": "^4.9.2"
</details>

[N-4]</a><a name="N-4"> Encourage Uniform Naming Convention for Immutables

In the current code, certain immutables are named with capital letters and underscores, while others are not. For enhanced code quality, it's recommended to adopt a consistent naming convention for all immutables.

<details> <summary><i>There are 1 instances of this issue:</i></summary>
File: InterchainTokenService.sol
address internal immutable implementationLockUnlock;
File: InterchainTokenService.sol
address internal immutable implementationMintBurn;
File: InterchainTokenService.sol
address internal immutable implementationLiquidityPool;
File: InterchainTokenService.sol
IAxelarGasService public immutable gasService;
File: InterchainTokenService.sol
IRemoteAddressValidator public immutable remoteAddressValidator;
File: InterchainTokenService.sol
address public immutable tokenManagerDeployer;
File: InterchainTokenService.sol
address public immutable standardizedTokenDeployer;
File: InterchainTokenService.sol
Create3Deployer internal immutable deployer;
File: InterchainTokenService.sol
bytes32 internal immutable chainNameHash;
File: InterchainTokenService.sol
bytes32 internal immutable chainName;
</details>

[N-5]</a><a name="N-5"> Events Should Include Emitted Parameters

Certain events lack emitted parameters. It is advisable to incorporate parameters reflecting changes in state or values when triggering events.

<details> <summary><i>There are 1 instances of this issue:</i></summary>
File: Pausable.sol
emit TestEvent()
</details>

[N-6]</a><a name="N-6"> Excessive Line Length

The lines in the code exceed the recommended maximum length, affecting readability and maintainability.

<details> <summary><i>There are 3 instances of this issue:</i></summary>
File: AxelarGateway.sol
/// @dev Storage slot with the address of the current implementation. `keccak256('eip1967.proxy.implementation') - 1`.
File: AxelarGateway.sol
// AUDIT: If `newImplementation.setup` performs `selfdestruct`, it will result in the loss of _this_ implementation (thereby losing the gateway)
File: AxelarGateway.sol
// Mark that this symbol is an external token, which is needed to differentiate between operations on mint and burn.
File: InterchainTokenService.sol
// There could be a way to rewrite the following using assembly switch statements, which would be more gas efficient,
File: InterchainTokenService.sol
// but accessing immutable variables and/or enum values seems to be tricky, and would reduce code readability.
File: InterchainProposalExecutor.sol
// Whitelisted proposal callers. The proposal caller is the contract that calls the `InterchainProposalSender` at the source chain.
File: InterchainProposalExecutor.sol
// Whitelisted proposal senders. The proposal sender is the `InterchainProposalSender` contract address at the source chain.
File: InterchainProposalExecutor.sol
// You can add your own logic here to handle the failure of the target contract execution. The code below is just an example.
</details>

[N-7]</a><a name="N-7"> Removing Empty Blocks or Emitting Relevant Information

It is recommended to remove empty blocks in the codebase or consider emitting relevant information within them. Empty blocks serve no functional purpose and can lead to confusion or unnecessary clutter in the code. If the blocks were intended for future implementation, it is suggested to emit relevant information or comments to provide clarity on their purpose or intended functionality. This promotes cleaner code and improves the overall maintainability and readability of the software.

<details> <summary><i>There are 6 instances of this issue:</i></summary>
File: InterchainTokenServiceProxy.sol
) FinalProxy(implementationAddress, owner, abi.encodePacked(operator)) {}
File: TokenManagerMintBurn.sol
constructor(address interchainTokenService_) TokenManagerAddressStorage(interchainTokenService_) {}
File: InterchainGovernance.sol
receive() external payable {}
File: TokenManagerLiquidityPool.sol
constructor(address interchainTokenService_) TokenManagerAddressStorage(interchainTokenService_) {}
File: FixedProxy.sol
function setup(bytes calldata setupParams) external {}
File: FinalProxy.sol
) Proxy(implementationAddress, owner, setupParams) {}
</details>

#0 - c4-judge

2023-09-08T11:29:18Z

berndartmueller marked the issue as grade-b

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter