Request Network Token Launch Bug Bounty

Security is our top priority at the moment. We have been really commited to it and will continue to be.

We are pleased to announce that our code has been reviewed by the team of iExec, audited by Quantstamp, and audited by Clement Lesaege, CTO at Kleros. No vulnerability that would impact the token launch has been found.

Now that the audit has been completed, we are launching a bug bounty program. The bounty concerns only the smart contracts of the token launch.

The code is available here (commit: d493261): https://github.com/RequestNetwork/RequestTokenSale

Critical vulnerabilities will be awarded with up to $20 000, while major bugs will be awarded with up to $15 000.

Rules & Rewards

The rules of our bug bounty program are the same which applied to the Ethereum protocol: https://bounty.ethereum.org

• Issues that have already been submitted by another user or are already known to the Request Network team are not eligible for bounty rewards.
• Public disclosure of a vulnerability makes it ineligible for a bounty.
• The Request Network core development team, employees, and all other people paid by the Request Network project, directly or indirectly, are not eligible for rewards.
• The Request Network bounty program considers a number of variables in determining rewards. Determinations of eligibility, score, and all terms related to an award are at the sole and final discretion of the Request Network Foundation bug bounty panel.

The value of rewards paid out will vary depending on Severity. The severity is calculated according to the OWASP risk rating model based on Impact and Likelihood :

Reward sizes are guided by the rules below, but are in the end determined at the sole discretion of the Request Network Foundation bug bounty panel.

• Critical: up to $20 000
• High: up to $15 000
• Medium: up to $10 000
• Low: up to $2 000
• Note: up to $500

All bounty will be paid in Ethereum.

Scope

5 files are within the scope.

• ProgressiveIndividualCappedCrowdsale.sol
• RequestToken.sol
• RequestTokenSale.sol
• StandardCrowdsale.sol
• WhitelistedCrowdsale.sol

The files inside the folder base are from Open Zeppelin and have not been modified.

Informal Specification of the Contract

The token launch is open only to registered users. Every user has the same individual cap for the amount of Ether he can contribute. In the event, a capped number of tokens are offered (e.g. there is a hard cap for raised Ether).

In the first 24 hours, user contribution is limited by the individual cap. In the second 24 hours, the individual cap doubles. In the 24 hours thereafter, the individual cap doubles again etc.. until token supply is depleted.

Preminted tokens are allocated to 4 different addresses.

• 500000000 REQ (50%) are sent to the token launch contract
• 150000000 REQ (15%) are sent to the team vesting contract
• 150000000 REQ (15%) are sent to the foundation multisig wallet
• 200000000 REQ (20%) are sent to the early investors multisig wallet

Detailed Description

Overview of the flow

The start time of the token sale is denoted by T.

1. On T-5 days, we deploy RequestTokenSale.sol which will deploy also Requestoken.sol. Then, we list users for the whitelist. The listing is done by us with a standard private key. Upon deployment, preminted tokens are already distributed to 4 different addresses. We manually verify that preminted tokens were assigned to the correct addresses. Token transfers are enabled only for the early contributors multisig wallet, the foundation multisig wallet, and the token launch contract. We start to issue the token to the early contributor via the early contributors multisig wallet.
2. On T -3, we compute the individual cap and set it up on the blockchain thanks to the entry “RequestTokenSale/setBaseEthCapPerAddress()”
3. On T-1, baseEthCapPerAddress and the whitelist are not modifiable anymore. We check the cap and the whitelist.
4. On T, the event starts. At this point, users can participate according to the individual cap. It is possible to buy several times, as long as cap is not exceeded.
5. On T+1, the event continues but the individual cap is doubled.
6. On T+2, the event continues if the hard cap is not reached with the individual cap being doubled again.
7. On T+3, the event continues if the hard cap is not reached with the individual cap being doubled again.
8. On T+4, the token launch is over. We transfer the tokens that are not sold to the foundation multisig wallet with the entry RequestTokenSale.drainRemainingToken()
9. On T+7, tokens are tradable for everyone.

Per module description

The system has 2 modules : the token launch (RequestTokenSale.sol) and the token (RequestToken.sol)

The token launch (RequestTokenSale.sol)

Implemented in RequestTokenSale.sol.

It inherits from StandardCrowdsale.sol by Open Zeppelin with small changes (see REQUEST-NOTE in comments) providing the basic check for the token launch.

It inherits from CappedCrowdsale.sol by Open Zeppelin providing the hard cap.

It inherits from ProgressiveIndividualCappedCrowdsale.sol developped by Request, providing the progressive individual cap.

It inherits from WhitelistedCrowdsale.sol developped by Request, providing the whitelist mechanism.

It uses SafeMath.sol by Open Zeppelin.

The owner can list and delist users until the last 24h before the token launch. The owner can modify the individual base cap until the last 24h before the token launch.

Because we expect > 10k users, we must start uploading the users before we have a full list. For this reason we also have an optimized version of listing which can take an array as input.

The token (RequestToken.sol)

Implemented in RequestToken.sol. It inherits from StandardToken.sol by Open Zeppelin (ERC20 standard token) It inherits from Ownable.sol by Open Zeppelin It uses SafeMath.sol by Open Zeppelin

The token is fully compatible with the ERC20 standard, with the next addition:

The tokens become transferable 7 days after the token launch start, hence October 20th. To be more precise, only the token launch contract, the early contributors multisig wallet and the foundation multisig wallet are allowed to transfer tokens before that date.

More information

The bug bounty program starts now, and we encourage you to report the bugs as an issue on the Github repository. You can also email security@request.network. Anonymous submissions are welcome as well.