Beginner FriendlyFoundryBridge
100 EXP
View results
Submission Details
Severity: medium
Invalid

Static Analyzer Report - Still In Development

[M-01] Ownership Irrevocability Vulnerability

Severity

  • Impact: Medium

  • Likelihood: Low

Description

The smart contract under inspection inherits from the Ownable library, which provides basic authorization control functions, simplifying the implementation of user permissions. The contract in question allows the owner to adjust parameters such as feeOwnerPercentageBuy. However, the contract does not provide a mechanism to transfer ownership to another address or account, and it retains the default renounceOwnership function from Ownable.
Given this, once the owner renounces ownership using the renounceOwnership function, the contract becomes ownerless. As evidenced in the provided transaction logs, after the renounceOwnership function is called, attempts to call functions that require owner permissions fail with the error message: "Ownable: caller is not the owner."
This state renders the contract's adjustable parameters immutable and potentially makes the contract useless for any future administrative changes that might be necessary.

Number Of Instances Found

3

Code Location

Click to show findings
Path: ./src/L1Vault.sol
12:contract L1Vault is Ownable { // @audit-issue

GitHub: 12

Path: ./src/TokenFactory.sol
11:contract TokenFactory is Ownable { // @audit-issue

GitHub: 11

Path: ./src/L1BossBridge.sol
27:contract L1BossBridge is Ownable, Pausable, ReentrancyGuard { // @audit-issue

GitHub: 27

[M-02] Centralization risk for privileged functions

Severity

  • Impact: Medium

  • Likelihood: Low

Description

Contracts with privileged functions need owner/admin to be trusted not to perform malicious updates or drain funds. This may also cause a single point failure.

Number Of Instances Found

5

Code Location

Click to show findings
Path: ./src/L1Vault.sol
19: function approveTo(address target, uint256 amount) external onlyOwner { // @audit-issue

GitHub: 19

Path: ./src/TokenFactory.sol
23: function deployToken(string memory symbol, bytes memory contractBytecode) public onlyOwner returns (address addr) { // @audit-issue

GitHub: 23

Path: ./src/L1BossBridge.sol
49: function pause() external onlyOwner { // @audit-issue
53: function unpause() external onlyOwner { // @audit-issue
57: function setSigner(address account, bool enabled) external onlyOwner { // @audit-issue

GitHub: 49, 53, 57

[M-03] approve will always revert as the IERC20 interface mismatch

Severity

  • Impact: Medium

  • Likelihood: Low

Description

Some tokens, such as USDT, have a different implementation for the approve function: when the address is cast to a compliant IERC20 interface and the approve function is used, it will always revert due to the interface mismatch.

Number Of Instances Found

1

Code Location

Click to show findings
Path: ./src/L1Vault.sol
20: token.approve(target, amount); // @audit-issue

GitHub: 20

[M-04] Non-compliant IERC20 tokens may revert with transfer

Severity

  • Impact: Medium

  • Likelihood: Low

Description

Some IERC20 tokens (e.g. BNB, OMG, USDT) do not implement the standard properly, but they are still accepted by most code that accepts ERC20 tokens.

For example, USDT transfer functions on L1 do not return booleans: when casted to IERC20, their function signatures do not match, and therefore the calls made will revert.

Number Of Instances Found

1

Code Location

Click to show findings
Path: ./src/L1BossBridge.sol
74: token.safeTransferFrom(from, address(vault), amount); // @audit-issue

GitHub: 74

Updates

Lead Judging Commences

0xnevi Lead Judge
almost 2 years ago
0xnevi Lead Judge almost 2 years ago
Submission Judgement Published
Invalidated
Reason: Other

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.