Cross Ecosystem Unified Businesses

Cross-chain within Polkadot

Within Polkadot, businesses can easily operate cross-chain. Polkadot chains are natively interconnected, with cross-chain messages' validity and reliability guaranteed by the core protocol. On top of this transport protocol, XCM can be used to allow businesses to expand their scope and easily operate within the whole Polkadot Ecosystem.

A business's token can move across the ecosystem through XCM in manner trusted by the whole ecosystem, thus liquidity or utility moves freely and can be easily deployed where needed. This allows the business to operate outside the confinements of its own chain, and expose to its customers chain-agnostic (infrastructure-agnostic) products.

Cross-chain outside Polkadot

Other ecosystems also have cross-chain models of operation with varying degrees of efficiency and success. This article does not attempt to compare them to Polkadot's, but it is important to understand that it is a critical topic for any ecosystem that moved or plans on moving from a single-chain model to a multi-chain one.

We can use Ethereum as a case-study, where we see its move to the multi-chain rollups model has heavily fragmented the ecosystem and where they are now working hard on cross-chain mechanisms meant to stich it back together. It is worth noting though, that the mechanisms they are developing are Ethereum-specific. These mechanisms are very opinionated towards EVM Contracts usecases, and are not natively compatible with other Ecosystems, Polkadot included.

Cross-Ecosystem Business

While Businesses can operate cross-chain with varying degree of ease depending on the Ecosystem, it is currently difficult to operate across multiple different Ecosystems in a unified manner. This holds true even for very similar Ecosystems such as Polkadot and Kusama.

Case-study: Bifrost as a liquid staking business: operating over multiple chains doing local-consensus liquid staking:

• Polkadot liquid staking using Bifrost (Polkadot) parachain,
• Kusama liquid staking using Bifrost (Kusama) parachain,
• Ethereum liquid staking using Bifrost SCs on Ethereum.

Currently these are separate businesses: even though they share or could share the same "owner" in the real world, they are fragmented on-chain. They each have their own token, and their own governance/admin. The business is fragmented, and its market valuation is fragmented.

(TODO: Other things they could/should share?)

This article will focus on primitives and mechanisms that Polkadot can implement to support cross-ecosystem unification. Allow components of the same business that are deployed in different ecosystems to share the same (teleportable) token (share market valuation), share the same governance/admin, and other business concepts we later identify as common between such multi-ecosystem businesses.

The long-term goal is to offer solutions to businesses to expand from Polkadot to other Ecosystems or from other Ecosystems expand into Polkadot. But, because the architecture varies greatly between Ecosystems, these solutions will likely be custom-made for each "external" Ecosystem's integration with Polkadot.

Starting point: Polkadot and Kusama

Our starting point is tighter integration between Polkadot and Kusama. The common architecture of these two sibling Ecosystems means we can do it faster here, experiment with solutions and validate initial assumptions as well as final business impact.

Another important driving factor is that there are already a number of businesses either already operating "separately" on both Kusama and Polkadot, or operating on one but currently looking into expanding operations into the other.

Non-exhaustive list of these businesses and their business models, integration requirements and integration success metrics (in no relevant order):

• Bifrost: see Annex 1.1
• Peaq: see Annex 1.2
• Integritee: see Annex 1.3
• Robonomics: see Annex 1.4

Unifying on-chain Governance

Unifying the Business' Admin or Governance over Polkadot and Kusama is straightforward if the business operates a substrate-based parachain on each side, and both support XCM. The Root/Admin origin can be configured to any XCM location, so it is a matter of choosing a common governing mechanism and pointing both chains' admin origins to it.

For example, say a business operating ParaP on Polkadot and ParaK on Kusama wants to use a single OpenGov instance as a token-holder governance mechanism for both parachains:

• deploys OpenGov instance on the ParaP,
• Root/Admin origin on ParaP references the local OpenGov instance,
• Root/Admin origin on ParaK references the same OpenGov instance on ParaP,
• Decisions/Referenda concerning ParaP are dispatched with local Root/Admin origin, while ones concerning ParaK are sent over XCM across the P<>K Bridge to ParaK where they will be executed using the matching Root/Admin origin.

Unifying Tokenomics and Market Value

In order to unify Tokenomics and Market Value, both sides of the business would need a (unified) token that is the same across both networks. In other words, the "Polkadot-flavor" and "Kusama-flavor" of the token are fungible. Customers, as well as the general market, attribute the same market value to the token no matter where it's located, therefore the market valuation of the business is unified and consolidated.

The high-level view should show a single unified token with consistently clear and easy User Journeys regardless of where the User operates. UIs should cover business-specific scenarios without leaking the underlying architecture. Users should not have to care about or even be made aware of the mechanisms and paths of token transfers.

How to merge economies?

Say there are two tokens owned by the same business on two different Ecosystems. They are not fungible on-chain, but we want to make them so.

Scenario 1: Tokens are equal/fungible off-chain.

The real world (off-chain) treats the two tokens as equal or fungible. The two businesses which might be separate on-chain are seen as a single entity off-chain, thus the market gives their tokens equal value.

If, for example, the Polkadot side of the business becomes more successful, the value of the token should increase on both Polkadot and Kusama. However, this is not guaranteed by any on-chain mechanism, only by Market sentiment. Furthermore, all off-chain Market tools (like CEXs) still need to handle them separately.

To guarantee the fungiblity regardless of Market sentiment, and allow off-chain to treat them as a single unified token, the tokens need to be 1:1 fungible on-chain.

ParaP holds X total issuance, while ParaK holds Y total issuance, the unified token would have X+Y total issuance and it would be 1:1 fungible on-chain (mechanisms to achieve this fungibility explored later in the article).

Scenario 2: Tokens are NOT equal/fungible off-chain.

The Market distinguishes between the "Polkadot flavor" and the "Kusama flavor" of the token, and their prices are thus disconnected. Each side most likely tracks the underlying value of the Business in the respective Ecosystem. The economies are disconnected both off-chain and on-chain.

To merge economies off and on-chain, a "new" unified token is required to capture the consolidated market value.

The business can choose one as the "new" unified token and start to push the other out of circulation: e.g. assuming a p/k exchange rate for the tokens, there is an on-chain mechanism that allows k tokens of "kusama-flavor" be burned on-chain for minting p tokens of "polkadot-flavor".

How to move liquidity in the merged economy?

The long-term vision is to allow businesses to serve their customers while leveraging multiple blockchains or blockchain ecosystems under the hood, while abstracting and hiding away all the business infrastructure complexity from the customer. Drawing a parallel to the Web2 Internet Businesses of today, their customers generally don't know or care which cloud provider the Business is using in their backend.

So, what underlying blockchain-specific mechanisms can we build to enable our desired User Journeys, but also allow easy abstraction of these mechanisms by top-level UIs?

Well, for the topic of unified tokenomics, it depends on which User Journeys does the business prioritize or even support. Let's dive deep into available options of supporting a unified token between ParaP and ParaK.

Operate a dedicated P<>K Bridge lane between ParaP and ParaK

Let's take a real example and use Bifrost's BNC as our unified token example. There is a Polkadot "flavor" of BNC and a Kusama "flavor" of it, and they are not fungible on-chain. However, it seems that they are considered by the Market as being of equivalent value, so their p/k price ratio is actually 1:1 and we can explore a mechanism where they are directly made fungible on-chain with no special exchange rate required.

We shall refer to the business as Bifrost, while BifrostP and BifrostK are the notations for this business' parachains on Polkadot, respectively, Kusama. We shall refer to the unified token as BNC, while PBNC and KBNC are the notations for their "flavors" on Polkadot, respectively, Kusama.

Bifrost could open a dedicated P<>K bridge lane between BifrostP and BifrostK and use it for teleporting BNC between the two chains. This is further described in this Polkadot Forum post.
Notice that by "teleporting" across the bridge, KBNC is burned on one side and PBNC is minted on the other, thus natively and easily achieving 1:1 fungibility. High-level UIs will simply show either flavor as unified BNC.

There is a potential UX challenge that needs to be considered here. All of the Polkadot Ecosystem sees PBNC as unified BNC, similarly the whole Kusama Ecosystem sees KBNC as unified BNC. But the translation between KBNC and PBNC can only be done by the Bifrost parachains. BNC cannot be transported over the main/default AH bridge, at least not with the same fungibility characteristics. Polkadot AH does not treat the bridged KBNC from Kusama AH as the same token as native BNC (PBNC).
This doesn't sound like a big deal, but it can become a big UX problem depending on your business' customer/user journeys.

Example: User on BifrostK wants to send BNC along with USDC to Hydration on Polkadot. This is not possible in a single transfer because BNC has to go over Bifrost Bridge, while USDC has to go over AH Bridge.
The same problem holds for combining BNC with any other AH asset (USDT, ETH, WBTC, etc).

The above user journey has to be split in separate flows using separate bridges, which adds extra cost to the user and considerable complexity to UIs to support it.

As described in this Polkadot Forum post, this design requires Bifrost to run or incentivize running off-chain relayers for their dedicated bridge lane. That comes with extra complexity for Bifrost, but it also provides tighter control over bridge trafic and fees.

Leverage the canonical P<>K AH Bridge lane (possible today)

Another, potentially more future-proof, approach is to turn the problem on its head. Instead of trying to unify existing tokens, the business chooses one flavor of its token that then "eats up" the other flavor(s).
An on-chain mechanism is introduced to do one-way swaps from one flavor to the other.

Going with the previous example of Bifrost and BNC, assuming PBNC total supply is p, and KBNC total supply is k, and Polkadot-native BNC (PBNC) is chosen as the unified token:

• (optional future-proofing) BNC (PBNC) is registered as a foreign asset on Polkadot AH: allows BNC to be teleported between BifrostP and PAH,
• PBNC is registered over the AH bridge on KAH (asset-id: Location { parents: 2, interior: X2(GlobalConsensus(Polkadot), Parachain(BifrostP)) }),
• Bifrost governance mints k PBNC on BifrostP and send it over the AH bridge to BifrostK, locked in some root account,
• On-chain mechanism on BifrostK that allows users (or UIs) to "convert" KBNC to PBNC, burns KBNC and "unlocks" bridged PBNC,
• UIs can even automate this conversion and do it under the hood, users/customers don't need to be aware of any distinction between KBNC and PBNC, it is all just BNC,
• All utility and value is moved to PBNC, now the canonical unified BNC.

On Kusama the reserve of BNC is AH (because BNC is a Polkadot asset), with Bifrost Polkadot as the asset Admin.

BNC can now be combined with other AH assets (USDT, USDC, ETH, WBTC, etc) in cross-chain transfers.

Reusing the AH Bridge, means no requirements to operate any offchain infrastructure. BNC natively handled by existing bridge flows.

This option potentially has extra complexity under UIs during the transition period, but is great in the long-term because the business ends up with a single unified token both above and under-the-hood. No special handling required long-term.

Enhance AH capabilities and leverage the canonical P<>K AH Bridge lane

The model above can be further enhanced by enhancing Asset Hubs with a mechanism where a token's Admin can configure trusted teleport locations for AH for said token.

This would basically also enhance AH bridges with teleport capabilities. This opens pure burn & mint operating models even across multiple ecosystems:

Uses existing infrastructure, no extra requirements to the business.

Annex 1.1 - Bifrost

P<>K Integration Requirements

TODO Requirements

TODO Critical User Journeys

P<>K Integration Success Metrics

TODO: Define Success and Metrics (What will this mean for the business, how will it benefit its customers?)

Polkadot<>Ethereum Integration Requirements

TODO Requirements

TODO Critical User Journeys

Annex 1.2 - Peaq

P<>K Integration Requirements

TODO Requirements

TODO Critical User Journeys

P<>K Integration Success Metrics

TODO: Define Success and Metrics (What will this mean for the business, how will it benefit its customers?)

Annex 1.3 - Integritee

P<>K Integration Requirements

Cross-Ecosystem TEER requirements and options.

Annex 1.4 - Robonomics

P<>K Integration Requirements

TODO Requirements

TODO Critical User Journeys

P<>K Integration Success Metrics

TODO: Define Success and Metrics (What will this mean for the business, how will it benefit its customers?)