Code Security Assessment

Nimbus
Jan 28th, 2022
 Nimbus Code Security Assessment

Table of Contents
Summary

Overview
Project Summary
Audit Summary
Vulnerability Summary
Audit Scope

Findings
NCK-01 : Missing emit events
NCK-02 : Use `revert` Instead of `return`
NCK-03 : Contracts that lock BNB
NPP-01 : Centralization Risk
NPP-02 : Whitelist Not Used
NPP-03 : Risk For Blocking The Function
NPP-04 : Incompatibility With Deflationary Tokens
NPP-05 : Missing Input Validation
NPP-06 : The comment `TODO`
TTN-01 : Centralization Risk
TTN-02 : Unknown Implementations
TTN-03 : Lack of update `weightedStakeDate` and `_userTokens`
TTN-04 : Potential Revert
TTN-05 : Lack of check the balance of the reward token
TTN-06 : Economy Model of Reward
TTN-07 : The comment `TODO`
TTN-08 : The activity period
TTN-09 : Redundant calculation
TTN-10 : Potential Reentrancy Attack
TTN-11 : Lack of Return Value Handling

Appendix

Disclaimer

About
 Nimbus Code Security Assessment

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

The auditing process pays special attention to the following considerations:

Testing the smart contracts against both common and uncommon attack vectors.
Assessing the codebase to ensure compliance with current best practices and industry standards.
Ensuring contract logic meets the specifications and intentions of the client.
Cross referencing contract structure and implementation against similar smart contracts produced
by industry leaders.
Thorough line-by-line manual review of the entire codebase by industry experts.

The security assessment resulted in findings that ranged from critical to informational. We recommend
addressing these findings to ensure a high level of security standards and industry practices.
We suggest
recommendations that could better serve the project from the security perspective:

Enhance general coding practices for better structures of source codes;

Add enough unit tests to cover the possible use cases;
Provide more comments per each function for readability, especially contracts that are verified in
public;
Provide more transparency on privileged activities once the protocol is live.
 Nimbus Code Secu

Overview
Project Summary

Project
Nimbus
Name

Platform BSC

Language Solidity

https://github.com/nimbusplatformorg/nim-
smartcontract/blob/1b15ac00e0c3b5c260ac44d98ad8420b894a8a1a/contracts/contracts_BSC/dApps/NFTTokens/TikT
https://github.com/nimbusplatformorg/nim-
smartcontract/blob/84475278eb4c5a25d2a943bc7bdbb9e07edb53bc/contracts/contracts_BSC/dApps/P2P/NimbusP2
https://github.com/nimbusplatformorg/nim-
Codebase
smartcontract/blob/0b330af5925c5609a6ac60500aa9f24dfefb6a84/contracts/contracts_BSC/dApps/P2P/NimbusP2P_V
(final report)
https://github.com/nimbusplatformorg/nim-
smartcontract/blob/9464164f00b7b9a103af3644398535343800cebe/contracts/contracts_BSC/dApps/NFTTokens/Smar
(final report)
https://github.com/nimbusplatformorg/nim-
smartcontract/pull/77/commits/341ba8e92a94d4cce212fb364e22440030842c5e (final report)

Commit

Audit Summary

Delivery Date Jan 28, 2022

Audit Methodology Static Analysis, Manual Review

 Nimbus Code Secu

Vulnerability Summary

Vulnerability Level Total Pending Declined Acknowledged Partially Resolved Mitigated Res

Critical 1 0 0 0 0 0

Major 3 0 0 2 0 0

Medium 4 0 0 1 1 0

Minor 4 0 0 1 0 0

Informational 8 0 0 3 0 0

Discussion 0 0 0 0 0 0
 Nimbus Code Security Assessment

Audit Scope

ID File SHA256 Checksum

NPP NimbusP2P_V2.sol bb641d7437e169be24f0b3202eb1d88b0ac8551510978584ac2b59243bb695c3

TTN TikToken.sol 6b075c2553fc67538264b96d13294e46576c4e025410941c088b959dfce609f0

 Nimbus Code Security Assessment

Findings

Critical 1 (5.00%)
Major 3 (15.00%)

20 Medium

Minor
4 (20.00%)

4 (20.00%)
Total Issues
Informational 8 (40.00%)
Discussion 0 (0.00%)

ID Title Category Severity Status

NCK-01 Missing emit events Coding Style Informational Acknowledged

NCK-02 Use revert Instead of return Logical Issue Informational Resolved

NCK-03 Contracts that lock BNB Con Medium Resolved

Centralization /
NPP-01 Centralization Risk Major Acknowledged
Privilege

NPP-02 Whitelist Not Used Logical Issue Minor Resolved

NPP-03 Risk For Blocking The Function Logical Issue Critical Resolved

NPP-04 Incompatibility With Deflationary Tokens Volatile Code Medium Acknowledged

NPP-05 Missing Input Validation Volatile Code Minor Resolved

NPP-06 The comment TODO Coding Style Informational Resolved

Centralization /
TTN-01 Centralization Risk Major Acknowledged
Privilege

TTN-02 Unknown Implementations Volatile Code Minor Acknowledged

Lack of update weightedStakeDate and

TTN-03 Logical Issue Medium Resolved
_userTokens

TTN-04 Potential Revert Logical Issue Major Resolved

 Nimbus Code Security Assessment

ID Title Category Severity Status

Lack of check the balance of the reward

TTN-05 Logical Issue Medium Partially Resolved
token

TTN-06 Economy Model of Reward Logical Issue Informational Acknowledged

TTN-07 The comment TODO Coding Style Informational Resolved

TTN-08 The activity period Logical Issue Informational Acknowledged

TTN-09 Redundant calculation Gas Optimization Informational Resolved

TTN-10 Potential Reentrancy Attack Logical Issue Minor Resolved

TTN-11 Lack of Return Value Handling Volatile Code Informational Resolved

 Nimbus Code Security Assessment

NCK-01 | Missing Emit Events

Category Severity Location Status

NimbusP2P_V2.sol: 72~75, 170~172

Coding Style Informational Acknowledged
TikToken.sol: 102~105, 415~417, 432~473

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

Recommendation
It is recommended emitting events for the sensitive functions that are controlled by centralization roles.

Alleviation
No Alleviation.
 Nimbus Code Security Assessment

NCK-02 | Use revert Instead Of return

Category Severity Location Status

NimbusP2P_V2.sol: 153~155
Logical Issue Informational Resolved
TikToken.sol: 398~400

Description
It is better to use revert instead of return when the left gas is less than 2300.

Recommendation
Consider using revert instead of return .

Alleviation
The development team partially resolved this issue in commit
7c9d7f0d1cf5f04ac3bebc9c6aa57768417c6b59 and 341ba8e92a94d4cce212fb364e22440030842c5e.
 Nimbus Code Security Assessment

NCK-03 | Contracts That Lock BNB

Category Severity Location Status

TikToken.sol: 475~477, 397

Con Medium Resolved
NimbusP2P_V2.sol: 184~186, 152

Description
The following contracts do not have a function to withdraw the BNB , every BNB sent to it will be lost.

NimbusP2P_V2

NimbusP2P_V2Proxy

TikToken

TikTokenProxy

Recommendation
Consider removing the payable attribute or add a withdraw function.

Alleviation
The development team resolved this issue in commits 7c9d7f0d1cf5f04ac3bebc9c6aa57768417c6b59 and
ea660b12ef93216a5fe3d8aa89c8b10624fe50b6.
 Nimbus Code Security Assessment

NPP-01 | Centralization Risk

Category Severity Location Status

Centralization / Privilege Major NimbusP2P_V2.sol: 659~662, 664~668, 170~172, 72~75 Acknowledged

Description
In the contract, Ownable , the role, _owner , has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to _owner may allow the hacker to take
advantage of this.

Authenticated Role Function State Variables

transferOwner
_owner transferOwnership
newOwner

In the contract, NimbusP2P_V2 , the role, _owner , has the authority over the functions shown in the diagram
below.

Any compromise to the privileged account which has access to _owner may allow the hacker to take
advantage of this.
 Nimbus Code Security Assessment

State Variables
Function

isAnyNFTAllowed
Authenticated Role toggleAnyNFTAllowed

State Variables
_owner
Function
nft
Address
updateAllowedNFT
allowedNFT
isAllowed

Function Calls

isContract

In the contract, NimbusP2P_V2Proxy , the role, _owner , has the authority over the functions shown in the
diagram below.

Any compromise to the privileged account which has access to _owner may allow the hacker to take
advantage of this.

State Variables

_newTarget

Authenticated Role Function

Function Calls
_owner setTarget
_setTarget

In commit ea660b12ef93216a5fe3d8aa89c8b10624fe50b6, the development team added the below

functions that can be called by the role _owner .

rescue(address to, address tokenAddress, uint256 amount)

 Nimbus Code Security Assessment

rescue(address payable to, uint256 amount)

toggleAnyEIP20Allowed

initialize

Recommendation
We advise the client to carefully manage the privileged account's private key to avoid any potential risks of
being hacked.

In general, we strongly recommend centralized privileges or roles in the protocol to be improved via a
decentralized mechanism or smart-contract-based accounts with enhanced security practices, e.g.,
Multisignature wallets.

Indicatively, here is some feasible suggestions that would also mitigate the potential risk at the different
level in term of short-term and long-term:

Time-lock with reasonable latency, e.g., 48 hours, for awareness on privileged operations;

Assignment of privileged roles to multi-signature wallets to prevent a single point of failure due to the
private key;

Introduction of a DAO/governance/voting module to increase transparency and user involvement.

Alleviation
No Alleviation.
 Nimbus Code Security Assessment

NPP-02 | Whitelist Not Used

Category Severity Location Status

Logical Issue Minor NimbusP2P_V2.sol: 181 Resolved

Description
Any ERC20 contract can be used when the user creates a trade. If the contract is not a standard ERC20, it
may cause unpredictable side effects.

Recommendation
Consider using whitelist for the ERC20 contract.

Alleviation
The development team resolved this issue in commit ea660b12ef93216a5fe3d8aa89c8b10624fe50b6.
 Nimbus Code Security Assessment

NPP-03 | Risk For Blocking The Function

Category Severity Location Status

Logical Issue Critical NimbusP2P_V2.sol: 573~574, 212, 228, 221 Resolved

Description
When the function createTradeEIP20ToNFT and the function createTradeBNBtoNFT are called, the value of the
param askedAmount is zero and the require statement in the function _createTradeSingle will always be
failed.

require(askedAmount > 0, "NimbusP2P_V2: Zero asked amount");

When the function createTradeNFTtoEIP20 is called, the value of the param proposedAmount is zero and the
require statement in the function _createTradeSingle will always be failed.

require(proposedAmount > 0, "NimbusP2P_V2: Zero proposed amount");

Recommendation
Consider removing the require statements.

Alleviation
The development team resolved this issue in commit 8bb2437da4c328a085c4de1b1efea8ecc6d73bb8.
 Nimbus Code Security Assessment

NPP-04 | Incompatibility With Deflationary Tokens

Category Severity Location Status

Volatile Code Medium NimbusP2P_V2.sol: 195~200 Acknowledged

Description
When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received
amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the
transaction may fail due to the validation checks.

Recommendation
We advise the client to regulate the set of tokens supported and add necessary mitigation mechanisms to
keep track of accurate balances if there is a need to support deflationary tokens.

Alleviation
[Nimbus]:Deflation tokens will not be exchanged on the platform, the contract owner will control the
tokens that are allowed to be exchanged in the P2P contract.
 Nimbus Code Security Assessment

NPP-05 | Missing Input Validation

Category Severity Location Status

Volatile Code Minor NimbusP2P_V2.sol: 238, 262, 283, 300 Resolved

Description
The given input askedAssets is missing a check in the function createTradeEIP20ToNFTs :

require(askedAssets.length > 0, "NimbusP2P_V2: askedAssets empty!");

The given input proposedAssets is missing a check in the function createTradeNFTsToEIP20 :

require(proposedAssets.length > 0, "NimbusP2P_V2: proposedAssets empty!");

The given input askedAssets is missing a check in the function createTradeBNBtoNFTs :

require(askedAssets.length > 0, "NimbusP2P_V2: askedAssets empty!");

The given input askedAssets and proposedAssets are missing a check in the function
createTradeNFTsToNFTs :

require(proposedAssets.length > 0, "NimbusP2P_V2: proposedAssets empty!");

require(askedAssets.length > 0, "NimbusP2P_V2: askedAssets empty!");

require(proposedAssets.length == proposedTokenIds.length, "NimbusP2P_V2: AskedAssets wrong

lengths");

require(askedAssets.length == askedTokenIds.length, "NimbusP2P_V2: AskedAssets wrong lengths");

Recommendation
Consider adding the check.

Alleviation
The development team resolved this issue in commit ea660b12ef93216a5fe3d8aa89c8b10624fe50b6.
 Nimbus Code Security Assessment

NPP-06 | The Comment TODO

Category Severity Location Status

Coding Style Informational NimbusP2P_V2.sol: 540, 526 Resolved

Description
There are some TODO comments in the contract. Are they implying some logic implementations missed?

Recommendation
Consider completing the todo feature if there is.

Alleviation
The development team resolved this issue in commit 341ba8e92a94d4cce212fb364e22440030842c5e.
 Nimbus Code Security Assessment

TTN-01 | Centralization Risk

Category Severity Location Status

Centralization / TikToken.sol: 102~105, 432~473, 784~788, 790~794, 796~800, 80

Major Acknowledged
Privilege 2~806, 819~823, 415~417, 808~818

Description
In the contract, Ownable , the role, _owner , has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to _owner may allow the hacker to take
advantage of this.

Authenticated Role Function State Variables

transferOwner
_owner transferOwnership
newOwner

In the contract, TikToken , the role, _owner , has the authority over the functions shown in the diagram
below.

Any compromise to the privileged account which has access to _owner may allow the hacker to take
advantage of this.

State Variables

_swapRouter
Address
_wbnb
_nbuToken
_gnbuToken
_bnbNbuPair
_gnbuBnbPair
_lpStakingBnbNbu
_lpStakingBnbGnbu
_lendingContract
_name
_symbol
swapRouter
WBNB
nbuToken
gnbuToken
lpStakingBnbNbu
 lpStakingBnbGnbu
lendingContract
Nimbus Code Security Assessment
rewardDuration
minPurchaseAmount

Function Calls

isContract
IRouter
Function
IWBNB
IBEP20
initialize
ILpStaking
ILending
rewardDuration
approve

State Variables

newSwapRouter
Address
swapRouter

Function Function Calls

isContract
updateSwapRouter
IRouter

State Variables

newLpStaking
Address
lpStakingBnbNbu

Function Function Calls

isContract
updateLpStakingBnbNbu
ILpStaking

State Variables

newLpStaking
Address
Authenticated Role Function
lpStakingBnbGnbu

_owner updateLpStakingBnbGnbu
Function Calls

isContract
ILpStaking

State Variables
Function
 newLendingContract
updateLendingContract Address
Nimbus Code Security Assessment
lendingContract

Function Calls

isContract
ILending

State Variables

Function
token
Address
updateTokenAllowance
amount
spender

Function Calls
Function
isContract
updateMinPurchaseAmount approve
IBEP20

State Variables

newAmount
minPurchaseAmount

In the contract, TikTokenProxy , the role, _owner , has the authority over the functions shown in the diagram
below.

Any compromise to the privileged account which has access to _owner may allow the hacker to take
advantage of this.
 Nimbus Code Security Assessment

State Variables

_newTarget

Authenticated Role Function

Function Calls
_owner setTarget
_setTarget

The TikToken contract is renamed as SmartLP , until the commit

`9464164f00b7b9a103af3644398535343800cebe, below functions are added and can only be access by
the owner:

rescue(address to, address tokenAddress, uint256 amount)

rescue(address payable to, uint256 amount)

Recommendation
We advise the client to carefully manage the privileged account's private key to avoid any potential risks of
being hacked.

In general, we strongly recommend centralized privileges or roles in the protocol to be improved via a
decentralized mechanism or smart-contract-based accounts with enhanced security practices, e.g.,
Multisignature wallets.

Indicatively, here is some feasible suggestions that would also mitigate the potential risk at the different
level in term of short-term and long-term:

Time-lock with reasonable latency, e.g., 48 hours, for awareness on privileged operations;

Assignment of privileged roles to multi-signature wallets to prevent a single point of failure due to the
private key;

Introduction of a DAO/governance/voting module to increase transparency and user involvement.

Alleviation
No Alleviation.
Nimbus Code Security Assessment
 Nimbus Code Security Assessment

TTN-02 | Unknown Implementations

Category Severity Location Status

Volatile Code Minor TikToken.sol: 433~441 Acknowledged

Description
There are several unknown implementations of contracts.

_swapRouter

_wbnb

_nbuToken

_gnbuToken

_bnbNbuPair

_gnbuBnbPair

_lpStakingBnbNbu

_lpStakingBnbGnbu

_lendingContract

The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness.
However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In
addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd
parties, migrating to new LP pools, etc.

Recommendation
We understand that the business logic of this protocol requires interaction with these functions. We
encourage the team to constantly monitor the statuses of 3rd parties to mitigate the side effects when
unexpected activities are observed.

Alleviation
No Alleviation.
 Nimbus Code Security Assessment

TTN-03 | Lack Of Update weightedStakeDate And _userTokens

Category Severity Location Status

Logical Issue Medium TikToken.sol: 544 Resolved

Description
Lack of update weightedStakeDate and _userTokens for the tokenId in the burnTik function. Is that
designed as expected?

Recommendation
Consider updating weightedStakeDate and _userTokens .

Alleviation
The development team resolved this issue in commit 7c9d7f0d1cf5f04ac3bebc9c6aa57768417c6b59.
 Nimbus Code Security Assessment

TTN-04 | Potential Revert

Category Severity Location Status

Logical Issue Major TikToken.sol: 576 Resolved

Description

lendedUserRewards = (userSupply.LendedITokenAmount * lendingContract.tokenPrice() / 1e18) -

userSupply.LendedBNBAmount;

The above calculation may be reverted caused by the underflow, is that designed as expected?

Recommendation
The development team heeded our advice and resolved this issue in commit
9464164f00b7b9a103af3644398535343800cebe.
 Nimbus Code Security Assessment

TTN-05 | Lack Of Check The Balance Of The Reward Token

Category Severity Location Status

Logical Issue Medium TikToken.sol: 600 Partially Resolved

Description

TransferHelper.safeTransfer(address(nbuToken), msg.sender, lpBnbNbuUserRewards +

lpBnbGnbuUserRewards);

The above statement lacks check whether there is enough nbuToken to distribute reward.

Recommendation
Consider updating the amount to be transferred to the miner value of nbuToken.balanceOf(address(this))
and lpBnbNbuUserRewards + lpBnbGnbuUserRewards, and emit relative event if the balance is not
enough.

Alleviation
The development team partially resolved this issue in commit
7c9d7f0d1cf5f04ac3bebc9c6aa57768417c6b59.
 Nimbus Code Security Assessment

TTN-06 | Economy Model Of Reward

Category Severity Location Status

Logical Issue Informational TikToken.sol: 570, 594, 596 Acknowledged

Description
Could you explain your calculation model of the reward distribution, include, the calculation formulas in the
getTokenRewardsAmounts function and the reward generating mechanism in the lpStakingBnbNbu contract,

the lpStakingBnbGnbu contract, and the lendingContract contract. We know that this contract needs to

interact with the ILpStaking contract, however, the ILpStaking contracts and the lendingContract contract
are out of this audit.

Recommendation
The economy model of this protocol is not in the scope of this audit.

Alleviation
[Nimbus]:
ILPStaking rewards model
In the SmartLP contract, we calculate how many rewards for LP
Staking NFT brings to its owner. In the SmartLP contract, we use the following formula to calculate LP
Staking rewards:
rewards =
(Converted LP Token Amount * (block.timestamp - date of last withdrawal *
reward rate))/ (100 * Reward Duration)

The LP Staking contract calculates the number of earned rewards by the SmartLP contract
In the
ILPStaking contract, the rewards are calculated according to a similar formula, only everything is
calculated for all stakes
made by the SmartLP contract in ILPStaking contract/

rewards = (Converted LP Token Amount * ((block.timestamp - weighted stake date * rewardRate)) / (100 *
rewardDuration);

Lended Rewards Model

The user has a number of IToken whose price may increase. When someone borrows a user's money, the
user receives rewards. In the lend, the price of IToken grows depending on the APR (interest rate for the
year).

In the SmartLP contract, we calculate Lend rewards as follows: The number of IToken converted to BNB
minus the amount of BNB delivered to Lend is equal to the user's rewards for lend.
 Nimbus Code Security Assessment

TTN-07 | The Comment TODO

Category Severity Location Status

Coding Style Informational TikToken.sol: 492 Resolved

Description
There is a TODO comment in the contract. Is it implying some logic implementations missed?

Recommendation
Consider completing the todo feature if there is.

Alleviation
The development team heeded our advice and resolved this issue in commit
7c9d7f0d1cf5f04ac3bebc9c6aa57768417c6b59.
 Nimbus Code Security Assessment

TTN-08 | The Activity Period

Category Severity Location Status

Logical Issue Informational TikToken.sol: 574~575 Acknowledged

Description

lpBnbNbuUserRewards = (_balancesRewardEquivalentBnbNbu[tokenId] * ((block.timestamp -

weightedStakeDate[tokenId]) * 100)) / (100 * rewardDuration);

lpBnbGnbuUserRewards = (_balancesRewardEquivalentBnbGnbu[tokenId] * ((block.timestamp -

weightedStakeDate[tokenId]) * 100)) / (100 * rewardDuration);

What if the value of (block.timestamp - weightedStakeDate[tokenId]) greater than the value of

rewardDuration in the above calculation?

Recommendation
The economy model of this protocol is not in the scope of this audit.

Alleviation
[Nimbus]: (block.timestamp - weightedStakeDate [tokenId]) if this value is greater than rewardDuration.
The user will continue to receive rewards.
 Nimbus Code Security Assessment

TTN-09 | Redundant Calculation

Category Severity Location Status

Gas Optimization Informational TikToken.sol: 600 Resolved

Description

TransferHelper.safeTransfer(address(nbuToken), msg.sender, lpBnbNbuUserRewards +

lpBnbGnbuUserRewards);

The calculation of lpBnbNbuUserRewards + lpBnbGnbuUserRewards could be replaced by totalReward that was

calculated before.

Recommendation
Consider refactoring the code.

Alleviation
The development team resolved this issue in commit 7c9d7f0d1cf5f04ac3bebc9c6aa57768417c6b59.
 Nimbus Code Security Assessment

TTN-10 | Potential Reentrancy Attack

Category Severity Location Status

Logical Issue Minor TikToken.sol: 550~563 Resolved

Description
A reentrancy attack can occur when the contract creates a function that makes an external call to another
untrusted contract before resolving any effects.
If the attacker can control the untrusted contract, they can
make a recursive call back to the original function, repeating interactions that would have otherwise not run
after the external call resolved the effects.

Recommendation
We recommend using the Checks-Effects-Interactions Pattern to avoid the risk of calling unknown
contracts or applying OpenZeppelin ReentrancyGuard library - nonReentrant modifier for the
aforementioned functions to prevent reentrancy attack.

Alleviation
The development team resolved this issue in commit 8bab94f389949826bf2f52de8a5a5ee3615fdafd.
 Nimbus Code Security Assessment

TTN-11 | Lack Of Return Value Handling

Category Severity Location Status

Volatile Code Informational TikToken.sol: 560, 558, 555 Resolved

Description
The following functions are lack of handling return value:

swapRouter.removeLiquidityBNB

lendingContract.burnToBnb

Recommendation
We recommend validating the output of the aforementioned function and continuing processing when
receiving a proper returned value, otherwise reverting.

Alleviation
The development team resolved this issue in commit 341ba8e92a94d4cce212fb364e22440030842c5e.
 Nimbus Code Security Assessment

Appendix
Finding Categories

Centralization / Privilege
Centralization / Privilege findings refer to either feature logic or implementation of components that act
against the nature of decentralization, such as explicit ownership or specialized access roles in
combination with a mechanism to relocate funds.

Gas Optimization
Gas Optimization findings do not affect the functionality of the code but generate different, more optimal
EVM opcodes resulting in a reduction on the total gas cost of a transaction.

Logical Issue
Logical Issue findings detail a fault in the logic of the linked code, such as an incorrect notion on how
block.timestamp works.

Volatile Code
Volatile Code findings refer to segments of code that behave unexpectedly on certain edge cases that may
result in a vulnerability.

Coding Style
Coding Style findings usually do not affect the generated byte-code but rather comment on how to make
the codebase more legible and, as a result, easily maintainable.

Checksum Calculation Method

The "Checksum" field in the "Audit Scope" section is calculated as the SHA-256 (Secure Hash Algorithm 2
with digest size of 256 bits) digest of the content of each file hosted in the listed source repository under
the specified commit.

The result is hexadecimal encoded and is the same as the output of the Linux "sha256sum" command
against the target file.
 Nimbus Code Security Assessment

Disclaimer
This report is subject to the terms and conditions (including without limitation, description of services,
confidentiality, disclaimer and limitation of liability) set forth in the Services Agreement, or the scope of
services, and terms and conditions provided to you (“Customer” or the “Company”) in connection with the
Agreement. This report provided in connection with the Services set forth in the Agreement shall be used
by the Company only to the extent permitted under the terms and conditions set forth in the Agreement.
This report may not be transmitted, disclosed, referred to or relied upon by any person for any purposes,
nor may copies be delivered to any other person other than the Company, without CertiK’s prior written
consent in each instance.

This report is not, nor should be considered, an “endorsement” or “disapproval” of any particular project or
team. This report is not, nor should be considered, an indication of the economics or value of any
“product” or “asset” created by any team or project that contracts CertiK to perform a security
assessment. This report does not provide any warranty or guarantee regarding the absolute bug-free
nature of the technology analyzed, nor do they provide any indication of the technologies proprietors,
business, business model or legal compliance.

This report should not be used in any way to make decisions around investment or involvement with any
particular project. This report in no way provides investment advice, nor should be leveraged as investment
advice of any sort. This report represents an extensive assessing process intending to help our customers
increase the quality of their code while reducing the high level of risk presented by cryptographic tokens
and blockchain technology.

Blockchain technology and cryptographic assets present a high level of ongoing risk. CertiK’s position is
that each company and individual are responsible for their own due diligence and continuous security.
CertiK’s goal is to help reduce the attack vectors and the high level of variance associated with utilizing
new and consistently changing technologies, and in no way claims any guarantee of security or
functionality of the technology we agree to analyze.

The assessment services provided by CertiK is subject to dependencies and under continuing
development. You agree that your access and/or use, including but not limited to any services, reports,
and materials, will be at your sole risk on an as-is, where-is, and as-available basis. Cryptographic tokens
are emergent technologies and carry with them high levels of technical risk and uncertainty. The
assessment reports could include false positives, false negatives, and other unpredictable results. The
services may access, and depend upon, multiple layers of third-parties.

ALL SERVICES, THE LABELS, THE ASSESSMENT REPORT, WORK PRODUCT, OR OTHER MATERIALS,
OR ANY PRODUCTS OR RESULTS OF THE USE THEREOF ARE PROVIDED “AS IS” AND “AS
 Nimbus Code Security Assessment

AVAILABLE” AND WITH ALL FAULTS AND DEFECTS WITHOUT WARRANTY OF ANY KIND. TO THE
MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW, CERTIK HEREBY DISCLAIMS ALL
WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE
SERVICES, ASSESSMENT REPORT, OR OTHER MATERIALS. WITHOUT LIMITING THE FOREGOING,
CERTIK SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AND ALL WARRANTIES ARISING FROM
COURSE OF DEALING, USAGE, OR TRADE PRACTICE. WITHOUT LIMITING THE FOREGOING, CERTIK
MAKES NO WARRANTY OF ANY KIND THAT THE SERVICES, THE LABELS, THE ASSESSMENT REPORT,
WORK PRODUCT, OR OTHER MATERIALS, OR ANY PRODUCTS OR RESULTS OF THE USE THEREOF,
WILL MEET CUSTOMER’S OR ANY OTHER PERSON’S REQUIREMENTS, ACHIEVE ANY INTENDED
RESULT, BE COMPATIBLE OR WORK WITH ANY SOFTWARE, SYSTEM, OR OTHER SERVICES, OR BE
SECURE, ACCURATE, COMPLETE, FREE OF HARMFUL CODE, OR ERROR-FREE. WITHOUT LIMITATION
TO THE FOREGOING, CERTIK PROVIDES NO WARRANTY OR UNDERTAKING, AND MAKES NO
REPRESENTATION OF ANY KIND THAT THE SERVICE WILL MEET CUSTOMER’S REQUIREMENTS,
ACHIEVE ANY INTENDED RESULTS, BE COMPATIBLE OR WORK WITH ANY OTHER SOFTWARE,
APPLICATIONS, SYSTEMS OR SERVICES, OPERATE WITHOUT INTERRUPTION, MEET ANY
PERFORMANCE OR RELIABILITY STANDARDS OR BE ERROR FREE OR THAT ANY ERRORS OR
DEFECTS CAN OR WILL BE CORRECTED.

WITHOUT LIMITING THE FOREGOING, NEITHER CERTIK NOR ANY OF CERTIK’S AGENTS MAKES ANY
REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS OR IMPLIED AS TO THE ACCURACY,
RELIABILITY, OR CURRENCY OF ANY INFORMATION OR CONTENT PROVIDED THROUGH THE
SERVICE. CERTIK WILL ASSUME NO LIABILITY OR RESPONSIBILITY FOR (I) ANY ERRORS, MISTAKES,
OR INACCURACIES OF CONTENT AND MATERIALS OR FOR ANY LOSS OR DAMAGE OF ANY KIND
INCURRED AS A RESULT OF THE USE OF ANY CONTENT, OR (II) ANY PERSONAL INJURY OR
PROPERTY DAMAGE, OF ANY NATURE WHATSOEVER, RESULTING FROM CUSTOMER’S ACCESS TO
OR USE OF THE SERVICES, ASSESSMENT REPORT, OR OTHER MATERIALS.

ALL THIRD-PARTY MATERIALS ARE PROVIDED “AS IS” AND ANY REPRESENTATION OR WARRANTY
OF OR CONCERNING ANY THIRD-PARTY MATERIALS IS STRICTLY BETWEEN CUSTOMER AND THE
THIRD-PARTY OWNER OR DISTRIBUTOR OF THE THIRD-PARTY MATERIALS.

THE SERVICES, ASSESSMENT REPORT, AND ANY OTHER MATERIALS HEREUNDER ARE SOLELY
PROVIDED TO CUSTOMER AND MAY NOT BE RELIED ON BY ANY OTHER PERSON OR FOR ANY
PURPOSE NOT SPECIFICALLY IDENTIFIED IN THIS AGREEMENT, NOR MAY COPIES BE DELIVERED TO,
ANY OTHER PERSON WITHOUT CERTIK’S PRIOR WRITTEN CONSENT IN EACH INSTANCE.

NO THIRD PARTY OR ANYONE ACTING ON BEHALF OF ANY THEREOF, SHALL BE A THIRD PARTY OR
OTHER BENEFICIARY OF SUCH SERVICES, ASSESSMENT REPORT, AND ANY ACCOMPANYING
 Nimbus Code Security Assessment

MATERIALS AND NO SUCH THIRD PARTY SHALL HAVE ANY RIGHTS OF CONTRIBUTION AGAINST
CERTIK WITH RESPECT TO SUCH SERVICES, ASSESSMENT REPORT, AND ANY ACCOMPANYING
MATERIALS.

THE REPRESENTATIONS AND WARRANTIES OF CERTIK CONTAINED IN THIS AGREEMENT ARE

SOLELY FOR THE BENEFIT OF CUSTOMER. ACCORDINGLY, NO THIRD PARTY OR ANYONE ACTING
ON BEHALF OF ANY THEREOF, SHALL BE A THIRD PARTY OR OTHER BENEFICIARY OF SUCH
REPRESENTATIONS AND WARRANTIES AND NO SUCH THIRD PARTY SHALL HAVE ANY RIGHTS OF
CONTRIBUTION AGAINST CERTIK WITH RESPECT TO SUCH REPRESENTATIONS OR WARRANTIES OR
ANY MATTER SUBJECT TO OR RESULTING IN INDEMNIFICATION UNDER THIS AGREEMENT OR
OTHERWISE.

FOR AVOIDANCE OF DOUBT, THE SERVICES, INCLUDING ANY ASSOCIATED ASSESSMENT REPORTS
OR MATERIALS, SHALL NOT BE CONSIDERED OR RELIED UPON AS ANY FORM OF FINANCIAL, TAX,
LEGAL, REGULATORY, OR OTHER ADVICE.
 Nimbus Code Security Assessment

About
Founded in 2017 by leading academics in the field of Computer Science from both Yale and Columbia
University, CertiK is a leading blockchain security company that serves to verify the security and
correctness of smart contracts and blockchain-based protocols. Through the utilization of our world-class
technical expertise, alongside our proprietary, innovative tech, we’re able to support the success of our
clients with best-in-class security, all whilst realizing our overarching vision; provable trust for all
throughout all facets of blockchain.