-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Gilts Pallet #8139
Gilts Pallet #8139
Conversation
Co-authored-by: Shawn Tabrizi <[email protected]>
Yes. Obviously any chain introducing this should configure the economics appropriately. |
Presuming this makes its way onto Kusama, what kind of "economic configuration" would make sense? Also this pallet will do crazy things if it is introduced at genesis along side the claims pallet. 💸 |
I expect ~12% for the target frozen under gilts, with otherwise the example parameters. But it probably makes sense to roll it out slowly and ramp it up depending on takeup. |
Gilt::enlarge(200, 3); | ||
|
||
// Double everyone's free balances. | ||
Balances::make_free_balance_be(&2, 100); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this correct? 2 is not everyone else, nor is the 100 double its original balance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment refers to the following three lines. 2's free balance is 50 (50 was reserved and a gilt issued). 1's free balance is zero. So this does what it says - doubles their free (i.e. non-gilted) balances.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty neat.
Staking should always have higher reward right (ignoring fee & slash)? Say 50% staking rate, 10% inflation rate and all goes to stakers, that's 20% reward rate not 10%. Gilt will only get 10%. |
* Initial draft * Enlarge function drafted. * Thaw draft * Retract_bid draft * Final bits of draft impl. * Test mockup * Tests * Docs * Add benchmark scaffold * Integrate weights * All benchmarks done * Missing file * Remove stale comments * Fixes * Fixes * Allow for priority queuing. * Another test and a fix * Fixes * Fixes * cargo run --release --features=runtime-benchmarks --manifest-path=bin/node/cli/Cargo.toml -- benchmark --chain=dev --steps=50 --repeat=20 --pallet=pallet_gilt --extrinsic=* --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/gilt/src/weights.rs --template=./.maintain/frame-weight-template.hbs * Grumble * Update frame/gilt/src/tests.rs Co-authored-by: Shawn Tabrizi <[email protected]> * Update frame/gilt/src/tests.rs Co-authored-by: Shawn Tabrizi <[email protected]> * Grumble * Update frame/gilt/src/tests.rs Co-authored-by: Shawn Tabrizi <[email protected]> * Update frame/gilt/src/lib.rs Co-authored-by: Shawn Tabrizi <[email protected]> * Update frame/gilt/src/lib.rs Co-authored-by: Shawn Tabrizi <[email protected]> * Fix unreserve ordering * Grumble * Fixes Co-authored-by: Parity Benchmarking Bot <[email protected]> Co-authored-by: Shawn Tabrizi <[email protected]>
I looked at the code and think this is ok mechanics wise. But we need to think about potential issues. The first I want to comfirm is whether or not we need to change the staking reward logic to get our target inflation figure. The logic works out how many tokens to mint to get the target % inflation, e.g. 10%, of tokens to be minted in a year and then divides that between the stakers and treasury. It's important that the total token supply used for that calculation does not include gilt locked tokens, as if it did, we'd end up with over 10% inflation. If we make the gilt locking limit 10% of the total supply, then I don't see it affecting the economics or staking security too much. However if 90% of tokens are locked like this and only 5% are used for staking, then we have a potential security issue that 2.5%-10% of tokens could be unlocked and used to stake and attack Polkadot more cheaply than is currently possible. We could limit that threat and have a higher fraction locked by making sure that not too many tokens could be unlocked at the same time. For that we'd want to rework the lazy unlock logic to force people to relock tokens. That can still be lazy; it's just that we'd limit inflation rewards to the lock duration rather than the total time since it was locked (though then the problem of including them in the total supply for staking again is an issue). Then we'd need complicated logic to allow locking only when not too many tokens would be unlocked near the end of the locking duration. Obviously that's not a priority if we want to test the economics and demand for this with small fractions as the limit first. And it also would make this even more complicated. |
If I understand, gilt says "inflation of my tokens do not pay for validation." It's useful when stakers unstake so they can avoid loosing most of their returns while locked, which encourages unstaking and makes dots more liquid. I donno if stakers can or should unbond directly into parachain backing. There is a problem however that gilts ignore slashing which makes gilts de facto a bet that slashing occurs, which sounds problematic politically if not for deeper reasons. We should probably apply slashes to gilts in some form, perhaps pro-rated by inflation with lower bound on the pro-rating, so that Alistair's concerns about 90% gilts never occurs. I've not thought through the exact details however. |
I might not see the bigger picture and/or miss some crucial aspects of the idea but I have a few concerns:
Aside from that and as a somewhat unrelated idea, I think providing some compensation for unbonding might be very good for the network. Right now, in Polkadot users forgo on almost a month of staking rewards if they unbond (in addition to be not liquid). This makes custodial services, which offer similar staking return but 0 unbonding time quite attractive. Giving some compensation for the unbonding time could increase the incentive to own your keys. |
@jonasW3F this exactly summarizes my concerns. Thank you. |
If gilts are considered to be beneficial from a tax perspective to reduce the number of payable events, there might be other ways to do so. For now, users could stake with third-party custodial services and sign an agreement to make sure that payouts are only once per some period, or, once we have parachains, such a system could certainly be implemented trustless. |
I don't think tax-friendliness is the goal here. |
My understanding is that we currently have 2 options and
What
This thread already mentioned the issues if the IMO
|
At Parity's Delivery Services team, we are doing some Learning Sessions, where we do presentations on many FRAME's pallets with the goal of spreading knowledge. For this week, The pallet isn't necessarily 100% "risk-free", given that some meaningful deflationary event will cause the user to actually lose tokens, which would be actually worse than not having tokens in a gilt during that period. Whether such deflationary event is actually possible or not is a separate tokenomics issue, but we should at least be careful about saying 100% "risk-free" or "0 risk", or at least restrict such narrative to exclusively inflationary contexts. |
TODO: