search

serai-dex / serai

Other
263 stars 49 forks source link

Liquidity Airdrop Mechanics #354

Open kayabaNerve opened 1 year ago

kayabaNerve commented 1 year ago

The simple idea is:

1) People add single-sided liquidity 2) The pools launch, adding the single-sided liquidity with airdropped SRI 3) Users may withdraw their liquidity at any time, yet they only receive a portion of the SRI (trickle-fed over some time period)

We have a few issues:

1) How do we decide how much SRI to add to each pool? Decide in advance? One-time oraclize values? 2) How do we handle IL?

If we use an Uniswap v3 mechanism for the AMM (#60), then the point is the ability to specify a range. If the liquidity is rocked, we can't let users specify arbitrary ranges as they can move it out of range and solely gain the SRI. We'd have to determine if the liquidity is actually in use to award SRI which seems... messy.

akildemir commented 1 year ago
kayabaNerve commented 1 year ago

@akildemir

Migrating from v2 to v3 would be more of a pain.

I'm not interested in offering ILP. I know realize my original post had a typo and I meant to say IL, not ILP D: Will edit. We do have to beat IL though. ILP would be one flawed mechanisms. Designs which minimize IL + a proper fee strategy is the other. We need to discuss the other, especially when requesting 1y lock-ups.

For the last bullet point, that fails to solve the issue. Not only am I personally strongly against choosing a value for SRI, we'd need to know how much the pools are worth by USD value to do such a fill. That'd require an oraclization of external values.

It's not about how much SRI to add in total. It's about the breakdown between the pools.

Also, over-pricing isn't something we can shrug off. That'd have very damaging effects.

akildemir commented 1 year ago

@kayabaNerve

I get the point but first, we can't overprice something that doesn't have a previous price, you mean if we put too little SRI into pools that can cause issues?

Second, we have no choice if we want to airdrop to the pools. Also I'm guessing it could be achieved without an oracle, since we know the DAI is $1, DAI pool can be filled with SRI with the same amount in terms of coins, and we can take approximate values for the other pools although I might be oversimplifying this.

Hm thinking about it now, I don't know if it is desirable but maybe the other option would be to have SRI token in another chain for price discovery and after the launch and everything is ok bridge the tokens in, tho seems like that would create it own set of problems and a headache option for something that could be solved in other ways.

kayabaNerve commented 1 year ago

Over-pricing refers to the idea putting too little of a token in the pools initially, creating a very high price, which quickly falls as distribution occurs (or simply a price so high it's psychologically unnerving, causing people to expect it to go down even if it has standard tokenomics, just shifted by 1000x, creating a self-fulfilling prophecy).

Regardless, I'd like to quash discussion on this. I've already stated

That'd require an oraclization of external values.

And this is a comprehensive solution. It does not set any price for SRI. It solely oraclizes the BTC/ETH/DAI values, letting us appropriately determine ratio between the pools.

Regarding your solution, filling 1:1 with DAI would be setting the price of SRI, and we'd be unable to determine approximate values for other pools.

We definitively cannot offer SRI on another blockchain.

kayabaNerve commented 11 months ago

Implementation blocked on #419 due to inability to transfer liquidity tokens (at least, any good implementation).