Terra Classic cannot be listed as Host Zone

[fragwuerdig]

Background

There is a small group of individuals who are known to the Terra Classic community and who are trying to get Terra Classic listed as liquid staking asset on Stride. They did some initial evaluations of the technical possibility for that. During their tests the following issue arose:

In order to list the staking asset of a cosmos zone the corresponding zone must be listed as host zone on Stride. Among other information the host zone store (living inside the stakeibc module) contains the chain-id and the denom of the native staking asset for the zone to be listed. Whenever a new hostzone is registered, the registering message handler is going to check whether the to be registered host zone is already in the hostzone store.

The host denom of Terra Classic is "uluna". It is the same denom as for Terra ("uluna"). Terra is already listed as staking asset on Stride mainnet. This makes it impossible to list Terra Classic on Stride mainnet as liquid staking asset, because during the registration of Terra Classic the existing "uluna" denom will make the registration fail here:

stride/x/stakeibc/keeper/msg_server_register_host_zone.go

Line 50 in e0c0291

if hostZone.HostDenom == msg.HostDenom {

Suggested Design

There is a possible backwards compatible solution that I wanted to discuss with the Stride team

1. Future LSD assets (aka "st" asset) will be prefixed with the chain-id, e.g. "columbus-5/stuluna", to avoid future clashes of host denoms from different chains.
2. LSD denoms that are already minted by the bank module will not be migrated to maintain compatibility with literally everything.
3. When constructing st-asset names some chain-id dependent exception handling will be needed to maintain compatibility with "legacy" st-assets. This is possible by changing the interface of StAssetDenomFromHostZoneDenom() to func(HostZone) string and implementing the exemption logic inside. I checked the source code and changing the interface is no problem, because the callers context has the corresponding HostZone available anyway.
4. Introduce an optional field chain_id in MsgLiquidStake proto to distinguish between host denoms that are the same but live on different chains. If the chain-id field is omitted, then legacy denoms will be preferred when searching host zones from the store by chain-id

I am open to develop such a solution so the Stride team does not have to. But before I do so I would of course like you to confirm the above solution as acceptable and workable. Thank you for your hard and ongoing work.

Humbly,
Till