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.

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

2 Likes

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

Following up on yesterday’s zoom DeFi sub-governance call, I found a few inconsistencies. If the community doesn’t mind, I’m going to speak out on some important issues.

As my professor used to say: “F**cking two things up at the same time isn’t multitasking”. Likewise, a would-be developer, hopping from one group to another and making judgements in a superficial manner, strains credulity.

From the conference call: “You can choose basically any license”. Indeed? You really think so? In fact, choosing the wrong license might very well lead to a “life or death” implications for a startup. You’ll face difficulties finding financing for your project having a GPL license, since your code does not have permission to be incorporated into other proprietary software.

Down below I’d like to bring your attention to the following:

  1. Incompetence and unprofessionalism of some jurors.
  2. Changing the contest rules on the fly
  3. About the collaboration
  4. Front-running

Let’s start from the second one.

Changing the contest rules on the fly.

“Dura lex, sed lex” as some of the Free Ton jurors love to quote.

If the rules have been set, don’t change them. It completely demotivates the contestants. Are we into the immutable blockchain or what? I could have financed the initial 30k phase out of my own pocket. But the challenge of winning the contest was pretty cool and appealing to our team. So we decided to give it a try.

Changing the rules, if any, must be done very carefully and should be based on the community feedback. Otherwise Free Ton risks losing the community confidence and authority. And definitely not because some guy from Ton Labs, constantly making grammatical mistakes both in his speech and writing, came and called the shots. Or are we talking corporate finance here?

About the collaboration

Do you really believe people will share their secret sauce with the competing teams by collaborating with each other? A productive team is like a good marriage often taking months or years to form. What was the moment I missed where the FreeTon DEX Architecture & Design Proposal turned into Ycombinator? Or do we have a conspiracy here? Let’s talk people into crowdsourcing their ideas and we’ll take the best ones to implement, since we have enough resources at our disposal. Didn’t we have enough cases across the blockchain industry revealing the fact that teams regularly steal ideas from one another and constantly seek the ways to protect their IP?

Incompetence and unprofessionalism of some jurors.

The goal of our DEX contest submission was aimed exclusively at the Ethereum DeFi sector, specifically on its weak parts so that we would be able to migrate as much of its liquidity as possible into the Free Ton ecosystem.

Free Ton developers can be hired and fired so we see no problem here whatsoever.

If the guy from the conference call didn’t get it, means either he didn’t read the whole white paper, at least to the “Nascent Phase” part, or was totally lopsided in his view of things.

Besides, it was clearly mentioned by some jurors in the previous call that the specific implementation on the Free Ton blockchain can be postponed to the next phase. Because there’s nothing to trade on the DEX yet. No infrastructure build yet. Even no decentralized bridge, which we deem is the most important prerequisite. We even outlined/underlined this in the white paper.

Therefore we concentrated on what we think is most important for Free Ton now: publicity, authority, usability and user friendliness. We implicitly outlined that by making a “correct hype” in the Ethereum DeFi niche, we would be able to draw the attention of the Ethereum yield farmers to our project and in the next Phase seamlessly (as possible) to migrate the liquidity on the Free Ton blockchain, which by that moment should be built by both our efforts and efforts of other teams. If some of the jurors didn’t get that idea, then I underline this again right here.

Front-running.

We were perfectly aware that front-running was deemed impossible on Free Ton. I personally had a talk with a number of Free Ton devs about this issue. But the contest rules definitely stated to describe the problem in as much detail as possible. I personally already had a pleasure to hit on the “dura lex, sed lex” wall of Vladislav formal submission guidelines and was taught by experience to follow every point in the list of the rules. So did the other participants. But it was mainly our team that was specifically made fun of by one juror.

From my own experience I always question any such statement, when someone is touting something is not possible. Because usually it is.

Bug-free code is a myth and can only be at the
“Hello World!
Press any key to continue…”

If someone’s just stating the Security Card for Free TON is made in Switzerland it doesn’t mean it can’t be hacked though. Better be on the safe side and seal up any hole even seemingly ephemeral. Just like the recent bug with the Surf wallet, where by sending an arbitrary small transaction one could make the wallet’s balance become negative. I’m sure there’s going to be pretty many bugs to be discovered down the road.

So we decided to elaborate on the issue starting off right where it was vastly discussed, from Ethereum. Since there’s no decent manuals/docs on Free Ton, and everybody keeps silent on the subject, we thought it would lead to a constructive discussion here in the forum thread.

Instead we had quite an opposite and unprofessional reaction from a jury member lashing out at us like a bull on the red flag. I just wonder why. Perhaps, some red-neck from out of Nowheresville has offered a simple but not so elegant solution to hijack Ethereum’s liquidity?

Let me finally ask a question:
Are we here for what? To build and promote Free Ton in as simple and most effective ways as we can or are we to brag about the size of our developer dicks?

P.S.
Almost forgot to mention: this very post is a copy-paste from some Ethereum whitepaper.

Thanks for the feedback! Let me try to give my feedback on your feedback)

  1. License issue is a huge topic TBD, GPL is definitely not a one size fits all thing, as well as MIT or Apache 2, it has to be decided on case per case basis. I don’t have a straight answer now what’s IMO is best for DEX for instance.
  2. Totally agree about rule of not changing the rules. Could you specify where was it violated in DEX contest?
  3. Free TON is still in early experimentation stage of how to move from Design/Architecture to Implementation to Support. We are solving a problem which is being solve for thousands of years in common states. There are different approaches in our Digital State already. Defi subgov on of the calls decided that we’ll for the start stick with the model where winners of Design/Architecture contests will be drafting proposal for the implementation stages. Here we are. Noone speaks here that this collaboration team will have to do one implementation together, moreover on last call we agreed that for each stage there will be a separate contest where everyone participates. But anyway someone has to draft the proposal and here my suggestion is to do it collaboratively and meritocratically, meaning those who won the contest and experts in subgov.
  4. I think you missed the point. Quite the opposite we wanted to restrict contestants as little as possible, the last thing subgov wanted to see in submissions - yet another copies of uniswap, mooniswap, sushiswap, etc. Why? 1. Because it’s design stage and all ideas are welcome 2. Who said that Uniswap is the only possible way to go? 3. Why Free TON being techincally different network from Ethereum, just copy their practices. As my proffesor said “You better 10 think about the program design before you sit to code!” TON has to search for its way of doing thing and this authenticity will one day attract by itself ethereum enthusiasts and migrate liquidity.
  5. Front-running. I have to agree with you here, I think for now it’s still a bold statement and has to be formally proved. But participants of the call are free to express and ideas they have, even the most extravagant and unproved, that’s how community projects and digital states work.
  6. We are here to have fun and build cool things, at least so I thought, cheers!)
1 Like