Fixed token and Bonds token

aggre commented 4 years ago

This proposal is designed to enhance the value of DEV further.

This proposal involves significant change. Therefore, it is helpful to get as much feedback as possible.

By this proposal, the issue that comes with APY going up (too much) turns into an increase in "bonds," not decrease value.

New structure of tokens

Symbol	Spec	Description
DEV	ERC20	Tokens with issuance cap. (The cap is the current total supply.)
pDEV	ERC20	Tokens pegged by 1:1 with DEV. By staking to a Property, it is also newly issued as a reward.
bDEV	ERC20	Bond tokens that are minted in the situation where pooled DEV is insufficient to pDEV. It also becomes a right to receive "pooled DEV for converting to pDEV."

Summary

The fundamental of the idea is to set a cap on DEV and stagger by bonds the timing of receipt of rewards. The increase in staking will reduce the number of bonds, keeping the tokenomics more healthy.

The total supply of DEV does not increase any more than it does now and has a cap.
Use pDEV (pegged to the DEV) for staking.
Rewards increase the total supply of pDEV, but the DEV is not increased. Therefore, the pDEV to DEV conversion may be oversubscribed. When oversubscribed, the pDEV is converted to bDEV instead of DEV.
bDEV can be preferentially converted to "pooled DEV for converting to pDEV."

Major lifecycle of tokens

By converting DEV or bDEV to pDEV, you obtain the same amount(1:1) of pDEV.
By staking pDEV to one or another Property, stakers get new pDEV block by block. pDEV works the same way as the current DEV.
When you convert pDEV with DEV in the situation where the total amount of deposits of DEV is insufficient, the bDEV token is converted instead of DEV.
bDEV can be preferentially swapped to "pooled DEV for converting to pDEV." bDEV takes effect by sending an exercise transaction to the Claim contract. That transaction brings a chronological priority to bonds.

Advantages

Since DEV is a fixed token, it is the most valuable in three tokens and surpasses the current value of DEV. pDEV and bDEV are rights that enable you to exchange with DEV, and their values are included in DEV.

Motivations for investors

Investors' purpose is to obtain the most valuable DEV as much as possible.
By staking after exchanging DEV with pDEV, investors can increase the amount of DEV that they hold.

Major risks

When the amount of DEV that is used for converting from pDEV is more than that of DEV that is deposited, its immediacy is lost because it gets bDEV instead of DEV. *However, bDEV becomes a right to receive future DEV.
In situations where there are too many bDEV (bond), more people may be hesitant to convert DEV to pDEV, reducing the staking rate. A proper APY is required to avoid that situation.

FAQ

Why bother staking with pDEV instead of DEV?

When a user converts DEV to pDEV, the DEV is deposited to the Converter contract. DEV deposited in the Converter contract is used when someone converts pDEV to DEV.

If you get pDEV by staking "DEV instead of pDEV," then your staked DEV may be consumed when someone else does pDEV to DEV conversion. This is a bad scenario, but when users have a significant amount of pDEV gained from staking rewards, and pDEV to DEV conversion is oversubscribed, deposited DEV could be reduced to zero. Staking will continue in such situations. In this situation, oddly, the amount of staking is zero while staking the DEV.

Staking by pDEV instead of DEV addresses that situation.

Akira-Taniguchi commented 4 years ago

・Why bother staking with pDEV instead of DEV? ・Are pDEV and bDEV also ERC20? 　・If that is the case, then there's a unique deal that occurs in DEX and other places that doesn't involve a converter.

@aggre

aggre commented 4 years ago

@Akira-Taniguchi

・Why bother staking with pDEV instead of DEV?

When a user converts DEV to pDEV, the DEV is deposited to the Converter contract. DEV deposited in the Converter contract is used when someone converts pDEV to DEV. If you get pDEV by staking "DEV instead of pDEV," then your staked DEV may be consumed when someone else does pDEV to DEV conversion. This is a bad scenario, but when users have a significant amount of pDEV gained from staking rewards, and pDEV to DEV conversion is oversubscribed, deposited DEV could be reduced to zero. Staking will continue in such situations. In this situation, oddly, the amount of staking is zero while staking the DEV. So that's what it means to stake using pDEV.

・Are pDEV and bDEV also ERC20? 　・If that is the case, then there's a unique deal that occurs in DEX and other places that doesn't involve a converter.

Yes, that's right.

I'll update the original post.

calaber24p commented 4 years ago

I think the three coin system this proposal uses adds an interesting dynamic with arbitrage between bdev and dev/pdev. For example im sure bdev will trade at a discount so it could reward those who wait for it to turn into dev.

My only large concern is that in practice a huge amount of bdev is issued and people are waiting a long period of time for it to convert over. Like you said this will come down to incentives though.

However that being said I worry that the system is over complicating things and people might have a harder time understanding how the system works, which could turn off new creators from entering the platform.

pdotall commented 3 years ago

I'm trying to figure out the system.

So when staking, for examples, that on t0 DEV 1:1 pDEV. On t1, let's say there's a 20% emission. So, it ends up being DEV 1:1.2 pDEV.

The idea is that it necessarily needs another player to join and cover that 0.2 DEV difference?

What if there's a 'bank run'? There won't be enough DEVs in the system. It just ends up being a ponzi, just like the current banking system, but we can't afford to 'close our doors' neither be rescued by other banks, if we can't print in this system, this is a fatal flaw.

One main issue that I still think about is that, for DEV to be sustainable, it should be sustainable even if there's One Staker and One Creator. It currently isn't, and this is the main negative aspect, it always need new 'blood' to keep it sustainable, in times of fear, the system collapses.

What if, DEV remains inflationary and the governance token is pDEV. pDEV has a cap, and is deflationary, some sort of mechanism deposits DEV on the pDEV contract, be it revenue based(buybacks) be it inflationary based, this way pDEV gets more valuable overtime in relation to DEV. Everytime anyone wants to withdraw, they'll automatically convert their pDEV since there are more DEV than pDEV in the pool.

aggre commented 3 years ago

So when staking, for examples, that on t0 DEV 1:1 pDEV. On t1, let's say there's a 20% emission. So, it ends up being DEV 1:1.2 pDEV.

The idea is that it necessarily needs another player to join and cover that 0.2 DEV difference?

What if there's a 'bank run'? There won't be enough DEVs in the system. It just ends up being a ponzi, just like the current banking system, but we can't afford to 'close our doors' neither be rescued by other banks, if we can't print in this system, this is a fatal flaw.

Thank you for your opinion. Think of this idea as immature and like a thought experiment. As you say, there are obvious risks. And I don't have a complete scheme to get around it yet.

What if, DEV remains inflationary and the governance token is pDEV. pDEV has a cap, and is deflationary, some sort of mechanism deposits DEV on the pDEV contract, be it revenue based(buybacks) be it inflationary based, this way pDEV gets more valuable overtime in relation to DEV. Everytime anyone wants to withdraw, they'll automatically convert their pDEV since there are more DEV than pDEV in the pool.

This new idea by you is interesting. If you have an expected deflationary mechanism for pDEV (let's call it gDEV), please let me know. I'll sort out the ideas later, but I'd like to consider indirect democratic governance like DPoS, creator support without undue bias.

pdotall commented 3 years ago

''' This new idea by you is interesting. If you have an expected deflationary mechanism for pDEV (let's call it gDEV), please let me know. ''' It would be pretty straight forward, on t0 there's a snapshot. gDEV = DEV 1:1; DEV continues to inflate, and some sort of mechanism deposits DEV into the gDEV pool, where individuals stake for Creators. gDEV continues to get more valuable in relation to DEV, since the number of gDEV will always stay constant.

This also reduces the incentive to sell, since the variable individuals see is gDEV, not DEV. For someone to sell their rewards, they would need unstake gDEV, since the reward system is inside gDEV now. So, to sell, the individual necessarily ends up with less gDEV.

aggre commented 3 years ago

@pdotall Can you explain with some components of 30 words or less to understand your suggested gDEV?

My understanding:

User gets gDEV by depositing DEV to a gDEV contract (Or does gDEV have a fixed supply and an allocation by a genesis event?)
gDEV's supply starts from 0 and will not be minted after a cap is reached
gDEV can use to stake on each Property
gDEV can be revert to DEV freely
The rate of DEV:gDEV is not 1:1, fluctuates with the inflation of DEV
Users who staked when "DEV:gDEV = 2:1" and unstaked when "10:1" increase 8x DEV

pdotall commented 3 years ago

Let me try @aggre ,

On day 0, a new staking pool contract is created.
-you stake and receive gDEV on the proportion of the pool. Day 0 is 1:1. -the gDEV cap could be the current amount of DEV staked. Let's say 500k DEV. -DEV inflates and is deposited on those pools, a 1000 gDEV holder could withdraw 1300 DEV after one year, if the apy is 30%. -now that gDEV is the token in their wallets, they don't see the rewards as an 'excess' and would be less prone to sell them since they'll necessarily have less than 1000 gDEV if they sell.

pdotall commented 3 years ago

gDEV I noticed a few problems with my idea now:

all gDEV (governance token holders) are able to receive the inflation.
for this to be implemented, the concept of staking has to be different. Maybe another way to distribute through voting?
on day 0, create a 24h or 48h period where no Dev minted is deposited on the contract, so that current stakers all get to stake at 1:1.
create other incentives? and some burnig mechanisms?

aggre commented 3 years ago

Thank you for your opinion. I'm still not sure if there is a gap between your opinion and my understanding, but I've organized the gist of the specification as follows. I would like to ask if there are gaps and if there are different views. (The day 0 you refer to is what I understand as a genesis block in gDEV.)

What is the interaction between DEV and gDEV?

Stake DEV to get gDEV (synonymous with borrowing gDEV with DEV as collateral)

How the collateral rate should be determined?

What should be the collateral rate at a genesis block in gDEV?

Is your expectation of providing gDEV under the same conditions to all users who have already staked DEV at the time of a genesis block in gDEV? If so, Dev Protocol can do it with a contract like Markle Distributor, and users can borrow with that initial condition at any time. (but limited to once)

What the collateral rate should be after a genesis block in gDEV?

In my opinion, the collateral rate is curved by a mechanism similar to an automatically market making such as Uniswap because gDEV has a cap, it cannot give equal opportunities to all users. If the rate is not a curve, the dynamics need to bridge the inequality of opportunity. Since gDEV has a cap, I think the protocol can draw a curve with a simple formula.

DEV issued as rewards will automatically enter the gDEV's collateral pool.

Unstake gDEV to get DEV (synonymous with repayments gDEV and redeems DEV)

In my opinion, the DEV equivalent to the collateral will be redeemed according to the collateral rate at the time of unstake. If the collateral rate is curved, one unstake will lower the collateral rate and the next unstake will be a bit of a disadvantage. I haven't been able to judge the pros/cons of this yet.

Total supply of gDEV

In my opinion, it starts at 0 and reaches the cap at around 9.3M. That is equal to the total supply of DEV at the moment. The basis of this idea is that all DEVs are stakeable, so it is reasonable to have a value close to the DEV's total supply (at a given point in time).

It is possible to set the gDEV collateral rate to a minimum of 2 or 3, but I think it is necessary to consider whether it is rational.

pdotall commented 3 years ago

Thank you for your opinion. I'm still not sure if there is a gap between your opinion and my understanding, but I've organized the gist of the specification as follows. I would like to ask if there are gaps and if there are different views. (The day 0 you refer to is what I understand as a genesis block in gDEV.)

Thank you for the great discussion @aggre , I think I was a little confusing in my post, I'll try to make my idea more clear. Day 0 is indeed the genesis block, but my idea was to delay the emissions of newly minted DEV tokens into that pool so that the proportion of DEV:gDEV was 1:1 for that time and early supporters could all get in the pool at that proportion.

In my opinion, the collateral rate is curved by a mechanism similar to an automatically market making such as Uniswap because gDEV has a cap, it cannot give equal opportunities to all users. If the rate is not a curve, the dynamics need to bridge the inequality of opportunity. Since gDEV has a cap, I think the protocol can draw a curve with a simple formula.

DEV issued as rewards will automatically enter the gDEV's collateral pool.

I think that having a hard cap made it sound really complex, even though I found your solution to it rather interesting and I'll study it further.

The intention was, gDEV will be swapped to staked DEV, but the proportion between them would be variable, so there always be equal opportunities, it's just that in that pool the price of gDEV in terms of DEV is always increasing.

For example: I deposit 10.000 DEV on the pool on day 0 (genesis) , I get 10.000 gDEV back in my wallet. On day 1 (or at a time to be decided) the pool starts to receive rewards, so the APY will be poured into the pool. With that the value of the rewards will always be inside of gDEV, the rewards wouldn't be seen as an extra/eternal DEV, it'll be inside the price of gDEV, this could change the psychology behind the decisions of sellers.

Let's say the APY in one year after I deposited was 30%. The equivalent of 3.000 DEV for me was deposited in that pool. I would still have 10.000 gDEV, it would just be equivalent to 13.000 DEV.

Imagine if Bob wanted to stake 6 months after I deposited, and he was the second one to do that. At that time gDEV:DEV would be equal to 1.15:1 , so if Bob deposited 10.000 DEV he would get ~8,695.65 gDEV.

I didn't do any simulations but I think that these is what you were referring to as the curve. The apy would change, it needs to be adjustable, and so is the price of gDEV:DEV (gDEV proportion/value in relation to DEV can't go down) , adding more stakers would probably make the APY converge but this is the basic concept.

I don't know how technically viable is this, it's just an idea to try to change the behavior of stakers, have a way to implement gDEV and maybe a solution to the FINMA request. With this the concept of re-staking would not exist. Since gDEV already does that, but in a linear way.

pdotall commented 3 years ago

Please tell me if I'm being too crazy just throwing ideas out there.

How about a general gDEV pool where minted DEV are deposited and the proportion of gDEV/DEV always grows, as I've mentioned above.

Then, gDEV were deposited on creators Contracts and this would give gDEV stakers the tokens from this Creator, instead of it going to the Treasury.

This could be a way of 'forcing' Creators to be active and earn those stakers. Since it's a problem today that, people stake not because they want to fund that specific staker, it's because they want the APY. So they just stake AND stakers are not using their tokens or not promoting enough, so it might help.

A few tokens that have pools that would be similar to this:

https://app.alchemix.fi/farms https://stakedaohq.medium.com/stake-dao-introduces-sdt-staking-and-adjusts-the-sdt-rewards-9376c7352515 https://badger.wiki/badger

aggre commented 3 years ago

Thanks for your input. Now I think that there is probably no gap between you and me.

How about a general gDEV pool where minted DEV are deposited and the proportion of gDEV/DEV always grows, as I've mentioned above.

Then, gDEV were deposited on creators Contracts and this would give gDEV stakers the tokens from this Creator, instead of it going to the Treasury.

I thought inflated DEV would automatically be added to the gDEV collateral pool (I think we share the same opinion, right?). In other words, the DEV collateral ratio to get gDEV would automatically keep increasing. However, that collateral rate will decrease when the gDEV is repaid, and the DEV is redeemed. This is my view.

In your idea, gDEV stakers receive Property tokens instead of DEV. So I imagine that gDEV stakers will get Property tokens by unstaking gDEV. Am I right?

If I'm not mistaken, backers get gDEV from DEV (or gets it on secondary markets), stakes the gDEV in Property tokens, waits a while and then unstakes the gDEV. In the end, the backer is left with the Property tokens and the gDEV. Or is it just the Property tokens?

There are some considerations yet, but I think the concept is an interesting one. So, first of all, I want to make sure that there are no differences between my opinion and yours.

pdotall commented 3 years ago

Oh yes, I think that the idea is getting clear.

I thought inflated DEV would automatically be added to the gDEV collateral pool (I think we share the same opinion, right?). In other words, the DEV collateral ratio to get gDEV would automatically keep increasing. However, that collateral rate will decrease when the gDEV is repaid, and the DEV is redeemed. This is my view.

This is what I tried to explain yesterday, in this model inflation occurs only inside the gDEV pool, so there will always be more DEV than gDEV, and the proportion of gDEV and DEV should always be the last gDEV:DEV deposit. gDEV is equal to all the deposited DEV in the pool at the proportion of the time it was deposited. It will only be 1:1 on the genesis.

For example, imagine that after 3 years, there ratio between DEV and gDEV in the pool is 2:1 . A new 100 DEV staker that bought DEV, wants to get gDEV, he would swap it to 50 gDEV. Now if everyone left the pool at the same time, they should all be able to claim their DEV at that proportion. The proportion never goes down. Even when gDEV is swapped back to DEV.

This is how all those examples above of single sided staking work.

https://app.alchemix.fi/farms https://stakedaohq.medium.com/stake-dao-introduces-sdt-staking-and-adjusts-the-sdt-rewards-9376c7352515 https://badger.wiki/badger

In your idea, gDEV stakers receive Property tokens instead of DEV. So I imagine that gDEV stakers will get Property tokens by unstaking gDEV. Am I right?

This was a secondary idea/possibility, gDEV holders would get the rewards just by being governance token holders. This could 'force' creators to do something with their tokens or platforms to attract the stakers. gDEV holders could stake their gDEV on a creator pool, Stakers wouldn't get any extra DEV for that, but they could get the Creator tokens when staking directly. This could help with the FINMA resolution and increase the use cases of the Creator Tokens.

When unstaking from a Creator pool, the staker would get back all of his gDEV + the Creator Tokens.

Is this closer to what you understood?

aggre commented 3 years ago

Oh, thank you, I understand now. (When I said that the collateral ratio would decrease, I meant it would fall relatively, not below 1:1.) Once again, I've sorted out my own thoughts and will share them here.

aggre commented 3 years ago

I think it is worthwhile to put up an RFC on the forum for the ideas that have been raised so far. I will summarize the ideas and discuss them on the forum.

pdotall commented 3 years ago

I think it would be great as well! Can't wait to discuss this further.

pdotall commented 3 years ago

Hi @aggre sorry to bump this discussion again, I just want to add some ideas and clarifications that might help in the future.

If, the Staking pools are totally open for staking and gDEV is not really fixed, but everyone that staked gets gDEV (at first the markle distribution 1:1 is a good idea). In this case, gDEV would capture only the emission that happens inside the Stakes Social system. Emissions that happen outside of it, like on the Geyser, or even other kind of way that DEV tokens that come from [(TotalSupply-CirculatingSupply)-(emission)]>0, won't be captured by gDEV. This could even make gDEV inflationary if staked{[(TotalSupply-CirculatingSupply)-(emission)]}>(emission). gdevtotalemission

Not fixing gDEV would mean that there will always be gDEV being added to the pool at diffrent :DEV proportion. This would mean that there always be gDEV available for conversion. Which is a great thing.

That's it, just a little point for further discussion, when possible.

pdotall commented 3 years ago

Another art just to visualize how this would incentivize Creators to do something to attract Stakers, and how Perks are a key part in this. gdevpool

and an economic game - game theory induction tree. gdevgametheory

dev-protocol / DIPs