Hey guys! Great to see that you have a real interest in this topic. I read all messages and appreciate your feedback.
As you can see, this topic is in the idea section, so it’s the place to find the best solution before we start any implementation; feel free to keep sharing ideas or concerns.
Regarding the timeline, we need to find a solution for all those questions within the next 4-6 months by keeping priority (Tech -> Economic-> Governance -> Growth)
Hi Andrey, I like the ideia of PRV_DAO token but this token should bring value besides voting on Governance. What if some percentage of Beacon rewards (PRV) was used to create a treasure. Liquididy Providers can earn fees and receive PRV_DAO tokens. PRV_DAO can be traded on PDex or staked on treasure pool so the owner can accumulate a share from the treasure on regular base. When withdrawing from treasure, you receive your accumulated treasure share but give back PRV_DAO (to avoid PRV_DAO inflation and to stimulate adding liquidity again).
Welcome to the community pfrg… 
Not sure having a DAO token would help maintain simplicity when PRV can serve that purpose now. It is important to have fair governance and not having 1 or 2 whales dictate the outcome. This is currently the case on KyberDao there are many addresses that hold a significant amount of KNC but when Binance votes it pretty much dictates which way that EPOCH will go. This nullifies any votes for nothing more than getting your rewards.
For liquidity
This is a great idea and it would provide better incentive to add liquidity.
Would it be possible to add other tokens to Provide that are less active but still held shielded in incognito at a smaller percentage maybe like 2-3 percent start? This could incentivize users to provide one side liquidity who maybe can’t easily provide to two side requirements of Add or fear the impermanent loss.
what % are we talking about? 5% 1% 50% ?
this value is pretty important in “voting” for an option.
Concerning this, incognito has solved this. There is no impermanent loss because people provide liquidity one-sided to a pool. This is why I love providing liquidity on incognito and will probably provide more soon! I’m just concerned about so much value being controlled by a smartphone hotwallet.
I don’t think they’ve fully disabled the ADD and the PROVIDE is only for the coins listed there currently. Impermanent loss is still a factor in the ADD.
Oh got it…my mistake. Thanks for the correction.
A very good read about the governance problems and possible solutions
Thanks, Interesting article @andrey.
I like this approach as we are using a kind of this system already for our builder rewards
My suggestion to run the DAO:
Like now every community member with a certain trust level gets 1-3 tokens for voting. Every 12 months everyone is getting 1-3 tokens to vote for a person who shall be in charge of the DAO. The person who runs the DAO will have to create a clear roadmap, which is always up to date. For all the changes which are shown in the roadmap every community member again gets 1-3 tokens but these are not used to vote for the proposals on the road map. Instead, these tokens would be used to vote against certain ideas. Once more than…votes have been done against a certain point, the change will not happen and the community or the leader of the DAO can look for a different approach. It would be like a more democratic system but with more influence from the community. The leader has not to fight for every change and run campaigns in order to get votes for all his ideas. Instead, he can let it flow but if there are certain things where the community does not agree with, they can force a change in this specific point. I guess this would be a little bit like the political system in Switzerland.
I would like to point out the forum profile ‘trust’ level is more a participation indicator and not really an indication of who is known and trusted by the community to have its best interest at heart.
Yes this is true, do you have an idea to solve this? Only way I see would be to connect everything to the amount of PRV someone holds. But then the whole DAO will be controlled by whales and last but not least mainly by the core team, because they have for sure a huge stack of PRV.
I think it would need to be based on a voting type.
Similar to the SSL certs we use on Web hosts, they are approved by a Central Authority (CA), but can be signed by sub-Authorities.
They must be renewed after a period of time.
Initially I thought this could not be token based but with a monthly and/or quarterly expiration of a trust token then everyone could move their trust to others.
Depending on length with the project, community involvement and prv staked, you would be given (x) tokens.
In this way:
if you have been in the project for a long time you know the issues and how the community works.
If you are in the forums posting, and responding you will have a knowledge of who is helping and who is just profiting.
If you have a large amount staked for a long duration you have the most to loose by bad decisions.
Now you can keep your trust tokens, but you will never have enough to have a high level of trust. So these tokens must be sent to others that you think are solid, trust-worthy people.
Let’s say user1 has 5 length, 5 participate, and 3 stakes. (Total 13)
user2 has 2 length, 2 participate, and 9 stakes (Total 13)
user3 has 2 length, 5 participate, and 0 stakes (Total 7)
User3 Trusts user2 but not user1. User3 can send 1 token to user2 and now they have more trust.
User2 can trust user3 and not user1 so he gives 6 tokens, now user3 have more trust than user1.
Obviously in small examples the scale of our members sharing just 1 or 2 tokens to key members will raise a group to a high trust level.
There may need to also be a secondary trust token that members get due to number of tokens they receive, that can be given to a other members to boost their trust level up.
This allows a user that is trusted to up-vote others and not be left as untrustworthy.
Just a rough idea of one concept to get the conversation started.
This is very interesting.
A governance token with no market to trade it is interesting. It can be earned through a variety of activities.
I don’t know if liquidity providers will want this new token in place of PRV…but it seems like earning PRV+gov token would be one way to earn the gov token.
My gut says I trust you guys to run this project…you’ve taken us this far and I know you have a lot of plans. You already take the community’s thoughts into account. Formalizing the structure might be a distraction or a burden. My gut says the value should be in creating working products and focusing just on PRV.
Can we wait X months to let the defi craze of earning governance tokens wear off and see what works in real life? My gut says that the projects that create value for the users, will have tokens that are valuable (and thus people will opt to earn this tokens for providing liquidity rather than fiat/interest in-kind). The projects that are not valuable will see pump and dump of the governance token.
The more I think about this, I don’t like the idea of another token. We have PRV and the focus should be there. I don’t have a good solution other than to tinker with the provide rates to build liquidity where you want to focus it—you’re doing that now successfully.
Since you’ve read a lot of replies here, can you give us any insight to what you and the team find intriguing from our comments?
This thread is definitely useful and brings into consideration several interesting ideas about governance and some understanding of what could incentivize people to provide more liquidity.
We do not rush with making a decision on it right away. Need to research more to be sure we choose the best solution.
Despite most of the comments here around governance and incentives, the first priority is Tech. Once we get the final design of the required changes, we will be able to estimate the timeline and kickstart work on the Economic part, then Governance and Growth.
i am trying to get an detailed understanding of how provide currently works. The main thing that I can’t seem to find documentation for is how providers of liquidity don’t ever lose anything from impermanent loss. For example if there is 100 BTC in liquidity then someone trades USDC for 10 BTC how is it possible that the liquidity providers of BTC see the same amount of BTC even though there is now only 90 BTC in liquidity remaining?
If I am misunderstanding something please let me know. If there is no documentation for this would i be able to find the answer to my question by looking through the code here https://github.com/incognitochain/incognito-chain?
Hey @TeaBear5
The pDEX is based on AMM, so there is still impermanent loss possible, but it’s covered by the LP incentives fund. Find more about the fund here.
As you can see above, the Provide is a temporary solution for a smooth transition from ADD to the Liquidity V2. There is no special documentation for the Provide, but there will be documentation for Liquidity V2 (Tech & Economic). Just give us some time to work it out 
Do you think we could create a new coin that is minted based on impermanent losses?
Basically depending on the time you withdraw, if you suffered from impermanent losses, you get a specific amount of this new coin to cover the losses. If you took no losses, then you don’t get the new coin. It would only be calculated on withdraw and the amount is correlated to the value of the losses (USD).
What is the use case?
What if your required to stake the coin to use the Provide Tab? Basically your buying losses to prevent yourself from losing your crypto. But this new coin would have value because to put more in Provide, you need to stake more of this coin. It might be an interesting concept to look into.
Maybe you could also make the coin be used for:
I like the idea of using this coin to give access to the Provide Tab, the value of the coin would be determined by how safe people want to be with their crypto assets.
Using a system like this,
Might require that when you pull out of the Provide Tab, the impermanent losses would be taken out of your holdings in this particular coin instead of your actual crypto. Meaning you still take impermanent losses, you just prepaid for it. But if the economics are done right, you could potentially be earning with the coin too which might counteract the costs to withdraw.
Hey, @Revolve thank you for sharing. The idea sounds interesting. Regarding the end-users wouldn’t it be complicated to understand for them? 
.
Hmmm,
I was trying to think of a simple analogy that makes it easy for users to understand the concept, but I couldn’t think of anything. If we were to go more in depth on the system:
“Add” liquidity providers wouldn’t lose money from impermanent losses as they get compensated with a token at an amount that is equivalent to the losses. They can trade away this token and buy back the same amount of crypto that they lost. This also means providing for lower liquidity pools is less risky because your value isn’t lost.
People buy these tokens because it allows them to earn an APY from the provide tab without having the potential to lose their crypto assets. The Provide Tab also allows one sided provisions, so it’s beneficial for people who don’t want to match their capital with PRV in the “Add” section.
Companies like Nexo.io and Crypto.com all have their own coin that if you own, increases your APY. So it’s a similar concept, except there would be a few differences.
I’m not quite sure how the functionality of the new token should work as there could be many better alternatives then the one i’m putting forward.
With This System:
When users withdraw from “Add”, new tokens get minted based on impermanent losses and given to the provider. That means when people withdraw from the Provide Tab, which is a layer that works on top of the current “Add” functionality. New tokens would be generated.
We have a few options at this point:
We could automatically exchange these new tokens to buy back the losses;
– But this would just inflate the amount of tokens created and eventually the system would fall apart when to many tokens are generated.
Instead of generating new tokens, we take the tokens from the persons account and use those to compensate for the losses;
– This scenario forces the losses on to the user who uses the Provide Tab. (Problem)This might force users to use the “Add” feature instead, which means the demand for the token would go down, messing up the system, but i’m not sure.
We could have a membership like program with the Provide Tab. To enter, you have to put these tokens into the Provide Tab. The tokens slowly get removed at a specific rate (Reverse Interest), and all your other holdings gain at at their rates.
– It is a very weird idea, but the tokens getting drained by everyone who is using the Provide Tab can pay for the Impermanent losses. The earnings should be more then the losses, but idk if this would actually be the case.
I think option 2 is the best I have, but we need to create more of a demand for the token if we want it to succeed. I’d say adding it as a requirement for staking nodes would increase the demand really hard, but their might be other options.
Your average end-user doesn’t necessarily understand impermanent losses so your right that it might be difficult explaining why you have to add this token to the Provide Tab, and lose some of it when you withdraw. But if they earn enough money from putting this token into the provide tab through price increases, or some sort of staking system, then you could make it so they aren’t losing any money on the token and withdraws.
It would be much easier to explain buying this token to put money in. The money is then being used to generate more money to pay for the losses associated with withdrawing.
If putting the token into the Provide Tab returns a rate in the token itself, then it might work out. But I don’t know the logistics behind a mechanism like that. As long as users have to put some percentage of their value into the Provide Tab as this token, then I guess it could work (at least for a while).
Idk this was just some sort of crazy midnight idea I had a thought about, didn’t really work out all the details.