---
# System prepended metadata

title: Internal Audit - aurora-is-near/spectre-bridge-protocol

---

# Internal Audit - aurora-is-near/spectre-bridge-protocol

## Number of security issues per severity.


| TYPE        | HIGH | MEDIUM | LOW | INFORMATIONAL |
| ----------- | ---- | ------ | --- | ------------- |
| Open        | 0    | 1      | 2   | 2             |
| Acknowledged| 0    | 0      | 0   | 0             |
| Closed      | 0    | 0      | 0   | 0             |




---

## Introduction
During the period of **DEC 20 2022** to **DEC 22 2022**.
**Adity Rout** performed a security audit for spectre-bridge-protocol smart contracts. 

## Issues Found – Code Review 
<!-- ### 1. spectre-bridge-protocol/eth/contracts/EthErc20FastBridge.sol -->
### High Severity Issues
    No issues found
### Medium Severity Issues
#### M.1 Array upperbound 
**Contract :** spectre-bridge-protocol/eth/contracts/EthErc20FastBridge.sol
**Description :** Loops in solidity have an upperbound on number of iterations and higher number of iteration may result in failure of execution with error "out of gas".
**Recommendation :** Run a test for the same and get upperbound which can be safely used as a size check on input array to counter this issue.

### Low Severity Issues
#### L.1 State variables than can be constants
**Contract :** spectre-bridge-protocol/eth/contracts/TestToken.sol
**Description :** State variables are stored in the storage slots where reading and writing are gas intensive operations while constants become a part of the contract bytecode and are cheaper to use. For constant variables, the value has to be fixed at compile-time, while for immutable , it can still be assigned at construction time.
**Recommendation :** Since, TestToken smart contract is non upgradable and variable tokenDecimals has to be constant, whereas it is being assigned at construction time it can be declared as immutable.

#### L.2 Gas optimization
**Contract :** spectre-bridge-protocol/eth/contracts/EthErc20FastBridge.sol
**Description :** Loops in solidity are expensive to use. Adding read/write operations in loop can be extreamly expensive.
Read is way cheaper than write operation 
**Recommendation :** In setWhitelistedTokens function add a check in loop so that it first checks that corresponding token already has same state.
```
  for (uint256 i = 0; i < _tokens.length; i++) {
            if (whitelistedTokens[_tokens[i]] != _states[i]) {
                whitelistedTokens[_tokens[i]] = _states[i];
            }
        }
```

### Informational Issues
#### I.1 Access Control
**Contract :** spectre-bridge-protocol/eth/contracts/EthErc20FastBridge.sol
**Description :** To limit an admin address with specific rights, For differnet admin actions there should be different roles. So that they can be assigned to same or different addresses.
**Recommendation :** For functions like pause, unpause, addToWhiteList and removeFromWhiteList differenet roles can be created. For pause related roles PAUSER_ADMIN_ROLE and for HANDLE_WHITELIST_ADMIN_ROLE can be created.

#### I.2 Best Practices
**Description:** Some of the best practices are not followed throughout the repo, some simple recommendations can be implemented.

**Recommendation:** Method parameter names should be preceded with ‘_’ to differentiate it from state variable.

## Automated Tests
### Slither:
![](https://i.imgur.com/kZJBGrd.png)
![](https://i.imgur.com/4w1v0v2.png)
![](https://i.imgur.com/3fyInv7.png)
![](https://i.imgur.com/CZE1OqJ.png)
![](https://i.imgur.com/6VZwHGy.png)
![](https://i.imgur.com/UdVFhtA.png)
![](https://i.imgur.com/oZmO7L2.png)
![](https://i.imgur.com/OQcsozI.png)






## Results
No major issues were found. Some false positive errors were reported by the tool. All the other issues have been categorized above according to their level of severity.

## Closing Summary
Overall, smart contracts are well written and adhere to guidelines.  

Reviewed the issues opened in the initial audit, some of the issues are still open and It is recommended to kindly go through the above-mentioned details and fix the code accordingly.

## Disclaimer
This audit is not a security warranty, investment advice, or an endorsement of the Aurora platform. This audit does not provide a security or correctness guarantee of the audited smart contracts. The statements made in this document should not be interpreted as investment or legal advice, nor should its authors be held accountable for decisions made based on them. Securing smart contracts is a multistep process. One audit cannot be considered enough. We recommend that Aurora put in place a bug bounty program to encourage further analysis of the smart contract by other third parties.



