[MRC-42] DOT Listing (IBC)

Summary
This governance proposal seeks to add Polkadot’s native token, DOT, as a collateral asset within the Red Bank. This can now be made possible using Composable’s Centauri bridge, an IBC-native bridging solution connecting Polkadot to the Cosmos ecosystem.

Motivation
Polkadot (DOT) is the native token of the Polkadot Network, commanding a nearly $7bn FDV, and offering the potential to inject massive value to the Red Bank.

To date, bridging solutions exist to bridge DOT to the Cosmos ecosystem, but most entail the use of an additional wrapping of an asset in order to bring it into the eco. Composable’s Centauri Bridge is the first bridging platform to integrate a native IBC connection between the Polkadot ecosystem and the Cosmos, and as such, servers as an idea candidate for bringing IBC-native DOT to the Red Bank.

Despite DOT’s position as a large-cap asset, it has lacked the ability to move outside of its own ecosystem in a way that becomes beneficial for holders and new users. By adding DOT as collateral within the Red Bank, current users may unlock addition utility from their DOT holdings by lending their holdings out, while new users within the Cosmos ecosystem have the ability to borrow this new asset. This should server as beneficial to the Red Bank by adding value to the lending side, while motivating additional user activity through the platform.

Technical Risk - DOT

Metric Requirements Polkadot Network
Time Since Launch Ideal DOT’s multi-stage launch began in May 2020 and was completed on December 18, 2021. Polkadot released 10 million DOT into circulation via an initial coin offering (ICO) in October 2017, with the tokens publicly becoming available in May 2020
Custom Public Audit Ideal The Polkadot Network has made two audits available here.
Recent Audit N/A Polkadot has not published any audits within the past year. However, XCM v3 was merged into the Polkadot codebase and is presently undergoing the audit and approval process.
No Critical Vulnerabilities Ideal No critical vulnerabilities have been exploited.
Bug Bounty Program Ideal Polkadot offers an ongoing bug bounty program; it does not report the size of the program (details here)

Centralization Risk

Metric Requirements Polkadot Network
Owner Decentralization Ideal The Polkadot Network itself is decentralized and governed by DOT holders using OpenGov. Automated enactment eliminates human involvement. Instead, DOT holders handle all network operations.
Admin Decentralization N/A N/A
Other permissioned addresses Ideal No other permissioned addresses.

Oracle Risk

Unlike similarly bridged L1 assets into the Cosmos ecosystem, ie. wBTC or WETH, DOT would be transferred using IBC as the native solution (uniform across the Cosmos). As such, there is not additional wrapping, or an underlying custodial asset to be aware of.

Pricing information for DOT should be robust and easily accessible for DOT using well-known solutions such as Chainlink or Pyth Network.

Market Risk

The following metrics were calculated to determine the LTV of DOT, according to the Mars Risk Framework 1:

  • Daily 95% Conditional Value-at-Risk (CVaR, 365-days): 7.01%
  • Maximum intraday drawdown (90-day): 13.01%
  • Median 24hr volume (90-day): $95,031,789
  • Median 24hr market capitalization: $6,720,815,011
  • Average high-low percent quoted spread (30-day): 4.77%
  • Amihud’s illiquidity measure (90-day): 0.0000000049800

Based on these quantitative metrics, in the next section we propose the LTV and other associated risk parameters.

Max Loan-to-Value: 53%

Liquidation Loan-to-Value: 65%

Liquidation Bonus: 12.5%

Usable as collateral? Yes
Available to borrow? Yes

Implementation

This is a proposal for discussion; if received well by the community we will update below to reflect the message to Execute the Red Bank contract and initialize the (ibc) DOT market

3 Likes

Hey guys, first of all, thanks for the post. It’s refreshing to see other protocols using the Mars risk framework (MRF) to independently propose parameters. Kudos for that!

Now, getting into the details of the proposal, I think one part that’s missing is the Centauri bridge analysis. In addition to the underlying asset itself, the MRF recommends that the bridge implementation itself is also evaluated from both a technical and centralization risk perspectives.

In this sense, it would be ideal to run the Centauri bridge through the list of technical and centralization risk requirements. I’d be particularly interested in understanding:

  • How long has the Polkadot <> Kusama IBC implementation been live for?
  • How long has the Kusama <> Cosmos IBC implementation been live for?
  • What are the key software pieces of both implementations? Where can new software bugs be critical here?
  • Have they been audited? Is there an active bug bounty available for them?
  • Are there any centralization points along the bridging chain?

Additionally, to get a proper mental model of the bridge it would be useful for me to understand how the flow of DOT from Polkadot to Cosmos works in detail, for example (don’t know whether what’s below is correct):

  • Native DOT is locked on Composable’s IBC module.
  • A relayer transfers the value of the tokens to Picasso.
  • Picasso’s IBC module prints vouchers that represent the locked tokens on Composable.
  • And so on until the tokens arrive on Neutron (or Osmosis), for instance.

From our side, I’ll also be reviewing and commenting on the proposed parameters within the coming days.

Thanks!

There may be risk associated with the founder of Composable Finance.

https://twitter.com/zachxbt/status/1494766254242123788

Thanks for getting back to us, will try to get clarity on all of your questions below…

i) How long has the Polkadot <> Kusama IBC implementation been live for?
Polkadot <> Kusama has been live just over 3mo now (Announcement Link)


ii) How long has the Kusama <> Cosmos IBC implementation been live for?
Kusama <> Cosmos has been live for ~1.5mo (Announcement Link)


iii) What are the key software pieces of both implementations? Where can new software bugs be critical here?
The main components of Centauri bridge are:

  • Pallet IBC - Pallet IBC is referred to as the IBC stack for non-Cosmos chains and is composed of IBC-rs and a Tendermint light client (ics07). IBC-rs is an implementation of IBC in Rust, which allows for IBC messages to be interpreted on Picasso (and other IBC-enabled chains). Together, these two components enable our parachains to process and interpret IBC packets.

  • Grandpa Light Client - GRANDPA is a protocol developed by Parity to verify finality proofs of parachain headers. The grandpa light client is based on the GRANDPA protocol and written in CosmWasm.

  • Hyperspace Relayer - Hyperspace is a custom-built relayer implementation that allows for transferring arbitrary packets on non-Cosmos blockchains using the IBC protocol.
    (Additional information and links on these components may be found in our docs here)


iv) Have they been audited? Is there an active bug bounty available for them?

Audits can be found on our GitHub here. We have a bug bounty campaign live with Immunfi .


v) Are there any centralization points along the bridging chain?

As the bridge is based off native IBC, centralization would only occur so far as any chain that is interacted with is itself centralized. From this perspective, the bridging chain should not face any current centralization risk.


Additionally, to get a proper mental model of the bridge it would be useful for me to understand how the flow of DOT from Polkadot to Cosmos works in detail, for example (don’t know whether what’s below is correct):

I will fill in the gaps on the general routing outline you’ve mentioned:

  • Native DOT is locked on Composable’s IBC module.
  • A relayer transfers the value of the tokens to Picasso.
  • Picasso’s IBC module prints vouchers that represent the locked tokens on Composable.
  • DOT is again locked on Picasso’s IBC module
  • A relayer transfers the value of the tokens to Centauri Chain
  • DOT is locked on Centauri Chain and transferred to Osmosis
  • A relayer transfers the value of the tokens to its final destination, Osmosis

A note on the above – We utilize a standalone chain running within the Cosmos ecosystem that we refer to as Centauri. This chain serves as an intermediary for assets between external ecosystems and Cosmos. Info on the chain can be found on ping.pub using the link here

1 Like

Since the said tweet above, Omar / Brainjar and our team have been tirelessly building Composable Finance.

The result speaks for itself:

  • We successfully bridged Kusama and Polkadot.
  • Then we successfully bridged Cosmos and Polkadot and Kusama.
    (Anyone can test this out at: trustless.zone)
  • We are the first to bring IBC outside of the Cosmos ecosystem because we believe that cross chain communication needs to adopt the most secure and battle-tested communication protocol.

Anyone can have an opinion, but our code, products, and our hard work speak for itself. Let’s have an open discussion around facts.

Here is 0xbrainjar / Omar’s official response for the tweet 1+ year ago: https://twitter.com/0xbrainjar/status/1494868573579317251?s=20

3 Likes

Thanks for the color.

I have one additional question: Who’s running the light clients on each chain? On Centauri I understand it’s the Centauri validators who run the Picasso light client, but who runs the Composable light client on Picasso? Is it the Kusama validators themselves or another group of validators?

Yes this would considered the Kusama validators on that side

Hey guys, thanks again for the proposal. While it’s definitely exciting to see a live IBC implementation outside of Cosmos, at this point I think what would be best is to allow for these new implementations to mature more and be further battle tested live (and ideally with some TVL) before endeavoring to list the asset on Mars. The reasons for this are as follows:

  • The IBC implementations used here have been live for a very short time. Polkadot <> Kusama for 3 months and Kusama <> Cosmos for 1.5 months.

  • The new pieces of software related to the IBC implementation have been audited only one time.

  • The bridging process is not as vanilla:

    • DOT is first locked on Composable (Polkadot).

    • A relayer relays the mesage to Picasso (Kusama).

    • Kusama validators (via the light client on Picasso) validate the message and print some vouchers for the locked DOT.

    • The vouchers are then locked on Picasso.

    • A relayer relays the mesage to Centauri (Cosmos chain).

    • Centauri validators validate the message and print some vouchers for the locked vouchers on Picasso.

    • Lastly, from Centauri the vouchers can then sent to any Cosmos chain using the battle tested Cosmos IBC implementation.

Thus, as stated before, I believe it’s best for Mars to delay listing this asset until the bridge infrastructure supporting it is more mature.

Would it be possible to provide something more specific in terms of maturity ? Is there a proposed amount of time that Mars would prefer to see this bridge (Centauri) in production ? Any sort of metrics to hit that would signal maturity ? etc.

The IBC implementation is under an additional audit from which we are just awaiting a finalized copy that we can provide as well (in addition to the Halborn audits).

Ideally, we complete our treasury proposal here: https://polkadot.polkassembly.io/post/1871 , and establish significant (ibc)DOT liquidity within Cosmos before moving further on this proposal regardless.

Definitely.

I don’t speak for Mars but personally I’d be more comfortable if the bridge implementation had been battle tested with at least 8 figures in TVL for a period of 6-12 months.

Love the idea of adding DOT and would love to see Mars support a huge array of assets. Agree with Jon’s timeline, though… I always trust a big honeypot in the wild that hasn’t been hacked for 6-12 months over audits. Also I think Mars should launch/prove out v2 before getting more aggressive with listings.

Love DOT as well. However I have to side with Jon here. I would like to see the bridging infrastructure be more mature in order to justify the bridging risk. Thus I would wait a while longer (6 to 12m) before listing this asset on Mars.

I’d really like to see DOT added to the Red Bank. But as Jonathan and Redphone mentioned above, I’d feel a lot more comfortable with more entropy on the bridge, which is crucial in this case. If the bridge was live for an extended amount of time (6-12 months) while holding significant amount of value (> 8 figures), risk to Mars would be considerably lower.

As such I’m voting ‘no’, for now. But would love to see a future prop once the bridge has been battle-tested

Having initially been in favour of the proposal I’ve decided to vote no here given arguments above.