1        INTRODUCTIONS

There are numerous examples of centralized exchanges that were hacked. One of the reasons is because power is centralized on the hands of few powerful individuals.

On the wake of Ethereum technology, Etherdelta was pioneer at applying Ethereum’s blockchain to run critical software pieces of an exchange in a decentralized, safe and transparent way. This feature was a breakthrough and provided, for the first time, an easy and transparent way to list new ERC20 tokens without compromising exchange security.

Still Etherdelta has being criticized for having a poor user interface, non-automatic order book filling, API problems and works with only Ethereum network and tokens. There are currently no decentralized exchanges that work for both Ethereum and Ethereum Classic chains.

Classic Delta fills this gap, it is an exchange that works with ERC20 tokens from both the classic and forked Ethereum networks and promotes positive social behavior by applying zero or reduced fees to selected social coins.

1.1         Background

The Centre for Citizenship and Governance (CCEG) is a non-profit Think Tank focusing on the challenge of quantifying the value of non-financial transactions. In January 2017, CEEG launched the CCEG UN Lab, which has developed the Seratio Blockchain. After a successful Initial Coin Offering (ICO) in Q3 of 2017, CCEG has created a web-wallet.

The development of an exchange complements CCEG’s vision to have a robust and sustainable ecosystem in the movement of value.

1.2         Assumptions and Constraints

• Etherdelta known API problems
• Interface with the Ethereum network
• Our own interface with Forked and Classic Ethereum networks
• Marketing strategy
• Legal requirements

 

1.2.1        Assumptions

• Etherdelta known API problems
• Interface with the Ethereum network
• Our own interface with Ethereum network

 

Etherdelta known API problems

Because of Etherdelta alleged problems and due to the evidences that Forkdelta has solved similar problems, it is assumed that ForkDelta doesn’t currently present any API problems and for this reason the starting codebase to be utilized is going to be Forkdelta’s rather than Etherdelta.

 

Interface with Forked and Classic Ethereum networks

Both services Etherdelta and Forkdelta are interfacing the application with the Ethereum network by means of myetherapi.com. This is a very famous endpoint and might present bottlenecks in providing the interface to the Ethereum blockchain whenever too many calls are sent at the same time.

The effect of clogged calls to the endpoint reflects on user interaction due to increased delays for every operation that involves communication exchange with the Ethereum network. As we have developed Seratio’s own forked and classic Ethereum endpoints we can compare user interaction with both services.

 

Our own interface with Ethereum network

When we compared our own endpoint, which we built on top of Google Cloud service, with already well stablished Ethereum endpoint service provider Infura, the operational delays we had were substantially lower.

It may also be so that when comparing with myetherapi.com we have a faster private endpoint. Because of this assumption the utilization of our endpoint to speed up ClassicDelta’s user interaction is an alternative as long it doesn’t compromise our wallet service.

To make sure there will be no compromise to services that rely on our endpoint (including Seratio wallet), metrics of how the endpoint is behaving must be in place.

 

1.2.2        Constraints

• Marketing strategy
• Legal requirements

 

Marketing Strategy

To follow success of EtherDelta by imitating their strategy. The figure 1 illustrates EtherDelta success in numbers, retrieved on April 9^th, 2018.

 

Compared to other decentralized exchanges, Etherdelta has greatest market capitalization as can be seen on Figure 2.

 

To attract a wider audience to our exchange, other than Seratio’s coins are going to be traded within the platform. But the coins that are going to be naturally more promoted in a non-explicit way are the ones with Seratio’s stamp on it.

Are possible means of promoting:

• order in list of tokens
• fees practiced
• Propaganda

To promote Seratio’s eco-system growth in a healthy way, a fee policy will be set in place to make sure the operation is at the same time profitable, and discretely positions Seratio social coins at premium levels. It is to be considered a variable fee proportional to the amount of SER coins a trader holds.

 

Legal Requirements

As a decentralized exchange that works with cryptocurrencies only, the task of running KYC and AML checks is not necessary because that is supposed to have already happened when converting from fiat to cryptocurrencies and vice versa. And not from crypto to crypto as our exchange is being strategically positioned.

A legal understanding of all implications related to this decision is needed to make sure there won’t be any future pitfalls.

 

2      Technical Overview

A deeper look at ForkDelta source code shows that it is a DApp[1]. DApp is an abbreviated form for decentralized application. As both ForkDelta and EtherDelta are utilizing Ethereum blockchain to perform its server operational side, this means they are basically relying on a combination of two technologies:

1. Web page front end.
2. Ethereum smart contracts back end.

[1] A DApp has its backend code running on a decentralized peer-to-peer network. Contrast this with an app where the backend code is running on centralized servers. If an app=frontend+server, since Ethereum contracts are code that runs on the global Ethereum decentralized peer-to-peer network, then DApp = frontend + contracts.

 

3        Philosophy

3.1        What is ClassicDelta?

• ClassicDelta is a free, open-source, client-side interfaced exchange.
• It allows users to interact directly with ClassicDelta’s smart contracts while users remain full control of their keys & funds.
• User and only the user is responsible for its security.
• ClassicDelta cannot recover user’s funds or freeze user’s account if it visits a phishing site or lose its private key.

3.2        ClassicDelta is not a Bank

• When user opens an account with a bank or exchange, they create an account for it in their system.
• The bank keeps track of user’s personal information, account passwords, balances, transactions and ultimately its money.
• The bank charge fees to manage user’s account and provide services, like refunding transactions when user’s card gets stolen.
• The bank allows the user to write a check or charge its debit card to send money, go online to check its balance, reset its password, and get a new debit card if it loses it.
• User has an account with the bank or exchange and they decide how much money it can send, where it can send it, and how long to hold on a suspicious deposit. All for a fee.

3.3        ClassicDelta is an Interface

• The user must already have an account created on Ethereum blockchain with access to a cryptographic set of numbers: its private key and its public key (address).
• The handling of user’s keys happens entirely on user’s computer, inside its browser.
• ClassicDelta never transmits, receives or stores user’s private key, password, or other account information.
• ClassicDelta charges a transaction fee in accordance to publicly provided fee policy.
• Users are simply using ClassicDelta’s interface to interact directly with ClassicDelta’s smart contracts deployed to both Ethereum blockchains.
• If user sends its public key (address) to someone, they can send user ETH, ETC to that address. 👍
• If user sends its private key to someone, they now have full control of user’s account. 👎

3.4        ClassicDelta needs each user to understand that it cannot…

• Access user’s account or send user’s funds for it.
• Recover or change user’s private key.
• Recover or reset user’s password.
• Reverse, cancel, or refund transactions.
• Freeze accounts.

3.5        The user and only the user is responsible for its security.

The user must be diligent to keep its private key and password safe. User’s private key is sometimes called its mnemonic phrase, keystore file, UTC file, JSON file, wallet file.

If user loses its private key or password, no one can recover it. If user enters its private key to a phishing website, it will have all its funds taken.

3.6        If ClassicDelta can’t do those things, what’s the point?

Because that is the point of decentralization and the blockchain. The user doesn’t have to rely on its bank, government, or anyone else when it wants to move its funds. The user doesn’t have to rely on the security of an exchange or bank to keep its funds safe. And that is exactly why the blockchain and cryptocurrencies are valuable.

3.7        Movement of financial and non financial value

Money is a model of value. CCEG is confident that also non financial value can be modeled and traded likewise. To buy land with love, for example:

What a lovely purchase you’ve made.

That would be fantastic wouldn’t it?

 

4         Functional Context

As can be seen on Figure 3, the user interacts with ClassicDelta DApp willing to perform either one of the two use cases:

• Collect market information, where the user utilizes the website as source of information to accessorize its decisions regarding its assets.
• Exchange ERC20 tokens where concretely the tokens are converted from one to another nature and which depends on previous item.

 

The Exchange ERC20 tokens use case comprises the following two other user cases:

• ERC20 tokens trade, where new buy or sell orders can be placed.
• ERC20 tokens Input/Output, where tokens or ethers are deposited, transferred or withdrawn.

ClassicDelta must provide infrastructure to support all the use cases comprised by ClassicDelta DApp component which is drawn on Figure 3 as the major surrounding rectangular box.

 

To provide an exchange that works for both forked Ethereum and Ethereum Classic, the components and connections shown on Figure 4 are needed.

 

Where the FrontEnd component is the web application that holds the user interface in place and organizes accesses to the back end (comprised by both Ethereum networks smart contracts) to ultimately fulfill user’s expectations.

In the development of the Seratio wallet, the following components were already developed and can be used by Classic Delta exchange too:

• Forked Ethereum Endpoint
• Ethereum Classic Endpoint

 

These components are already working properly and interact directly with Forked Ethereum and Ethereum Classic Blockchains through already built-in Interface Web3 JavaScript API.

 

4.1        User Requirements

ClassicDelta Dapp needs to provide the functionality to support two types of users already represented as actors on Figure 3.

• Regular user
• ClassicDelta’s Admin

Because ClassicDelta is a decentralized exchange, there is a reduced set of exclusive activities for ClassicDelta’s admin to perform. Still, in a normal scenario, the admin must manage each ERC20 token lifecycle by listing or delisting tokens and to make sure information provided within each token project is legit and not misleading.

A regular user needs to upload locally its already generated public and private key to unlock the exchange functionality. The safety of this process is of user’s responsibility since ClassicDelta only acts as an interface to the blockchain and does not store personal sensitive information in its servers.

ClassicDelta’s admin has more responsibilities in the sense it is a regular user but also a key actor for the working and maintenance of the platform. ClassicDelta’s admin will be responsible to orient community and drive requests accordingly to technical team. Tasks are split on two fronts, the backend mostly blockchain development and the frontend, mostly user interface and pursue of user expectations.

4.2        Data Flow Diagrams

 

Figure 3: Sequence diagram of general data flow.

As can be seen in the sequence diagram of Figure 3, the basic data flow starts with the user request to the web server requesting the webpage or general information. Consequently, to render the information accordingly, the frontend needs fresh data from the connected blockchain endpoints, in this case Ethereum Classic and forked Ethereum.

There are more specific diagrams that are subject to be detailed in the development process comprising the following scenarios:

• Creation of new account
• Account import, account forget
• Ledger Nano S integration
• Set gas price
• Place buy, sell order
• Cancelling an order
• Deposit, withdrawals, transfers.

4.3        Logical Data Model/Data Dictionary

The blockchain can be considered a decentralized database where a lot of historical information can be retrieved just by browsing it. However, the speed of access to blockchain data depends on a variety of factors and has associated costs. Since the blockchain is constantly writing history to the distributed ledger and once a block is written there is virtually no way to change it, there are specific use cases where a regular database can be handy to post attach information to previously written blocks. A good example of when this is needed is in the addition of metadata identifying and linking a dropped by a replaced transaction.

But more complex queries throughout a huge amount of data (more than 50 GB) can be used upon a regular database to extract valuable information. One example is extracting technical analysis indicators with artificial intelligence techniques to better orient in which tokens the user should rather invest on  a given Friday.

 

4.4        Functional Requirements

• To provide the user with updated information about the order book status in real time (with a delay no greater than 5 seconds).
• Execute deposits, withdrawals, transfers, buy and sell orders placement smoothly and without human intervention. Humans prohibited here!
• Whenever there is a relevant blockchain event, keep information shown in the website coherent to blockchain’s state.
• To protect privacy and user data with state of the art technology.
• To have the most critique parts if not the entirety of the exchange code open source with bug bounty programs to increase safety and reduce risk surface. This follows Parity’s state of the art safety procedure[1].
• Periodic auditing by selected companies.

[1] http://paritytech.io/the-multi-sig-hack-a-postmortem/. On Wednesday 19th July, 2017 a bug found in the multi-signature wallet (“multi-sig”) code used as part of Parity Wallet software was exploited by parties unknown. As of the time of writing, three wallet accounts holding large balances of ETH have been compromised and the balances moved into accounts held by the attacker. The self-titled “White Hat Group” used the same exploit to secure the other compromised wallets within Ethereum, with the stated intention of returning control to the original owners.

 

5           Follow up

5.1         Milestones

 

The milestones were raised accordingly to the foreseeable future based on research already made and are present on Table 1.

 

Table 1: Milestones for the operation of Classic Delta exchange

Milestone	Due Date mm/dd/yyy	Completed / Delayed / On time
ClassicDelta Smart Contracts Development	03/05/2018	Completed
Functional Requirement Preliminary Document	03/12/2018	Completed
ClassicDelta Smart Contract Deployment	03/19/2018	Completed
Website launch and integration	03/26/2018	Completed
Exchange API launch	10/26/2018	On time
Incremental upgrades	12/26/2018	On time

 

The code of the smart contracts, the most important software piece here, was already created based on EtherDelta smart contracts.

The ClassicDelta organization was created at GitHub to fork ForkDelta. The starting web server is GitHub to speed-up development process. But as soon the project scales a more professional service is planed to take place with Cloudflare DDoS protection around October 2018. The exchange is already beta launched and can be tested here for forked Ethereum network.