How does Provide balance relate to the liquidity pool

[MrAwesome]

Hello everyone!

Interesting project you guys have here. I like the idea and having an overview of the code and collateral systems you have I thought I would help with your admittedly horrendous liquidity problems. I put in an reasonably large amount (compared to the total liquidity pool) via the provide option. I also did purchase a larger amount of PRV to balance some things out as I thought it would be a pair system like in uniswap. To my surprise there is no requirement via the provide option to need to submit both a crypto and the PRV coin.

However I noticed that even if I did provide a larger amount the pool liquidity in the application did not increase. I’m wondering what the reason for this is? Does the coins provided in provide not directly go into the liquidity pool to stop so much slippage? Are they there but just not represented in the pool size?

[Revolve]

First of all, welcome to Incognito,
and thank you for deciding to add liquidity.

For now I can only tell you what I know about the process of providing liquidity on the Incognito platform. Hopefully this will give you more insight about how you want to utilize your money.

Incognito currently has two methods of providing liquidity:

"Add"
-The add feature allows you to provide liquidity to the network by adding pairs. When you provide liquidity this way, you have to match the crypto you want to insert with Incognito’s own currency PRV. Users who provide liquidity this way earn rewards from transaction fee’s based on the percentage that they inputted. However, providing this way leaves you susceptible to impermanent losses because of Incognito’s Automated Market Making algorithm.

Because people were being hit hard with impermanent losses, and returns where lowering, Incognito came out with Provide to help mitigate the risk.

"Provide"
-The provide Tab is a layer built on top of the “Add” functionality. However, it comes with certain benefits that aren’t available to normal liquidity providers.
With Provide:
Users are guaranteed to be able to pull out the same amount of crypto that they put in (meaning no Impermanant Losses). Users are also allowed to provide only one side of the pair, making it more reasonable for the average user. However since the “Provide” layer is built on top of the “Add” layer, impermanent losses are still a factor. Incognito get’s around this problem by making the return rates variable as well as supplementing some of the losses with the Incognito Reserves. From what I understand, “Provide” was only meant to be a temporary feature while we looked for a more sustainable solution. In fact I would encourage you to read this: Liquidity v.2

Provide matches inserted PRV with other inserted crypto, across users, to add pairs to the liquidity. I believe this could possibly take some time to do.

[MrAwesome]

Thanks for the reply Revolve. Impermanent loss is a bad term because it makes people think that all loses will go away in due time which, in the case of the match making systems, is not always the case. In the uniswap area we more so use the term divergence loss. Losses are not guaranteed to be reversed. Using divergence loss instead of impermanent loss makes sure people understand that by putting up funds you are not always guaranteed an equal return vs holding it.

Personally I think provide is a really great system if you have an intermediary exchange coin like PRV. Using a portion of the block rewards to top up the PRV matching pool to reduce the slippage and makes sure that people don’t need to necessarily buy PRV to transact is the best option. This makes more people to put in more liquidity and hold the liquidity in the system. It’s transparent and easy. While you might think that is bad for the tokenomics being that it reduces the demand for PRV it would massively increase the amount of liquidity and thus usability and value of the network as a whole. That will make PRV more sustainable and worthwhile to hold on to just to make these exchanges possible. The current reward rates are not at all sustainable though looking at the total fees (which are basically 0% on paper but technically at least 2.5% due to low liquidity slippage). Matching this way is not cheap.

If I look at my provide history I see my first meaningful provide was on the 21 of September. The amount I provided was about 10% of the coin’s liquidity pool. I guess it’s possible the total liquidity I put up was in fact transacted away in the next week and a half. Still I put in more and it wasn’t represented in the liquidity pool. If Provide is in fact needing to be matched still across the coin pairs paying compounding rewards for unmatched liquidity is quite literally wasting money for the incognito team. If they are missing PRV already to match these one sided liquidity options (that they are paying PRV rewards on) that is something which needs ASAP priority to be fixed. If people are providing one sided liquidity but it’s not matched and not getting added to the liquidity pool that is really bad.

This project has a lot of potential. The shielding mechanisms, required privacy, complete pooling, and the transaction scalability with your POS sharding on an isolated blockchain sets you guys up like nobody else. The only thing which can kill this project is

1. PRV flash crashing to $0 and self-coordinated custodial withdrawal of all individuals currency. Aka a majority of the custodial individuals steal the shielded funds rendering the p variants not equal to the custodial amounts. Being that PRV wouldn’t be worth anything (do to no equal shielding amounts) everyone who has coin in the network would effectively be stolen from with the payment back being worthless. The sad part is the way you guys have it setup with a 2X upfront lock could create a full on massive liquidation. If a sizable amount of custodials took the funds all at once PRV would tank which would then require the remaining custodials to put up more PRV which depending on their individual buying power might not be possible at all. “trust-less” is not really trust-less if you don’t hold the keys right? You are trusting both the custodials to return the funds when requested and if they don’t you will get at least the same equivalent value. If the value is paid back in PRV but there is no liquidity to cash out the equivalent value it’s problematic and dooming to say the least. However as long as PRV is able to be liquefied into a usable currency of meaningful value which can be withdrawaled this system is ok. Still calling it trust-less is a hard stretch though. Not worse than other systems. At least on ethereum you have a contract system to uniswap easily.

2. Simply put: Not enough liquidity. It’s a catch 20/20. You need sizable liquidity to make effective exchanges to attract individuals to provide more sizable liquidity to make bigger effective exchanges. Not enough liquidity will mean more slippage and the higher “fee” to make a larger transaction. Thus less people will want to use it. If you lose 5% to transact to a different currency via the platform it’s not competitive. This is a similar issue that bisq has. They need people to put up liquidity in their order book so people can meaningfully trade. At least in this project there is privacy to be had. And people will pay for that privacy. I know I already did lol. Of all the projects that I have saw trying to do what you guys are doing you have the best chance of really breaking through on that liquidity front. The moment you have enough liquidity you have made it. Uniswap started off with basically no liquidity now it’s doing nearly half a billion normalized volume and is 2.37Billion in liquidity. 1.08BILLION ethereum locked up. Crazy.

I kinda went on a rant there. But I do like this project but there is simply not enough documentation when it comes to such a central point as how the liquidity is provided in the pool.

[andrey]

Hey @MrAwesome Wellcome on board!

@Revolve thanks for jumping in ). Just want to confirm your words here)

@MrAwesome, if ou use ADD function it works exactly as Uniswap, it goes directly to the chain protocol and liquidity pools balances affect right away.

The Provide feature collect funds and do rebalance twice per week. This feature is a transition between ADD and implementation of the Liquidity v2, which allows you to provide one-way liquidity in a decentralized way.

[MrAwesome]

Thanks for popping in. My main issue is how the rebalancing works. At least from what I see there is no documentation on where the other side of the pair is provided from. Like is it from you guys?

Edit: and if it is what is the guarantee that the provided liquidity will be matched and not just paid rewards without a match. If you are not getting liquidity in the pool but are still paying for that one side it’s a super great deal for one side and not the other. As someone who wants to see this project succeed it’s important that all provided pairs are matched ASAP and provided into the liquidity pool.

[andrey]

@MrAwesome just went thought your second post.

You are right in terms of liquidations, trustless mechanism, and LP incentives - these are works in progress. I believe that we can actively push Incognito pDEX to the mass market when those issues are solved. Here is what we are working on to solve those challenges:

Interoperability

1. Portal v3 will be based on the Ethereum bond contract, which allows the use of ethereum based assets as collateral. Plus it will allow liquidations on Uniswap. Here is the design of the implementation. Estimated delivery time - end of November. Track development progress here.

2. We are also doing some research into related interoperable projects, such as Ren’s bridge implementation. They hold 10x more Bitcoins than are collateralized by their Node operators. We’re assessing risks and benefits, and if it all checks out, it sounds like we might have two options: to build a similar type of a bridge or use Ren as a bridge.

Liquidity

1. As I mentioned, Provide is a transition product, and will be continually improved.

Here is a quick graph on how the matching flow works right now:

2. We work towards launching a sustainable pDEX. Please jump in the Liquidity v.2. In this thread, we discuss Tech, Economic, Governance, and Growth ideas for the pDEX v2.

Thank you for sharing your thoughts and ideas!

[Revolve]

Hopefully I can put my 2 cents on some of the things you said @MrAwesome :

@MrAwesome

PRV flash crashing to $0 and self-coordinated custodial withdrawal of all individuals currency. Aka a majority of the custodial individuals steal the shielded funds rendering the p variants not equal to the custodial amounts.

If you are talking about Trustless Custodians: A Decentralized Approach to Cryptocurrency Custodianship, I believe that you are required to put up 2x collateral in the crypto that you are providing custodian services for (or at the very least Ethereum, or ERC-20 based coins [However I would prefer it the first way]).

If PRV is 0, and the collateral is in a different currency, your right in saying that you wouldn’t be able to trade the value for the backed collateral. I guess the simple fix is what I mentioned above, have the collateral be backed in the same currency, that way this isn’t a problem. But I am unsure why PRV would go down to 0, it might decrease in price, but it seems like it’s extremely unlikely for all the PRV to get liquidated as there is huge incentive to not do that (Large Value Loss). PRV is only as valuable as the liquidity in the system. As liquidity is pulled out, the less valuable PRV becomes, which means the more PRV is required to pull out.

@MrAwesome

If Provide is in fact needing to be matched still across the coin pairs paying compounding rewards for unmatched liquidity is quite literally wasting money for the incognito team. If they are missing PRV already to match these one sided liquidity options (that they are paying PRV rewards on) that is something which needs ASAP priority to be fixed. If people are providing one sided liquidity but it’s not matched and not getting added to the liquidity pool that is really bad.

I forgot to mention that the PRV that is given to the Provide Tab is being staked in a vNode. The earnings from all the PRV getting staked is what gets matched with other people’s crypto. I don’t know if that fixes the problem, but it means that there is a constant supply of PRV getting generated, ready to be matched. This PRV might possibly also be used to pay out rewards, not quite sure (I think the fixed nodes are more for that though). But if worst comes to worst, I believe PRV could probably get unstaked to match the influx of a particular crypto. Though the unstaking process does potentially take a while, so it might not be feasible.

@MrAwesome

Using a portion of the block rewards to top up the PRV matching pool to reduce the slippage and makes sure that people don’t need to necessarily buy PRV to transact is the best option.

I agree that this is a good choice for long term sustainability, but cutting off some earnings from stakers might upset some people. The community tries its best to come up with many different ideas to minimize negative impacts. I do however understand that this idea would be a net positive overall.

[MrAwesome]

@Revolve @andrey

There is a good feedback loop on both the reward systems and company reserve systems to make sure there is a influx of PRV into the Liquidity pool. The bond contract on ethereum is a good way to back collateral in a way which isn’t pegged on the value of PRV. It’s important that collateral is not only backed by a single coin’s value. Things can happen and if a coin’s price was to fall drastically the collateral getting liquidated in that falling coin is one of the worse things to happen.

Building interoperability for the other collateral systems to provide more ability to those who are already attached to other collateral projects to assist in this privacy protecting one seamlessly is a great idea. If the ease of enter is simply sending funds to a different contract address that will at least get some people to participate.

My main pain point about PRV being used as both the utility, staking, and collateral backing is that if anything ever happened (maybe a minor exploit which allowed collateral to be taken) that suddenly devalued the coin it can cause a full on chain reaction of liquidation in the entire network. Yes there is right now a large value loss potential making sure that PRV is at least valued at something when there is liquidity in the network. If that ever changed though it would spell the doom. Not an easy thing to handle.

As of making sure the PRV matching pool is always upped to use the one sided provide with a cut of the block rewards I honestly don’t think the stakers would mind. Being that ultimately it would be adding more liquidity in the network consistently on a compounding basis thus increasing the worth of PRV. Plus it would consistently remove the amount of PRV in active circulation locking it up to be use only for liquidity thus reducing the overall inflation which increases PRV price overall. If the network is going to be sustainable there needs to be matching liquidity for the one sided provide coins. At any point that there is not a excess supply of PRV to be matching the provide liquidity it will overall hurt the network by limiting the active pool size. Really it just makes sense to make sure that there is a fluid pool of PRV on standby to pair up any provided coins thus increasing liquidity. We can’t rely on a fixed slot company reserve.

[andrey]

Hey @MrAwesome

Regarding bridges. Important to clarify that bridge with a bond contract will be implemented for the bitcoin network, for the ethereum network we use a different approach that works in a trustless way and doesn’t require to have collaterals. A fun thing that we published it exactly a year ago on ethersearch:

Incognito mode for Ethereum

Regarding sustainability, I agree with you, if LPs get rewards that come from fixed slots, would make more sense to get it directly from the block reward, which will be fully decentralized and will not depend on any party.

A similar issue can be addressed to custodians or users who will maintain the cross-chain bridges in the future. Interoperability is already here, and the question of how to make it sustainable in a long run.

If you are interested in contributing ideas and knowledge to design tokenomic improvements that could make the whole ecosystem sustainable in the next 10-20 years, let’s make a working group and move it forward.