GrowFi - UDT Swap

Team Background

The GrowFi team is currently developing a DeFi infrastructure, including the fundraising model Growdrop, interest derivatives and DeFi aggregate. Growdrop has already released an Open Beta version(Ethereum). Our goal is to enable DeFi to expand financial inclusion, which has not been possible with centralized financing.

The GrowFi team has been running the Nervos Korean community for the past year, and we have written development research and content on various Nervos and made it known to Korea. Philosophy like Nervos PoW, layer architecture has inspired us a lot and we want to make this philosophy public. So in order to contribute to Nervos decentralized ecosystem, we want to create a financing that anyone can participate in DeFi infrastructure on top of Nervos. Our development proposal is as follows.

Github:https://github.com/bannplayer/Growdrop/tree/master
Github:https://github.com/bannplayer/Nervos

Medium:https://medium.com/growfi

Twitter:https://twitter.com/Grow_drop

Growdrop app: http://dev.growdrop.io/

Mike MU : Blockchain researcher(Create a Blockchain research report 30+ ) , DeFi Korea Co-Organizer, GrowFi Co-Founder, Korea Government Support Blockchain Education Instructor

David Park : ex-Bithumb coin(20+) wallet, sign server development & node operation guide. Samsung Galaxy S S-memo Development.

Jay Lee : ex-Bithumb coin(20+) wallet, sign server development & node operation guide. LG Mobile Developer ex-Bithumb coin.

Brian Noh : Defi Proeject full-stack Developer. (https://github.com/bannplayer/Growdrop/tree/master ). Korea Government Support Blockchain Education Instructor.

Adonis Seo : exchange service Front-end & Back-end development Bithumb Cryptocurreny Deposit/Withdraw development .

Ian Son : Bithumb new exchange system development, Coin/Token Management/Listing system development.

Kidori Park : exchange web solution developer. Korea Government Support Blockchain Education Instructor.

Gami Wang : ​Exchange​ ​Product manager

Project and Nervos Ecosystem Growth

UDT swap
we will be able to trade tokens for Nervos scalability to make it easier for investors and users to enter. This requires a trading site that is easy to list and exchange. This enables users to experience various Nervos environments.​ As the Nervos ecosystem expands in the future, Layer 2 and Dapp will offer tokens a liquidity pool of UDT swap (x * y = k models) to create new business models through fees. The price of the token is also determined by the size of the liquidity pool.

We also focus on the token interface (UDT) of the Nervos network, and we know that the Nervos community is already actively discussing UDT. We will modify this proposal and continue working.

Technical Specification and Implementation
image

We will create an UDTswap lock script and an UDTswap type script, and the UDTswap lock script checks only if there is an UDTswap type script within that transaction.

The UDTswap type script will check for other content.
There are five kinds of transactions.

Create UDTswap
Create a cell to store the liquidity pool related data between UDT and ckb.

Add liquidity pool
Add a liquidity pool to provide users with the ckb or UDT needed for swap.

Liquidity pool providers are provided by quantifying the ratio of liquidity pools to the ckb ratio of liquidity pools.

Liquidity pool removal
Depending on the percentage of the liquidity pool provided to the user, it can be removed from the liquidity pool again to get back ckb and UDTs based on the removed ratio of the liquidity pool.

Swap ckb to UDT (swap UDT to ckb)
Depending on the ratio of ckb to UDT or UDT to ckb provided to the liquid pool, you can either provide ckb and receive a UDT, or provide a UDT to receive a ckb.

The shared state of the figure indicates that the latest liquidity pool related information cell by all users should be used as input.

Also, if the liquidity pool is empty, ckb will have 200ckb, and the remaining ckb is the liquidity pool balance.

Similarly, if the liquidity pool is empty, the UDT will have 1 and all other UDTs are liquidity pool balances.

There is an undefined fee for every transaction, which is a fixed fee to prevent the occupancy of the shared state.

The fee for swap is 0.3%, which is left in the liquidity pool so that liquidity pool providers can earn it on a percentage basis.

Create UDTswap
There is one input and three outputs.

The input is shown below.

Ckb for cell creation.

The output is shown below.

Cell that stores ckb amount of liquidity pool provided as capacity and locks up, stores information about liquidity pool.

Cell where the UDT is actually locked and stored.

Cell to get the remaining change after cell creation.

When you create an UDTswap type script, you create a unique type script using the first input of the transaction as args.

After that, all transactions containing UDTswap type script should check below.

whether the UDTswap lock script is used,

type script is used,

the args of the type script match,

The number of input and output cells in the transaction is
correct

Etc., and further checks according to the other situation

Add liquidity pool
There are five inputs and five outputs.

The inputs are as follows:
Cell that stores liquidity pool information
Cell locking up UDT by liquidity pool information
Cell providing ckb liquidity pool
Cell provides UDT liquidity pool
Cell with the ckb needed to create the cell

The outputs are as follows:
Cell with updated liquidity pool information
Cell to lock up the UDT by updated liquidity pool information
Cell to store liquidity pool ratio information of user
Cell to return the remaining ckb after cell creation
Fixed fee cell to prevent occupancy of shared state

For cell that store liquidity pool information and cell that lock up UDTs as much as liquid pool information, the latest updated output should be used as input each time the user uses.

If you add a liquidity pool through ckb and UDT, you must add it according to the ratio of ckb and UDT of liquidity pool.

After the addition, the user’s liquidity pool percentage information is based on ckb’s previous liquidity pool information and the percentage of ckb users added.

‘ckb reserve’ refers to the amount of ckb that exists in the liquidity pool.

‘UDT reserve’ refers to the amount of UDTs that exist in the liquidity pool.

‘total liquidity’ means quantifying the total proportion of the liquidity pool.

For a UDT you should add :
UDT reserve * ckb amount to add liquidity / ckb reserve + 1

The liquidity pool ratio information for a user is as follows :
total liquidity * ckb amount to add liquidity / ckb reserve

At this time, if the liquidity pool is empty, the first time you add a liquidity pool, you can add as many ckb and UDTs as you want, and this ratio will be used to calculate when you add the liquidity pool later.

In addition, upon initial addition of the liquidity pool, the total liquidity is equal to the ckb amount.

Liquidity pool removal
There are four inputs and six outputs.

The inputs are as follows:
Cell that stores liquidity pool information
Cell locking up UDT by liquidity pool information
Cell storing user’s liquidity pool information
Cell with the ckb needed to create the cell

The outputs are as follows:
Cell with updated liquidity pool information.
Cell to lock up the UDT by updated liquidity pool information.
Cell to get back ckb according to the percentage of liquidity pool removed.
Cell to get back the UDT based on the percentage of liquidity pool removed.
Cell to return the remaining ckb after cell creation.
Fixed fee cell to prevent occupancy of shared state.

For the cell that stores liquid pool information and cell that locks up UDTs as much as liquid pool information, the latest updated output should be used as input each time the user uses.

If you remove the liquidity pool, you will get back the ckb and UDT based on the ratio of the liquidity pool.

For the returned UDT :
removing liquidity * UDT reserve / total liquidity

For the returned ckb :
removing liquidity * ckb reserve / total liquidity

Swap ckb to UDT (similar to swapping UDT to ckb)
There are four inputs and five outputs.

The inputs are as follows:
Cell that stores liquidity pool information
Cell locking up UDT by liquidity pool information
Cell containing ckb provided for swap
Cell with the ckb needed to create the cell

The outputs are as follows:
Cell with updated liquidity pool information
Cell to lock up the UDT by updated liquidity pool information
Cell containing UDT to receive as a result of swap
Cell to return the remaining ckb after cell creation
Fixed fee cell to prevent occupancy of shared state

For cell that stores liquidity pool information and cell that locks up UDTs as much as liquid pool information, the latest updated output should be used as input each time the user uses.

In the above case, ckb is exchanged for UDT. When ckb and UDT are reversed, same calculation will be used.

‘input amount’ means the ckb or UDT amount you want to provide.

The ‘output amount’ is the ckb or UDT amount that you will receive.

‘input reserve’ refers to the amount of liquidity pool provided by the user, such as ckb or UDT.

‘output reserve’ refers to the amount of liquidity pool that you receive, such as ckb or UDT.

The formula is shown below.

Determine input amount based on output amount :
input amount = input reserve * output amount * 1000 / (output reserve-output amount) * 997 + 1

Determine output amount based on input amount :
output amount = input amount * 997 * output reserve / (input reserve * 1000 + input amount * 997)

If any of the above two formulas are correct during transaction verification, they will be treated correctly. If both formulas do not match, the verification will fail.

front-running
If a malicious person first checks a transaction and assumes that the transaction is processed before it is processed, then the user’s transaction will not be processed because it did not use the latest updated output. This prevents front-running.

future work
We may make user’s liquidity as UDT and transmit it. UDT to UDT swap is already available through two transactions, but we may make it possible to use one transaction.

Road map:
We propose a 4 month timeline, with 3 checkpoints.

Checkpoint 1(1 Month):
● UDTSwap code MVP model release

Checkpoint 2(2 Month):
● UX/UI
● Test swap
● Bug Improvements
● Guide Documents Video

Checkpoint 3 (1 Month):
● Full version UDT Swap
● UDTswap price history API
● UDTswap info

3 Likes