Free TON

Contest Proposal: FreeTon DEX Architecture & Design 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
  • 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
  • Detailed technical specification of the proposed implementation with the justification of the selected approach: smart contracts, integration layer, interfaces
  • Name and contact information of the contestant for communication (Telegram username, e-mail)

Your work and the proposed solution must be:

  • Original. It should not include more than 10% of other contestants’ works;
  • 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;
  • Modern. Inspire by the leading market solutions.

Evaluation criteria and winning conditions

Hard criteria

  • Support for non-custody exchange of any tokens within the FreeTON network
  • 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
  • Non-custody approach to both exchange and liquidity provision
  • Scalability potential for adding new tokens
  • Maximum utilization of the FreeTON network advantages such as speed and sharding
  • 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
  • A good economic model for exchange, liquidity makers (providers), and liquidity takers

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
  • Brevity
  • Mostly everyday English to facilitate understanding
  • Readiness to participate in the implementation of the solution in the next stage

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.

  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.

  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.

  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.

  5. 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.

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.

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.
  • Timing. Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.
  • 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.
  • 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.

4 Likes

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.



● 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

  1. You can pretty easily take a look at Uniswap contracts and maybe 100 other ones for how to build a LP-based DEX.

  2. Integration layer. We gotta ditch the flowJS and use Typescript. I already have github.com/gram-net/gram-sdk with lots of up-to-date Typescript stuff.

  3. 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

hortonelectric@gmail.com

DoD: signed via Malaysian entity and Philippines citizen. I’m only the mouth, I’m not the heart :slight_smile:


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):

  • token supply,

  • min/burn/deflation rules,

  • whitelist/blacklist,

  • time required and number of votes required to reach a consensus

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

https://firebasestorage.googleapis.com/v0/b/ton-labs.appspot.com/o/documents%2Fapplication%2Fpdf%2F2pnir8h8oghkgkpyrh5-FreeTon%20Dex%20Architecture%20%26%20Design%20Proposal.pdf?alt=media&token=1a5d2bea-777b-4f6f-92a2-842c1fbea31f


● 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.


  1. 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.

3 Likes

Free TON does not currently have a token ecosystem on its platform. Therefore, I think that at the moment it is much more important to do cross-chain solutions for DEX.

FreeTon DEX Architecture & Design Proposal

Proposal PDF

Proposal Google Doc (having a well organized table of contents to navigate)

Highlights

  • Non-custodial censorship resistant instant exchange.
  • Cross-chain solutions implemented in Nascent Phase, based on the current state of Free TON ecosystem.
  • Highly experienced in the Ethereum DeFi team.
  • No waiting for deposits and withdrawals.
  • Implements time-tested approaches from Uniswap, Curve, Balancer, Bancor and Moniswap exchanges.
  • Deflationary governance Hilda Token to effectively incentivize/reward liquidity providers, traders and the development team. Killer features described in the corresponding section.
  • Impermanent loss mitigation for liquidity providers by introducing free to use on-chain oracles like Keep3r.
  • Customizable exchange fee for liquidity providers and slippage for traders.
  • No strict 50/50% for pairs in the pools, you can customize the proportion to adjust risk exposure for any token, e.g. 98/2%.
  • Instantly add/withdraw any token pair. No waiting for approval.
  • AragonDAO for governance.

License

The sources are licensed under MIT license.

Contacts

Telegram: @Defi_Alert
E-mail: DefiAlert@protonmail.com
Free TON Address: 0:f8603be35430ba13025d493504bc153f199185649c74f5ded84080dd07e5a829

I, as Free TON Defi jury, openly state that I abstain from voting on this proposal.

1 Like

FreeTon DEX Architecture & Design Proposal

:rocket: Proposal PDF :rocket:

:speech_balloon: Contacts :speech_balloon:

:rocket: Telegram: :guitar: @ducktalesblock
:email: E-mail: :email: info@itty-bippy.space
:gem: **FREETON Address: :gem:0:c0efbaaa82ea20862cc7b49fdd57288275eae56ff92832c5c948a37943888691

1 Like

FreeTon DEX Architecture & Design Proposal

Proposal PDF:

License

GPL-3

Contacts
Email: cto@svoi.dev
TG: @lailune
FreeTON forum: @lailune

1 Like

FreeTon DEX Architecture & Design Proposal

Proposal Google Doc (English, commenting enabled)

Proposal Google Doc (Russian, commenting enabled)

Proposal PDF

Highlights

  • Completely decentralized and scalable solution
  • Integrated with TIP-3 specification
  • Source codes of smart contracts and a demonstration of the concept’s functionality on github [https://github.com/charon-exchange/exchange-proto]
  • Interface for governance
  • Architecture optimized for low gas consumption

License
The sources are licensed under MIT license.

Contacts
Telegram: @sergeydobkin
Telegram: @nailkhaf
E-mail: sergeydobkin8@gmail.com
E-mail: 854297992c@gmail.com

Free TON Address: 0:54838fa8f5009228e75bc260c14ac2a7931ec688edf3fc92866c5c2c10054a4f

1 Like

Hi there ! Here is my work for this Contest.

TG: @HeKit
Email: nikitlysenko@gmail.com
FreeTon forum @cyber

1 Like

Submission for FreeTon DEX Architecture contest

Google Doc for comments:

PDF:

Contacts
TG: @dnugget , @yanmsk
Email: radiance.here@gmail.com
FreeTON forum: @dnugget

License
Document licensed under CC-SA license.

1 Like

Hello! Here is my FreeTon DEX Architecture & Design Proposal.

Proposal PDF

Google link:


Telegram ID: @dividik
Email: kondensfo@mail.ru

Everything published under the GPL3 license.

There was a failure during the submission of a proposal for the competition, so I submitted again.

1 Like

Here is my proposal:

MIT License
TG @rainblowing
Mail rainblowing@me.com

1 Like

Hello!
My submission:


My Telegram: @cryptoq11
1 Like