Identification of Staking & Fee Assets about chain-registry HOT 11 CLOSED

I think Number 2 could work well, it should also have some data of what kind of staking system the chain uses (interchain staking, interfluid, epoched staking, etc)

from chain-registry.

Thanks for contributing @mccallofthewild

Can we include comments in the schema or README defining what each of these systems means? Once we get to 'epoched' and 'permissioned-liquid', I start to get a little confused of what those mean... Also don't know which to use to standard/native staking, and what about superfluid staking (unless that under another category)?

Finally, I'm skeptical that this structure alone will be able to capture the various ways that each asset might be able to be staked. Are we to assume that all staking tokens are applicable to all staking systems specified? What if some tokens are stakable one way, and another set of taken are stakable another way?
Perhaps we should have each staking system have it's own set of tokens (or each token have its own set of systems)?

from chain-registry.

@pyramation I do too but the staking denom should be available at the chain level without having to load all tokens and their metadata

And to answer your question, ICS / Interfluid / Superfluid would suggest yes. But for the purposes of this PR, I just want to identify the asset which represents a sovereign unit of voting power

from chain-registry.

I like the idea of being able to specify different types of staking (i.e., interchain, interfluid, etc.), if required, although it's hard to imagine before much of this has been enabled.

I worry that as more and more types of assets might be accepted for paying fees on a chain, that we'll be having to repeat a list of all the assets again in the chain.json file just to specify them as a fee asset. I don't know if this might ever happen for staking. For this reason, I'm wondering if instead adding properties or features under assets in the assetlist.schema might be more efficient.

Another alternative is to specify default staking and fee currencies in chain.json, (like we have now, plus combined with option 2,) but then expanding upon it could happen in the assetlist.json.

For specifying fee assets, I think it'd be nice to also specify minimum, low, average, and high fee rates (like in Keplr wallet) for each fee currency.

e.g.,
Under assetlist.json::asset
"fee_currency": { "minimum": 5, "low": 100, "average": 130, "high": 250 }
and
"stake_currency": true

from chain-registry.

Staking & fees both belong on the chain level. An asset alone doesn't need that context. Particularly not when it's an IBC voucher on a counterparty chain.

    "staking": {
       "staking_systems": [ "superfluid" ],
        "staking_tokens": [
            {
                "denom": "uosmo",
            }
        ]
    },

Going to open a PR with the schema updates. Initial staking_systems enum will include

interchain | interfluid | epoched | permissioned-liquid

from chain-registry.

@JeremyParish69 There is no standard for any staking system besides default DPoS so I don't forsee the staking_systems property being much use beyond user-facing metadata.

All tendermint based systems should still have a token representing units of voting power, even if it is derivative of other tokens or dynamically managed by the protocol. So for superfluid/interfluid, you can bond LP tokens but uosmo is still the unit of voting power, as calculated by the TWAP of the pair.

"staking_systems" is a bit of a catch-all. It could also be "staking_features". Epoched staking is a more efficient implementation of staking/distribution that uses time intervals rather than exhausting compute at every block. Permissioned Liquid staking refers to the Crescent model where they have a permissioned whitelist of validators that can receive system delegations from ucre bonded into ubcre.

from chain-registry.

Thanks, @mccallofthewild.

If I may ask, should we split superfluid from interfluid? Superfluid refers to the OSMO in the LP to count as stake, while interfluid refers to the foreign token in the LP (e.g., ATOM) to count as stake on a foreign chain (e.g., Cosmos Hub), and I'm thinking these are sufficiently distinct such that they warrant separate categories. Thoughts?

Also, as for epoched, I believe the natively staked OSMO is not epoched, but only the bonded LP incentives is epoched.
I don't know, however, if superfluid staked OSMO is epoched, so Osmosis maybe should have that, but also not... Kinda thinking 'epoched' perhaps should be removed because of the timing (maybe) only applying to a certain type...

from chain-registry.

@JeremyParish69 superfluid -> interfluid sounds right.

Osmosis LP rewards implement epoching. But ADR 39: Epoched Staking was proposed by Dev & Sunny a while back to improve the efficiency & reliability of the staking module. Development is on pause right now so I'm happy to exclude it until the implementation is complete.

from chain-registry.

I like simplicity of stake_currency: true.

Question: is it possible stake more than one currency on a chain?

from chain-registry.

Starting to think we should take a step back to:

    "staking_token": {
        "denom": "uosmo"
    },

As @pyramation suggested there is really only one sovereign unit of voting power per chain. And all of the aforementioned staking_systems either don't exist yet or only exist on one chain, rendering them mostly useless in this context.

from chain-registry.

One of the most frequent blockers is guessing what technology there will be and trying to anticipate that from the start. In this case, I think we aren't risking too much work or loss of data by omitting the staking systems, so I'd be OK with just "staking_token" to get quicker movement on this. Would you be able to make that change to you PR, @mccallofthewild ?

from chain-registry.