Pre-Proposal: Auto DCA / Dynamic SL

1

Purpose
At this stage, the purpose of this post is to serve as discussion starter and - hence - to facilitate the gathering of people’s thoughts on viability/desirability of this feature before deciding whether to create a formal proposal

At a glance

  • Introduce a new ‘automatic DCA / dynamic stop loss’ functionality to leveraged yield farms.
  • This feature automatically adds collateral on your behalf when the safety buffer of a LYF hits a certain threshold

Context
As we all know, crypto is a very volatile asset class. Yes, we’ve all experienced first hand what it means to see the value of a token move by 10-20% in the matter of hours.

And while we all love to see our favourite token pump in price, we all have had that awakening moment when somehow the dip keeps dipping.
For those brave enough to use leveraged farms, this stressful emotion gets amplified even further.
This is often mitigated by trying to constantly be online to ensure your positions are in check.
But we know that this is not often possible, which makes the whole thing even harder and more stressful.
This feature aims at providing LYFarmers with peace of mind.

What problem are we solving?

  • Remove the need for Farmers to manually have to monitor/add collateral to a position

For discussion
Please refer to this simplified diagram

Draftprop
Draftprop3627×1102 191 KB

  • New feature enables the Farmer to add ‘liquidity’ to the protocol to be used as collateral, if required.
  • When the price of the token decreases to a certain key level (e.g. 5% safety buffer), the feature is triggered (similarly to how the liquidation contracts work)
  • When triggered, the new contract automatically uses a % of the locked ‘DCA liquidity’ to add collateral to the relevant LYF
  • This process is repeated until no more ‘DCA liquidity’ is available

Notes/Considerations

  • Once deposited, the ‘DCA Liquidity’ is locked and can’t be used by the Farmer unless withdrawn.
  • The triggering threshold (5% in the example) is illustrative. However – conceptually – the lower the better as it gives the best benefit from a ‘reducing the break-even point’ of the position perspective
  • The amount of collateral automatically added by the platform is the minimum required to restore a certain safety buffer (e.g. 10%).

Example (numbers are illustrative)

  1. Tom opens a 3X TKN-BUSD position for $1000 (Safety buffer 30%)
  2. Tom locks $500 as ‘DCA liquidity’ to the platform/position
  3. The price of TKN drops by 30%
  4. Safety buffer decreases to 5%. First threshold is hit.
  5. Platform checks if Tom has got any ‘DCA liquidity’. Finds $500
  6. Platform adds $200 of collateral. Safety buffer is increased to 10%

Edits/Improvements
The following have been gathered from fellow Alpacas

  1. Maximising efficiency of unused capital - ‘DCA liquidity’ should be deployed into the Lending protocol to make it work harder while locked
  2. Multi-position LYF liquidity - ‘DCA liquidity’ should be shared across multiple pools and used on a first-come-first-served basis
2 Likes
2

Hi, thanks for the proposal. What you’re talking about could be better packaged as cross-margin. Unfortunately, this is a somewhat niche feature that would take months of work to implement. However, we are considering this for AlpacaV2 where it may be easier to implement.

1 Like
3

Thanks Sam -

I can’t comment on the desirability of the feature as no one has replied (which might be a tell), but how come you reckon this takes long?

I would have actually assumed that it’s quick as it reuses existing services and API calls your platform already has. For instance:

  • The service to add liquidity to an open position (the one we currently use to manually add collateral)
  • The service to initiate an action once a certain safety buffer is hit (the one we use for liquidation)
  • The service to lock liquidity in the platform (lending pools)
4

“How come you reckon this takes long?”

Because I’ve spoken to the development team about it several times

5

It would be nice to use ibTokens for that “DCA Liquidity” to improve capital efficiency.

6

I think what you say " When the price of the token decreases to a certain key level (e.g. 5% safety buffer), the feature is triggered " it is hard to achieve. Because maybe it is against with smart contract. When you want to set a stoploss, actually , you delegate someone to help you interact with smart contract. But this has a risk beacuse others dont want to help you do this without benefit. It is unlike the liquidate, liquidator has benefit after interact with liquidate contract, so they pretty like to do this.