Contest Entry @hortonelectric: FreeTon DEX Architecture & Design
This document uses code format to reference the original PDF contest rules. All other content is original and part of the contest entry for best workflow and ease of reading.
Originality of this work
I would say that the primary goal here is to not copy each otherās work, but Iām going to release my work before the contest ends, so that others can try to do better. That might be unconventional and whatever I put here might change. I guess if I get something wrong in the draft and you fail to do your own research, keep in mind, I am not trying to sabotage you, I just got it wrong.
Contest Proposal
Contest dates
ā Warm-up period: 23-25 October 2020
ā Submission period: 26 October (00:00:00 UTC) - 15 November (23:59:59) 2020
General description
The goal of this contest is to work out possible architectures, design approaches, and
technological stack for implementation of decentralized exchange (DEX) on top of free ton
blockchain and infrastructure.
Good working examples with different approaches on the Ethereum network could be found
here - https://defipulse.com/ in category DEXes and include:
1. https://uniswap.org/
2. https://curve.fi/
3. https://balancer.finance/
4. https://loopring.org/
5. https://bancor.network/
Both popular approaches (1) Liquidity pools as in Uniswap and Bancor and (2) Distributed
orderbook as in loopring and idex are possible.
Governance is an optional requirement but can be used as a way to reward active users
and/or distribute profits for trading and liquidity provision.
All tools developed prior to the contest on the free ton network can be fully utilized for
purpose of this contest (e.g. atomic swaps, stable coins solutions, etc).
Deliverable of the contest is a technical paper with a description of the proposed
architecture. Images, diagrams, and illustrations are nice to have. A good economic model is
a huge plus as well.
Motivation
Thereās no need to explain that in the heart of any economy - be it state-governed, global or
local market exchanges or community governed blockchain, there is always a need for a
place to exchange assets like tokens, loans, IOUs, or other types of liabilities.
Free Ton is no exception and desperately needs a mechanism of a non-custodial distributed
way of exchanging assets/tokens (simply ādecentralized exchangeā or DEX) and the ability to
earn income for the provision of liquidity to the market with different risk/reward
characteristics (depools is a good example of earning on the provision of liquidity).
Such a decentralized exchange might become a major service for other dApps like
decentralized borrowing/lending services, payment solutions, derivatives trading, and other
ways of earning passive income.
General contest requirements
Your submission should include:
ā The basic economic model and description of money flow in the system
TON-based DEX Proposed Architecture & Design
Basic Economic Model: Liquidity Pools
The two primary DEX choices that we can use today are the āLiquidity Poolā model and the āDistributed Order Bookā model. My contest entry describes a āLiquidity Poolā model.
In a liquidity pool model, users send 2 currencies in a specific ratio, for example 1 ETH to 400 USDT (based on the market price among other things). Later, when other users need to swap ETH to USDT or vice versa, the liquidity provided earlier is used to ensure a smooth swap.
Simply put, when a user wants to swap 2 currencies, the liquidity pool makes it rather simple by offering a price with a āslippage toleranceā, meaning, the biggest loss that the user is willing to take in order to swap his two assets at the market price. This is in contrast with a stop-limit or limit order system, which concepts are made more complex (and more invisible & efficient) by the liquidity pool slippage tolerance system.
The obvious advantage of liquidity pools over distributed order books is the elimination of āfake buy/sell wallsā that create undue speculation and can mislead traders.
Listing tokens in the liquidity pool DEX model is a no-nonsense exercise, and itās easy to verify the value of a token based on how much liquidity can be ālockedā. In short the liquidity pool model can be a way to ensure the authenticity of new listings, as long as investors do their own research.
Thereās a host of information on what liquidity pools are and how they relate to distributed order books on Google. The author refrains from further explanation for the sake of brevity.
https://www.google.com/search?q=liquidity+pools+vs+distributed+order+books&rlz=1C5CHFA_enMY857MY857&oq=liquidity+pools+vs+distributed+order+books&aqs=chrome..69i57.3902j0j7&sourceid=chrome&ie=UTF-8
ā The general technical architecture of the solution including all of the features listed
below in the hard evaluation criteria section along with the proposed customer
journeys
Technical architecture/stack
-
react or Vue work fine for the front-end
-
of course as Iām proposing a fork of something like Uniswap, one could look at sushiswap.fi as a great example of how the front-end might look and one of the popular forks like sakeswap for advanced smart contract implementation
-
weāll have to use subgraph with thegraph.com or something very similar
ā Detailed technical specification of the proposed implementation with the justification
of the selected approach: smart contracts, integration layer, interfaces
-
You can pretty easily take a look at Uniswap contracts and maybe 100 other ones for how to build a LP-based DEX.
-
Integration layer. We gotta ditch the flowJS and use Typescript. I already have GitHub - gram-net/gram-sdk: A TON Toolkit with lots of up-to-date Typescript stuff.
-
Interfaces. Well, you hope there are only a couple of screens here. Again you can take a look at Uniswap, and at the existing designs available for most crypto wallets like TrustWallet or Surf.
Thereās very little reason to describe these parts of my solution, but of course I do have something. Iāve created a fork of uniswap front-end called Hulk https://exchange.hulk.finance/ which is really really really just a fork with basic implementation, but I hvenāt got farther.
My posits written like this are the ones to look at. Iām not technical enough in this area to offer more.
ā Name and contact information of the contestant for communication (Telegram
username, e-mail)
@hortonelectric
[email protected]
DoD: signed via Malaysian entity and Philippines citizen. Iām only the mouth, Iām not the heart 
Your work and the proposed solution must be:
ā Original. It should not include more than 10% of other contestantsā works;
Originality of this work
I would say that the primary goal here is to not copy each otherās work, but Iām going to release my work before the contest ends, so that others can try to do better. That might be unconventional and whatever I put here might change. I guess if I get something wrong in the draft and you fail to do your own research, keep in mind, I am not trying to sabotage you, I just got it wrong.
ā Implementable. Keep in mind the peculiarities and goals of FreeTON;
ā Consistent. Its elements should not contradict each other and the FreeTON
Declaration of Decentralization;
ā Safe. It must ensure a due level of funds security;
A note on safety
All of us need to stop acting like thereās a way to get 100% safe. But of course we all have to assume at least some things. Donāt get too caught up in security that you forget that 100% of the systems we use today have severe security vulnerabilities.
ā Modern. Inspire by the leading market solutions.
Evaluation criteria and winning conditions
Hard criteria
I was inspired by extensive work in the Uniswap/Sushiswap smart contracts, deploying my own DeFi projects and heavy research into the area. I consider Uniswap a defining moment in the DEX story and have essentially been āall up in thatā for several months.
ā Support for non-custody exchange of any tokens within the FreeTON network
As mentioned elsewhere, briefly, the idea of āwrapped ETHā should be carefully examined and referenced as a method to allow non-custodial exchange of assets that would be considered āextra-currenciesā. Hard to say whether the same would work for any token, but theoretically it would, given the TON gas model.
ā Support for adding liquidity to the exchange from external blockchains at least
through smart contract system or using atomic swap bridges described in atomic
swap contest
About external blockchain integrations
Oracles are well-known but little understood. I donāt pretend to have a complete picture here, but I hope that the insights in this article will better entertain the concept than we have done in the past.
ā Non-custody approach to both exchange and liquidity provision
ā Scalability potential for adding new tokens
Adding new tokens is easy BUT
On any LP model (ex: Uniswap) the process for adding tokens is as simple as creating a liquidity āpairā by adding the initial liquidity.
BUT BUT BUT BUT!!! This process is flawed in the current models like Uniswap. The āmarket priceā of a token can easily get totally messed up, when liquidity for a new token goes very close to 0.
To solve this problem I propose that a pool can be completely ābought outā by a new entrant, who can reset the pool configuration.
ā Maximum utilization of the FreeTON network advantages such as speed and
sharding
Speed and sharding āadvantagesā
I posit that the speed and sharding will not be any particular kind of advantage for this particular purpose.
Having said that, it could be extremely useful to use a virtual workchain for each and every liquidity pool, but testing that, I would say, the TON technology is still quite untested.
Therefore the best solution is to develop methods for using āadditional currencyā features as well as ānew virtual workchainā features, if the volume of a particular DEX reaches certain high levels.
Until people can actually use the software, itās impossible to tell whether things like that will work. That doesnāt mean we shouldnāt develop it though!
ā Optional governance mechanism or a possibility of adding such a mechanism in the
future to govern the parameters of the exchange, including but not limited to the
liquidity provision and the fees
Governance
There are already a number of effective governance contracts which can control which functions are run on smart contracts.
I propose a āstandard tokenā similar to the ERC223 but with added functions that can control the following token characteristics via a time-locked governance model (AT LEAST):
The % of tokens in circulation held by an individual voter should determine the weight of each vote, because thereās no other way to determine whether, for example, 100 individual holders are actually all influenced by the same person, effectively discouraging āstealing votesā or political propaganda surrounding governance.
I propose a standard liquidity provision and fees governance model similar to the storage fees system provided by TON blockchain to be implemented on virtual workchains, when a tokenās exchange liquidity reaches a point, and this could be triggered by a vote.
ā A good economic model for exchange, liquidity makers (providers), and liquidity takers
Economic models for liquidity
The biggest problem we have is that scammers and opportunists went after Uniswap and its various āchildrenā in a massive way. In one sense it was a way for people to capitalize on writing good smart contracts. But the rewards were incredibly disproportionate to the effort offered (E.G. K33per, Sushiswap which netted certain people 10s of millions for simply writing a contract that the foolish money-grubbing DeFi investors jumped all over).
To combat this problem is simple enough, and TON does tend to automatically do it, at least so far.
Therefore itās my proposal, to simply ātry Uniswap with some useful changes on TONā and ābuild a better wallet interface that takes advantage of TONās awesome gas paradigmā
Artifacts
ā PDF with the technical paper containing the backlink to the submission
Soft criteria
ā Your position on existing DEX problems (see āExisting DEX problems to be aware ofā
section below) and how they are tackled in the proposed architecture
ā Detailed and easily understandable charts explaining the architecture and business
processes
Explanation of what Uniswap is
This has been explained above, and there are a host of information telling all about how Uniswap works, flowcharts and etc. I suppose there are some interesting ones.
TODO, or Iāll just ignore it and let you figure it out as a juror with at least some kind of experienc (hopefully you have Googled this!)
ā Brevity
ā Mostly everyday English to facilitate understanding
L.O.L.
ā Readiness to participate in the implementation of the solution in the next stage
Oh sure, Iām ready to go and help review code and build interfaces, I wouldnāt be here if I wasnāt. I was deep-diving into things when TonLabs hadnāt even open sourced hardly anything. I compiled WASM libraries for FIFT and FUNC (and they work even on iOS). I am not a stranger to hard work, I just need to be paid more for my work FFS
Existing DEX problems to be aware of
1. Frontrunning (flash boys 2.0 and Mooniswap vs Uniswap value proposition). If it is
not possible in Free TON (as it is), should be clearly stated why.
Front-running in Uniswap vs TON
Of course front-running is going to be possible āsomehowā. Thereās always
a way for hackers to screw things up for the rest of us.
However, the DHT protocol described in the TON whitepaper and implemented seemingly āsemi-wellā in the TON source code we have today, in addition to the fee structure used in TON, will mean that hackers will need to come up with an entirely new way to do it.
Since the receiving contracts can decide whether to accept a message or reject it, they can by definition reject messages that might be front-running by offering higher GAS fees.
However, contracts would still need to be written so as to predict a front-running attempt, because specifically, the data from the first (real) request, canāt be stored in a retrievable way in the blockchain.
I propose that to end front-running completely (if needed depending on how TONās fee and message delivery structure performs as a deterrent), we need simply create separate contract OPCODES that communicate intent ONLY, and lock specific funds and the effective price for a single block.
This is an experimental idea, but similar to what the SushiSwap makers did, to lock up liquidity that can respond faster to new transactions than a front-runner due to their effective proximity to the original request.
This isnāt necessarily a simple thing to understand, but one could research first the Sushiswap āSushiLock.solā contract and various research on the subject of front-running to get an idea how it works.
Another front-running point. Take āwrapped ETHā as the example in a real solution, but realize that ANY TON ASSET MUST BE WRAPPED to prevent front-running. We cannot transfer the asset directly. Just like Uniswap used wrapped ETH so must we wrap any TON-based asset! Right now Uniswap only wraps ETH, but TON might need to wrap any āextra currencyā
2. Shortcomings of standard curves and its inflexible nature in liquidity based approach.
These result in the issue - dilution of liquidity into several AMMs (general and specific
ones with a more specific curve like Uniswap vs. Curve) which leads to non-optimal
price execution.
On curves in liquidity
To be honest Iām not even sure exactly what this means, perhaps itās an obscure technical issue.
I think itās obvious from the contest authorās text that there is a strong need to know shortcomings of liquidity-based approaches. I think we should forego this issue while weāre this early on in the process of developing a solution, or if someone has plenty of experience, offer it in the form of an opinion, not open-ended question.
Having said that, the biggest problem we have is āeveryone for themselves mentalityā and hence why we have 1000 DeFi loan protocols and 10 of them actually have sizable amounts of liquidity. āeverybody for themselvesā is why freeTON is still obscure AF. So, end it, then we can move forward.
freeTONās governance in the early stages could ensure that only 1 or 2 DEXs are allowed to be released and promoted, which will decrease the fracturing that happened in ETH.
We run the risk of letting scientific progress get in the way of real progress here. I propose we quit messing around and try to build an effective DEX on TON right away.
3. One-sided liquidity. Impairment loss problems. The market risk of two assets in the
pool is widely discussed. These problems should be somehow covered or at least
mentioned for further research.
One-sided liquidity is easily fixed by my approach above where someone can ābuy outā the entire liquidity pool and start a new one with new parameters, and allow VOTING on these types of events so that someone has to actually agree.
Impairment loss and impermanent loss are two different things and both deserve a look.
However both of these are fairly similar problems, commonly involving the depreciation of an asset that is due to some investor āselling outā all of their shares of a token in a āstop-lossā maneuver.
The unfortunate part of this is that those who cause these types of losses are always losing their own money.
I propose that liquidity pool funds can be used to āpromise buybacksā to maintain the price of an asset. This can be done by allowing folks to āpledge liquidityā (similar to ālocking liquidityā) and that both locking and pledging should result in higher fee shares than simply āprovidingā liquidity.
4. Another liquidity pool-based approach problem is the customized proportion of
assets, number of assets in the pool, and metapools. How to regulate the number of
assets in the pool, what is the price optimal routing, will it be available to create
metapools.
I propose simply that metapools must only be able to be created by swapping liquidity from the main liquidity pool (or in some cases another metapool) so that new metapools must be essentially created by existing pool holders.
To deal with the price changes, would be simple in this solution, except the liquidity pools would need to receive price data from other pools, meaning, if I wanted to create a metapool of ETH/USDT called ETHUSDT/WBTC, I would need an oracle to tell me all of the available prices and only allow initial liquidity to be added at the correct prices.
- Orderbook-based exchanges should state clearly how the on-chain order book is
maintained and how its scalability issue is resolved. It is naive to state that
transactional expenditures would stay at an effective zero level, so it has to be
covered.
As Iāve proposed a liquidity-based solution I donāt want to comment too much on this. However I feel that an oracle-based āmirrorā of an existing order-based DEX (or even better, an INDEX of several order-based DEX books) would go a long way as a research project to understand the impact of TON architecture on order-based DEX.
Rewards
Place Reward,
TON
1 50,000
2 30,000
3 15,000
4-10 5,000
Voting
ā Jury members who vote in this contest must have a solid understanding of the
technology. Those jurors who donāt, should not vote or choose āAbstain.ā
ā Jurors whose team(s) intend to participate in this contest by providing submissions
lose their right to vote in this contest.
ā Each juror will vote by rating each submission on a scale of 1 to 10 or can choose to
reject it if it does not meet requirements or choose to abstain from voting if they feel
unqualified to judge.
ā Jurors will provide feedback on your submissions.
ā The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.
Jury rewards
An amount equal to 2% of the prize fund will be divided equitably between all jurors who vote
and provide feedback based on their votesā quantity and quality. Both voting and feedback
are mandatory to collect this reward.
Governance rewards
An amount equal to 2% of the prize fund will be divided equitably between all governance
members.
Conclusion of primary submission
Thanks for reading!
Procedural reminders to all contestants
ā Accessibility. All submissions must be accessible for the Jury to open and view, so
please double-check your submission. If the submission is inaccessible or does not
fit the criteria described, jurors may reject the submission.
Check the submission at the following web link:
ā Timing. Contestants must submit their work before the closing of the filing of
applications. If not submitted on time, the submission will not count.
Submission date: Sunday, November 8th 2020
ā Contact information. All submissions must contain the contestantās contact
information, preferably a Telegram username by which jurors can verify that the
submission belongs to the individual who submitted it. If not, jurors may reject your
submission.
Telegram username: hortonelectric
ā Content. The content published in the forum and the provided PDF file should not
differ, except for formatting. Otherwise, jurors may reject the submission.
ā Well-formed links. If your submission has links to the work performed, the content of
those links must have the contestantās contact details, preferably a Telegram
username, or backlink to your submission at the FreeTON forum, so jurors can match
it and verify to whom the work belongs. If not, jurors may reject your submission.
ā Multiple submissions.
ā Each contestant has the right to provide several submissions if they contain
different approaches to the contest problemās solving. However, if works are
not unique enough or differ just in insignificant details, jurors may reject such
repeating submissions.
ā If the contestant wants to make an additional submission that overrides the
one previously published, he must inform the Jury about this fact and indicate
the correct revision to assess. In this case, only the indicated work will count.
If the contestant hasnāt indicated the updated submission as the correct one,
only the first one will count, the Jury will reject all the others.
Disclaimer
Anyone can participate, but Free TON cannot distribute Tons to US citizens or US entities.
Proposal PDF 
Contacts 
E-mail: 
**FREETON Address: