This proposal recognizes a generic specification of Alloyed Asset as being the canonical representations of assets on Osmosis. This generic specification is required to reduce governance load by declaring a standard that all newly formed alloyed assets are held to.
What are Alloyed Assets?
Alloyed Assets comprise multiple underlying bridged assets within a tokenized CosmWasm Transmuter pool type and aim to provide a superior cross-chain experience to users while optimizing the capital efficiency of liquidity required for asset composability and minimizing the risk of exposure to a variety of bridges.
By swapping into an alloyed asset, a user receives a representative token of the underlying assets within the pool, which can then be used as a risk-diversified version of the asset that is usable throughout the Osmosis Ecosystem.
This results in a user flow similar to major CEXs, which accept deposits from multiple chains and increase a user’s balance, but with an entirely decentralized, on-chain mechanism.
When a transaction is initiated, IBC hooks are used to transfer the asset along the selected bridging option and automatically join or exit the Transmuter pool.
As this flow will be frontend only, advanced users, or those interacting with frontends that have not integrated the IBC hooks will be able to retain the un-alloyed asset on Osmosis.
From there a swap would route through the Transmuter pool as usual, not stranding these users if they do arrive on Osmosis via a frontend without this full integration.
For a full description of Alloyed Assets, see the Blog Post
Standard Specifications of Alloyed Assets
If an Alloy meets these criteria then it should be considered by Osmosis integrators to be the canonical asset. In the event of two alloys representing the same asset, the one with the highest liquidity will be treated as canonical if reviewed.
Denomination
-
Must begin with
allto indicate that it is intended to be an alloy. -
Must be a single block of characters. I.e.
allUSDTnotall USDT -
Must reference the contents of the alloy. I.e. allETH should be composed of ETH representative assets.
Assets
-
Must all be referencing the same initial issuance of tokens before bridging.
- Example: allETH must be composed of ETH bridged derivatives rather than forks such as ETHW or ETC
- Example: allUSD could consist of USDC and USDT but would need to be specifically approved by governance rather than falling under these standards.
-
Must all reference the same base.
- Example: allETH must not contain ETH and wstETH as these intentionally differentiate in value, but could potentially contain ETH and stETH as stETH targets a 1 ETH redemption rate.
Normalization Factors
Normalization Factors dictate the ratio between each minimum denomination within the Alloy and the Alloy itself. These should attempt to match the unbridged standard for the token with the exception of 18 exponent tokens which may be trimmed to 12 to be closer to the non-EVM standard of 6-12.
Example: allBTC has an exponent of 8, WBTC has an exponent of 8 and nBTC has an exponent of 14. Resulting in allBTC’s normalization factor being 1(1:1x10^6)
Example: allASI has an exponent of 12, FET has an exponent of 18 and ASI has an exponent of 18. Resulting in allASI’s normalization factor being 1(1x10^6:1x10^6)
Example: allSOL has an exponent of 9, SOL.pica has an exponent of 9, SOL.wh has an exponent of 8. Resulting in allSOL’s normalization factor being 10(10:1)
-
Internal Normalization factors
- Must result in the value between the constituents being 1:1
-
External wrapping Normalization factor
- Must maintain an exponent of at least 6
- Must not expand above the highest of the contributing token exponents and the un-bridged exponent
- 18 Exponent tokens should be trimmed to 12 exponent where possible
Rate Limits
Alloyed Assets have built-in rate limitation settings, which can prevent the ratio of tokens from changing excessively in a set period. These rate limits minimize any issue with one constituent from draining the liquidity of the paired assets in the alloy.
Static Rate Limits
Determines the maximum percentage of the pool allowed to be a specific asset, preventing extreme imbalance from occurring and minimizing the exposure of the Alloyed Asset to a particular constituent.
None are required as these may be maintained by Osmosis governance to manage liquidity risk.
If set, Static Rate limits must be set at a level that allows normal trading to occur. i.e. The sum of rate limits should be above 100% and no rate limit should be smaller than 5%
Change Rate Limits
Determines the maximum percentage of an asset permitted to enter the pools based on the moving average of the asset’s relative weighting over a specified period.
None are required as these may be maintained by Osmosis Governance to manage liquidity risk.
If set, Change Rate limits must be set at a level that allows normal trading to occur.
Admin Role
The administrator for canonical Alloyed Assets must be set to Osmosis Governance (osmo10d07y265gmmuvt4z0w9aw880jnsr700jjeq4qp)
The Admin Role can perform the following tasks:
Delegate Set Active Status
Allows the Admin to delegate a Moderator address to disable the underlying Transmuter pool of the Alloyed Asset temporarily in an emergency. Disabling will freeze the pool’s contents, as no internal messages can be run apart from enabling the Active Status again. This delegation allows either the wider Osmosis DAO or a large subDAO to handle Metadata and Limiter settings while retaining rapid response by a smaller subDAO in an emergency.
Set Alloyed Metadata
Adjusts the on-chain metadata for how the Alloyed Asset is displayed, such as the displayed denomination, description, and symbol.
Manage Limiters
Allows the rate limiters to be created, removed, or modified. These must be set appropriately so that normal trading is not impacted and a security issue in any of the constituent assets is minimized.
Add New Assets
Allows the admin to add a new constituent asset to a pool, which can then be used as an underlying token for the Alloyed Asset. Further administrative action can then be taken to add any limiters. This allows the Alloyed Asset to grow as more bridges become available without fragmenting liquidity by having multiple Alloyed Assets for the same token in circulation.
Moderator Role
The Moderator for Canonical Alloys must be set to the Alloyed Moderator SubDAO. (osmo1ugrn8qgsvyr8zwrv8h2g4r8ascngxk7qeaz7e0htjq3znswkh4cqhjdpgy)
This is a 3 of 6 subDAO, composed of Osmosis contributors, validators and security specialists.
Additional Moderators can be passed by Osmosis governance.
Set Active Status
In an emergency, the Moderator can temporarily disable the underlying pool of the Alloyed Asset. This allows time for any information about an incident to become available and a path forward to be decided without exposing the Alloyed Asset to losses beyond those incurred by the backing at the time of the freeze.
Mark Corrupted Assets
By marking an asset as corrupted, the Moderator signals that it should be removed from the Alloyed Asset. No new deposits will be allowed, but withdrawals are allowed. This will allow the Alloyed Asset to restore its peg, particularly when paired with any intervention approved by governance, such as Insurance, which can deposit an uncorrupted asset and withdraw the corrupted component
Canonical Status
Canonical status sets the following agreement:
Default Asset List – Assets will be affixed and unmarked in the app.osmosis.zone default asset list, e.g., BTC, with all other bridges’ assets being BTC.bridge1, BTC.bridge2, etc. Osmosis DAO requests that allied/friendly frontends do the same, though any frontend is free to make its own decisions.
Osmosis Incentives – Osmosis DAO commits to prioritizing the canonical bridge assets, incentivizing them earlier and more heavily than the comparable assets of non-canonical bridges. In general, canonical pools should earn substantially more incentives than their counterpart pools.
Canonical status itself does not guarantee incentives.
Target Onchain Date: 12th August 2024
These terms are designed to allow the easy onboarding of a wide range of Canonical assets on Osmosis while ensuring that they are able to be managed by governance, resistant to depeg events and suitable for purpose for usage across the Osmosis ecosystem.
Please add any feedback on points that may cause issues before this goes to the chain.
Example alloys that this approves that the initial forms are already created on Osmosis include:
allSOL
allTRX
allSHIB
allDOT
allLINK
allPEPE
allARB
allOP