fundrequest / contracts Goto Github PK

Context

During the public token sale whitelisted participants will be able to transfer ETH to the FundRequest token sale contract and receive FND tokens in exchange.

The goal of this story is to implement the functions of the token sale contract that are needed during the token sale.

Flow of events of buying FND tokens

1. The user sends ETH to the token contract.
2. The token contract checks is the contract is pauzed (if so, the transaction fails).
3. The token contract checks if the total hard cap is not reached (if so, the transaction fails).
4. The token contract checks if the sending ETH address is whitelisted (if not, the transaction fails).
5. If it is the first/capped round of the public token sale
   • then the token contract checks the amount of ETH against the max. cap per person and against the ETH that was already transferred from this address. (if the max. cap is exceeded the transaction fails).
6. The token contract sends the ETH to the FundRequest MultiSig wallet.
7. The token contract mints the tokens: 1.800 FND / ETH
8. The token contract assigns the FND to the ETH address from which the ETH were send.

Extra Functions

Pause / Unpause

It has to be possible to pause and unpause the token sale contract.

• Only a FundRequest address can call this function.
• When the contract is paused, it is not possible to transfer ETH to the token sale contract.

Whitelist an ETH address

The token sale contract contains a list of whitelisted ETH addresses. It has to be possible to add an extra address.

Set max cap per person

In the first round of the public token sale there will be a max cap per person. It is not allowed to transfer more .

End first/capped round

When the first round is ended and a user transfers ETH, there will not be checked on max. cap per person when a user transfers ETH. A person can transfer any amount of ETH to the token contract as long as it does not make the hard cap exceed.

Set hard cap

There is a hard cap. As soon as this hard cap is reached it will no longer be possible to transfer any ETH to the token contract.

Note that the user can make multiple transfers from his contract. The sum of the ETH has to be compared to the personal cap.

Test cases

See attachement.

When funding we currently check the available tokens based on the platform, owner, repo and the issuenumber.
It would be better if it would only be platform, owner and repo, this would be more performant to cache (see FundRequest/platform#475)

Create a travis configuration for this solidity-based repository, so we can have a decent CI

Expected behavior

Only the active environment property is used

Actual behavior

sometimes the wrong property is shown when the property was overridden by a specific environment file (ex. production:)

Should not contain kovan

Allow a request to be funded with Ether.

• use 0x00eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee as Ether token address

Expected behavior

require(multisigWallet != address(0));

require(startsAt <= endsAt);

function() payable {
revert();
}

Actual behavior

if(multisigWallet == 0) {
    throw;
}

if(startsAt >= endsAt) {
    throw;
}

function() payable {
throw;
}

Steps to reproduce the behavior

Context

We want cryptoprojects that have their own ERC-20 token to be able to fund issues in their own ERC-20 token. Though the use of en ERC-20 token is limited to the repositories of the project itself.

• add configuration to smart contract
• delete configuration from smart contract
• check when funding is placed on an issue if the token is allowed
• adapt Azrael to cope with multiple ERC-20 tokens

Actual behavior

Currently it is only possible to fund an issue in FND tokens

Desired behavior

Link between Github Repository and ERC-20 token

An admin has to be able to link Github repositories with an ERC-20 token in the FundRequest smart contract. Only when this link exists the user can use the specified ERC-20 token to fund issues in the specified GitHub repository.

And admin can also remove the link between an ERC-20 token and a Github repo from the FundRequest smart contract.

The FND token can always be used to fund an issue in any Github repository!

Check when an issue is funded

Whenever the FundRequest platform smart contract receives a call to fund an issue in another token as the FND token the contract checks if it is allowed to fund this issue with the ERC-20 token that is sent. If the configuration allows the use of the token the transaction succeeds, else the transaction fails.

Flow of events

1. The user uses a non FND token to fund a Github issue.
2. The platform contract checks if the token is allowed for this repository according to the contract specifiation
3. If the contract specification is available:
   3.1 Then the transaction succeeds;
   3.2 Else the transaction fails.

Test cases

• Testcase: An entry is registered to allow a specific ERC-20 token on a github repo. A funder add funds in that ERC-20 token.
  • Result: The funding is added to the issue. The backend is notified by Azrael.
• Testcase: A funder adds funding to an issue. The ERC-20 token is not allowed on the repository
  • Result: the funding transaction fails.
• Testcase: An entry is removed to allow a specific ERC-20 token on a github repo. A funder add funds in that ERC-20 token.
  • Result: the funding transaction fails.

Expected behavior

Actual behavior

Steps to reproduce the behavior

Expected behavior

Approve works

Actual behavior

approve does not work when current approve balance > 0

Steps to reproduce the behavior

• approve x FND
• approve y FND

Context

The tokens will already be generated and distributed to participants to the presale. The token contract will thus have to support multiple funding rounds. To support this the presale contract will need to have a number of functions.

Functions

• Whitelist an address:
  • Only whitelisted addresses can transfer ETH to the contract. Other transfers fail.
  • When whitelisting an address the ETH address, the amount of tokens / ETH and the percentage of tokens to be vested are

Testcases

When trying to refund following issues, the transaction fails:

• https://tst1.fundrequest.io/requests/8 (https://kovan.etherscan.io/tx/0x09a3748dd05a841e73ea8decd3e2c7b0063f318e76a7ae73143bd0c7a921f7e8)
• https://tst1.fundrequest.io/requests/36 (https://kovan.etherscan.io/tx/0xd1e2e149dbd0d740ba5c0030e2dce2e98c07f68ae3d50e5bee8751670eed3c57)
• https://tst1.fundrequest.io/requests/17 (https://kovan.etherscan.io/tx/0x01f7b15a0ecb950d153eff3cfcb1ed58ffd2400d81ff1460ae5082527e5c94c2)

Expected behavior

balances[_from] = balances[_from].sub(_value);
balances[_to] = balances[_to].add(_value);
allowed[_from][msg.sender] = _allowance.sub(_value);

Actual behavior

balances[_to] = balances[_to].add(_value);
balances[_from] = balances[_from].sub(_value);
allowed[_from][msg.sender] = _allowance.sub(_value);

Steps to reproduce the behavior

Reorder these lines as substraction should always come before the addition to make your code more secure against re-entrancy attacks.
Also, please make sure that this correctly done in other functions.
Good example:
https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol

Expected behavior

Actual behavior

Steps to reproduce the behavior

Expected behavior

Actual behavior

Steps to reproduce the behavior

https://github.com/fravoll/solidity-patterns/blob/master/EternalStorage/EternalStorage.sol

--> implement fundrepository/claimrepository

    function removePrecondition(uint _index) external onlyOwner {
        delete preconditions[_index];
    }

Expected behavior

Removed item from the array

Actual behavior

Empty gap

Steps to reproduce the behavior

Try to add and then remove the precondition. The size of an array does not change after removal.

As there is a function that iterates over this array:

for (uint idx = 0; idx < preconditions.length; idx++) {
            ....
}

If the array grows very large, the loop could exceed the block gas limit and fail.

Hello there
I have noticed there is (Broken Authentication and Session Management) bug in your website.

POC:
Steps:
We have to use two browser (Browser A) and (Browser B)

1 : Open (Browser A) and go to "https://key.fundrequest.io/auth/realms/fundrequest/protocol/openid-connect/auth?response_type=code&client_id=fundrequest_dev&redirect_uri=https%3A%2F%2Ffundrequest.io%2Fsso%2Flogin&state=efff0a99-79e7-4c60-a883-12ebaeb384e7&login=true&scope=openid" and login your " fundrequest" account with your valid email and password.

2 : Open (Browser B ) and (Similarly) go to "https://key.fundrequest.io/auth/realms/fundrequest/login-actions/reset-credentials?client_id=fundrequest_dev&tab_id=M58shjzspTU&response_type=code&client_id=fundrequest_dev&redirect_uri=https%3A%2F%2Ffundrequest.io%2Fsso%2Flogin&state=efff0a99-79e7-4c60-a883-12ebaeb384e7&login=true&scope=openid" and get a  password reset token .

3 : Suppose (Browser A is an shared computer's browser, and you left your account logged in at that computer. Then you changed your account password from (Browser B). By getting a password reset token link Now Go to (Browser B) and change your account password.

Step 4 : When you change your account password at (Browser B) , the session at (Browser A ) should expire and the account should automatically logged out.

Step 5 : Go to (Browser B ) , and visit your account page and refresh the page.
**You will notice that even after changing the account password at (Browser B) , the session at (Browser A) didn't expired which can cause major problems. And also after that you can change user information's.

Impact
Authentication and session management includes all aspects of handling user authentication and managing active sessions. Authentication is a critical aspect of this process, but even solid authentication mechanisms can be undermined by flawed credential management functions, including password change, forgot my password, remember my password, account update, and other related functions. Because “walk by” attacks are likely for many web applications, all account management functions should require re-authentication even if the user has a valid session id.

Expected behavior

Actual behavior

Steps to reproduce the behavior

Expected behavior

uint8 public decimals;

Actual behavior

uint public decimals;

Steps to reproduce the behavior

The ERC20 standard specifies that decimals should be of type uint8.
More: https://theethereum.wiki/w/index.php/ERC20_Token_Standard

P.S. also don't forget to change it in the constructor.

Callable is now duplicated across ClaimRepository and FundRepository. Move this to a separate class.

• KYC integration
  • Just Whitelisting
• Hard Code Private Presale allocation
• Hard Code public Presale allocation
• Previously allocated Tokens implementation [details needed]
• Vesting + Cliff

Add refund functionality

Context

Seed and presale participants will receive their tokens prior to the token sale so it is possible to already generate and use the tokens for ecosystem incentivization.

The ETH of the seed participants is already received, the ETH or FIAT of the presale participants will also be received before the public token sale.

Flow of events

1. A FR member calls the method assignTokens on the token sale contract with the parameters: beneficiary address, amount of FND tokens, percentage (0% - 25% or 50%) to be vested.
2. The token sale contract mints the tokens.
3. The token sale contract calculates the amount of FND tokens that can be assigned to the beneficiary address and the amount of tokens that have to be vested.
4. The token sale contract assigns the calculated amount of FND tokens to the beneficiary address.
5. The token sale contract assigns the calculated amount of FND tokens to the vesting wallet with a vesting period and cliff of 6 months.

Additional info

Calculations

Calculation of FND tokens to be vested:

FND tokens to be vested = amount of FND tokens * percentage to be vested.

Calculation of FND tokens to be assigned to beneficiary address

FND to assign to beneficiary address = amount of FND tokens - FND tokens to be vested

Vesting

The tokens that have to be vested are assigned to the vesting wallet and can be withdrawn after a period of 6 months by the beneficiary address.

Testcases

• Testcase: A a FR member I call the assignTokens function with a beneficiary address, 100 FND and 25% vesting.
  • Result: 75 FND are assigned to the beneficiary address, 25 FND to the vesting wallet with a vesting period and cliff of 6 months.
• Testcase: A a FR member I call the assignTokens function with a beneficiary address, 100 FND and 50% vesting.
  • Result: 50 FND are assigned to the beneficiary address, 50 FND to the vesting wallet with a vesting period and cliff of 6 months.
• Testcase: A a FR member I call the assignTokens function with a beneficiary address, 100 FND and 0% vesting.
  • Result: 100 FND are assigned to the beneficiary address, 0 FND to the vesting wallet.
• Testcase: A a FR member I call the assignTokens function with a beneficiary address, 100 FND and 10% vesting.
  • The transaction fails.
• Testcase: A a FR member I call the assignTokens function with not all parameters
  • The transaction fails.
• Testcase: Another person as a FR member calls the assignTokens function with a beneficiary address, 100 FND and 0% vesting.
  • The transaction fails.

Expected behavior

Actual behavior

Steps to reproduce the behavior

Context

During the presale and the public tokens sale the donators will receive FND tokens in exchange for the ethers they have donated. The functionality to do so is developed in previous stories.

When the FND for a donator are generated and transfered to his account, the mint agent also has to mint extra FND tokens to assign to the different allocations. The generation and allocation of these extra tokens is the scope of this user story.

Flow of events

1. A donator transfers ETH to the token sale contract.
2. The mint agent generates the FND for the donator and assigns them to the donator's address.
3. The mint agent generates tokens for ecosystem incentivisation and assigns them to the corresponding address.
4. The mint agent generates tokens for cold storage and assigns them to the corresponding vesting wallet (vesting over 2 years, 2 year cliff).
5. The mint agent generates tokens for the advisors and assigns them to the corresponding vesting wallet (vesting over 6 months, 3 month cliff).
6. The mint agent generates tokens for the team and assigns them to the corresponding vesting wallet (vesting over 2 years, 6 month cliff).

Alternative flow

When the assignTokens() function on the token sale contract is called, step 3 to 6 also have to be executed.

Token allocation

• 40% to donator
• 30% to ecosystem incentivisation
• 10 % to cold storage
• 2% to advisors
• 18% to team

Allocation of 1 ETH

During the token sale for every ETH transferred to the token sale contract to following allocations are made:

• 1800 FND for the donator
• 1350 FND for ecosystem incentivisation
• 450 FND for cold storage
• 90 FND for the advisors
• 810 FND for the team
  The allocations are relative to the amount of ETH transferred.

Allocation for assignTokens(4500)

When the function assignTokens() is called with for example 4500 FND tokens assigned to the donator, the allocation is as follows:

• 4500 FND for the donator
• 3375 FND for ecosystem incentivisation
• 1125 FND for cold storage
• 225 FND for the advisors
• 2025 FND for the team
  The allocations are relative to the amount of tokens assigned.

If we deploy a new version of the token, we need to give everyone new tokens that can be used in the alpha environment.

Next to the token, if we're deploying on rinkeby, also deploy a faucet contract.

functional requirements:

• The faucet contract needs to be a mintAgent.
• when calling the default function of the faucet, a user needs to receive 100 FND tokens

In the past, we chose for the TokenMarket model.

In this spike, we'll create the entire token model, including existing crowdsale contract using the Minime architecture.

• Rewrite entire architecture using minime

• Write Blogpost about our differences

• Choose our own architecture based on the findings

Description

As FundRequest we want our community to audit the FundRequest contracts to make sure we get the best audit possible.

Scope of Ticket

• Only FundRequest platform contracts:
  https://github.com/FundRequest/contracts/tree/master/contracts/platform

• Find a Major security breach

A major security breach qualifies as an issue in the FundRequest production code base that can cause: 
- a loss of funds;
- a loss of control over the smart contracts;
- an outage of the production environment;

Reward

The first reward is $10 000 in FundRequest tokens (FND), for each subsequent major security issue the bounty is lowered by $1 000 in FundRequest tokens (FND).

Precondition

• The auditor must be logged into fundrequest
• The auditor must have experience in Solidity, Code Review & auditing

Flow: Create Pull Request

• Create a new issue in this repository
• Edit
  https://github.com/FundRequest/contracts/blob/develop/vulnerabilities.md
• Add your name as an auditor
• Describe the security breach using the example template
  
• Create a pull request with a reference to the GitHub issue you created, this will be used by the FundRequest platform. (How to reference an issue in a GitHub Pull request?)
• FundRequest administrator(s) will review the pull request and validate the reported issue

Postcondition

• The auditor succesfully created a ticket and pull request
• The FundRequest team has successfully reviewed the pull request and funded the issue with $10,000 (or less) in FND tokens (price of FND)
• The FundRequest team merges the pull request
• The auditor can claim the funds once the platform is live (May 2018)

Acceptance criteria

• The reported issue is considered a major security breach as stated in the ticket
• The security breach has to be unique.
• The first person reporting the breach will be awarded the bounty.
• The timestamp of the pull request will be used to define the first person who reported the security breach.
• The bug may only be reported in this the FundRequest Github repository and cannot be made public on other platforms/media without the consent of the FundRequest team.
• Determinations of eligibility, rewards and all terms related to an award are at the sole and final discretion of the FundRequest team.
• The issue is reported before June 2018

FundRequestToken should have an abstraction above it. The only thing this abstraction should be able to do is identify if the token is indeed a FundRequestToken.

This seperates the FundRequestContract code with the actual Token Model.

Context

The FND token contract keeps track of the FND token balances on the ethereum accounts. Before the token sale only addresses that are whitelisted are allowed to transfer tokens and only to the FundRequest Platform Contract. The FundRequest Platform Contract can transfer tokens to any address.

Additional information

The FND token contract must contain a parameter (allowAnyTransfer) that enables/disables the possibility to transfer tokens between any ethereum address:

• By default this parameter is set to false
• If the parameter is false ethereum addresses (expect the FundRequest Platform Contract) can only transfer FND if they are whitelisted and they can only transfer to the Platform Contract address.
• The platform contract can transfer FND to any ethereum address.
• There is a function that allows to change this parameter that can only be called by a FundRequest account.
• When the parameter is set to true, all transfers of FND between any address are allowed.

A function is available to whitelist an ethereum address. This function can only be called by a FundRequest account.

Testcases

• Testcase: A user transfers FND to the Platform contract, allowAnyTransfer=false, the user his address is not whitelisted.
  • Result: The FND are not transferred.
• Testcase: A user transfers FND to the Platform contract, allowAnyTransfer=false, the user his address is whitelisted.
  • Result: The FND are transferred.
• Testcase: A user transfers FND to another address as the Platform contract, allowAnyTransfer=false, the user his address is whitelisted.
  • Result: The FND are not transferred.
• Testcase: A user transfers FND to another address as the Platform contract, allowAnyTransfer=false, the user his address is not whitelisted.
  • Result: The FND are not transferred.
• Testcase: A user transfers FND to the Platform contract, allowAnyTransfer=true, the user his address is not whitelisted.
  • Result: The FND are transferred.
• Testcase: A user transfers FND to another address as the Platform contract, allowAnyTransfer=true, the user his address is not whitelisted.
  • Result: The FND are transferred.
• Testcase: A user transfers FND to another address as the Platform contract, allowAnyTransfer=true, the user his address is not whitelisted.
  • Result: The FND are transferred.
• Testcase: The Platform Contract transfers FND to another address as the Platform contract, allowAnyTransfer=false.
  • Result: The FND are transferred.
• Testcase: The Platform Contract transfers FND to another address as the Platform contract, allowAnyTransfer=true.
  • Result: The FND are transferred.

Expected behavior

During the Crowdsale it shouldn't be possible to transfer the ownership, otherwise, it could not go well.

Actual behavior

// Create initially all balance on the team multisig
balances[owner] = totalSupply;

Steps to reproduce the behavior

#5
#6
#7
#8

As part of the upgradability, we want to be able to migrate tokens on the Fundrequestcontract to a new Fundrequestcontract.

db.setUint(keccak256("claims.count"), db.getUint(keccak256("claim.count")).add(1));

Expected behavior

The count of claims should be incremented by 1.

Actual behavior

The count of claims stays at 1 forever. Indeed, the incorrect key is used to retrieve the basis to be incremented by 1. It should be "claims.count" on both sides. I recommend using enums to flag this at compilation time.

Steps to reproduce the behavior

Call addClaim several times. Then call getClaimCount: il will not have evolved.

Description

As FundRequest we want our community to audit the FundRequest contracts to make sure we get the best audit possible.

Scope of Ticket

• Only FundRequest platform contracts:
  https://github.com/FundRequest/contracts/tree/master/contracts/platform

• Find a minor security breach

A minor security breach qualifies as an issue in the FundRequest production code base that is not a major security breach and can cause: 
- a loss of data;
- corruption of data;

Reward

Each unique minor security breach is rewarded with $250 in FundRequest tokens (FND)

Precondition

• The auditor must be logged into fundrequest
• The auditor must have experience in Solidity, Code Review & auditing

Flow: Create Pull Request

• Create a new GitHub issue in this repository
• Edit
  https://github.com/FundRequest/contracts/blob/develop/vulnerabilities.md
• Add your name as an auditor
• Describe the security breach using the example template
  
• Create a pull request with a reference to the GitHub issue you created, this will be used by the FundRequest platform. (How to reference an issue in a GitHub Pull request?)
• FundRequest administrator(s) will review the pull request and validate the reported issue

Postcondition

• The auditor succesfully created a ticket and pull request
• The FundRequest team has successfully reviewed the pull request and funded the issue with $250 in FND tokens (price of FND)
• The FundRequest team merges the pull request
• The auditor can claim the funds once the platform is live (May 2018)

Acceptance criteria

• The reported issue is considered a minor security breach as stated in the ticket
• The security breach has to be unique.
• The first person reporting the breach will be awarded the bounty.
• The timestamp of the pull request will be used to define the first person who reported the security breach.
• The bug may only be reported in this the FundRequest Github repository and cannot be made public on other platforms/media without the consent of the FundRequest team.
• Determinations of eligibility, rewards and all terms related to an award are at the sole and final discretion of the FundRequest team.
• The issue is reported before June 2018