Repository navigation
Reduce Rewards for Unauthenticated Property #9
Description
Anyone can create a Property, now. But, is it suitable for people who are not creators or developers, etc. to create properties, stake on it, and receive 100% of the reward?
But, specifications that require oracle on mining will damage UX.
Solution
I propose to reduce the total reward for a Property that has not been authenticated.
Reduces the total reward (holders + stakers) for a Property that is not authenticated for any Market. I think that the reduction percentage should be the same as the holder reward share. In the current Policy, holder reward share is 51%; therefore, the total reward of unauthenticated Property will be reduced by 51%. Its percentage depends on effective Policy at this time.
Although I thought an idea to increase/decrease depending on the number of authenticated assets, it is not always good for creators to have a large number of assets. So it should change the total reward depending on whether a Property is authenticated or not.
However, this proposal also rejects participating in areas where creating a Market is difficult. Please comment if you have any other ideas.
Activity
defi-er commentedon Jul 28, 2020
I would rather make sure that property can't be created if it's not authenticated. If this is not possible then I think this is a good solution to stop users from staking in asset pools which have not been authenticated. However, to provide further disincentives for the property owner you can implement a large burn on withdrawal of rewards received from property that isn't authenticated.
aggre commentedon Jul 31, 2020
@defi-er Thanks for the idea!
I think to negative incentives from burning are a simple and reasonable idea. I will consider it in detail!
aggre commentedon Aug 14, 2020
This issue is not inherently an authenticated/unauthenticated issue; it's a question of whether there is an entity because it cannot dispel the possibility that an authentication result is a dummy or empty content.
I'm considering using a Market's asset valuation method that worked before DIP4. At that time, it was used to calculate the reward rate. In this DIP, it is used to judge target or not of a penalty.
If the result of the asset valuation is less than or equal to the average of
x%, then the target Property can not receive any reward until it reaches theyblock. The Policy manages these variables.Penalty decisions are opt-in and generally are not enforced. In other words, if there is communication between the Property author and the stakers, or if the authenticated assets are valid, no one will execute the penalty. Even if the penalty is executed, nothing happens if the asset value exceeds the threshold.
Besides, if a user withdraws the reward when a Property not authenticated,
z% of the reward will be burned. This percentage is equal to theholdersSharedefined in the Policy.aggre commentedon Aug 15, 2020
This method( #9 (comment) ) increases dependency on oracle and makes it difficult to create a new Market. Market must always implement valuation formulas, and it will not be possible to create a Market without a clear indicator.
So I think we need other ideas. For example, we are also considering a scheme such as claims and challenges.
defi-er commentedon Aug 15, 2020
I believe unauthenticated assets and authenticated dummy assets are two completely different issues with two different solutions.
Unauthenticated assets- Don't grant rewards to unauthenticated assets
Dummy assets- Implement Kleros as decentralized arbitrator to find and remove dummy assets
defi-er commentedon Aug 15, 2020
If you use Web 2.0 property metrics (downloads, likes, views) to decide if something is worthy of creating inflation in Web 3.0 then this still opens the door for an attack. Downloads, likes, and views can all be automated and purchased. This attack is also reasonably cheap.
defi-er commentedon Aug 15, 2020
There's a flaw with using downloads x staking as a weighted average. Staking and downloads are highly correlated since users have a bias to support large projects. This ultimately becomes a network effect on Dev Protocol as seen by Chalk. Therefore, successful attackers could have a lot of DEV staked from unknowing stakers which will get them approved in your formula. The proposal put forward would allow effective bad actors to be accepted and non effective bad actors to be rejected.
Cold-A-Muse commentedon Aug 15, 2020
Maybe it is also an idea to look at the amount of stakers in a project + how much they each stake into it as additional metrics?
aggre commentedon Aug 15, 2020
This is what actually happened. Therefore, this can also happen.
@defi-er Which do you think is better: zero rewards or a reduction of the same amount as the creator reward amount?
With zero rewards, the code of protocol can keep simple.
I also think the arbitrator implementation is appropriate. We should increase integration with arbitrator protocols like Kleros.
@Cold-A-Muse The account address is considered essentially meaningless. It's easy for an attacker to generate a large number of addresses, and it's easy for a bot to automate it.
As @defi-er said, DIP9 can be broken down into two problems. First, set the reward for unauthenticated assets to 0, or implement the reduction.
Next, we will take measures against dummy assets. This should be created as a new DIP, so I will create a DIP later.
defi-er commentedon Aug 15, 2020
@aggre
Zero rewards is the best option because we shouldn't allow unverified actors, or bad actors, the slightest chance of creating artificial inflation which I believe to be an attack on the protocol and the protocol's participants.
Unauthenticated assets currently don't show in the Stakes Social dashboard, which is good. We can take that a step further by not allowing deposits into unauthenticated asset pools.
aggre commentedon Aug 15, 2020
Thank you for your opinion. I also agree.
I updated this DIP status to Stage 2. We will prepare to develop, with seeking additional opinions.
The problem of dummy assets was opened by @defi-er as #14, thank you.
And I deleted duplicate two comments.
Akira-Taniguchi commentedon Aug 17, 2020
I think so, too.
1 remaining item
aggre commentedon Aug 18, 2020
We are working on some parts of the development.
Let I wrap-up the specs:
defi-er commentedon Aug 18, 2020
I agree on all points, but I'm impartial on point 3. It would be nice to set a strong precedent though.
aggre commentedon Aug 19, 2020
Most of the implementation is complete. I share one concern here.
Authenticated assets are removable. (But there is an exception, Current NPM isn't removable)
That is, an authenticated-property can become an unauthenticated-property.
According to the current specifications, the reward is temporarily 0 when their status changes from authenticated to unauthenticated. If they go from unauthenticated to authenticate again, the reward will be repaired with also includes an unauthenticated period.
The Wrapped Property proposed by DIP #5 reduces the need for asset removal, so we might consider removing the asset removal feature.
defi-er commentedon Aug 19, 2020
Good catch.
What's the problem here?
The reward should go to 0 when an asset becomes unauthenticated. If it becomes authenticated again then it should start accumulating rewards at current APYs. What's the unauthenticated period and what's its significance?
We should solve this before moving onto DIP #5 which may overgeneralize the complexities.
Also:
If authenticated assets become unauthenticated then what happens to user's stake? Do they get returned or they must be withdrawn?
aggre commentedon Aug 19, 2020
Consider the real-world case:
That's all.
In reality, the unauthenticated period is short, but the specification allows an unlimited period.
A staker who believes Alice will recertify will wait for reauthentication.
However, this issue is annoying, so I'm considering if the asset removal feature should be removed in the future.
aggre commentedon Aug 19, 2020
Note: If Alice authenticates both "lib-alice" and "lib-alice-2" and then removes "lib-alice", this problem does not occur.
defi-er commentedon Aug 19, 2020
aggre commentedon Aug 20, 2020
As the development issue was closed, this issue was also automatically closed as well, but I reopen because the discussion continues yet.
aggre commentedon Aug 20, 2020
Alice may or may not do it. Alice only transfers 100% to Bob, de facto ownership is transferred. However, the Author's address recorded in Property "alice" does not change, so it does not look good. (That is the motivation for Bob to create a new Property.)
Yes, Alice may or may not remove "lib-alice". In fact, those procedures are based on a trusting relationship between the two parties.
If their relationship can trust each other enough to make the transfer of the project viable, that problem may not manifest. A secure transfer of the ownership can be achieved by using a contract like escrow; Dev Protocol is not involved in that process.
I'm sorry if I used faulty expression. "lib-alice-2" is Alice's project, so Alice can authenticate it herself.
What I'm trying to figure out is how we should handle rewards for the unauthenticated period when Alice makes the state transition like Authenticated -> Unauthenticated -> Authenticated.
aggre commentedon Aug 20, 2020
I'm thinking of deploying DIP9 with the current specs, as the issue of toggling authenticated and unauthenticated is not yet alive.
defi-er commentedon Aug 20, 2020
I agree, DIP9 should be deployed with the current spec. This issue won't appear in the near future. When it does then an authenticated property to unauthenticated property should receive 0 rewards. However, if a property receives 0 rewards then creators will never "deactivate them".
aggre commentedon Sep 24, 2020
I created another DIP ( #20 ) about self-staking, so I close this DIP.