Creating Decentralised Wallet and Exchange like binance with its on ICO

KONG Decentralised Cold/offline Wallet and Exchange The objective of this project is to create a decentralized exchange with a focus on speed and capacity, or more precisely, a dex blockchain that is low-latency and high-throughput. The dex Blockchain should have the following features: Sending and receiving of the native coin New token creation Sending, receiving, freezing, and burning of tokens Ability to trade one token with another token (all within the same chain) Bonus feature: Native on-chain ICO For performance, we recommend the following design considerations: All features mentioned above built-in natively to the blockchain No support for smart contracts, virtual machines or turing complete languages If a trade-off is required, always choose speed and simplicity over fancy features. Mining & Consensus A blockchain where all native tokens are pre-mined, there will be no mining (all GAAIUS/XGA coins will be proof of stake You are free to use any consensus algorithm you like; performance is key. Basics Basic features such as block generation and sending/receiving of the native coin should be included. You are also free to use graphs instead of chains, assuming you can make it work reliably. Token Creation Native support for new token generation is required. That is, users should be able to create new tokens simply by specifying token parameters, such as symbol, total supply, decimals, etc, without having to write smart contracts. New token generation will cost a fee, payable in the native coin of the blockchain. Tokens can follow a simple structure; fixed supply, all pre-mined, etc. Again, if there is a need for a trade-off between advanced features vs speed and simplicity, the latter wins. Orders & Trades Users should be able to place orders and trade one token for another directly on the blockchain. These orders should be natively supported by the blockchain and not via smart contracts. Limit GTC orders must be supported, and maybe a limit FOK and IOC, market, and other advanced order types, but keep in mind that speed is of higher priority. An order should contain: Symbol (trading pair) Side Price Amount Expiry time (in blocks) Owner Trading is done via sending orders to the network. As network resources are required to process each order, a fee will apply. The order fee will be dynamically adjust based on how busy the network is, similar to other network fees. Order fees are charged when the orders are submitted to the network. Orders can be cancelled before they are traded. Each cancellation is also a new message to the network, thus incurring another network fee. If an order matches against another order, a trade event happens. A trade is simply one atomic event involving two token transfers on the network. Again, network transfer fees will apply. A trade should also trigger an execution report. We recommend an execution report structure similar to standard FIX 4.4 or higher protocol. Matching Engine You are free to use on-chain or off-chain matching engines in your design. The main consideration factor should be performance. Nodes Nodes on the blockchain will handle: Sending of the native coin Issuing of tokens Sending/receiving of tokens Placing orders and handling trades Nodes on the network will be compensated by transfer, order, trading, and other fees. Other fees include token creation, and potentially ICOs at a later date. For this competition, nodes running in one OS will suffice, ideally Linux. Wallet The wallet is the user’s interface to the blockchain. GUI wallets are required. ICO Required, a natively supported ICO implementation . Implementation We generally like to see new implementations built from scratch, but you may choose to fork existing blockchain implementations and improve upon them. You must ensure you do not violate any copyright or license restrictions. Considering each trade may involve many orders, you will probably want to avoid (or change) blockchains that only allow you to have one input and one output address. Bitcoin’s many-to-many model may be a better fit here.