We apologize for the long silent period that continued from the previous year. For the past two months, we have reached our aim by integrating with Metamask the new feature of encrypting/decrypting messaging systems. Our initial post was dated 18 July 2019 https://github.com/MetaMask/metamask-extension/issues/1190 and the initial message about this feature request is dated from 2017. These 8 months we have been working with Metamask core team and community to provide the new way of secure communication.
We have described our “Talk” system in the previous articles and now ideas implemented in the ESCB hybrid exchange will serve for the good on all blockchain communities. Metamask extension has more than 1 million users that can use secure channels for communication. In our next project, we will reuse the “Talk” system code because it is the universal subsystem for any p2p model project.
The next big thing that we have started to implement is United Cryptocurrency Depositing System (UCDS)
United Cryptocurrency Depositing System allows having a gateway for accepting cryptocurrencies on your addresses and watching transactions.
UCDS works by event model, which allows using it as microservice for transforming data from the blockchain to offline data.
For example, you can handle the event that you have got a transaction in 0.01 BTC and record this to DB or send an email, etc.
UCDS system will support all popular blockchain projects and can be expanded by the community. With such a system anyone can accept crypto coins without any fee. An online business can use direct access to financial information on any blockchain. And all this is possible with a unified interface. The standard exchange point can use UCDS library for tracking incoming transactions and exchange it for cash. All centralized cryptocurrency exchanges have their own depositing system with a proprietary codebase. We want to bring for the community the possibility of starting your own exchange business without any investment in the developing process. We believe that the open-source force and the community contribution will give more benefit than closed projects for only commercial gain.
Topic: ∞💰∞【ANN】【IITO】Escrow Platform with ESC9 protocol ∞💰∞ (Read 601 times)
This year was busy. We managed to gather around the project an audience sufficient to further advance our ideas. Now it is more than 6,000 followers who, together with us, want to change the familiar model of counterparty interaction.
For this year we posted in the public domain the code of our hybrid exchange ESCB. The project is developing, but not as fast as we would like. Since the beginning of summer, we have been trying to introduce a new function in the Metamask extension, which will allow you to encode and decode messages using Ethereum keys. You can watch the current progress in merging our developments with the expansion core here https://github.com/MetaMask/metamask-extension/issues/1190
We completely rewrote the logic of the “Talk” system, now the interaction between contractors will be more logical. The main feature is that the public key for communication and the public key for entering the account will be different and will be generated only once. This allows you to make the “Talk” system more secure by isolating yourself from other services of the ESCB exchange.
We have added the initial implementation of “fee for exchange” so that other members of the community can use our code to open their hybrid exchanges and make a profit. The fee is a personal characteristic and can be displayed to each participant in transactions on the ESCB exchange. This allows you to set the fee rate based on trading volumes, based on the retention volume of a particular currency, etc.
In the near future, we want to implement an automatic referral program. Now it exists only to determine the relationship between referral and referred. After the additions, everyone who will attract new users to the ESCB hybrid exchange will automatically receive part of the fee for a certain amount of time. We will announce additional conditions in preparation for the launch of the product version.
Our team understands that there is still a lot of work to be done, but we hope that the new year will bring many positive moments to our community.
Next year we have planned new token giveaways to attract participants to our community. Therefore, stay tuned in our official channels.
Happy New Year!
For this year we posted in the public domain the code of our hybrid exchange ESCB. The project is developing, but not as fast as we would like. Since the beginning of summer, we have been trying to introduce a new function in the Metamask extension, which will allow you to encode and decode messages using Ethereum keys. You can watch the current progress in merging our developments with the expansion core here https://github.com/MetaMask/metamask-extension/issues/1190
We completely rewrote the logic of the “Talk” system, now the interaction between contractors will be more logical. The main feature is that the public key for communication and the public key for entering the account will be different and will be generated only once. This allows you to make the “Talk” system more secure by isolating yourself from other services of the ESCB exchange.
We have added the initial implementation of “fee for exchange” so that other members of the community can use our code to open their hybrid exchanges and make a profit. The fee is a personal characteristic and can be displayed to each participant in transactions on the ESCB exchange. This allows you to set the fee rate based on trading volumes, based on the retention volume of a particular currency, etc.
In the near future, we want to implement an automatic referral program. Now it exists only to determine the relationship between referral and referred. After the additions, everyone who will attract new users to the ESCB hybrid exchange will automatically receive part of the fee for a certain amount of time. We will announce additional conditions in preparation for the launch of the product version.
Our team understands that there is still a lot of work to be done, but we hope that the new year will bring many positive moments to our community.
Next year we have planned new token giveaways to attract participants to our community. Therefore, stay tuned in our official channels.
Happy New Year!
Monthly update (October 2019)
Our team has developed the key feature for our Talk system several months ago, but it is not merged into Metamask extension till recently. We are forced to delay our launch production version of the ESCB exchange but in this period we have had time to improve our approach for many difficult technical parts.
We have decided that we won’t include the initial listing of coins that has an average daily trade volume of less than 500 000$. The listing of coins that has less than this volume will be postponed.
Also, we have decided to change our initial decision to do zero fees for ESCB exchange, because we need to replenish our budget for faster progress.
Our referral program will start at the moment of the launch of the ESCB exchange. We plan to provide 50% of fees per referral for all time. Also, as we have promised, all fees will have a discount in a proportion of ESCB tokens staked. The discount table for fees will be disclosed at a later date.
We hope that we will launch our production hybrid ESCB exchange version before the end of this year but it all depends on many factors and we apologize in advance if it will be delayed.
We are working hard to improve the usual service by the new technological stack.
Our team has developed the key feature for our Talk system several months ago, but it is not merged into Metamask extension till recently. We are forced to delay our launch production version of the ESCB exchange but in this period we have had time to improve our approach for many difficult technical parts.
We have decided that we won’t include the initial listing of coins that has an average daily trade volume of less than 500 000$. The listing of coins that has less than this volume will be postponed.
Also, we have decided to change our initial decision to do zero fees for ESCB exchange, because we need to replenish our budget for faster progress.
Our referral program will start at the moment of the launch of the ESCB exchange. We plan to provide 50% of fees per referral for all time. Also, as we have promised, all fees will have a discount in a proportion of ESCB tokens staked. The discount table for fees will be disclosed at a later date.
We hope that we will launch our production hybrid ESCB exchange version before the end of this year but it all depends on many factors and we apologize in advance if it will be delayed.
We are working hard to improve the usual service by the new technological stack.
Monthly update for August
In the past month, we have implemented the new version of our “matching engine” for hybrid ESCB exchange platform. New implementation works as a distributed cluster. Each worker in this system takes a piece of the global order book and matches it with others. Such a strategy allows infinite scaling and implements a separate “matching engine” for a specific coin. It will help to manage a large number of assets.
We have implemented the new decrypting message feature for Metamask, but unfortunately, we are waiting to merge from third party project https://github.com/MetaMask/eth-simple-keyring/pull/15.
As we have described previously our “Talk” system is built on agreement security between counterparties. Metamask has a significant user base and we cannot launch our production environment before they include our patch into core code. As you can see here https://github.com/MetaMask/metamask-extension/issues/1190 many users want to have this option for Dapp. It will open the way for new chatting applications based on Ethereum blockchain tools.
Also, this month we have started implementing the core of our own oracle system infrastructure. It will allow tracking external blockchain for delayed transactions. The key mechanics of this oracle system is the input node. Such a node will have the ability to interact with MHW structures directly because it will have rights for writing in eternal storage.
Also, we have started thinking about distributed “matching machine” as a subproject of ESCB exchange platform. Such an approach will allow joining together all exchanges based on our open-source code in the global system that will resolve initial liquidity flow problems for newbie exchanges. Such a system will work separately from every Exchange and will be based on Raft protocol.
In the past month, we have implemented the new version of our “matching engine” for hybrid ESCB exchange platform. New implementation works as a distributed cluster. Each worker in this system takes a piece of the global order book and matches it with others. Such a strategy allows infinite scaling and implements a separate “matching engine” for a specific coin. It will help to manage a large number of assets.
We have implemented the new decrypting message feature for Metamask, but unfortunately, we are waiting to merge from third party project https://github.com/MetaMask/eth-simple-keyring/pull/15.
As we have described previously our “Talk” system is built on agreement security between counterparties. Metamask has a significant user base and we cannot launch our production environment before they include our patch into core code. As you can see here https://github.com/MetaMask/metamask-extension/issues/1190 many users want to have this option for Dapp. It will open the way for new chatting applications based on Ethereum blockchain tools.
Also, this month we have started implementing the core of our own oracle system infrastructure. It will allow tracking external blockchain for delayed transactions. The key mechanics of this oracle system is the input node. Such a node will have the ability to interact with MHW structures directly because it will have rights for writing in eternal storage.
Also, we have started thinking about distributed “matching machine” as a subproject of ESCB exchange platform. Such an approach will allow joining together all exchanges based on our open-source code in the global system that will resolve initial liquidity flow problems for newbie exchanges. Such a system will work separately from every Exchange and will be based on Raft protocol.
We are happy to announce that we have published our open-source ESCB hybrid DEX exchange on Github. It is our first step by way of creating a whole ecosystem on ESCB9 protocol base.
The goal of publishing open sources for ESCB exchange platform is to use the capabilities of local crypto-crypto and crypto-fiat exchanges.
Thus, Escrowblock Foundation forms a global rating system of counterparties involving escrow for the prevention of fraudulent schemes.
The owner who wants to create a new exchange based on this software must use HMW and follow by two GPL-3.0-or-later and ESCB.LICENSE
People will use our software because:
To do this we need help from the community, this will allow achieving our aim faster. Any interested developer can see our Roadmap and support this project.
We can also stimulate any ideas via grants and rewards in tokens.
The goal of publishing open sources for ESCB exchange platform is to use the capabilities of local crypto-crypto and crypto-fiat exchanges.
Thus, Escrowblock Foundation forms a global rating system of counterparties involving escrow for the prevention of fraudulent schemes.
The owner who wants to create a new exchange based on this software must use HMW and follow by two GPL-3.0-or-later and ESCB.LICENSE
People will use our software because:
- It is free as opposed to a proprietary exchange platform which requires significant funding foundation on launching.
- It uses the newest well-tested technologies
- It allows scaling “matching engine” infinitely.
- It has the latest and best security. It uses keys ETH wallet on sign-in/ sign-up operations and also for building a secure channel for “Talk” system.
- Simple for developers. Eslint + mocha won’t allow to use dirty code or bring any bugs to code.
- The owner doesn’t need to pay a fee or royalty to Escrowblock foundation for using in commercial circumstances, just needs to follow our ESCB.LICENSE
- Community drives developing. Each developer can be involved in building the new hybrid DEX exchanges generation.
To do this we need help from the community, this will allow achieving our aim faster. Any interested developer can see our Roadmap and support this project.
We can also stimulate any ideas via grants and rewards in tokens.
This type of transaction allows users to exchange crypto assets to fiat or any other material assets that are available on the ESCB exchange platform.
The difference is that this sort of trade is carried out offline, counterparties cannot specifically know about the trade, only about the time of execution. This type of trade demands an escrow, only from one side, the counterparty must complete all expected actions by agreement for closing such a trade.
For example, let us consider an exchange process for BTC_JPY. In this case, Alice wants to buy 1 BTC for 1 000 000 (1M) JPY, Bob creates a sell limit order with parameters: 1 BTC as the Quantity and the Limit Price at 1M, Alice creates a buy limit order with parameters: 1 BTC as the Quantity and the Limit Price at 1M. When the “matching engine” is faced with this order it creates the trade with “deferred” status, as opposed to the typical “closed” status. In this status, no one asset is transferred until it is actioned. ESCB exchange platform creates a “Talk” channel for such trades, we have described this service in our earlier articles.
The key aspect is security in providing such a trade. Bob, who owns crypto assets, will wait until the transfer of external assets from Alice and only after this moment will “confirm” trade.
After this confirmation escrow will transfer to the counterparty 100% of the value. Before sending external assets Alice has the option to “refuse” this deal. Then escrow will return to Bob 100% of the value.
But what happens if Alice could only transfer 50% of the deal (or any part thereof) of the agreement amount due to a bank issue? This is when counterparties can ask for arbitration and that will resolve any disputes. The typical escrow deal can be closed without any 3rd party intervention but when a counterparty sees some suspicious offer or action and are faced with a force majeure, he/she can ask arbitration to close such a deal in a particular mode. In such cases, the arbitration will participate in “Talk” and will make a decision after listening to both sides. The trade will be decided by arbitration after a dispute resolution.
Orders from a trade which has been resolved will not be created additionally. After this moment such trades will have a “closed” status and will be seen on tickers and trade feed as basic trades.
The main concepts for deferred trades:
Only one person from counterparties needs to call for arbitration.
Only if arbitration is used, the current Talk messages will be accessible for exploring.
Any messages and files will be encrypted by channel identity.
Any user can set up a welcome message with some conditions and information about accepted payment methods or any other financial information.
Any KYC procedures must be processed by counterparties, ESCB platform is not responsible for any risks related to counterparties rights on any assets that can be involved in an exchange. As a method of confirming any rights on assets, a user can demand the counterparty to provide a picture with the current financial data including a credit/debit card with the first 4 and last 4 numbers hidden, signed by the counterparty
The sandbox mode is not used on the blockchain. For production environment we will be using HMW smart contract, this will avoid any possible scam schemes.
For the production environment, a rating system will be available to use based on the blockchain. This will allow for trusted trader status.
P.S
For the 20 days in the sandbox testing mode 2 084 871 orders were tested, 771 557 trades with 1 138 instruments. The next step in our roadmap is the preparation of publishing the open source. We hope that this will happen during these coming weeks.
The difference is that this sort of trade is carried out offline, counterparties cannot specifically know about the trade, only about the time of execution. This type of trade demands an escrow, only from one side, the counterparty must complete all expected actions by agreement for closing such a trade.
For example, let us consider an exchange process for BTC_JPY. In this case, Alice wants to buy 1 BTC for 1 000 000 (1M) JPY, Bob creates a sell limit order with parameters: 1 BTC as the Quantity and the Limit Price at 1M, Alice creates a buy limit order with parameters: 1 BTC as the Quantity and the Limit Price at 1M. When the “matching engine” is faced with this order it creates the trade with “deferred” status, as opposed to the typical “closed” status. In this status, no one asset is transferred until it is actioned. ESCB exchange platform creates a “Talk” channel for such trades, we have described this service in our earlier articles.
The key aspect is security in providing such a trade. Bob, who owns crypto assets, will wait until the transfer of external assets from Alice and only after this moment will “confirm” trade.
After this confirmation escrow will transfer to the counterparty 100% of the value. Before sending external assets Alice has the option to “refuse” this deal. Then escrow will return to Bob 100% of the value.
But what happens if Alice could only transfer 50% of the deal (or any part thereof) of the agreement amount due to a bank issue? This is when counterparties can ask for arbitration and that will resolve any disputes. The typical escrow deal can be closed without any 3rd party intervention but when a counterparty sees some suspicious offer or action and are faced with a force majeure, he/she can ask arbitration to close such a deal in a particular mode. In such cases, the arbitration will participate in “Talk” and will make a decision after listening to both sides. The trade will be decided by arbitration after a dispute resolution.
Orders from a trade which has been resolved will not be created additionally. After this moment such trades will have a “closed” status and will be seen on tickers and trade feed as basic trades.
The main concepts for deferred trades:
Only one person from counterparties needs to call for arbitration.
Only if arbitration is used, the current Talk messages will be accessible for exploring.
Any messages and files will be encrypted by channel identity.
Any user can set up a welcome message with some conditions and information about accepted payment methods or any other financial information.
Any KYC procedures must be processed by counterparties, ESCB platform is not responsible for any risks related to counterparties rights on any assets that can be involved in an exchange. As a method of confirming any rights on assets, a user can demand the counterparty to provide a picture with the current financial data including a credit/debit card with the first 4 and last 4 numbers hidden, signed by the counterparty
The sandbox mode is not used on the blockchain. For production environment we will be using HMW smart contract, this will avoid any possible scam schemes.
For the production environment, a rating system will be available to use based on the blockchain. This will allow for trusted trader status.
P.S
For the 20 days in the sandbox testing mode 2 084 871 orders were tested, 771 557 trades with 1 138 instruments. The next step in our roadmap is the preparation of publishing the open source. We hope that this will happen during these coming weeks.
The ESCB exchange sandbox environment has been launched
As we promised in an earlier announcement during May we planned to launch the sandbox environment for showing our community the current state of our development process and this moment has come. You can see the current state of development using this link https://sandbox.escb.exchange
Our team has worked hard and as a result, we can provide the platform that performs not only limit orders, but also work with algorithmic orders including Trailing stop limit and Trailing stop market orders.
As was expected our current implementation “matching engine” won’t allow you to produce matching orders at more than 60 orders per second, that equivalent is 720 000 orders per 24 hours. In the near future, we want to implement a “matching engine” with the capability to perform up to 10 000 orders per seconds and it will allow us to reach around 864 000 000 orders per day. We understand that this is such a large amount of trades that can’t be reached for real needs and the more realistic goal for the moment is to perform 1000 orders per second (86 400 000 per 24 hours). All this can be achieved with a distributed “matching engine” with in-memory storage.
We have created the sandbox environment for a solutions test before using it in production and to allow a user with API in test mode (for example https://api.sandbox.escb.exchange/ping). Later we will load all production data with some delay from real-time to sandbox mode and any developer will be able to train their own bot with this data without any worries about losing real assets.
In our current roadmap:
“Matching engine” that will perform at least 1000 orders per second.
Creating a deposit system via oracle and integrate into our exchange sandbox environment.
Integrating HWM on test-net with oracles and our sandbox environment.
We expect that we will be ready with the production environment in the next few months.
As we promised in an earlier announcement during May we planned to launch the sandbox environment for showing our community the current state of our development process and this moment has come. You can see the current state of development using this link https://sandbox.escb.exchange
Our team has worked hard and as a result, we can provide the platform that performs not only limit orders, but also work with algorithmic orders including Trailing stop limit and Trailing stop market orders.
As was expected our current implementation “matching engine” won’t allow you to produce matching orders at more than 60 orders per second, that equivalent is 720 000 orders per 24 hours. In the near future, we want to implement a “matching engine” with the capability to perform up to 10 000 orders per seconds and it will allow us to reach around 864 000 000 orders per day. We understand that this is such a large amount of trades that can’t be reached for real needs and the more realistic goal for the moment is to perform 1000 orders per second (86 400 000 per 24 hours). All this can be achieved with a distributed “matching engine” with in-memory storage.
We have created the sandbox environment for a solutions test before using it in production and to allow a user with API in test mode (for example https://api.sandbox.escb.exchange/ping). Later we will load all production data with some delay from real-time to sandbox mode and any developer will be able to train their own bot with this data without any worries about losing real assets.
In our current roadmap:
“Matching engine” that will perform at least 1000 orders per second.
Creating a deposit system via oracle and integrate into our exchange sandbox environment.
Integrating HWM on test-net with oracles and our sandbox environment.
We expect that we will be ready with the production environment in the next few months.
Due to the recent hacker attacks on Binance and other exchanges we want to explain how we will secure users assets.
- Each transaction to an internal account (top up) or from an internal account (withdraw) must be signed by ETH private key. It will prove that only the owner can process this demand.
- We add IP whitelist for bots working via API.
- We will use secure oracle services for blockchain, it will allow tracking any incoming or outcoming transaction.
- A deposit from the external blockchain can only be done from by a specified user address and withdraw operation will be processed only on the same address. Specified deposit-withdraw addresses cannot be changed after binding.
- Each isolated oracle service will spread users assets on HMW structure.
- Each transaction on HMW structure can be declined and reverted during a secure period. Newbies, users with a high-risk rating, won’t be able to withdraw without a holding period, a secure time for rechecking legal ability for this procedure.
- 10-25% of fees from ESCB exchange will be used for an all risks-fund as it was described in our White Paper.
- API keys can be regenerated and it will block all operations via API. For authorization user must receive temporary API-token, this will not be related to the API secret. Each request for invocation of a private method must be signed by HMAC SHA256.
- To avoid DDOS attack we will implement a rate-limit shield. It will protect from flood requests from one IP address for unauthorized users and will also help to detect abnormal behavior from an internal account, which will be suspended if this is the case.
- We implement our own analytics system for web and mobiles clients, this will allow to us detect suspicious behavior on the client's side (web, desktop, mobile clients)
Coins that will be listed from the start, selected by volume and popularity. Our users will be able to trade between crypto coins/tokens and between crypto/fiat. The base coins/tokens are:
ADA, AE, AGI, AION, AMB, ARN, AST, BAT, BCD, BCHABC, BCPT, BNB, BQX, BTC, BTT, CELR, CMT, DASH, DGD, DLT, DNT, DOCK, ELF, ENJ, EOS, ESCB, ETC, ETH, EVX, FET, FUEL, GO, GTO, GXS, HC, HOT, ICX, INS, IOST, IOTA, IOTX, KMD, KNC, LINK, LOOM, LSK, LTC, MANA, MCO, MDA, MFT, MITH, MTL, NANO, NAS, NCASH, NEO, NPXS, NULS, OAX, OMG, ONG, ONT, OST, PAX, PHX, PIVX, POLY, QKC, QLC, QTUM, RDN, REN, REP, RVN, SC, SKY, STRAT, SYS, THETA, TNB, TPAY, TRX, TUSD, USDC, USDS, VET, VIA, VIB, WABI, WAN, WAVES, WTC, XEM, XLM, XMR, XRP, XVG, XZC, ZEC, ZIL, ZRX
Funding coins/tokens are:
ESCB, BNB, BTC, ETH, PAX, TUSD, USDC, USDS, USDT, XRP
Fiat funding is:
USD (US dollar), JPY (Japanese yen), BGN (Bulgarian lev), CZK (Czech koruna), DKK (Danish krone), GBP (Pound sterling), HUF (Hungarian forint), EUR (Euro), PLN (Polish zloty), RON (Romanian leu), SEK (Swedish krona), CHF (Swiss franc), ISK (Icelandic krona), NOK (Norwegian krone), HRK (Croatian kuna), RUB (Russian rouble), TRY (Turkish lira), AUD (Australian dollar), BRL (Brazilian real), CAD (Canadian dollar), CNY (Chinese yuan renminbi), HKD (Hong Kong dollar), IDR (Indonesian rupiah), ILS (Israeli shekel), INR (Indian rupee), KRW (South Korean won), MXN (Mexican peso), MYR (Malaysian ringgit), NZD (New Zealand dollar), PHP (Philippine peso), SGD (Singapore dollar), THB (Thai baht), ZAR (South African rand)
We don’t know as exactly will be conducted p2p transactions between counterparties for crypto/fiat deals, but card to card will be the preferred method.
Cryptocurrencies to Fiat bases are:
ADA, BCH, BNB, BTC, ETH, EOS, ESCB, LTC, USDT, XML, XRP
The basis of any Crypto Exchange is a product that can be exchanged via quote product. For example ESCB_CHF, we can define that a user can use CHF for buying and selling ESCB tokens. Such a deal assumes a working crypto-fiat model, this means using the deferred transaction and “Talk system”. All such transactions are conducted on HWM.
Our fee policy will be built on an agreement that internal transactions will be free for a limited time period, but the withdrawal process will cost a small amount, which we will announce before the DEX is launched. After this happens we will introduce a fee per transaction at 0.015% 6 months after DEX is launched with no withdrawal fee. Also, we can provide a discount period on fees for certain coins/tokens and specify different fees for operations between base/quote pairs.
As was introduced in our earlier articles, our deposit system will be based on the HMW concept. It will prevent “the exit scam” actions because any transaction will need to provide a certain number of signatures. Other transactions will have time for auto-executing, but they can be blocked from the HMW at the top level. The HMW top level cannot work with deposits at lower levels and can only do a restriction for such actions.
Our open source license will allow using the exchange code only with the main HMW.
Our release date for ESCB test environment will be in May 2019.
ADA, AE, AGI, AION, AMB, ARN, AST, BAT, BCD, BCHABC, BCPT, BNB, BQX, BTC, BTT, CELR, CMT, DASH, DGD, DLT, DNT, DOCK, ELF, ENJ, EOS, ESCB, ETC, ETH, EVX, FET, FUEL, GO, GTO, GXS, HC, HOT, ICX, INS, IOST, IOTA, IOTX, KMD, KNC, LINK, LOOM, LSK, LTC, MANA, MCO, MDA, MFT, MITH, MTL, NANO, NAS, NCASH, NEO, NPXS, NULS, OAX, OMG, ONG, ONT, OST, PAX, PHX, PIVX, POLY, QKC, QLC, QTUM, RDN, REN, REP, RVN, SC, SKY, STRAT, SYS, THETA, TNB, TPAY, TRX, TUSD, USDC, USDS, VET, VIA, VIB, WABI, WAN, WAVES, WTC, XEM, XLM, XMR, XRP, XVG, XZC, ZEC, ZIL, ZRX
Funding coins/tokens are:
ESCB, BNB, BTC, ETH, PAX, TUSD, USDC, USDS, USDT, XRP
Fiat funding is:
USD (US dollar), JPY (Japanese yen), BGN (Bulgarian lev), CZK (Czech koruna), DKK (Danish krone), GBP (Pound sterling), HUF (Hungarian forint), EUR (Euro), PLN (Polish zloty), RON (Romanian leu), SEK (Swedish krona), CHF (Swiss franc), ISK (Icelandic krona), NOK (Norwegian krone), HRK (Croatian kuna), RUB (Russian rouble), TRY (Turkish lira), AUD (Australian dollar), BRL (Brazilian real), CAD (Canadian dollar), CNY (Chinese yuan renminbi), HKD (Hong Kong dollar), IDR (Indonesian rupiah), ILS (Israeli shekel), INR (Indian rupee), KRW (South Korean won), MXN (Mexican peso), MYR (Malaysian ringgit), NZD (New Zealand dollar), PHP (Philippine peso), SGD (Singapore dollar), THB (Thai baht), ZAR (South African rand)
We don’t know as exactly will be conducted p2p transactions between counterparties for crypto/fiat deals, but card to card will be the preferred method.
Cryptocurrencies to Fiat bases are:
ADA, BCH, BNB, BTC, ETH, EOS, ESCB, LTC, USDT, XML, XRP
The basis of any Crypto Exchange is a product that can be exchanged via quote product. For example ESCB_CHF, we can define that a user can use CHF for buying and selling ESCB tokens. Such a deal assumes a working crypto-fiat model, this means using the deferred transaction and “Talk system”. All such transactions are conducted on HWM.
Our fee policy will be built on an agreement that internal transactions will be free for a limited time period, but the withdrawal process will cost a small amount, which we will announce before the DEX is launched. After this happens we will introduce a fee per transaction at 0.015% 6 months after DEX is launched with no withdrawal fee. Also, we can provide a discount period on fees for certain coins/tokens and specify different fees for operations between base/quote pairs.
As was introduced in our earlier articles, our deposit system will be based on the HMW concept. It will prevent “the exit scam” actions because any transaction will need to provide a certain number of signatures. Other transactions will have time for auto-executing, but they can be blocked from the HMW at the top level. The HMW top level cannot work with deposits at lower levels and can only do a restriction for such actions.
Our open source license will allow using the exchange code only with the main HMW.
Our release date for ESCB test environment will be in May 2019.
ESCB exchange platform release roadmap
Our developer team has reported that almost everything is ready for launching our test environment for the ESCB exchange platform.
What will be included for this test-env release:
Our test environment for ESCB exchange platform follows the next aims:
We expect to launch the test environment for ESCB exchange platform during May 2019. Our production version launching is scheduled for the beginning of Summer 2019, but we will gather community opinions and this all depends on this feedback, only then we can make a decision about moving the production version launch to a later date if necessary.
After this time we will be able to publish our code by open source for new opportunities. We expect that many entrepreneurs will want to launch their own exchanges based on our ESCB9 protocol.
Our developer team has reported that almost everything is ready for launching our test environment for the ESCB exchange platform.
What will be included for this test-env release:
- Trade UI.
- The order placement/cancelation.
- The matching engine based on MongoDB. The matching engine for the production version will work on Redis in-memory database.
- The depositing system.
- The deferred transactions.
- The “Talk system” based on private channels identity.
- The secured profile with OTP and white list IP features.
- RESTful API for public and private operations.
Our test environment for ESCB exchange platform follows the next aims:
- Testing with the community our solutions before the production version is launched.
- The correction if any bugs found.
- Taking feedback for any improvements to the test environment and updates before the production version will be deployed.
- Providing an environment for testing strategies and bots.
- The forming of a developer community for joining our core team.
We expect to launch the test environment for ESCB exchange platform during May 2019. Our production version launching is scheduled for the beginning of Summer 2019, but we will gather community opinions and this all depends on this feedback, only then we can make a decision about moving the production version launch to a later date if necessary.
After this time we will be able to publish our code by open source for new opportunities. We expect that many entrepreneurs will want to launch their own exchanges based on our ESCB9 protocol.
This week we started trading on EtherFlyer exchange - https://www.etherflyer.com/trade.html?pairs=ESCB-ETH&market=03. It is the second exchange we have been listed on so we can now be listed on Coinmarketcap. We can pass their screening criteria for listing but we have decided to postpone this event for the time being. We will update everyone when we are live on CMC.
Also, EtherFlyer exchange is conducting a new Airdrop with ESCB tokens that will gain new participators/token holders to our community.
Our developer team is in the process of testing our secure messaging system that will provide a clear dispute process in difficult situations. After this has been done we will be close to launching the test environment and open access for our community.
Also, EtherFlyer exchange is conducting a new Airdrop with ESCB tokens that will gain new participators/token holders to our community.
Our developer team is in the process of testing our secure messaging system that will provide a clear dispute process in difficult situations. After this has been done we will be close to launching the test environment and open access for our community.
On the classical exchanges, you first need to make a deposit to the account of the exchange and then trade. We decided to add this type of deposit for making quick deals during the day. This will allow traders to perform thousands of transactions per day. At the same time, our platform will not have more than 5% of the total deposits on each depositary account in HMW, this is to minimize possible attacks on the blockchain infrastructure of the ESCB exchange. It will also serve as evidence that our exchange will not be able to control our customer deposits.
To maintain decentralization, we added a pending transaction. Under such a transaction, one of the participants makes a deposit for the transaction using HMW, and the second one fulfills the conditions of the transaction, after which it receives the deposited funds.
Consider an example of a transaction on the example of buying 1 ETH for $ 100. Seller 1 ETH has on deposit the amount that is reserved for the transaction. The buyer receives the details for the transfer of p2p, for example from card to card. After confirming the transfer, the amount of 1 ETH is transferred to the buyer. At this stage, there could be possible disputes between the parties of the transaction. To solve such situations there is a “Talks” section on the ESCB exchange, which allows you to exchange messages between the counterparties to the transaction. If the dispute cannot be resolved, then a moderator is added to the conversation.
A natural problem in such a situation is trust between the parties. To do this, all messages in the conversation will be confidential. We have developed our own confidential correspondence system based on the elliptic curves of the ETH keys of the blockchain.
Photo by Haley Lawrence on Unsplash
Such a communication channel works in the following simplified way:
Bob and Alice each have two keys — open, which is used to generate the ETH address of the wallet and closed, which is used to sign transactions.
At the stage of forming a new communication channel, Bob generates a new key pair, public and private (identity), and encrypts this identity channel with Alice’s public key.
At this stage in the database for two counterparties, there is an identity channel encrypted with the public key for Bob and Alice. This provides a confidential channel for their communication.
To send a message, Bob decrypts with his private key the identity channel. Encodes the message with the public key of the identity channel and sends it.
Alice and Bob use the identity channel private key to read all messages in a confidential channel.
If the process of the transaction requires assistance in resolving the dispute. Then Bob or Alice can invite other participants to the group through the following mechanism.
One of the parties, for example, Alice, presses the button — to invite the moderator into the conversation.
Identity channel is encrypted in Bob’s browser with the public key of the moderator and is recorded in the database.
The moderator decrypts the private key of the identity channel and can use a confidential channel of communication with the parties to the transaction.
If in the course of the transaction it is necessary to provide evidence in the form of images or other media files, they are encrypted by the identity channel and recorded in ipfs. Such files can be obtained by a hash code by anyone who has it. But such files can only be decrypted using the identity channel.
The advantages of such a scheme for building a confidential communication channel:
Only encryption keys available in the user’s browser are used. This eliminates a middle-man attack. All data is sent via end-to-end encryption. Generation of an identity channel does not require the participation of the server part or any other party, as is the case in the algorithm https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
Identity channel is stored in an encrypted form for each participant in a confidential conversation. This eliminates the possibility of its leakage by hacking the database.
The ability to add an unlimited number of participants in the conversation.
The good speed of encoding and decoding messages, as one identity channel is used for all messages and files in a confidential conversation.
For each communication channel a new identity channel is formed, so if one identity channel leaks, it is impossible to read other channels.
The only possible disadvantage of this construction scheme:
In case of a leak of the private key of one of the participants in a confidential conversation, as it is possible to read all the messages in the channel.
It is not possible to use the server performance for a search. Any string search can be performed only on the client side, but due to each deal in creating a new channel, the data length for a search will be limited.
The article link - https://medium.com/@escrowblock/deposit-flows-deferred-transactions-confidential-communication-channels-d6e7348b0f57
To maintain decentralization, we added a pending transaction. Under such a transaction, one of the participants makes a deposit for the transaction using HMW, and the second one fulfills the conditions of the transaction, after which it receives the deposited funds.
Consider an example of a transaction on the example of buying 1 ETH for $ 100. Seller 1 ETH has on deposit the amount that is reserved for the transaction. The buyer receives the details for the transfer of p2p, for example from card to card. After confirming the transfer, the amount of 1 ETH is transferred to the buyer. At this stage, there could be possible disputes between the parties of the transaction. To solve such situations there is a “Talks” section on the ESCB exchange, which allows you to exchange messages between the counterparties to the transaction. If the dispute cannot be resolved, then a moderator is added to the conversation.
A natural problem in such a situation is trust between the parties. To do this, all messages in the conversation will be confidential. We have developed our own confidential correspondence system based on the elliptic curves of the ETH keys of the blockchain.
Photo by Haley Lawrence on Unsplash
Such a communication channel works in the following simplified way:
Bob and Alice each have two keys — open, which is used to generate the ETH address of the wallet and closed, which is used to sign transactions.
At the stage of forming a new communication channel, Bob generates a new key pair, public and private (identity), and encrypts this identity channel with Alice’s public key.
At this stage in the database for two counterparties, there is an identity channel encrypted with the public key for Bob and Alice. This provides a confidential channel for their communication.
To send a message, Bob decrypts with his private key the identity channel. Encodes the message with the public key of the identity channel and sends it.
Alice and Bob use the identity channel private key to read all messages in a confidential channel.
If the process of the transaction requires assistance in resolving the dispute. Then Bob or Alice can invite other participants to the group through the following mechanism.
One of the parties, for example, Alice, presses the button — to invite the moderator into the conversation.
Identity channel is encrypted in Bob’s browser with the public key of the moderator and is recorded in the database.
The moderator decrypts the private key of the identity channel and can use a confidential channel of communication with the parties to the transaction.
If in the course of the transaction it is necessary to provide evidence in the form of images or other media files, they are encrypted by the identity channel and recorded in ipfs. Such files can be obtained by a hash code by anyone who has it. But such files can only be decrypted using the identity channel.
The advantages of such a scheme for building a confidential communication channel:
Only encryption keys available in the user’s browser are used. This eliminates a middle-man attack. All data is sent via end-to-end encryption. Generation of an identity channel does not require the participation of the server part or any other party, as is the case in the algorithm https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
Identity channel is stored in an encrypted form for each participant in a confidential conversation. This eliminates the possibility of its leakage by hacking the database.
The ability to add an unlimited number of participants in the conversation.
The good speed of encoding and decoding messages, as one identity channel is used for all messages and files in a confidential conversation.
For each communication channel a new identity channel is formed, so if one identity channel leaks, it is impossible to read other channels.
The only possible disadvantage of this construction scheme:
In case of a leak of the private key of one of the participants in a confidential conversation, as it is possible to read all the messages in the channel.
It is not possible to use the server performance for a search. Any string search can be performed only on the client side, but due to each deal in creating a new channel, the data length for a search will be limited.
The article link - https://medium.com/@escrowblock/deposit-flows-deferred-transactions-confidential-communication-channels-d6e7348b0f57
The full article placed here - https://medium.com/@escrowblock/the-impression-from-internal-testing-period-escb-exchange-66d58076acc3
We are in the process of testing our ESCB exchange platform and we want to share first impressions from this achievement on the way to the best open source software for new DEX generation.
Here you can see the chart with candles and blocks, the book order and the recent trades and the block for placing orders. As we have described earlier we will support 7 order types. But several such algorithmic orders can be bought with the main two types of order, market and limit.
For placing any order you will need to log in to the ESCB exchange via the purple button at the top right hand corner. We don’t split sign up and log in operations. An internal account will be created after the first login and become bonded with your ETH address. A user can use 4 ways for sign in/ sign up process:
Metamask;
Ledger;
Trezor;
Create a wallet;
Unlock a wallet;
ESCB DEX sign in/sign up page
In our ESCB exchange, we have 6 menu items.
“Trade” item is used for all operations related to trading.
“My account” item contains your counterparties address book, the history of interactions, ratings and other information from the blockchain.
“My profile” item contains all “personal data“ that you want to share with other counterparties. Some nodes of the HWM demands KYC, some do not.
“News” item contains information about new markets and announcements. We plan to expand this menu item and include market information that can help to trade.
“Talks” item contains all interactions via the internal secure chatting platform in the processes of resolving dispute issues in process of operation between you and counterparty.
“Notifications” item contains the information about events related to your orders and can require action from your side. For example, to close a deal you must confirm operation, etc.
We are only at the beginning of an epoch new DEX generation and soon we will publish ESCB DEX on Testnet and share code as open source. Each developer will get some rewards but this is the theme for our next post.
Also, don’t forget about that the ESCB token will be listed on https://p2pb2b.io exchange platform on 1st of March at 10 a.m. UTC.
We are in the process of testing our ESCB exchange platform and we want to share first impressions from this achievement on the way to the best open source software for new DEX generation.
Here you can see the chart with candles and blocks, the book order and the recent trades and the block for placing orders. As we have described earlier we will support 7 order types. But several such algorithmic orders can be bought with the main two types of order, market and limit.
For placing any order you will need to log in to the ESCB exchange via the purple button at the top right hand corner. We don’t split sign up and log in operations. An internal account will be created after the first login and become bonded with your ETH address. A user can use 4 ways for sign in/ sign up process:
Metamask;
Ledger;
Trezor;
Create a wallet;
Unlock a wallet;
ESCB DEX sign in/sign up page
In our ESCB exchange, we have 6 menu items.
“Trade” item is used for all operations related to trading.
“My account” item contains your counterparties address book, the history of interactions, ratings and other information from the blockchain.
“My profile” item contains all “personal data“ that you want to share with other counterparties. Some nodes of the HWM demands KYC, some do not.
“News” item contains information about new markets and announcements. We plan to expand this menu item and include market information that can help to trade.
“Talks” item contains all interactions via the internal secure chatting platform in the processes of resolving dispute issues in process of operation between you and counterparty.
“Notifications” item contains the information about events related to your orders and can require action from your side. For example, to close a deal you must confirm operation, etc.
We are only at the beginning of an epoch new DEX generation and soon we will publish ESCB DEX on Testnet and share code as open source. Each developer will get some rewards but this is the theme for our next post.
Also, don’t forget about that the ESCB token will be listed on https://p2pb2b.io exchange platform on 1st of March at 10 a.m. UTC.
We are glad to announce the big event for our community. The ESCB token will be listed on https://p2pb2b.io exchange platform on 1st of March at 10 a.m. UTC. Please keep in mind that it would be prudent to be registered before the new market starts.
Our development team has worked hard to show the initial MVP for our own exchange platform, we are hoping to be ready for this announcement at the expected time. It is a big project that will bring to the market new abilities and new benefits for token holders.
All fees on our own exchange platform will be available for payment in ESCB tokens. This decision will allow increased liquidity for tokens and bring more participants to our Escrowblock ecosystem.
Our development team has worked hard to show the initial MVP for our own exchange platform, we are hoping to be ready for this announcement at the expected time. It is a big project that will bring to the market new abilities and new benefits for token holders.
All fees on our own exchange platform will be available for payment in ESCB tokens. This decision will allow increased liquidity for tokens and bring more participants to our Escrowblock ecosystem.
Do you have an understanding of how the fork of etherium will be delayed due to the identified vulnerability? This, after all, can negatively affect your token?
We don't have any doubts about our tokens. In any case, if "the identified vulnerability" mentioned by you can really influence on our tokens, then it can influence on whole Ethereum network. Please paste a link on "the identified vulnerability".The Escrow Platform project seems to be a very serious conception and depending on the team's management in implementing it, the Escrow Platform project can have a great future. Congratulations. Good luck.
Thank you very much for participating in our community.
Holidays associated with Christmas and New Year, in different countries, were drawn out but we worked hard in those days for the benefit of our offering. From the 1st to the 4th of January we paid the referral program reward for the first time. Our telegram community is approaching close to 10 thousand as the statistics show at https://etherscan.io/token/0x5e365a320779acc2c72f5dcd2ba8a81e4a34569f our token holders are almost 8 thousand. Thank you all for such confidence!
We are happy to announce that our token will soon be trading on https://p2pb2b.io exchange. Agreements have already been signed and we are currently working with the exchange for an easy adoption but unfortunately, we cannot disclose all information right now. We are preparing a big announcement in conjunction with the trading platform, which will be the first to offer the ESCB token to its users. You can find some information in press-releases https://coins.newbium.com/post/24763-8-projects-to-consider-for-investment-in-2019-p2 https://www.openpr.com/news/1490887.html
We are stopping our Airdrop phase 1 today 15 January, but we will be considering to continue Airdrop phase 2. For this reason, you don’t need to stop sharing info about ESCB. All rewards for Airdrop phase 1 will be paid up to 1 February.
Our technical department is busy testing the MVP exchange platform for the experimental environment. Soon we will be able to explain the dispute resolution subsystem based on Ethereum keys. In the meantime, we posted the concept of HMW on Github. The development of such a complex system as escrow services on the Ethereum blockchain requires a great deal of effort so we plan to establish a system of grants/rewards for third-party developers after listing on the exchange.
We are happy to announce that our token will soon be trading on https://p2pb2b.io exchange. Agreements have already been signed and we are currently working with the exchange for an easy adoption but unfortunately, we cannot disclose all information right now. We are preparing a big announcement in conjunction with the trading platform, which will be the first to offer the ESCB token to its users. You can find some information in press-releases https://coins.newbium.com/post/24763-8-projects-to-consider-for-investment-in-2019-p2 https://www.openpr.com/news/1490887.html
We are stopping our Airdrop phase 1 today 15 January, but we will be considering to continue Airdrop phase 2. For this reason, you don’t need to stop sharing info about ESCB. All rewards for Airdrop phase 1 will be paid up to 1 February.
Our technical department is busy testing the MVP exchange platform for the experimental environment. Soon we will be able to explain the dispute resolution subsystem based on Ethereum keys. In the meantime, we posted the concept of HMW on Github. The development of such a complex system as escrow services on the Ethereum blockchain requires a great deal of effort so we plan to establish a system of grants/rewards for third-party developers after listing on the exchange.
The Escrow Platform project seems to be a very serious conception and depending on the team's management in implementing it, the Escrow Platform project can have a great future. Congratulations. Good luck.
Do you have an understanding of how the fork of etherium will be delayed due to the identified vulnerability? This, after all, can negatively affect your token?
Holidays associated with Christmas and New Year, in different countries, were drawn out but we worked hard in those days for the benefit of our offering. From the 1st to the 4th of January we paid the referral program reward for the first time. Our telegram community is approaching close to 10 thousand as the statistics show at https://etherscan.io/token/0x5e365a320779acc2c72f5dcd2ba8a81e4a34569f our token holders are almost 8 thousand. Thank you all for such confidence!
We are happy to announce that our token will soon be trading on https://p2pb2b.io exchange. Agreements have already been signed and we are currently working with the exchange for an easy adoption but unfortunately, we cannot disclose all information right now. We are preparing a big announcement in conjunction with the trading platform, which will be the first to offer the ESCB token to its users. You can find some information in press-releases https://coins.newbium.com/post/24763-8-projects-to-consider-for-investment-in-2019-p2 https://www.openpr.com/news/1490887.html
We are stopping our Airdrop phase 1 today 15 January, but we will be considering to continue Airdrop phase 2. For this reason, you don’t need to stop sharing info about ESCB. All rewards for Airdrop phase 1 will be paid up to 1 February.
Our technical department is busy testing the MVP exchange platform for the experimental environment. Soon we will be able to explain the dispute resolution subsystem based on Ethereum keys. In the meantime, we posted the concept of HMW on Github. The development of such a complex system as escrow services on the Ethereum blockchain requires a great deal of effort so we plan to establish a system of grants/rewards for third-party developers after listing on the exchange.
We are happy to announce that our token will soon be trading on https://p2pb2b.io exchange. Agreements have already been signed and we are currently working with the exchange for an easy adoption but unfortunately, we cannot disclose all information right now. We are preparing a big announcement in conjunction with the trading platform, which will be the first to offer the ESCB token to its users. You can find some information in press-releases https://coins.newbium.com/post/24763-8-projects-to-consider-for-investment-in-2019-p2 https://www.openpr.com/news/1490887.html
We are stopping our Airdrop phase 1 today 15 January, but we will be considering to continue Airdrop phase 2. For this reason, you don’t need to stop sharing info about ESCB. All rewards for Airdrop phase 1 will be paid up to 1 February.
Our technical department is busy testing the MVP exchange platform for the experimental environment. Soon we will be able to explain the dispute resolution subsystem based on Ethereum keys. In the meantime, we posted the concept of HMW on Github. The development of such a complex system as escrow services on the Ethereum blockchain requires a great deal of effort so we plan to establish a system of grants/rewards for third-party developers after listing on the exchange.
As described in the previous post on the technical details of the implementation of a decentralized exchange based on the ESCB9 protocol, the web interface itself and the server part will only be a wrapper for the Ethereum network based blockchain architecture.
Due to this technological solution, it is necessary to minimize the data collected from the user and not to store sensitive information on the servers of the exchange. In order to accumulate statistics, to store information about completed transactions and quickly interact with the Trust System, based on the HWM solution, the user must have a profile in the exchange database based on the ESCB9 protocol.
Regular applications use registration by email address or phone number. Registration by phone number may immediately discredit the user. Registration by email reserves the risk of phishing attacks. Registration with OAuth technology reveals even more information about the user.
We decided to abandon all these methods and implement the registration based on the signature from the Ethereum wallet. Thus, even if a stock exchange based on the ESCB9 protocol is hacked, no personal data, passwords, etc. will be known to attackers. To implement the authorization mechanism for signing a crypto wallet, we added the ability to use Metamask, Hardware-wallet, create a new Ethereum wallet, unlock a UTC / JSON-based wallet with a password in the user’s browser.
We want to achieve a balance in which the maximum amount of data that will be stored in the ESCB9 database is data available on the blockchain, or data that will not lead to a compromise due to a leak. In this case, the user will be provided with the necessary information quickly and in sufficient quantities.
When authorizing only by signing the wallet, a natural question arises about how to notify the user about actions on the exchange, how to implement security when accessing data stored on the exchange.
We hope that these three methods of receiving notifications will be enough for our users.
To check the legality of access to data stored on the ESCB9, the standard two-factor authentication mechanism OTP is used.
Also, the user can configure IP login verification. This option will be available only if he/she specifies an email address as a means of receiving notifications. The exchange stores the IP addresses of users in a database in an encrypted form using the sha256 algorithm. Each time user logs into an account from a new IP address, the hash of the IP address in the database will be compared with the hash of the user’s IP address. If the hashes do not match, the pin-code will be sent to the email address specified by the user to validate the input from an unknown IP address.
We also do not plan to use third-party services for analytics and statistics collection, such as google analytics. Since such services collect statistics on the real IP address of the user.
For the dispute resolution system, file uploading is required. For this function, we use the distributed decentralized file storage system ipfs.
Due to this technological solution, it is necessary to minimize the data collected from the user and not to store sensitive information on the servers of the exchange. In order to accumulate statistics, to store information about completed transactions and quickly interact with the Trust System, based on the HWM solution, the user must have a profile in the exchange database based on the ESCB9 protocol.
Regular applications use registration by email address or phone number. Registration by phone number may immediately discredit the user. Registration by email reserves the risk of phishing attacks. Registration with OAuth technology reveals even more information about the user.
We decided to abandon all these methods and implement the registration based on the signature from the Ethereum wallet. Thus, even if a stock exchange based on the ESCB9 protocol is hacked, no personal data, passwords, etc. will be known to attackers. To implement the authorization mechanism for signing a crypto wallet, we added the ability to use Metamask, Hardware-wallet, create a new Ethereum wallet, unlock a UTC / JSON-based wallet with a password in the user’s browser.
We want to achieve a balance in which the maximum amount of data that will be stored in the ESCB9 database is data available on the blockchain, or data that will not lead to a compromise due to a leak. In this case, the user will be provided with the necessary information quickly and in sufficient quantities.
When authorizing only by signing the wallet, a natural question arises about how to notify the user about actions on the exchange, how to implement security when accessing data stored on the exchange.
- Event notifications can be configured to receive on the device on which the entry is made to the exchange. For example, when using a personal mobile phone push-notification of actions on the exchange will be received via a secure channel.
- The user can add his personal email to receive notifications. We recommend using Protonmail or other protected platforms for this purpose.
- Also, the notification can be configured to receive messages from the bot in the Telegram messenger.
We hope that these three methods of receiving notifications will be enough for our users.
To check the legality of access to data stored on the ESCB9, the standard two-factor authentication mechanism OTP is used.
Also, the user can configure IP login verification. This option will be available only if he/she specifies an email address as a means of receiving notifications. The exchange stores the IP addresses of users in a database in an encrypted form using the sha256 algorithm. Each time user logs into an account from a new IP address, the hash of the IP address in the database will be compared with the hash of the user’s IP address. If the hashes do not match, the pin-code will be sent to the email address specified by the user to validate the input from an unknown IP address.
We also do not plan to use third-party services for analytics and statistics collection, such as google analytics. Since such services collect statistics on the real IP address of the user.
For the dispute resolution system, file uploading is required. For this function, we use the distributed decentralized file storage system ipfs.
New details about our roadmap
- We have distributed ESCB tokens in manual mode for members who did not take tokens by faucet mechanism on 1 December 2018.
- All referrals and distribution rewards will be made from 1 to 10 January 2019.
- Exchange listing will be possible from 15 January — 15 February 2019 depending on our negotiations with exchange platforms. We will announce this big event soon.
- Our development team promises to launch the ESCB exchange platform in test mode on 15 February 2019.
Jump to: