How the token registering and depositing will be done with Krakin’t exchange…

Previously, we made this post stating that we can have an exchange without using the private keys. The only private key we need is the one which alters some data within a smart-contract.

There are many solutions that different exchanges use, and solution that we want to use is to make sure everyone has their private keys to themselves. However, we are not creating a swap but a centralized exchange. We want to build a fee-less and a centralized hybrid exchange where anyone can list whatever token they want (without any need to deposit a liquidity Ethereum) and exchange it without any trading fees. We also want to avoid the use of any private keys on our behalf, and to keep the need to alter the contract parameters to a bare minimum. Also, we want to make sure everyone can get their money back if Krakin’t gets shut down.

Unfortunately, there is a part of a source code that must be exposed to a public and this means that someone else is already taking this idea from us or unknowingly developing a similar solution. In any way, it does not matter since they won’t have a clue how we solved the other half.

What we must expose to a public is the general workflow. This is something we will do right now. Within this workflow, we are marking the components for which the source code will be exposed or kept a secret. Simply, we must expose the smart-contract and oracles, while centralized solution will have to be kept a secret. Nevertheless, any experienced developer should be able to develop their own solution from this.

So basically, the idea is to make a contract that will communicate with an external database and our server using nothing but a GET call. The flowchart may be simple, but what makes this very complicated is that we need a type of a service that cannot fail to execute a call to a database and return some values. Second, we need to make the contract fail-safe. This means that even if the exchange gets cut off (for whatever reason), people can still withdraw their assets from a contract. Third, we need to make things as modular as possible so we can evolve the components. For example, we may start with an internal database and then transfer everything to a cloud-based database that is open to a public (for example, Google database). Fourth, if I were a hacker, I would attack the GET-POST part communicating between the contract and the exchange or trick the system into a false identity… To implement solutions, we simply need to separate components and this may cost additional fees on Ethereum. We have a Krakin’t token that makes a transfer too expensive, and adding the exchange contract fees on top of everything would be a complete absurd. Hopefully Ethereum will solve this and we won’t have to issue our own block-chain.

Another big problem is that we cannot have this solution fully autonomous, so if something happens to a contract owner, the asset-flow may remain frozen (unless the private keys are shared with a trusted entity).

Anyway, we must draw a line somewhere and this solution will have to do.

Another idea is to automatically register tokens as they are deposited to a contract, so the only thing the new token owners will have to do is to deposit a token and fill-out the wikipedia like page describing a token.

This is it for now. Let us hope that the Ethereum prices will rise and that the fees will get lower. Otherwise, it is standing in a way of a progress and development… and we will be forced to do something completely different in the meantime.