Security Assessment

Revault
Sept 22nd, 2021
 Revault Security Assessment

Table of Contents
Summary

Overview
Project Summary
Audit Summary
Vulnerability Summary
Audit Scope

Findings
RCC-01 : No Need to Use `storage`
RCC-02 : Privileged ownership
RCC-03 : Missing Emits Events
RCC-04 : Centralized Control of Contract Upgrade
RCC-05 : Incorrect Sanity Check
RCC-06 : Potential issue on `revaReward` Amount
RCC-07 : `treasury` Can Mint Unlimited Tokens Repeatedly
RCC-08 : `treasury` could receive minted Tokens
RFR-01 : Centralized Control of Contract Upgrade
RFR-02 : Privileged ownership
RLS-01 : Unchecked Value of BEP20 `transfer()`/`transferFrom()` Call
RLS-02 : Check Effect Interaction Pattern Violated
RLS-03 : Privileged ownership
RLS-04 : Functions Should Be Declared External
RLS-05 : Missing Emit Events
RSP-01 : No Need to Use `storage`
RSP-02 : `vRevaToken` not Burned
RSP-03 : Privileged ownership
RSP-04 : Centralized Control of Contract Upgrade
RSP-05 : Functions Should Be Declared External
RSP-06 : No Upper Limit For `earlyWithdrawalFee`
RSP-07 : Missing Emit Events
RTC-01 : Variable could be declared as `constant`
RTC-02 : Delegation Not Moved Along With `transfer()`
RTC-03 : Functions Should Be Declared External
RTC-04 : Privileged ownership
RTC-05 : Missing Emit Events
 Revault Security Assessment

RTK-01 : Use `revert` Instead of `require`

RTK-02 : Privileged ownership
RUP-01 : Interfaces imported but not used
RUP-02 : Unchecked Value of BEP20 `transfer()`/`transferFrom()` Call
RVC-01 : No Need to Use `storage`
RVC-02 : Unchecked Value of BEP20 `transfer()`/`transferFrom()` Call
RVC-03 : Potential Sandwich Attacks
RVC-04 : Centralized Control of Contract Upgrade
RVC-05 : Add `nonReentrant` Guard
RVC-06 : Privileged ownership
RVC-07 : No Upper Limit For Profit Distribution
RVC-08 : Missing Emit Events
RVC-09 : Variables Should Be Initialized In `initializer`

Appendix

Disclaimer

About
 Revault Security Assessment

Summary
This report has been prepared for Revault to discover issues and vulnerabilities in the source code of the
Revault 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.
 Revault Security Assessment

Overview
Project Summary

Project Name Revault

Platform BSC

Language Solidity

Codebase https://github.com/Revault-network/backend/tree/master/contracts

Commit 63b680150606d291840c14fb0674747afd7cb886

Audit Summary

Delivery Date Sept 22, 2021

Audit Methodology Static Analysis, Manual Review

Key Components

Vulnerability Summary

Vulnerability Level Total Pending Declined Acknowledged Partially Resolved Resolved

Critical 1 0 0 0 0 1

Major 18 0 0 1 0 17

Medium 1 0 0 0 0 1

Minor 9 0 0 0 0 9

Informational 11 0 0 0 0 11

Discussion 0 0 0 0 0 0
 Revault Security Assessment

Audit Scope

ID File SHA256 Checksum

 Revault Security Assessment

Findings

Critical 1 (2.50%)
Major 18 (45.00%)

40 Medium

Minor
1 (2.50%)

9 (22.50%)
Total Issues
Informational 11 (27.50%)
Discussion 0 (0.00%)

ID Title Category Severity Status

Gas Optimization,
RCC-01 No Need to Use storage Minor Resolved
Language Specific

Centralization /
RCC-02 Privileged ownership Major Resolved
Privilege

RCC-03 Missing Emits Events Coding Style Informational Resolved

Centralization /
RCC-04 Centralized Control of Contract Upgrade Major Resolved
Privilege

RCC-05 Incorrect Sanity Check Logical Issue Major Resolved

RCC-06 Potential issue on revaReward Amount Volatile Code Major Resolved

treasury Can Mint Unlimited Tokens

RCC-07 Logical Issue Critical Resolved
Repeatedly

Centralization /
RCC-08 treasury could receive minted Tokens Major Resolved
Privilege

Centralization /
RFR-01 Centralized Control of Contract Upgrade Major Resolved
Privilege

Centralization /
RFR-02 Privileged ownership Major Resolved
Privilege

Unchecked Value of BEP20

RLS-01 Volatile Code Minor Resolved
transfer() / transferFrom() Call
 Revault Security Assessment

ID Title Category Severity Status

RLS-02 Check Effect Interaction Pattern Violated Volatile Code Major Resolved

Centralization /
RLS-03 Privileged ownership Major Resolved
Privilege

RLS-04 Functions Should Be Declared External Gas Optimization Informational Resolved

RLS-05 Missing Emit Events Coding Style Informational Resolved

Gas Optimization,
RSP-01 No Need to Use storage Minor Resolved
Language Specific

RSP-02 vRevaToken not Burned Logical Issue Minor Resolved

Centralization /
RSP-03 Privileged ownership Major Resolved
Privilege

Centralization /
RSP-04 Centralized Control of Contract Upgrade Major Resolved
Privilege

RSP-05 Functions Should Be Declared External Gas Optimization Informational Resolved

No Upper Limit For Centralization /

RSP-06 Major Resolved
earlyWithdrawalFee Privilege

RSP-07 Missing Emit Events Coding Style Informational Resolved

RTC-01 Variable could be declared as constant Gas Optimization Informational Resolved

Delegation Not Moved Along With

RTC-02 Logical Issue Medium Resolved
transfer()

RTC-03 Functions Should Be Declared External Gas Optimization Informational Resolved

Centralization /
RTC-04 Privileged ownership Major Resolved
Privilege

RTC-05 Missing Emit Events Coding Style Informational Resolved

Gas Optimization,
RTK-01 Use revert Instead of require Informational Resolved
Coding Style

Centralization /
RTK-02 Privileged ownership Major Resolved
Privilege
 Revault Security Assessment

ID Title Category Severity Status

RUP-01 Interfaces imported but not used Volatile Code Informational Resolved

Unchecked Value of BEP20

RUP-02 Volatile Code Minor Resolved
transfer() / transferFrom() Call

Gas Optimization,
RVC-01 No Need to Use storage Minor Resolved
Language Specific

Unchecked Value of BEP20 Control Flow, Volatile

RVC-02 Minor Resolved
transfer() / transferFrom() Call Code

RVC-03 Potential Sandwich Attacks Logical Issue Major Acknowledged

Centralization /
RVC-04 Centralized Control of Contract Upgrade Major Resolved
Privilege

RVC-05 Add nonReentrant Guard Volatile Code Minor Resolved

Centralization /
RVC-06 Privileged ownership Major Resolved
Privilege

Centralization /
RVC-07 No Upper Limit For Profit Distribution Major Resolved
Privilege

RVC-08 Missing Emit Events Coding Style Informational Resolved

Variables Should Be Initialized In

RVC-09 Volatile Code Minor Resolved
initializer
 Revault Security Assessment

RCC-01 | No Need to Use storage

Category Severity Location Status

Gas Optimization, Language contracts/reva/RevaChef.sol (revault): 94, 169, 195, 207,

Minor Resolved
Specific 157

Description
The storage property is mainly used for modifying storage variables, reading storage variables will cost
more gas.

Recommendation
We recommend removing storage property if there are no storage variables updated.
 Revault Security Assessment

RCC-02 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaChef.sol (revault): 180, 184 Resolved

Description
The owner of contract RevaStakingPool has the permission to:

1. call setRevaPerBlock to update revaPerBlock at any time

2. call setRevault to modify revaultAddress
3. call setTreasury to modify treasury address

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RCC-03 | Missing Emits Events

Category Severity Location Status

Coding Style Informational contracts/reva/RevaChef.sol (revault): 180, 184, 188 Resolved

Description
"The function that affects the status of sensitive variables should be able to emit events as notifications to
[fixme].

setRevaPerBlock()

setRevault()

setTreasury()

Recommendation
Consider adding events for sensitive actions, and emit them in the aforementioned functions.
 Revault Security Assessment

RCC-04 | Centralized Control of Contract Upgrade

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaChef.sol (revault): 10 Resolved

Description
The contract owner can upgrade the contract without the community's commitment. If an attacker
compromises the account, he can change the implementation of the contract and drain tokens from the
contract.

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multi-signature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RCC-05 | Incorrect Sanity Check

Category Severity Location Status

Logical Issue Major contracts/reva/RevaChef.sol (revault): 118 Resolved

Description
Function updateRevaultRewards is called by notifyDeposited and notifyWithdrawn , if there are more
than two transactions calling notifyDeposited or notifyWithdrawn to deposit/withdraw the same token,
transactions after the first transaction will not update tokenInfo , because block.number ==
tokenInfo.lastRewardBlock is true, updateRevaultRewards function will return before updating

tokenInfo .

1 function updateRevaultRewards(address _tokenAddress, uint256 _amount, bool

_isDeposit) internal {
2 TokenInfo storage tokenInfo = tokens[_tokenAddress];
3 if (block.number <= tokenInfo.lastRewardBlock) {
4 return;
5 }
6 ...
7 }

Recommendation
We advise the client to fix it.

Alleviation
Fixed in commit hash ef02495eb5748ffdbeed23f8afc6aed2e23101c7 by removing tokenInfo.tvlBusd
update logic.
 Revault Security Assessment

RCC-06 | Potential issue on revaReward Amount

Category Severity Location Status

Volatile Code Major contracts/reva/RevaChef.sol (revault): 100, 127 Resolved

Description
In function updateRevaultRewards , totalRevaultTvlBusd and tokenInfo.tvlBusd depend on the return
value of zap.getBUSDValue , which may be manipulated by hackers, so they can get more reve tokens.

Recommendation
If a project requires price references, it needs to be caution of flash loans that might manipulate token
prices. To minimize the chance of happening, we recommend the client to consider following according to
the project's business model:

1. Use Time-Weighted Average Price (TWAP). The TWAP represents the average price of a token over a
specified time frame. If an attacker manipulates the price in one block, it will not affect too much on
the average price.
2. If the business model allows, restrict the function caller to be a non-contract/EOA address.
3. Flash loans only allow users to borrow money within a single transaction. If the contract use cases
allowed, force critical transactions to span at least two blocks.

Alleviation
Fixed in commit hash ef02495eb5748ffdbeed23f8afc6aed2e23101c7 by removing tokenInfo.tvlBusd
update logic.
 Revault Security Assessment

RCC-07 | treasury Can Mint Unlimited Tokens Repeatedly

Category Severity Location Status

Logical Issue Critical contracts/reva/RevaChef.sol (revault): 175 Resolved

Description
treasury can repeatedly call claimTreasuryReward to mint as many tokens as they want because

lastTreasuryRewardBlock is not updated.

Recommendation
We advise to use checks-effects-integrates patten to update lastTreasuryRewardBlock .

Alleviation
Team: The function mint does not trigger callback, so checks-effects-integrates are not required.
 Revault Security Assessment

RCC-08 | treasury could receive minted Tokens

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaChef.sol (revault): 175 Resolved

Description
treasury could receive minted tokens by calling function claimTreasuryReward .

Recommendation
We advise the client to explain this design because users need to know where tokens go.

Alleviation
Team: As part of REVA tokenomics (https://revaultnetwork.medium.com/revaults-token-economics-
e9bef267d9d2), the revault DAO treasury must be able to receive tokens (10% of the total supply). The
treasury will be under multisig control, and eventually in the hands of the community just like all the other
contracts until the community handover.
 Revault Security Assessment

RFR-01 | Centralized Control of Contract Upgrade

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaFeeReceiver.sol (revault): 11 Resolved

Description
The contract owner can upgrade the contract without the community's commitment. If an attacker
compromises the account, he can change the implementation of the contract and drain tokens from the
contract.

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multi-signature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RFR-02 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaFeeReceiver.sol (revault): 20 Resolved

Description
The owner of contract RevaFeeReceiver has the permission to:

1. call addRecipient to approve any address to take all revaToken from this contract.

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RLS-01 | Unchecked Value of BEP20 /

transfer() transferFrom() Call

Category Severity Location Status

Volatile Code Minor contracts/reva/RevaLpStakingPool.sol (revault): 123, 128, 153, 158, 169 Resolved

Description
"The linked transfer() / transferFrom / approve invocations do not check the return value of the function
call which should yield a true result in case of proper ERC-20 implementation.

Recommendation
It is recommended to use SafeBEP20.

1 using SafeBEP20 for IBEP20;

2 ...
3 IBEP20(fromVault.depositTokenAddress).safeTransfer(userProxyAddress,
fromVaultTokenAmount);
 Revault Security Assessment

RLS-02 | Check Effect Interaction Pattern Violated

Category Severity Location Status

Volatile Code Major contracts/reva/RevaLpStakingPool.sol (revault): 113, 140, 166 Resolved

Description
Hackers may manipulate the pool.lpToken contract, so there is a potential re-entrancy issue. The external
call/transfer and storage manipulation sequence must follow a checks-effects-interactions pattern to avoid
re-entrancy attacks. For example:

Function deposit()
Function withdraw()
Function emergencyWithdraw()

Recommendation
We advise the client to use checks-effects-interactions pattern AND add ReentrancyGuard . checks-
effects-interactionsLINK [ReentrancyGuard](https://github.com/OpenZeppelin/openzeppelin-
contracts/blob/master/contracts/utils/ReentrancyGuard.sol
 Revault Security Assessment

RLS-03 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaLpStakingPool.sol (revault): 187, 205, 216 Resolved

Description
The owner of contract RevaStakingPool has the permission to:

1. call add to add pools with any allocPoint

2. call set to set any pool's allocPoint
3. call setRevaPerBlock to update revaPerBlock at any time

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RLS-04 | Functions Should Be Declared External

Category Severity Location Status

Gas Optimization Informational contracts/reva/RevaLpStakingPool.sol (revault): 166, 187, 205 Resolved

Description
Functions that are never called internally within the contract should have external visibility. For example,
emergencyWithdraw , add , and set .

Recommendation
We recommend changing the visibility of the aforementioned functions to external.
 Revault Security Assessment

RLS-05 | Missing Emit Events

Category Severity Location Status

Coding Style Informational contracts/reva/RevaLpStakingPool.sol (revault): 217 Resolved

Description
The function that affects the status of sensitive variables should be able to emit events as notifications to
users.

setRevaPerBlock()

Recommendation
Consider adding events for sensitive actions, and emit them in the function.
 Revault Security Assessment

RSP-01 | No Need to Use storage

Category Severity Location Status

Gas Optimization, Language Specific Minor contracts/reva/RevaStakingPool.sol (revault): 129~130 Resolved

Description
The storage property is mainly used for modifying storage variables, reading storage variables will cost
more gas.

Recommendation
We recommend removing storage property if there is no storage variables updated.
 Revault Security Assessment

RSP-02 | vRevaToken not Burned

Category Severity Location Status

Logical Issue Minor contracts/reva/RevaStakingPool.sol (revault): 230 Resolved

Description
vRevaToken minted in deposit and burned in withdraw , but not burned when users call withdrawEarly ,

emergencyWithdraw or emergencyWithdrawEarly .

Recommendation
We advise to burn vRevaToken in these aforementioned functions. .
 Revault Security Assessment

RSP-03 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaStakingPool.sol (revault): 249, 271, 282 Resolved

Description
The owner of contract RevaStakingPool has the permission to:

1. call add to add pools with any allocPoint

2. call set to set any pool's allocPoint
3. call setRevaPerBlock to update revaPerBlock at any time
4. call setEarlyWithdrawalFee to update earlyWithdrawalFee at any time

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RSP-04 | Centralized Control of Contract Upgrade

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaStakingPool.sol (revault): 10 Resolved

Description
The contract owner can upgrade the contract without the community's commitment. If an attacker
compromises the account, he can change the implementation of the contract and drain tokens from the
contract.

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multi-signature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RSP-05 | Functions Should Be Declared External

Category Severity Location Status

Gas Optimization Informational contracts/reva/RevaStakingPool.sol (revault): 230, 249, 271 Resolved

Description
Functions that are never called internally within the contract should have external visibility. For example,
emergencyWithdraw , emergencyWithdrawEarly , add , and set .

Recommendation
We recommend changing the visibility of the aforementioned functions to external.
 Revault Security Assessment

RSP-06 | No Upper Limit For earlyWithdrawalFee

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaStakingPool.sol (revault): 329 Resolved

Description
The owner can set the earlyWithdrawalFee when deploying the contract and there is no upper limit on
what the rate can be. In the extreme case, the rate can be as high as 100%, which means all deposited
tokens can be deducted as earlyWithdrawalFee .

Recommendation
We recommend setting an upper limit for the earlyWithdrawalFee variable.

Alleviation
The max earlyWithdrawFee is 50% of all deposited tokens.

1 uint public constant EARLY_WITHDRAWAL_FEE_PRECISION = 1000000;

2 uint public constant MAX_EARLY_WITHDRAWAL_FEE = 500000;
 Revault Security Assessment

RSP-07 | Missing Emit Events

Category Severity Location Status

Coding Style Informational contracts/reva/RevaStakingPool.sol (revault): 323, 327 Resolved

Description
The function that affects the status of sensitive variables should be able to emit events as notifications to
users.

setRevaPerBlock()

setEarlyWithdrawalFee()

Recommendation
Consider adding events for sensitive actions, and emit them in the function.
 Revault Security Assessment

RTC-01 | Variable could be declared as constant

Category Severity Location Status

Gas Optimization Informational contracts/reva/RevaToken.sol (revault): 24 Resolved

Description
Variables _maxSupply could be declared as constant since it is never to be changed.

Recommendation
We recommend declaring it as constant .
 Revault Security Assessment

RTC-02 | Delegation Not Moved Along With transfer()

Category Severity Location Status

Logical Issue Medium contracts/reva/RevaToken.sol (revault): 62, 77 Resolved

Description
The voting power of delegation is not moved from token sender to token recipient along with the
transfer() and transferFrom .

Recommendation
We advise to invoke _moveDelegates() in transfer and transferFrom functions.

Alleviation
Delegation feature is removed from RevaToken contract.
 Revault Security Assessment

RTC-03 | Functions Should Be Declared External

Category Severity Location Status

Gas Optimization Informational contracts/reva/RevaToken.sol (revault): 27, 34, 40, 46, 52, 57 Resolved

Description
Functions that are never called internally within the contract should have external visibility. For example,
mint , setTreasury , setRevaStakeFeeReceiver , setRevaLpStakeFeeReceiver , setBurnFee , and

setMinter .

Recommendation
We recommend changing the visibility of the aforementioned functions to external.
 Revault Security Assessment

RTC-04 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/RevaToken.sol (revault): 34, 40, 46, 52, 57 Resolved

Description
The owner of contract RevaToken has the permission to:

1. call setTreasury to set fee receiver and fees ratio which is up to 1%

2. call setRevaStakeFeeReceiver to fee receiver and fees ratio which is up to 1%
3. call setRevaLpStakeFeeReceiver to fee receiver and fees ratio which is up to 1%
4. call setBurnFee to set the burn fee ratio which is up to 1%
5. call setMinter to set any address as a minter

So every Reva Token transfer transaction ， up to 3% of the transferred amount Reva Token will be
transferred to different receivers, up to 1 of the transferred amount Reva Token will be burned

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Deployed a Gnosis multi sig :
https://bscscan.com/address/0x98bc7b818e148f46a35f8a767e8d5ef7f1152193 Timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#code
 Revault Security Assessment

RTC-05 | Missing Emit Events

Category Severity Location Status

Coding Style Informational contracts/reva/RevaToken.sol (revault): 34, 40, 46, 52, 57 Resolved

Description
"The function that affects the status of sensitive variables should be able to emit events as notifications to
[fixme].

setTreasury()

setRevaStakeFeeReceiver()

setRevaLpStakeFeeReceiver()

setBurnFee()

setMinter()

Recommendation
Consider adding events for sensitive actions, and emit them in the aforementioned functions.
 Revault Security Assessment

RTK-01 | Use revert Instead of require

Category Severity Location Status

Gas Optimization, Coding Style Informational contracts/reva/vRevaToken.sol (revault): 11, 19 Resolved

Description
In function transfer and transferFrom , require statement can be replaced by revert .

Recommendation
we advise to use revert directly.

1 revert("Can't transfer VREVA");

 Revault Security Assessment

RTK-02 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/vRevaToken.sol (revault): 23, 28 Resolved

Description
The owner of contract vRevaToken has the permission to:

1. mint tokens to any address,

2. burn tokens from any address,

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RUP-01 | Interfaces imported but not used

Category Severity Location Status

Volatile Code Informational contracts/reva/RevaUserProxy.sol (revault): 7~9 Resolved

Description
Interfaces imported but not used

Recommendation
We advise to remove unused imports.
 Revault Security Assessment

RUP-02 | Unchecked Value of BEP20 /

transfer() transferFrom() Call

Category Severity Location Status

Volatile Code Minor contracts/reva/RevaUserProxy.sol (revault): 38, 41, 52, 63 Resolved

Description
"The linked transfer() / transferFrom / approve invocations do not check the return value of the function
call which should yield a true result in case of proper ERC-20 implementation.

Recommendation
It is recommended to use SafeBEP20.

1 using SafeBEP20 for IBEP20;

2 ...
3 IBEP20(fromVault.depositTokenAddress).safeTransfer(msg.sender, fromVaultTokenAmount);
 Revault Security Assessment

RVC-01 | No Need to Use storage

Category Severity Location Status

Gas Optimization, Language contracts/reva/ReVault.sol (revault): 71, 72, 90~91, 109~110,

Minor Resolved
Specific 126, 183, 221

Description
The storage property is mainly used for modifying storage variables, reading storage variables will cost
more gas.

Recommendation
We recommend removing storage property if there are no storage variables updated.
 Revault Security Assessment

RVC-02 | Unchecked Value of BEP20 /

transfer() transferFrom() Call

Category Severity Location Status

Control Flow, Volatile Code Minor contracts/reva/ReVault.sol (revault): 78, 96, 150, 205, 233, 161 Resolved

Description
"The linked transfer() / transferFrom / approve invocations do not check the return value of the function
call which should yield a true result in case of proper ERC-20 implementation.

Recommendation
It is recommended to use SafeBEP20.

1 using SafeBEP20 for IBEP20;

2 ...
3 IBEP20(fromVault.depositTokenAddress).safeTransfer(userProxyAddress,
fromVaultTokenAmount);
 Revault Security Assessment

RVC-03 | Potential Sandwich Attacks

Category Severity Location Status

Logical Issue Major contracts/reva/ReVault.sol (revault): 298 Acknowledged

Description
A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding
liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate
the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of
the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the
asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so
transactions triggering these functions are vulnerable to sandwich attacks, especially when the input
amount is large:

zap.zapInTokenTo

Recommendation
We recommend setting reasonable minimum output amounts, instead of 0, based on token prices when
calling the aforementioned functions.

Alleviation
Team: We will be providing a disclaimer that no minReturn param is accepted in this version,
slippage/frontrunning is a possibility for larger amounts.
 Revault Security Assessment

RVC-04 | Centralized Control of Contract Upgrade

Category Severity Location Status

Centralization / Privilege Major contracts/reva/ReVault.sol (revault): 14 Resolved

Description
The contract owner can upgrade the contract without the community's commitment. If an attacker
compromises the account, he can change the implementation of the contract and drain tokens from the
contract.

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multi-signature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RVC-05 | Add nonReentrant Guard

Category Severity Location Status

Volatile Code Minor contracts/reva/ReVault.sol (revault): 68 Resolved

Description
These external functions don't have reentrancy issues from its code logic, but it calls third-party vault
contracts, which may cause reentrancy issues, so it's better to add nonReentrant for safety.

external functions: rebalanceDepositAll rebalanceDepositAllDynamicAmount withdrawFromVault

depositToVaultFor depositToVault harvestWithdrawVault harvestCompoundVault

Recommendation
We recommend applying OpenZeppelin ReentrancyGuard library - nonReentrant modifier for the
aforementioned function to prevent pentential reentrancy attack.
 Revault Security Assessment

RVC-06 | Privileged ownership

Category Severity Location Status

Centralization / Privilege Major contracts/reva/ReVault.sol (revault): 327, 336, 340, 345, 323 Resolved

Description
The owner of contract ReVault has the permission to:

1. call addVault to add VaultInfo

2. call setHarvestMethod to approve harvest payload to be executed
3. call setProfitToReva to set profitToReva fee ratio
4. call setProfitToRevaStakers to set profitToRevaStakers fee ratio
5. call withdrawToken to withdraw any tokens transferred to this contract accidentally

Recommendation
We advise the client to carefully manage the admin 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 via smart-contract-based accounts with enhanced security
practices, e.g. Multisignature wallets. Here are some feasible solutions that would also mitigate the
potential risk:

Time-lock with reasonable latency, i.e. 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
Owner changed to timelock:
https://bscscan.com/address/0x30ec49ef0243c00cf133a133e745c3957d4e28bc#readContract

The owner of the timelock contract is a Gnosis Multisig:

https://bscscan.com/address/0x636bf0bd0986a1c96998f26f34b9076e113d9d48#code
 Revault Security Assessment

RVC-07 | No Upper Limit For Profit Distribution

Category Severity Location Status

Centralization / Privilege Major contracts/reva/ReVault.sol (revault): 342, 347 Resolved

Description
The contract owner can set profit distribution parameters profitToReva=PROFIT_DISTRIBUTION_PRECISION
and profitToRevaStakers=0 or profitToReva=0 and
profitToRevaStakers=PROFIT_DISTRIBUTION_PRECISION , which means 100% of the profit will be

distributed to one of profitToReva or profitToRevaStakers , not both.

Recommendation
We recommend setting an upper limit for both profitToRevaStakers and profitToReva .

Alleviation
There could be 50% maximum distruted to vault.

1 uint public constant PROFIT_DISTRIBUTION_PRECISION = 1000000;

2 uint public constant MAX_PROFIT_TO_REVA = 500000;
3 uint public constant MAX_PROFIT_TO_REVA_STAKERS = 200000;
 Revault Security Assessment

RVC-08 | Missing Emit Events

Category Severity Location Status

Coding Style Informational contracts/reva/ReVault.sol (revault): 340, 345 Resolved

Description
The function that affects the status of sensitive variables should be able to emit events as notifications.

setProfitToReva()

setProfitToRevaStakers()

Recommendation
Consider adding events for sensitive actions, and emit them in the function.
 Revault Security Assessment

RVC-09 | Variables Should Be Initialized In initializer

Category Severity Location Status

Volatile Code Minor contracts/reva/ReVault.sol (revault): 39~40 Resolved

Description
ReVault is an upgradeable contract, there are initial values in field declarations.

Recommendation
We recommend setting all initial values in an initializer function.
 Revault 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.

Control Flow
Control Flow findings concern the access control imposed on functions, such as owner-only functions
being invoke-able by anyone under certain circumstances.

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

Language Specific
Language Specific findings are issues that would only arise within Solidity, i.e. incorrect usage of private or
delete.

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

 Revault Security Assessment

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.
 Revault 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
 Revault 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
 Revault 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.
 Revault 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.