Skip to content
The securities tokens issuing platform
JavaScript Solidity
Branch: master
Clone or download

Latest commit

Fetching latest commit…
Cannot retrieve the latest commit at this time.


Type Name Latest commit message Commit time
Failed to load latest commit information.

Tokens Issuing Platform

Platform supports the most popular tokens standards and its modifications on Ethereum blockchain. Modified tokens standards provide the symbol uniqueness in the network, additional security and protection for tokens owners by means of symbol registry, permission and transfer modules.

Project architecture and relations beetwen components

                  Picture 1 - Project architecture and relations beetwen components

1. Registry layer goals are: Register new token Symbols, Store a list of all created tokens Create new tokens and companies STO.


  • Symbol registry system is a repository for symbol instances. It also provides an opportunity to register token symbols in our network.
  • Token Issuing system deploys new token.
    • Token Factory is a component which accepts a request to create a new token, Request consist of: TokenName, TokenSymbol, TokenSupply, TokenStandard. Token Factory Checks parameters, checks whether chosen standard is supported in our system.Then Tokens Factory sends request to the "Token Deployment Strategy".
    • Token Deployment Strategy to check a standard and add strategy according to the chosen standard (only 1 strategy available for 1 standard) and deploys the token.

2. Request verification layer provide reliable security at any request which goes to the Smart Contracts.


  • Permissions verification system serves as a core for verification of the requests which are processed in our Smart Contracts. It includes:
    • Permission Module is a flexible mechanism which allows to create and set rules for accessing the network components. Permission Module grants the ability to take control over the token issuance, symbol registration, registration of new verification services, adding/removal strategies, etc.
    • Network Roles Manager - verifies request which belongs to our system (Register a symbol, Token Creation, Adding new Strategies, Adding new transfer verification services).
    • Token Roles Manager - verifies requests which belong to the token. (Example add/remove to/from the WhiteList, create RollBack).
  • Transfer verification system validates transactions through Transfer module by the logic which was related to the token standard. Each standard can implement own transfer verification logic and can contain one or few verification services. (WhiteList, Rules Engine).
    • Transfer Verification contains “transfer verification logic” created for each standard. “Transfer verification logic” can be implemented by means of different “transfer verification services”. There could be different “transfer verification services” for each standard.
    • Transfer Verification Service
      • Whitelist stores the list of accounts with a proven identity over KYC. Hence WhiteList checks the accounts which send or receive requests in our Smart contracts. If an account is not found in the WhiteList request would be rejected. (Applied for Securrency standards CAT-20, CAT-721)

3.Transaction layer - stands for token transfers from one account to the other via the verification layer. Transfer layer extends the token transfer on: whiteList verification and Cross-Chain transfers.


  • Transfer Module receives requests and sends them to the token factory to get to know the information about the token. Tokens factory accepts the token address and approves that this token exists to provide its standard. Later when the information is received from Token factory transfer module sends it on verification to the "transfer verification layer" where the token is getting verified according to the whitelists, rules engine etc services which have been provided in the standard.
  • Cross Chain service allow transfer tokens to the other chain. Before it checks who's transaction initiator, whether it's "Transfer module" or not. If the request comes from "Transfer module", "FromChain" records the transaction to the blockchain: token address, token owner, target chain, targetAddress Recipient wallet in the other chain, value Amount of tokens or token id for the CAT-721 token. "ToChain" gets the direct requests from the verified third party (Securrency) and sends third-party's wallet to the Permission module to check whether this wallet is allowed to perform cross chain transaction or not. "FromChain" module records the following information into the blockchain:
    • fromTokenAddress Token address in the previous chain
    • sentFrom Sender address in the previous chain
    • recipient address
    • tokenAddress Token address in the current chain
    • from Original chain
    • originalTxHash Tx hash which initiate cross chain transfer
    • value Amount of tokens || token id for the CAT-721 token

Package version requirements for your machine:

  • node v8.10.0
  • npm v3.5.2
  • Truffle v5.0.0
  • Solidity v0.5.0 (solc-js)
  • Ganache CLI v6.2.5 (ganache-core: 2.3.3)


The smart contracts are written in Solidity and tested/deployed using Truffle version 5.0.0.



To test the code simply run:

$ truffle test


To deploy the code simply run:

$ truffle migrate

CLI applications


You can’t perform that action at this time.