Merge pull request #158 from MyBitFoundation/develop

Develop

README.md

@@ -11,27 +11,27 @@
 
 A software development kit for the automated machine economy.
 
-The SDK's contain a local blockchain and smart-contracts for developers to run and deploy dapps that allow for the funding and distribution of virtual assets represented by ERC tokens on the Ethereum blockchain. The contracts can be combined in different ways to customize the crowdfunding and re-distribution details, or plug into a local MyBitChain to test already operating assets. 
+The SDK's contain a local blockchain and smart-contracts for developers to run and deploy dapps that allow for the funding and distribution of virtual assets represented by ERC tokens on the Ethereum blockchain. The contracts can be combined in different ways to customize the crowdfunding and re-distribution details, or plug into a local MyBitChain to test already operating assets.
 
 ## Getting Started
 
-## Roles 
-The tokenized asset management structure is made up of different actors who have specific incentives to participate in the creation and management of tokenized assets within the ecosystem. The assets are managed by the broker, who receives a fee for his work and escrows tokens as collateral to investors. The tokens remain in escrow until the asset tokens returns sufficient income. The platform owners can choose how assets are governed, whether by asset token holders or designated ownership roles.  
+## Roles
+The tokenized asset management structure is made up of different actors who have specific incentives to participate in the creation and management of tokenized assets within the ecosystem. The assets are managed by the AssetManager, who receives a fee for his work and escrows tokens as collateral to investors. The tokens remain in escrow until the asset tokens returns sufficient income. The platform owners can choose how assets are governed, whether by asset token holders or designated ownership roles.  
+
+AssetManagers interact with the AssetManagerEscrow, AssetManagerFunds and Crowdsale Generators contracts, while Investors interact with the Crowdsale and DividendTokens contracts.
 
 #### Platform Owner(s)
-The owners of the platform are in charge of deciding high level upgrades and authorization changes made in the platform. Ownership can be decided by one owner, a multi-sig, or token holders themselves. 
+The owners of the platform are in charge of deciding high level upgrades and authorization changes made in the platform. Ownership can be decided by one owner, a multi-sig, or token holders themselves.
 
-#### Investor 
+#### Investor
 The investor is any user that holds asset tokens through participating in an asset crowdsale or by means of purchasing them on an exchange.
 
-#### Broker 
-The Broker is a user that initiates a crowdfunding period for an asset. After the funding period, the Broker is in charge of handling real world operations between the asset operator and the investors. The role of the Broker varies depending on the type of asset, but they are responsible for the asset operating properly if the conditions allow it. The Broker can put down tokens in escrow, which is at stake to get burned if the owners of the asset find negligence. 
+#### AssetManager
+The AssetManager is a user that initiates a crowdfunding period for an asset. After the funding period, the AssetManager is in charge of handling real world operations between the asset operator and the investors. The role of the AssetManager varies depending on the type of asset, but they are responsible for the asset operating properly if the conditions allow it. The AssetManager can put down tokens in escrow, which is at stake to get burned if the owners of the asset find negligence.
 
 #### Operator
-The operator is the producer of the asset, physical or digital. They are in charge of receiving the crowdfunding funds and producing, delivering and installing the asset. Brokers will deal with Operators to ensure continued functioning of the asset. 
+The operator is the producer of the asset, physical or digital. They are in charge of receiving the crowdfunding funds and producing, delivering and installing the asset. AssetManagers will deal with Operators to ensure continued functioning of the asset.
 
-#### StakeHolders 
-The Stakeholders have the opportunity to purchase a portion of the Brokers earnings in exchange for depositing escrow in the place of the Broker. The Stakeholders will agree on a contract address for Broker fees to get sent and split according to the arrangement between Brokers and Stakeholders. 
 
 ✏️ All contracts are written in [Solidity](https://solidity.readthedocs.io/en/v0.4.24/) version 0.4.24.
 
@@ -52,8 +52,6 @@ Run tests
 
 `yarn test`
 
-✏️ All contracts are written in [Solidity](https://solidity.readthedocs.io/en/v0.4.24/) version 0.4.24.
-
 ## Compiling
 
 `yarn compile`
@@ -87,14 +85,14 @@ GIT_USER=<GIT_USER> \
 ```
 
 
-# Live example test-net contracts 
+# Live example test-net contracts
 * [InitialVariables](https://ropsten.etherscan.io/address/0x9e6606dedcf9d4960f8652abe2d624a048231841#code)
 * [UserAccess](https://ropsten.etherscan.io/address/0xb14c50bb7530c71e14f28498bad1f65d10b5b3a9#code)
 * [API](https://ropsten.etherscan.io/address/0x139ebd700b089f51a9dd90c0403e5326b1426f3b#code)
 * [AssetCreation](https://ropsten.etherscan.io/address/0x011d426358f1982e327648506d3fdae01d054297#code)
 * [FundingHub](https://ropsten.etherscan.io/address/0xb94bd7c5ca000beeff27db7cebb9c03749901f19#code)
 * [MyBitToken](https://ropsten.etherscan.io/address/0xbb07c8c6e7cd15e2e6f944a5c2cac056c5476151#code)
-* [TokenFaucet](https://ropsten.etherscan.io/address/0x8742272c58f6fe0c2943eba9399c04cbd5342ab2#writeContract)
+* [TokenFaucet](https://ropsten.etherscan.io/address/0x564a7464b6ea98259aae1ad4aa8a11ca9b502cf8#code)
 
 ### ⚠️ Warning
 This application is unstable and has not undergone any rigorous security audits. Use at your own risk.

accounts.json

@@ -0,0 +1,12 @@
+[
+    "0x13c1cb47836fd4875e4fb0b44627a1ed0babf0b8",
+    "0xf76f915ae32ad19fd4359b0d1a56328f7beef8be",
+    "0x0dfb69ce3123487acdd8c6e3ab2e4ce8655b6a6c",
+    "0xb798b6b56024329e03b211db4c47007a3005eb68",
+    "0x14a89c951a59131d3e61339501f4a95cf1190efd",
+    "0x62bcf293e78716718bb79db862dae9ad918e0069",
+    "0xd72eb39df4b7d974c114f152c90c1919deed3fcc",
+    "0xc1334b27495bd3edba0815a2b96cab50d4abc3a1",
+    "0xc513d4bfd54602a931ed0ac7b160c694316e7ec8",
+    "0x4e8eaf8efa38c6ee6dd0fb1f11def4e6b89c3415"
+]

addresses.json

@@ -1,17 +1,18 @@
 {
-    "MyBit": "0x10ba0d4c2c7595ae432df40ade94eb12478dcc62",
-    "ERC20Burner": "0x2c35763a5f741c2c28729063849ed90d21b4b531",
-    "Database": "0x98c58fd3425769cc781db10e78871e7b9f374eb4",
-    "ContractManager": "0x354c94041017bfa144b35774211e46357b0ce444",
-    "SingleOwned": "0x66a8a37c680621bc3e8e628ee058b1b2b694fd6d",
-    "Pausible": "0xb5af519ca7d760f99a3ff2663caed179e869e7a5",
-    "AccessHierarchy": "0xd64d4bd78c1c7358f4714914ef3346585cdf68f8",
-    "PlatformFunds": "0xf338cc0647c26c59c57fba9ff9ee753ae36c6055",
-    "Operators": "0xf6ff2a4db825c684ba31af5b4cfb9c114c6bfaeb",
-    "BrokerEscrow": "0x02b83ec8d0f27993b48942b9070c528fd4750487",
-    "CrowdsaleETH": "0x86a589cf40e6d18e09e2b2cedb57aa2b78e424a2",
-    "CrowdsaleGeneratorETH": "0xae89c0e0121ced29ffb68823c066bbc5ec55b8ed",
-    "CrowdsaleERC20": "0x63c2e1f877ec19ddd60902586247ac6b609b3583",
-    "CrowdsaleGeneratorERC20": "0x875a2c93fc963c99dfeb4b516071b864859e02ac",
-    "AssetExchange": "0x2f1452f25d08b49c525b1efe40ef96012ce20c09"
+    "MyBit": "0x0c57ca00b9b0f2aff3e1c5113a7c1e51287112af",
+    "ERC20Burner": "0xecd561c23e5c92a4d26cbd27f287e5ba473f09e9",
+    "Database": "0x723d5ff1e50cc8dcec5a1e2971f5094f5887b048",
+    "ContractManager": "0x85e0c4b687c0c618ff662b17b89673b17b462fa0",
+    "API": "0x73b0545e6d872b4c904079eb1d8e9cc6c8f89773",
+    "SingleOwned": "0x6e79eb19081f2af35f05acf824f2bc9de34fb343",
+    "Pausible": "0x55a76d119817552795f74d3605508d8c36297696",
+    "AccessHierarchy": "0x63d36c6b8f53309c93b6c53966be526aa0ebec0e",
+    "PlatformFunds": "0xc1aa884796ace39a79ee275f9e2e06f9a33534c2",
+    "Operators": "0xf8762a3c840716a208d384de93211b16bcc7492b",
+    "AssetManagerEscrow": "0xf2ed6113851c6a8ad781d1af4044616d8c0f8c57",
+    "CrowdsaleETH": "0x25ec303b7e9a8aa5f2817ddb4cf13969bf785a7e",
+    "CrowdsaleGeneratorETH": "0x0df14b00baeab8428e7488c37f8154281704df73",
+    "CrowdsaleERC20": "0x85ce610be8878cc1c18a9c7cd3188f2b012f231c",
+    "CrowdsaleGeneratorERC20": "0xcea1a56634b6879f2ec6592375c1b29cbe237437",
+    "AssetExchange": "0x311224c4cf2ac2acd4009cf72d74fca5242a0987"
 }

contracts/README.md

@@ -8,16 +8,16 @@ MyBit SDK allows developers to create personalized platforms which create and di
 ## Contract Categories
 
 ### Access
-Access is where user access is managed. Access can be limited to users in a hierarchical manner that allows different users access to different functionality on the platform. Currently, access contracts are not implemented in the platform.
+Access is where user access is managed. KYC restrictions can be applied across the platform using KYC.sol. Requirements can be set here, restricting access to users who can probably burn platform tokens, or pay for a time-based subscription.  
 
 ### Crowdsale
-In the crowdsale folder you can find all the contracts involved in funding new assets, which subsequently create new ERC tokens which represent shares of the asset. The total supply of each asset is determined by the lowest denomination including 18 decimals.
+In the crowdsale folder you can find all the contracts involved in funding new assets. Funds can be received in either Ether or any ERC20 token the operator agrees to accept. Each base unit of the received tokens or Wei represent 1 share of the asset. The total supply of each asset is determined by the amount raised plus the Asset Managers fee.
 
 ### Database
 The database folder contains all contracts that abstract storage away from the logical 'front-end' contracts. When deploying the database, you can choose to have an upgradeable platform or a non-upgradeable. Write privileges to the database are determined by the contract manager, which is managed by the owner/owners of the platform.
 
 ### Ecosystem
-The ecosystem folder contains all the non-core contracts that are used for the onboarding of users, and the exchange, burning, and escrow of tokens.
+The ecosystem folder contains all the non-core contracts that are used for the on-boarding of non-platform assets, asset-exchange, staking, and platform payment and token controls. Before funding assets the platform-token and the platform-wallet need to be set.  
 
 ### Interfaces
 All interfaces that our contracts use to interact with other deployed contracts.
@@ -26,10 +26,13 @@ All interfaces that our contracts use to interact with other deployed contracts.
 Math contracts are helper libraries for performing arithmetic without worrying about overflows and underflows.
 
 ### Ownership
-Contracts for controlling the platform (such as updating or pausing contracts) by a single account or multiple accounts.
+Contracts for controlling the platform (such as updating or pausing contracts) by a single account, multiple accounts or ERC20 token holders. Investors holding asset-tokens can vote to choose or fire their current Asset Manager here.
+
+### Roles
+Asset Managers and Operators can control their funding preferences in the roles contracts. Asset Managers fees are held here to prevent them from transferring away the tokens.
 
 ### Test
 Contracts that are only used for local testing to ensure full code coverage of the platform contracts.
 
 ### Tokens
-Token contracts are used to represent fungible divisible assets. Tokens representing assets can be burnable, mintable, and can receive ETH, which is then distributed to holders according to their holdings.
+Token contracts are used to represent fungible divisible assets. Tokens representing assets can be burnable, mintable, governed, and can receive ETH or ERC20 tokens as payment. The payment is distributed to asset-token holders according to their holdings.

contracts/ecosystem/ERC20Burner.sol → contracts/access/ERC20Burner.sol

@@ -6,7 +6,7 @@ import "../interfaces/DBInterface.sol";
 /// @title A contract for burning ERC20 tokens as usage fee for dapps
 /// @author Kyle Dewhurst & Peter Phillips MyBit Foundation
 /// @notice Allows Dapps to call this contract to burn ERC20 tokens as a usage fee
-/// @dev This contract does not accept tokens. It only burns tokens from users wallets when approved to do so
+/// @dev This contract does not accept tokens. It only burns tokens from investors wallets to run platform functionality
 contract ERC20Burner {
 
   BurnableERC20 public token;  // The instance of the ERC20 burner contract
@@ -15,14 +15,14 @@ contract ERC20Burner {
 
   // @notice constructor: initializes database and the MYB token
   // @param: the address for the database contract used by this platform
-  // @param (address) _myBitTokenAddress = The MyBit token address
   constructor(address _database)
   public {
     database = DBInterface(_database);
     token = BurnableERC20(database.addressStorage(keccak256(abi.encodePacked("platformToken"))));
+    require(address(token) != address(0));
   }
 
-  // @notice authorized contracts can burn mybit tokens here if the user has approved this contract to do so
+  // @notice authorized contracts can burn mybit tokens here if the investor has approved this contract to do so
   // @param (address) _tokenHolder = the address of the mybit token holder who wishes to burn _amount of tokens
   // @param (uint) _amount = the amount of tokens to be burnt (must include decimal places)
   function burn(address _tokenHolder, uint _amount)
@@ -35,14 +35,6 @@ contract ERC20Burner {
     return true;
   }
 
-  function givePermission()
-  external
-  returns (bool) {
-   bytes32 currentState = database.bytes32Storage(keccak256(abi.encodePacked("currentState")));
-   database.setBool(keccak256(abi.encodePacked(currentState, msg.sender)), true);
-   return true;
-  }
-
   // @notice owners can set the cost of functionality on the platform here.
   // @dev _amount will be how many platformTokens are burned to call the method at _contractAddress
   // @param (bytes4) _methodID: the methodID of the function which is to require a burning fee
@@ -81,10 +73,10 @@ contract ERC20Burner {
     _;
   }
 
-  // @notice reverts if user hasn't accepted current contract state or if he doesn't ignore state changes entirely
-  modifier acceptedState(address _user) {
+  // @notice reverts if investor hasn't accepted current contract state or if he doesn't ignore state changes entirely
+  modifier acceptedState(address _investor) {
     bytes32 currentState = database.bytes32Storage(keccak256(abi.encodePacked("currentState")));
-    require(database.boolStorage(keccak256(abi.encodePacked(currentState, _user))) || database.boolStorage(keccak256(abi.encodePacked("ignoreStateChanges", _user))));
+    require(database.boolStorage(keccak256(abi.encodePacked(currentState, _investor))) || database.boolStorage(keccak256(abi.encodePacked("ignoreStateChanges", _investor))));
     _;
   }
 

contracts/access/KYC.sol

@@ -9,7 +9,7 @@ import './AccessHierarchy.sol';
 contract KYC is AccessHierarchy {
 
   constructor(address _database) public AccessHierarchy(_database){}
-    
+
   // @notice Owner can approve KYC for user
   function approveKYC(address _user)
   onlyOwner
@@ -18,7 +18,7 @@ contract KYC is AccessHierarchy {
     emit LogKYCApproved(msg.sender, _user);
   }
 
-  // Owner can approve KYC for user
+  // @notice Owner can approve KYC for user
   function revokeKYC(address _user)
   onlyOwner
   external  {

contracts/access/README.md

@@ -6,6 +6,9 @@ Authorization is where contracts restricting user access levels are stored. Add
 ### AccessHierarchy.sol
 Contract to allow the contract owner to manually adjust the access levels of users on the platform.
 
+### ERC20Burner
+To use certain investment functions of the platform, one must burn the platform tokens (such as MYB in the case of MYBit Go). The investor only needs to approve this contract to burn their tokens. Other contracts can then call this contract if they need to burn tokens to access functionality.
+
 ### Expirable.sol
 Extends AccessHierarchy.sol by letting user's access to the system expire after certain number of blocks. The number of blocks until expiration can be passed in the contstructor.