merge master

.travis.yml

@@ -1,21 +1,20 @@
 language: node_js
-
 node_js:
-  - "8"
-
+- '8'
 cache:
   directories:
-    - "node_modules"
+  - node_modules
 env:
-  -
-  - SOLIDITY_COVERAGE=true
+- 
+- SOLIDITY_COVERAGE=true
 matrix:
   fast_finish: true
   allow_failures:
-    - env: SOLIDITY_COVERAGE=true
+  - env: SOLIDITY_COVERAGE=true
 before_script:
-  - truffle version
+- truffle version
 script:
-  #- npm run lint
-  #- npm run lint:sol
-  - npm run test
+- npm run test
+notifications:
+  slack:
+    secure: W4FZSabLrzF74f317hutolEHnlq2GBlQxU6b85L5XymrjgLEhlgE16c5Qz7Emoyt6le6PXL+sfG2ujJc3XYys/6hppgrHSAasuJnKCdQNpmMZ9BNyMs6WGkmB3enIf3K/FLXb26AQdwpQdIXuOeJUTf879u+YoiZV0eZH8d3+fsIOyovq9N6X5pKOpDM9iT8gGB4t7fie7xf51s+iUaHxyO9G7jDginZ4rBXHcU7mxCub9z+Z1H8+kCTnPWaF+KKVEXx4Z0nI3+urboD7E4OIP02LwrThQls2CppA3X0EoesTcdvj/HLErY/JvsXIFiFEEHZzB1Wi+k2TiOeLcYwEuHIVij+HPxxlJNX/j8uy01Uk8s4rd+0EhvfdKHJqUKqxH4YN2npcKfHEss7bU3y7dUinXQfYShW5ZewHdvc7pnnxBTfhvmdi64HdNrXAPq+s1rhciH7MmnU+tsm4lhrpr+FBuHzUMA9fOCr7b0SQytZEgWpiUls88gdbh3yG8TjyZxmZJGx09cwEP0q7VoH0UwFh7mIu5XmYdd5tWUhavTiO7YV8cUPn7MvwMsTltB3YBpF/fB26L7ka8zBhCsjm9prW6SVYU/dyO3m91VeZtO/zJFHRDA6Q58JGVW2rgzO39z193qC1EGRXqTie96VwAAtNg8+hRb+bI/CWDVzSPc=

CHANGELOG.md

@@ -1,9 +1,31 @@
 # Changelog
 All notable changes to this project will be documented in this file.   
 
-## [Unreleased](https://github.com/PolymathNetwork/polymath-core_v2/compare/npm-publish-2...master)
+## [Unreleased](https://github.com/PolymathNetwork/polymath-core/compare/npm-publish-2...master)
 
-[__0.3.0__](https://www.npmjs.com/package/polymath-core_v2?activeTab=readme) __02-04-18__
+[__0.3.1__](https://www.npmjs.com/package/polymath-core?activeTab=readme) __06-04-18__
+
+## Added
+* Add `emit` keyword to emit the events.    
+* Two new variable is added at the time of registeration of ticker. `swarmHash` represents the off-chain data storage location on IPFS and `owner` It reperesent the ethereum address of the owner.       
+* `LogRegisterTicker` emits two more variable called `_swarmHash` and `_owner`.   
+* Two events are added in `GeneralPermissionManager` contract to facilitate the notifications for the UI end.
+          __`LogChangePermission`__ :Emit when permissions to a delegate get changed.    
+          __`LogAddPermission`__: Emit when delegate is added in permission manager contract.   
+* `getInstructions()` is a public function added into the factories contracts. Use to get the useful instructions about the corresponding factory.   
+* `_securityTokenRegistry` is more argument is added in __securityTokenV2__ contract. 
+
+## Changed
+* All contracts get migrated from solc version 0.4.18 to 0.4.21. 
+* Now symbols get stored in smart contract in uppercase instead of lowercase.    
+* Public variable `STRAdress` name in TickerRegistry smart contract changed to `strAddress`.   
+* Function `permissions()` name in all module factories get changed to `getPermissions()`.   
+* Function `delegateDetails()` name gets changed to `getDelegateDetails()` in GeneralPermissionManager contract.      
+* `STVersionProxy_001 & STVersionProxy_002` contract name changed to STVersionProxy001 & STVersionProxy002 respectively.   
+
+***
+
+[__0.3.0__](https://www.npmjs.com/package/polymath-core?activeTab=readme) __02-04-18__
 
 ## Added   
 * Multiple events are added to `ModuleRegistry` contract to facilitate the Logging of the operations.   
@@ -44,7 +66,7 @@ All notable changes to this project will be documented in this file.
 
 ***
 
-[__0.2.0__](https://www.npmjs.com/package/polymath-core_v2?activeTab=readme) __26-03-18__
+[__0.2.0__](https://www.npmjs.com/package/polymath-core?activeTab=readme) __26-03-18__
 
 ## Added      
 * ModuleRegistry contract will provide the list of modules by there types.  
@@ -93,3 +115,4 @@ All notable changes to this project will be documented in this file.
 * Remove the Delegable.sol, AclHelpers.sol, DelegablePorting.sol contracts. Now permission manager factory takes their place . * `delegates` mapping removed from the GeneralTransferManager.  
 
 
+

README.md

@@ -1,25 +1,122 @@
-[![Build Status](https://travis-ci.com/PolymathNetwork/polymath-core_v2.svg?token=rqsL7PsbwLxrskjYAHpq&branch=master)](https://travis-ci.com/PolymathNetwork/polymath-core_v2)
+[![Build Status](https://travis-ci.com/PolymathNetwork/polymath-core.svg?token=rqsL7PsbwLxrskjYAHpq&branch=master)](https://travis-ci.com/PolymathNetwork/polymath-core)
 <a href="https://t.me/polymathnetwork"><img src="https://img.shields.io/badge/50k+-telegram-blue.svg" target="_blank"></a>
 
 ![Polymath](Polymath.png)
 
-# Polymath core v2
+# Polymath Core
 
-The polymath core smart contracts provide a system for launching regulatory
-compliant securities tokens on a decentralized blockchain.
+The Polymath Core smart contracts provide a system for launching regulatory-compliant securities tokens on a decentralized blockchain. This particular repository is the implementation of a system that allows for the creation of ST-20-compatible tokens. This system has a modular design that promotes a variety of pluggable components for various types of issuances, legal requirements, and offering processes.
 
-# Polymath Core Smart Contracts
+
+# ST-20 Interface Overview
+## Description
+An ST-20 token is an Ethereum-based token implemented on top of the ERC-20 protocol that adds the ability for tokens to control transfers based on specific rules. ST-20 tokens rely on Transfer Managers to determine the ruleset the token should apply in order to allow or deny a transfer, be it between the issuer and investors, in a peer to peer exchange, or a transaction with an exchange.
+
+## How it works
+ST-20 tokens must implement a `verifyTransfer` method which will be called when attempting to execute a `transfer` or `transferFrom` method. The `verifyTransfer` method will determine whether that transaction can be completed or not. The implementation of `verifyTransfer` can take many forms, but the default approach is a whitelist controlled by the `GeneralTransferManager`.
+
+### The ST-20 Interface
+
+```
+contract IST20 {
+
+    // off-chain hash
+    bytes32 public tokenDetails;
+
+    //transfer, transferFrom must respect the result of verifyTransfer
+    function verifyTransfer(address _from, address _to, uint256 _amount) view public returns (bool success);
+
+    //used to create tokens
+    function mint(address _investor, uint256 _amount) public returns (bool success);
+}
+```
+
+
+# The Polymath Core Architecture
+The diagram below depicts a high-level view of the various modules, registries, and contracts implemented in Polymath Core:
+
+![alt text](https://github.com/PolymathNetwork/polymath-core/blob/master/docs/images/PolymathCore.png)
+
+## Components
+### SecurityToken
+SecurityToken is an implementation of the ST-20 protocol that allows the addition of different modules to control its behavior. Different modules can be attached to SecurityToken:
+- TransferManager modules: These control the logic behind transfers and how they are allowed or disallowed.
+By default, the ST (Security Token) gets a GeneralTransferManager module attached in order to determine if transfers should be allowed based on a whitelist approach. The GeneralTransferManager behaves differently depending who is trying to transfer the tokens.
+a) In an offering setting (investors buying tokens from the issuer) the investor's address should be present on an internal whitelist managed by the issuer within the GeneralTransferManager.
+b) In a peer to peer transfer, restrictions apply based on real-life lockups that are enforced on-chain. For example, if a particular holder has a 1-year sale restriction for the token, the transaction will fail until that year passes.
+- Security Token Offering (STO) modules: A SecurityToken can be attached to one (and only one) STO module that will dictate the logic of how those tokens will be sold/distributed. An STO is the equivalent to the Crowdsale contracts often found present in traditional ICOs.
+- Permission Manager modules: These modules manage permissions on different aspects of the issuance process. The issuer can use this module to manage permissions and designate administrators on his token. For example, the issuer might give a KYC firm permissions to add investors to the whitelist.
+
+### TickerRegistry
+The ticker registry manages the sign up process to the Polymath platform. Issuers can use this contract to register a token symbol (which are unique within the Polymath network). Token Symbol registrations have an expiration period (7 days by default) in which the issuer has to complete the process of deploying their SecurityToken. If they do not complete the process in time, their ticker symbol will be made available for someone else to register.
+
+### SecurityTokenRegistry
+The security token registry keeps track of deployed STs on the Polymath Platform and uses the TickerRegistry to allow only registered symbols to be deployed.
+
+### ModuleRegistry
+Modules allow custom add-in functionality in the issuance process and beyond. The module registry keeps track of modules added by Polymath or any other users. Modules can only be attached to STs if Polymath has previously verified them. If not, the only user able to utilize a module is its owner, and they should be using it "at their own risk".
+
+
+# Stepping through an issuance with the CLI Tool
+First, assure that you have [setup Polymath Core properly](#Setting-up-Polymath-Core).
+
+The CLI (Command Line Interface) ST-20 Generator tool is a wizard-like script that will guide technical users in the creation and deployment of an ST-20 token. The commands are operated from a *nix command prompt (unix or mac).
+
+To use it, make sure you are connected to a full ethereum node (or locally to Ganache-cli, a local private test network).
+You can run Parity with the following command to get started (make sure the node is fully synced before using the CLI tool):
+`parity --chain ropsten  --rpcapi "eth,net,web3,personal,parity" --unlock YOUR_ETH_ACCOUNT --password $HOME/password.file`
+
+1. Edit `demo/helpers/contract_addresses.js` to make sure scripts are pointing to the correct contract addresses
+2. On the terminal, run the following command: `npm run st20Generator`
+3. Follow the text prompts:
+    * You will be asked for a token symbol. Enter a new symbol to register or a symbol you have already registered.
+    * Enter a token name (long name seen by investors) to complete the token registration process. The token will be deployed to the blockchain.
+    * (Optional) If you want to issue tokens to an address you own, enter the address and then how many tokens you want to issue.
+    * Configure the Capped STO. Enter start and end times, the issuance cap, and exchange rate.
+4. Once the process is finished, you can run the `npm run st20generator` command again and enter the token symbol to see the STO's live-progress.
+
+## Whitelisting investors
+
+After starting the STO you can run a whitelist script to mass-update a whitelist of allowed/known investors.
+Make sure the `whitelist_data.csv` file is present in the demo folder.
+
+```
+node demo/whitelist TOKEN_SYMBOL
+```
+
+## Investing in the STO
+
+You can run the invest script to participate in any STO you have been whitelisted for.
+The script takes 3 parameters:
+- The token symbol for the STO you want to invest in
+- The account that will receive the tokens
+- How much ETH to send
+
+```
+node demo/invest TOKEN_SYMBOL BENEFICIARY ETHER
+```
+
+## Transferring tokens
+You can run the transfer script to transfer ST tokens to another account (as long as both are whitelisted and have been cleared of any lockup periods).
+- The token symbol of the ST you want to transfer
+- The account that will receive the tokens
+- How many tokens to send
+
+```
+node demo/transfer TOKEN_SYMBOL ACCOUNT_TO AMOUNT
+```
+
+
+# Setting up Polymath Core
 ## Ropsten
 
-- TickerRegistry:
-- SecurityTokenRegistry:
-- ModuleRegistry:
+- TickerRegistry: TBA
+- SecurityTokenRegistry: TBA
+- ModuleRegistry: TBA
 
 ## Setup
 
-The smart contracts are written in [Solidity][solidity] and tested/deployed
-using [Truffle][truffle] version 4.1.0. The new version of Truffle doesn't
-require testrpc to be installed separately so you can just do use the following:
+The smart contracts are written in [Solidity][solidity] and tested/deployed using [Truffle][truffle] version 4.1.0. The new version of Truffle doesn't require testrpc to be installed separately so you can just run the following:
 
 ```bash
 # Install Truffle package globally:
@@ -37,7 +134,8 @@ To test the code simply run:
 $ npm run test
 ```
 
-# Setting up Polymath Network
+
+# Extending Polymath Core
 
 1. Deploy ModuleRegistry. ModuleRegistry keeps track of all available modules that add new functionalities to
 Polymath-based security tokens.
@@ -50,7 +148,7 @@ Polymath-based security tokens.
 
 5. Deploy SecurityTokenRegistry. This contract is responsible for deploying new Security Tokens. STs should always be deployed by using the SecurityTokenRegistry.
 
-## Deploying Security Token Offerings (Only Network Admin)
+## Deploying Security Token Offerings (Network Admin Only)
 
 Security Token Offerings (STOs) grant STs the ability to be distributed in an initial offering. Polymath offers a few out-of-the-box STO models for issuers to select from and, as the platform evolves, 3rd party developers will be able to create their own offerings and make them available to the network.
 
@@ -62,22 +160,18 @@ To make an STO available for Issuers, first, deploy the STO Factory and take not
 
 Once the STO Factory has been registered to the Module Registry, issuers will be able to see it on the Polymath dApp and they will be able to add it as a module of the ST.
 
-# Using the CLI ST-20 Generator
+Note that while anyone can register an STO Factory, only those "approved" by Polymath will be enabled to be attached by the general community. An STO Factory not yet approved by Polymath may only be used by it's author.
 
-The CLI ST-20 Generator is a wizard-like script that will guide you in the creation and deployment of the ST-20 token.
 
-To use it, make sure you are connected to a full-node (or locally to Ganache-cli).
-1. Edit demo/ST20Generator.js to make sure it's pointing to the correct contract addresses
-2. On your terminal, run the following command: `node demo/ST20Generator`
-3. Follow the Command-line prompts
-
-### Styleguide
+# Code Styleguide
 
 The polymath-core repo follows the style guide overviewed here:
 http://solidity.readthedocs.io/en/develop/style-guide.html
 
-[polymath]: https://polymath.network
-[ethereum]: https://www.ethereum.org/
-[solidity]: https://solidity.readthedocs.io/en/develop/
-[truffle]: http://truffleframework.com/
-[testrpc]: https://github.com/ethereumjs/testrpc
+# Links    
+
+[Polymath](https://polymath.network)
+[Ethereum](https://www.ethereum.org/)
+[Solidity](https://solidity.readthedocs.io/en/develop/)
+[Truffle](http://truffleframework.com/)
+[Testrpc](https://github.com/ethereumjs/testrpc)

contracts/Migrations.sol

@@ -1,24 +1,27 @@
-pragma solidity ^0.4.18;
+pragma solidity ^0.4.21;
+
 
 contract Migrations {
-  address public owner;
-  uint public last_completed_migration;
 
-  modifier restricted() {
-    require (msg.sender == owner);
-    _;
-  }
+    address public owner;
+
+    uint public lastCompletedMigration;
+
+    modifier restricted() {
+        require(msg.sender == owner);
+        _;
+    }
 
-  function Migrations() public {
-    owner = msg.sender;
-  }
+    function Migrations() public {
+        owner = msg.sender;
+    }
 
-  function setCompleted(uint completed)public  restricted {
-    last_completed_migration = completed;
-  }
+    function setCompleted(uint _completed)public  restricted {
+        lastCompletedMigration = _completed;
+    }
 
-  function upgrade(address new_address)public  restricted {
-    Migrations upgraded = Migrations(new_address);
-    upgraded.setCompleted(last_completed_migration);
-  }
+    function upgrade(address _newAddress)public  restricted {
+        Migrations upgraded = Migrations(_newAddress);
+        upgraded.setCompleted(lastCompletedMigration);
+    }
 }