Sparks Interview — Andromeda: As a Native of the Blockchain World, I Had Been Anticipating to Be Tokenized, Part 2
X-Order is an investment and research organization dedicated to the study of value capture in open finance. We strive to be a bridge between new finance and interdisciplinary fields with relation to science and research. It is founded by Tony Tao, who is also a partner at NGC Ventures.
Read Part 1 here.
Part 1. About Andromeda (Continuation)
Matataki has exchange too, does it have any link with the decentralized exchange that you have encountered?
I have to open my own exchange. — Li Xiaolai
Yes, the current liquid protocol used by Instant-Matataki’s exchange is in line with the evolution of Kyubey.network.
In fact, the design of Kyubey exchange originated from a contract we developed called eosotcbackup. As the name suggests, it is actually an open order book. We found that many EOS project launchers would not immediately go online to the exchange after issuing tokens, or have their own ad-hoc transaction logic. However, at this point, these tokens have already begun to flow in the private sector, and have their own prices.
Even if the transfer interface of these tokens is officially closed, people will still think of various ways to conduct transactions, such as seller directly authorizing the account containing the token to the buyer’s private key.
This kind of flow is what we call OTC. There is usually a group leader who acts as a guarantor and charges a certain handling fee from it. This is very similar to the period when people were playing altcoins at the end of 2014 and the beginning of 2015. At that time, there would be cases of guarantors running away from time to time. I was wondering if I could develop a decentralized guarantee system to solve this problem once and for all? Now, I find that I hold much more development tools in my hands compared to the past……
The first version of the EOS OTC exchange contract took only one night to develop and was deployed to the main network. With the help of many friends, the “product” was officially launched on the second day. In the first version of the exchange, there are only orders, but no matching function. The matching of orders requires the users to operate on their own. The common scenario is after the two parties to the transaction have communicated the price on WeChat, they will respectively put up and take up the order on the exchange.
It’s such a simple long-tail trading scenario that is unimaginable to develop on Ethereum. The fee and latency are simply too high. However, in EOS, users can easily use our products for free. As the rate of the EOS CPU is very unstable, coupled with the product scale expansion, therefore in order to keep our Dapp available all the time, we have to buy more EOS in the market to mortgage CPU sufficiently. Then came a new issue: some traders put up some symbols on the exchange, but they issued cheap “counterfeit tokens “ with different contracts. Some users saw these low-cost “counterfeit tokens”, and out of the fear of losing out (FOMO), they chose to buy them without checking the name of the contract carefully. As a result, some of our early users bought these “counterfeit tokens” and after realizing it, they came to us to “protect their rights”. Although this is not a contract bug, considering that we didn’t explicitly warn users of the risk of counterfeit tokens in the design of our UI / UX, it had misled them to a certain extent. Therefore, we “compensated” the losses of these users.
Hence, we lost money on this version of the exchange, but considering that it accumulated enough popularity at the beginning of its launch, we decided to focus on the development and improve it.
We added a white list mechanism in the contract allowing the operators to review it, thereby completely eliminating the misleading situation of “counterfeit tokens”. At the same time, we added a matchmaking engine in the contract, because EOS integrates boost’s multi_index map, which can flexibly perform a binary search in the case of multiple keywords and optimize the time complexity. Hence, we can achieve a similar level of experience as other semi-centralized exchanges. In order to give users a better interaction experience, we also redesigned the UI / UX. As for the earliest version of the exchange, it will be preserved by us under “protection mode”. Since it does not need the administrator to edit the white list, it is more Serverless, and more in line with our definition of Public Good.
Later, of course, it’s the story of the bleak period for cryptocurrency prices, and we were struggling on the borderline. During the same period, many semi-centralized exchanges on EOS began to seek transformation. Our code has since been lying quietly in GitHub until a few days ago, an EOS developer from a foreign community came to ask about our exchange, how to set up and some questions about the contract. I was very excited about this, and I was actually looking forward to giving it a new life.
At present, the design of the fan token mainly comes from our reflection on the exchange project. Looking back at the agreement of the decentralized exchange, there is still some immaturity in its design. The biggest flaw is that Bancor’s liquid protocol is not compatible with the order listing system. The other problem is that the trading mechanism that we have previously designed is still too complex.
Almost in the same period with the development of our products, I noticed that a decentralized exchange has also been launched on Ethereum. The mechanism of this decentralized exchange comes from a proposal by Vitalik on Reddit three years ago — “can we build a decentralized exchange by building a market prediction method?”
This exchange is called Uniswap. If I had to redesign it now, I would have chosen Uniswap.
As for decentralized exchanges, in addition to the abovementioned form of automatic market making, there is also the thin order book form, which both have their pros and cons. I am not an expert in this aspect. For details, please refer to the guest sharing during DeFi.WTF last held in DevCon, Osaka, 2.2 Tom Schmidt @ 0x — Evolution of Exchange Architecture of DEXes.
Of course, other than the flaws mentioned above on the protocol level, I think the bigger problem is that there are too few users in this market segment.
Originally, programming related collaboration is nearly the most advanced form of generalized collaboration, which requires professional knowledge and a lot of communication. Thus, the evaluation system is also difficult to carry out automatically. Then again, there are fewer programmers developing Dapp, even fewer of them are developing it on a specific public chain, and much less know how to design the Dapp model correctly. In hindsight, I may have just designed a product for my own use.
Building for crypto influencers. This is another common trap for crypto startups. In most industries, if you build a product that influencers will love, millions of other customers will follow. But crypto is a weird space — the preferences of crypto influencers are very unrepresentative of crypto customers. — Haseeb Qureshi, Dragonfly Research, So you want to build a crypto startup?
There is a greater world outside of Ethereum and blockchain.
Could you explain more about the design of fan tokens?
Liquid Protocol
Comparing Bancor and Uniswap, the latter has won for many reasons. First of all, Uniswap will not be rent-seek by Bancor tokens (previously, Bancor operators contacted us to help our EOS tokens be listed on Bancor’s exchange, of course, the cost is 5000 USDT). The more fatal reason is that Bancor’s liquidity is dead, while the liquidity of the Uniswap protocol is flexible enough to dynamically adjust with the market changes.
Lastly, the premise of Bancor protocol — assuming cw is a constant value, seems unreasonable. All of these reasons will lead to Bancor’s anchored tokens to lack decoupling mechanisms. I have also explained this in my article in Dapp Review: Re-examining Bancor’s algorithm and why cw is a failed design.
I still remember when I just opened the Vyper contract, which has less than 200 lines with Uniswap core, I was immediately attracted by its grace. Uniswap’s protocol was minimalist and really achieved what Philip Stark defined as Less is more.
In short, compared with the Bancor protocol that we have used before, the Bounding Curve of the Uniswap protocol has nothing to do with cw. It is an inverse proportional function, and there is no BNT to rent in the system.
The core mechanism is that the liquidity of Uniswap is dynamic and provided by users.
This feature meets my requirements perfectly for AMMS (Automated Market Makers) — it should be smart, generous, and grow with the growth of the token itself. Further, its liquidity can be transferred externally, and live in harmony with the external environment — and the purpose of these designs is so that it can leave the cradle of the reserve system and realize decoupling.
For the decoupling experiment, we can refer to the article that X-Order published — Ponzi Structure and Law of Expansion.
Why Ethereum private chain?
This question can be answered in two parts.
First, why do we choose to return to Ethereum?
First of all, Ethereum is the most politically correct choice. Moreover, we can also make the most use of its infrastructure by developing with Ethereum. For example, the protocol of Uniswap can be directly used by forking, and Etherscan can also be directly used to trace each transaction record. In addition, Ethereum itself is also in the process of rapid changes and updates. Last month, at the Ethereum Developer Conference held in Osaka, we saw many surprising new features, such as the significant performance improvement brought by the use of Plasma, zk-rollup and optimal rollup. These allowed us to see the infinite possibility of Ethereum in the future.
Choosing the private chain is a necessary trade-off that we have to make after researching on the current challenges that other Dapps are facing, and the current situation that our own products are in. At the end of Felix Feng’s slide, ‘Story of DeFi, How it Started, Where It Stands Now, DeFi Definition Revisited’, it summarizes the four problems that the DeFi industry currently faces, and I think it will be the same when promoting it to the Dapp field.
One, the bottleneck of increasing the number of users
Two, myths of capturing value
Three, unverified decentralizing routes
Four, potential risks relating to smart contracts
Point one is the easiest to be understood and it is the most critical point. As mentioned above, most blockchain users are speculative users. Solving the customer acquisition problem is something that every industry practitioner must face. The most effective solution is to create some sort of new value, or redistribute the misplaced value, so as to meet the needs of a certain user whose demand was not well met. This is what we often call the discovery of a Killer Dapp. Monetization and payment are one of them, but we need more. The other way is to make some auxiliary facilities, among which MyKey is the most representative. It is a system that supports multi-chain autonomous identities and has gained a lot of growth at present.
The second is the most complex problem to consider when designing Dapps. Currently, there does not exist a mature methodology in the market. Some relatively failed examples are the Raiden network and the Bancor network on Ethereum, which is generally considered to not doing a good job in capturing value. On the other hand, MakerDao is an example of successful value capturing. MakerDao has established a meaningful market structure, met the demand of a stock market just in time and closed the business loop. Therefore, it stands out from the rest.
Point three is closely related to point two. As a Dapp developer, the features you are expected to meet by default are Opensource, Serverless and Forkable. Before you are forked by others, how to capture enough value, form enough network effect to create barriers, and effectively managing the chain in this process are also the aspects we have to think carefully about.
We don’t need to talk much about the fourth point. Probably every Dapp developer is required to pay some tuition fees. Even Gavin Wood paid nearly 500,000 ether as tuition fees for a silly mistake.
Choosing private chains can effectively provide a buffer for solving the abovementioned problems, and it can also help us save the user’s transaction fee. After all, considering the product form, our product is supported by numerous small payments.
We hope to make use of the resources from the Internet world, carry out a kind of “re-attack”, and guide users to the world of Web3 step by step.
What’s Next?
Stay tuned to the remaining interview in the next few articles!
Connect with us on Linkedin!
Translated by (via our WeChat Account): Xin Yue
Editor: Daphne Tan
