RFC #1: DCA Dapp

Hello everyone :raised_hands: Welcome to the very first attempt at RFC.

After reading @with-heart 's post - RFC Implement Champion-led, RFC-drive decision-making process - I was inspired to get my idea out in the world using the above mentioned approach.

(If you haven’t read it yet, I 100% recommend it!)

Before, I had to go in multiple Discord servers, post my idea & wait for days to receive a “meh” response & critique from other developers. With RFC, we’re onto something different. Champions, will have a specific place to share their ideas with a well constructed structure - the what, why and how - and receive a well thought-out response.

So here goes my attempt at creating the very first RFC - subject to improvement.

What are we doing?

I came up with the idea back in October at ETHGlobal Hackathon. I was trying to create income management tool for users receiving their crypto via streams.

Project Name: Decentralized Dollar-Cost-Averaging Dapp (DCA Dapp)

One sentence explanation: DCA Dapp allows users to Dollar-Cost-Average from one crypto to another using smart contracts.

Detailed explanation: DCA Dapp will utilize smart contracts to allow users to exchange one crypto asset for another, over time. Smart contracts will allow the Dapp to cut out any 3rd party service providers, like Kepeers, thus making the Dapp completely decentralized.

Example: Steve has $100 in USDC. He wishes to buy ETH, but ETH’s price is falling and he doesn’t want to go all in @ a certain price. Steve is smart. Steve deposits his $100 USDC into DCA-Dapp, which will exchange Steve’s USDC for ETH over a period of 10 days (for example). Specifically - DCA Dapp will purchase $10 of ETH a day over 10 days, taking the price fluctuations into account.
After the operation, Steve has successfully Dollar-Cost-Averaged into ETH position with his USDC, meaning he now has more ETH than he’d have with simply buying ETH 10 days prior at fixed price.

NOTE: In the above example, we presume that the price of ETH fell each day, leaving Steve with more ETH at the end of the 10 day period.

Why are we doing it?

We’ve protocols like Uniswap - where users can exchange one asset for another @ a fixed price (slippage taken into account). Limit orders were also created by Sushiswap - providing traders with more tools to play around with and to compete with centralized exchanges.
We haven’t really seen any Dollar-Cost-Averaging Dapp where you could park your asset in exchange for another, over time. Today’s DCA is heavy-work. You’ve to execute multiple trades yourself & each time pay the gas fees. With DCA Dapp, you only have to pay gas for depositing/withdrawing your asset(s). After that, you DCA into any asset you wish - gas-free.

You pay the gas fees only, when you:

  1. Approve (one time, per asset)
  2. Deposit
  3. Withdraw

Rest of the heavy-duty work - Dollar-Cost-Averaging - is gas-free & automated.

Advantages:

  1. Decentralized DCA mechanism
  2. Relatively cheap (gas fees wise)
  3. No 3rd parties required
  4. DCA-ing is gas-free
  5. DCA-ing is automated
  6. Completely customizable (timeframe, amount)

How are we doing it?

Like I mentioned in the beginning, I came up with the idea during ETHGlobal Hackathon. I was trying to develop an income management tool for Superfluid’s users (different from DCA Dapp.)

Tech

What’s Superfluid?

Superfluid is a smart contract framework on L1 Ethereum, enabling you to move assets on-chain following predefined rules called agreements. With a single on-chain transaction, the money will flow from your wallet to the receiver in real time! No further transactions required- it works like magic :sparkles:

source

Super Tokens
Super Tokens are upgraded ERC20 tokens. They’ve super powers that enable them to go from one wallet to another in real-time without performing a TX, unlike regular ERC20 tokens.

Super Apps
Super App is a contract in which we can write our own logic to handle incoming super tokens. What are we going to do with them? Send them to another user? Trade them? Or… DCA?

Architecture

Users will have to upgrade their ERC20 tokens to “Super Tokens” - allowing it to transfer from one wallet to another without any transactions.

After the user has their upgraded ERC20 token, he/she can deposit the asset into DCA Dapp (Super App), which will take two parameters:

  1. Amount of ERC20
  2. Timeframe for ERC20

Say Steve wishes to purchase $100 worth of ETH with USDC over 10 days - DCA Dapp will purchase $10 worth ETH a day.
Stephanie wishes to sell $100 worth of ETH (at that time) for USDC over 10 days - DCA Dapp will sell $10 worth ETH a day.

NOTE: In the above example, we presume that the price of ETH over 10 day period is constant.

Pools

Pools are another option for DCA Dapp, although I haven’t given enough thought to it.

Essentially, users would be providing liquidity (one asset, or both assets), earning fees in the process. This resembles Uniswap V3, although major difference between DCA Dapp’s pool model & Uni V3 is that DCA Dapp is constantly exchanging one token for another on its own, taking the price into account at each exchange. Whilst Uni V3 is dependent on users interacting with it, causing price/pool changes.

Challenges

Price changes
Above example is a simple one. Two parties, each want to exchange same amount of asset (in USD value) within the same timeframe.
Challenge that I see is what should the logic be to handle multiple users, for multiple currencies, with different amounts & timeframe, whilst keeping track of price fluctuations between all these different assets.

Even the above mentioned example poses few questions - what if price of ETH is not constant and changes by 1% daily? Let’s imagine this is the case:

  • Steve has $100 in USDC.
  • Stephanie has 1 ETH, which is $100.
  • Price of ETH decreases by $1 each day

Logging the days:

  1. $10 for 0.1 ETH
  2. $10 for 0.101 ETH
  3. $10 for 0.102 ETH
  4. $10 for 0.103 ETH
  5. $10 for 0.104 ETH
  6. $10 for 0.105 ETH
    etc.

All-in-all Steve accumulated more by utilizing DCA Dapp, than he would’ve otherwise. Whilst Stephanie sold her ETH for less.

Multiple parties
As mentioned above, having multiple parties with different parameters is a challenge. How can DCA Dapp keep track of them is still unbeknownst to be.

Usage
Why should Stephanie sell her ETH? In above mentioned example, she sold her 1 ETH for $78.37, when she could’ve just sold it in one transaction @ $100 or $99. That’d leave her with a lot more USDC than selling ETH whilst price is depreciating.

Pooling
Why would someone provide liquidity, knowing they’ll DCA into another asset and potentially lose money? We call this - Impermanent Loss.

8 Likes

I hope my math is correct :face_with_monocle:

Example: Steve has $100 in USDC. He wishes to buy ETH, but ETH’s price is falling and he doesn’t want to go all in @ a certain price. Steve is smart. Steve deposits his $100 USDC into DCA-Dapp, which will exchange Steve’s USDC for ETH over a period of 10 days (for example). Specifically - DCA Dapp will purchase $10 of ETH a day over 10 days, taking the price fluctuations into account.
After the operation, Steve has successfully Dollar-Cost-Averaged into ETH position with his USDC, meaning he now has more ETH than he’d have with simply buying ETH 10 days prior at fixed price.

I really love this example. Made it clear to me what your idea hopes to accomplish for a user.

We haven’t really seen any Dollar-Cost-Averaging Dapp where you could park your asset in exchange for another, over time.

Any idea why? Makes me wonder if there are some hidden pitfalls here.

Amazing how much more an image can say than a bunch of words.

I think you basically nailed it will this RFC except for one aspect: there’s probably a fair bit of UI work involved in making the contract useful to end users, so it might be worth spending a little time thinking about what you envision the experience of the app side of this proposal being like! Not sure you necessarily need a whole lot of detail, but at least mentioning it will let potential contributors know the ways they might be able to get involved here.

4 Likes

Any idea why? Makes me wonder if there are some hidden pitfalls here.

I know one Dapp was built using Superfluid, but it utilizes Keepers - 3rd party who calls functions every X amount of time.
Not sure about its pitfalls. There might be something so wrong with the model, that it might not work. Still, there’s a lot to explore - whether it be having pools with fees or just users depositing & withdrawing like in case of Tornado cash - you use the app only when there’s a collective demand. Meaning, Dapp is no use for individual, if there’s no collective demand i.e. a lot of ETH hodlers willing to sell for USDC & a lot of USDC hodlers willing to buy ETH.

I’ll try & come up with UI for the frontend. Let’s see how it goes : P

Edit: Ok, I think my math is wrong, but it’s getting late : )

I forgot the name but I am sure I have seen a few apps that do DCA using smart contracts

1 Like

Would love to see an example of this.

But we’ve to make one key distinction - it should not use 3rd party services/relayers in order to execute trades.

So far, that’s what I’ve seen.

Great well written RFC!

I believe the challenge is the probable need to trigger the smart contract execution in a cost effective way. A smart contract cannot trigger its function at arbitrary time or arbitrary condition. It has underlying cost which at low value might not be cost efficient. I believe you have had a look at Introduction to Chainlink Keepers | Chainlink Documentation as an example way to solve this. Many others can be explored as well as other chains.

If the cost problem can be solved along with the who to trigger (user, oracle or another contract) then it will gives wings to this idea. Or perhaps an out of the box thinking.

I addressed Keepers & provided a solution for such mechanism - using SuperFluid’s Super Tokens & Super App.

1 Like

I love this idea!

I think the significant pitfall here is:

How to trigger the contract function that will buy the crypto periodically? (Maybe Keepers from Chainlink)
How to deal with the gas cost of each operation?

The idea sounds great!

1 Like

Those problems are solved by upgrading the token to Super Token.

I recommend diving into Superfluid’s Docs. Tech is there, just needs some building :hammer:

Prob be worthwhile to do some cost modelling based on different approaches to see that is viable?

Found it ser - https://mean.finance/

2 Likes

Thanks!

Had a look at their docs and looks like it’s they’ve some form of market maker mechanism, where you get rewarded for filling the order, like Sushiswap limit orders use relayers to execute orders.

And they also use Keepers.

Key difference between my proposed Dapp & existing DCA dapps, is that DCA Dapp is completely decentralized and requires no 3rd parties to execute or otherwise fill orders. It just happens.

I love this idea. One option for automating smart contract execution is Gelato, but I’ve only tested it a couple of times so it would require more research into the gas costs over time.

https://dangodca.eth.limo/#/
Came across this one, powered by Gelato. Not sure if 3rd parties are involved.

@cybergirldinah @zeox7 thanks for chiming into the convo! Appreciate it!

Idea behind this specific DCA dapp would be to not use any 3rd parties or otherwise networks like Keeper or Gelato to call functions on behalf of the app/user. To achieve this, we use upgraded tokens like I’ve mentioned before, which basically streams money from one wallet to another, taking the exchange ratio into account.

1 Like

Went through the superfluid docs videos and tutorials. I think it’s a really promising Tech! There is a currently a bounty in the DAO hackathon if you use their tech.

The smart Contract part seem simple enough to implement. Still trying to wrap my head around it like constant flow is at a per second level so the flow needs to be redirected somewhere holding until the time comes for the execution of the swap. Obviously other areas like the swapping and getting exchange rates need to be tackled so you still need an oracle and a third party unless you wanna build your own Dex.

I am not sure if you have seen this https://app.ricochet.exchange/RicochetExchangeWhitepaper.pdf

But it’s practically a blue print on how to do it using Superfluid at the core.

1 Like

There is a similar/competing product on Solona: MeanFi
I think you can have a test and add more improvements or features.

  • Exchange is what you wanna do.
  • Transfers is like SuperFluid.

yo. Are you still working on this @LucaSilverhand ? sounds great. would love to have a chat to see if it makes sense to have this built on top of our new drips protocol and have it grant funded.

https://www.drips.network/

1 Like

Haven’t touched the idea for few months.

Sounds good! Here’s my Discord: Luca | 🇪🇳🇸.eth#3285 Feel free to reach out.