You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is to have a way for the asset that is closer to any limit or close to 0 has an incentive to reduce / increase its composition in the pool. That can be done in any means:
exit pool (aka. swap from alloyed) with limit reaching asset
join pool (aka. swap for alloyed) with other asset
swap from other underlying asset to the limit reaching one
Not just close to a limit, but also close to 0, to increase its composition in the pool.
As an example, let’s say that the allowed range of nBTC in the BTC alloy is 0 - 10%
That means it CANNOT go above 10% or below 0% (obv)
But we want to have a “target range” of say 3-7%
This means that above 7% it should charge fees if you move it farther away from 7%
But also below 3%, it should charge fees if you move it close to 3%
These fees should increase the further you are from the target range
Additionally, given that the actual risk comes from bridge/chain rather than the exact denom. having bridge/chain tags and having limits/caps for them would make more sense than specific denom caps as the actual risk coming from bridge/chain vulnerability rather than the specific denom itself.
The text was updated successfully, but these errors were encountered:
iboss-ptk
changed the title
[Transmuter] Rebalancing Incentive
[Transmuter] Rebalancing Incentive Design
Jul 29, 2024
The idea is to have a way for the asset that is closer to any limit or close to 0 has an incentive to reduce / increase its composition in the pool. That can be done in any means:
example reference:
https://stargateprotocol.gitbook.io/stargate/v/user-docs/tokenomics/protocol-fees
Additionally, given that the actual risk comes from bridge/chain rather than the exact denom. having bridge/chain tags and having limits/caps for them would make more sense than specific denom caps as the actual risk coming from bridge/chain vulnerability rather than the specific denom itself.
The text was updated successfully, but these errors were encountered: