GrowFi - Nervos DeFi Infrastructure

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

This is a proposal to ease the DeFi ecosystem and user entry on Nervos. CKB chrome extension wallet, UDTswap, Growdrop can be a great help for the entire Nervos ecosystem, not just GrowFi. We will be able to experience Nervos through a simple UX for users and developers.

CKB chrome extension wallet

Which allows users to easily access these sites. Currently, Nervos wallet requires node by default. We’ve already seen a lot of things that make it harder for users to run nodes, access open nodes, and manage keys. To do this, you can use wallet anywhere in the world with Chrome, and we suggest wallet that users don’t need to know what nodes are.Of course, for this wallet, the node must also be operated, and depending on the number of users, this node must distribute the transaction to the node and also manage the ongoing management of Nervos updates.

We need to provide an easy development environment as the Nervos Dapp ecosystem grows. We provide a Nervos full node API to ease the development burden.The infrastructure for Nervos & Web 3.0 apps is much easier to access.

Technical specification and implementation


Figure 1:​ ​CKB Chrome Extension Wallet Architecture

CKB chrome extension wallet can be used to create CKB public key through the Google authentication server (Figure 1 ) by logging in with SNS accounts such as Google and Twitter. CKB chrome extension wallet will be developed based on ckb.sdk.js.

When a user arrives at a DApp, the javascript client is loaded. From there, a user logs in, they provide proof that they are logged in, and the proof is verified by server individually. This proof is integrated with the modern OAuth 2.0 Token Authentication flow. For new users, servers will assign a new key share from the pre-generated set of key shares, and store this assignment in an internal mapping. For returning users, servers will look up their internal mapping and return that user’s corresponding key share.​

A typical workflow is as follow, detailed flowchart please refer to next section:

  1. User goes to a Nervos Dapp website.
  2. The user requests an authentication from the Client (our server).
  3. The Client sends an Authorization Request to the user to authenticate (ex Facebook, Google login url).
  4. User sends authorization to client by sending Authorization Grant to url to signal that authentication has been completed and authentication completed.
  5. The Client sends its Authorization Grant to the Authorization Server.
  6. The Authorization Server checks the Authorization Grant and, if the user is correct, issues the Access Token, Refresh Token, and the user’s profile information to the Client.
  7. Client stores the Access Token in DB.
  8. If the user needs a resource on the resource server, the client requests the resource server with an access token.

It also runs CKB full-node offerings, such as the Ethereum Infura service, within the team, allowing you to quickly load Unspent cells and provide a good UX to your users without having to block-sync. For developers, our Infura service will reduce the barriers to development and give them convenience.

Roadmap:
We propose a 8 month timeline, with 3 checkpoints.

Checkpoint 1(3 Month):
● CKB Cell model Simple transfer
● Dynamic fee caculation and customizable fee rate
● Nervos DAO Integration
● OAuth 2.0 Connect (Google)
● Browser UX/UI

Checkpoint 2(3 Month):
● CKB Full node API for wallet MVP model
● Testing wallet
● Bug Improvements
● Wallet Guide Documents
● CKB Full node API Document

Checkpoint 3 (2 Month):
● Full version Nervos Chrome extention wallet
● Full version Nervos Full node API


UDTswap

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


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


Growdrop Nervos DAO Version

The blockchain project has yet to have a successful business model and is faced with even more funding difficulties for an open source community. Projects like Ethereum 2.0 now require the power of the open source community to develop and maintain protocols. Open source can not only open code but also build trust and open collaboration of blockchain. Blockchain protocols that are not open source will not be able to build trust and the road ahead will be blocked, and it is hard to imagine that blockchain protocols are not open source. So the value created by the open source community is the only key to creating the Fat Protocol of the blockchain.

Examples include the ERC-1789 inflation funding proposal, Gitcoin, and MolochDAO, which contribute open source projects/communities to the sustainable development of the Ethereum ecosystem. The key elements of ecosystem financing are a) sustainability b) community consensus c) transparency and d) value parity.

Nervos has a strong ecosystem community. However, to create the Nervos Fat protocol, we believe that a platform is needed for Nervos community members to contribute to the open source project ecosystem.

Growdrop is a protocol that minimizes trust costs and contributes interest to open source projects generated through Nervos DAO. Like the aforementioned model, Growdrop’s community members contributed to various open source projects / communities through the interest generated, and the blockchain protocol provides a long-term sustainable direction.

Technical Specification and Implementation

UDT Fundraising Model

What we think so far is that the cost of trust in financing is very high. It’s expensive, so you pay a lot of money to maintain all sorts of unnecessary surveillance systems. Growdrop is a crowdfunding solution that minimizes the trust costs of existing third parties, deposits investment funds into DeFi Lending Protocol’s liquidity pool, contributing interest to open source projects and ensuring investor principal.

Given that Growdrop allows third parties to securely operate smart contracts, Growdrop can invest in projects, greatly reduce the risk of supporters’ seed investments, and projects will slowly build communities to help promote public relations and technology development. Here, in the early Ethereum community, it is very similar to the nature of DAICO, and projects can start as a community and receive seed investment and promotion effects.

Growdrop logic


Among the above and the below, data field to be entered may be changed, and some of logics may be changed.

All cells in transaction which is interacting with growdrop should have appropriate type script and lock script.

All about growdrop index is replaced to creation transaction’s first input, so growdrop index type script will be removed.

How to create a project

Growdrop has 3 scripts. Growdrop lock script, growdrop type script, growdrop_index type script.

Growdrop_index will make number to identify growdrop projects.

When new growdrop is created, the number will increase by one. A cell to lock up UDT and a cell to sum interest data will be created.

The condition of this transaction is as follows.

There must be only 3 input and 4 output.

The pkh provided as project and growdrop should be appropriate pkh.

The actual UDTs locked up into cell must be the same amount of data provided in cell.

current epoch + 181 The epoch timeout must be added to the cell data.

How to join Growdrop

When the project is created, it finds the output with the latest total interest updated.

Find the output after dao withdraw phase 1.

This results in three outputs

  • 1 an output that sends the principal to itself
  • 2 an output that binds interest
  • 3 an output that was created in # 1 when the total interest was updated.

The conditions of this transaction are as follows.

It must occur within the 181 epoch hours generated by the project.

In addition to the inputs and outputs mentioned above, no other inputs or outputs should exist.

The inputs and outputs for which the total interest is to be updated must both have the same capacity.

The output to lock up the interest should be the same as the type script of #3 and args too. The interest is stored in capacity.

The cell data with updated total interest must equal the capacity of the output with the interest plus the interest on the input.

Growdrop withdraw

First input uses the nervos default lock script for transferring capacity to itself.

Finds the output that will hold the previously generated interest and the latest output with updated total interest.

Finds latest output that locks up UDT.

Four outputs occur.

  • Output that will give the project 99% interest.
  • Output to send UDTs to user as interest rate of user to total interest.
  • Output to pay Growdrop 1% interest.
  • Updated output of total interest.
  • Updated output deducted by the total UDTs sent to itself from the total UDTs.

The conditions of this transaction are as follows.

It should occur after the 181 epoch time you generated in the project.

In addition to the inputs and outputs mentioned above, no other inputs or outputs should exist.

The inputs and outputs with updated total interest must both have the same capacity.

Input 2 and Input 3 must have the same type script and args.

The amount of UDTs a user takes should be equal to user interest / total interest * UDTs distribution.

The capacity of the project must be 99% of interest and the Growdrop’s commission capacity must be 1% of interest.

When a user takes UDTs through Growdrop withdraw, the UDTs tied to the output cell whose total interest has been updated must be subtracted by the amount of UDTs taken by the user.

The output that will give to the project and Growdrop should be the nervos default lock script that is locked by the pkh of the project and its Growdrop.

The UDTs bound to the cell will be updated as the user continues to take them, and because they are also shared by all users, they must be updated for the latest output each time.

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

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

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

Checkpoint 3 (1 Month):
● Full version Growdrop

6 Likes

这个看起来很宏大

@LBMike
growdrop 的目标用户 是 众筹投资人吗?
从用户角度看,产品可以只是一个钱包,能投项目获取收益
那么他们的收益会包括:CKB利息,项目增长产生的UDT分成
而且可以基于Uniswap交易来获取流动性
赞Grants

有个问题:本Grants使用的技术栈是什么?如何参与并支持?

您好!
Growdrop是对于开源项目众筹平台,希望让更多的开源项目来Nervos上扩展生态,用户角度来说使用CKB的钱包拥有CKB的话就可以无风险贡献项目,项目方可以获得CKB利息、UDT在Uniswap(新增流动性池)上交易、社区支持等。

我们近期会更新技术细节,有什么问题可以随时问我!

本Grants使用的技术栈有:
CKB chrome extension wallet:

  • React
  • nodejs
  • Redux
  • C

CKB Infura

  • Network
  • linux
  • Cloud service
  • Infrastructure
  • Vuejs
  • PHP

CKB based Uniswap

  • Javascript
  • Typescript
  • C
  • nodejs

Growdrop Nervos DAO Ver.

  • Vuejs
  • Php
  • C

如果您想参与本Grants您可以加我的微信再深入聊聊!
Wechat ID:whdqkf88