Giter VIP home page Giter VIP logo

crowdsale's Introduction

Crowdsale and Token Details

SOLID Token Details

  • ERC20 mintable token

  • 18 decimal places

  • 1 Solid token = 0.015 ETH

  • Total max supply: 4,000,000 SOLID tokens

6-month non-transferable period on all tokens, from the end of the main sale.

Sale Details

Sale

  • Total cap for sale to be 2,400,000 SOLID tokens.
  • Length: 3 months

Discount Period

  • Cap of 1,200,000 SOLID tokens (30% of the total supply)
  • Duration: max 1 month
  • Discount: 20%

General Rules

  • Targeted at auditors, Ethereum projects, developers and security experts
  • No Soft Cap (no Refunds).
  • No Token Burning
  • Minimum Participation: 0.5 ETH
  • Maximum Participation: 100 ETH
  • Funds are sent to a multisig ETH
  • Auction type: static price
  • Only ETH is accepted
  • KYC whitelisted addresses only

After both sales are finished: The total supply is determined by how much we sell during sale (which will represent 60% of the existing tokens)

Afterwards tokens will be minted to:

  • Team Fund (20% of total supply) Vesting: 1 year cliff, 3 year total.
  • Community & Audit Training Fund (10% of total supply)
  • Liquid Reserve (5% of total supply)
  • Partners (4% of total supply)
  • Airdrops (1% of total supply)

Whale protection: Combination of maximum participation limit and KYC’d addresses.

Edge Cases: Last transaction for sale should get refunded whatever it sent over.

Intended Behavior

The sale is based on the Open Zeppelin framework, with a few additions, the biggest one being stages, because there will be multiple phases.

  1. Sale is deployed with SETUP.
  2. After configuration the sale moves to READY.
  3. When the start date arrives the sale should go to DISCOUNT(either by calling updateStage or making a purchase), since it's resolved in timedTransition
  4. The DISCOUNT stage ends when either the cap is reached or the endTime arrives.
  • If the cap is reached the stage will move during the last transaction in the _postValidatePurchase
  • If the time is reached, the transition must happen in updateStage, since making a purchase will revert the stage.
  • If the sale enter the state where the cap haven't been reached but the remaining amount is less than the minimum purchase, the transition should happen in updateStage;
  1. The MAINSALE should start when the time arrives, either by calling updateStage or making a purchase.
  2. The MAINSALE stage ends when either the cap is reached or the endTime arrives.
  • If the cap is reached the stage will move during the last transaction in the _postValidatePurchase
  • If the time is reached, the transition must happen in updateStage, since making a purchase will revert the stage.
  • If the sale enter the state where the cap haven't been reached but the remaining amount is less than the minimum purchase, the transition should happen in updateStage;

The other meaningful addition is the changeDue and capReached variables.

The change is needed when a purchase is overpaid, either when a buyer sends more than the personal cap or more than what is available. This should be calculated in _preValidatePurchase and saved in the storage to be transferred back to the buyer in the _postValidatePurchase.

All the sale parameters should be increased considering only the accepted amount.

Lastly, there's the added mechanism for minting and distributing the non-sale tokens. The values will be harcoded in the Distributable.sol with percentages. When the sale is finalized the tokens will be distributed following the rules:

  • The amount sold in both sale stages will be 60% of the total Tokens
  • The other addresses percentages must account up to 40%
  • If a given address has rights to 5%, it means that it will receive 5% of the total tokens (even if not all of them are minted yet);
Note on units

Given the solidity restriction to floating point numbers, some variables are considered differently.

  • The rate will be divided by 1000. A rate of 15 actually means 0.015. This is considered in the contracts
  • The percentages will be divided by 10. A percentage of 14 means 1.4%

Known Weaknesses

  • In overpaid transactions that require change, the TokenPurchase event will be emitted with the wrong value(but correct token amount).
  • Keeping the changeDue variable in storage makes the purchase a bit more expensive gas-wise

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.