Assets and the Actions they Enable – Ideas for Cross-chain UX

In a cross-chain world, we envision a future where assets float between different chains, where they can serve different functions and represent a range of different opportunities in different places. What could a seamless multi-chain UX look like? How might users discover the different opportunities a token represents on different chains?

Moving towards a cross-chain world, in which users can explore their opportunities across different chains naturally

Increasing Complexity
Multi-chain interactions on Polkadot today are mainly centered around transferring tokens, but they will only get combinatorially more complex going forward. Token A might be used as a governance token on chain A, but could also be used as a collateral on chain B. And maybe chain C tries something new and allows for token A to be used as a second governance token for its chain, but with only half the voting power. With more chains and tokens you can imagine an ever changing range of use cases and combinations.

There is a chain-opportunity matrix for any given token

Increasing Opportunities = Increasing Apps Discoverability
How are users supposed to know about the growing range of opportunities? Unless they follow projects regularly and allocate time to read through announcements and tutorials, they will not be aware if functionality was added to a token. So how can we design apps in a manner that focuses on assets and the actions they enable?

A start would be to have a kind of app explorer that lets users search for apps and filter by category or token used. It’d be also conceivable to connect a wallet and a “show me what I can do with my tokens” option.

Some kind of app explorer would be a natural step to showcase the breadth of multi-chain, multi-token apps

An approach for apps themselves would be to experiment with existing web2 UX conventions making use of pop-ups, tooltips and context menus. Those are established UI components that not only reveal action potential, but also send the user to other apps. These components could be much more aware of context.

We coded up some dummy cross-chain component concepts here.

Learning from mobile conventions, in which apps are opened within apps, sharing options are aware of a user’s favorite contacts, or their other devices, a cunning multi-chain experience could give users a range of interaction. By providing a range of options we actually increase the discoverability of apps across the network and evangelize network effects.

Eg: swap token to token derivative, lend token derivative, and delegate rewards in governance. Claim NFT in game, let it evolve as you progress in the game, and set it as a profile pic for a social dapp. All in one flow.

Using Network Effects
Just as hyperlinks were critical for the early internet, tokens can be used as means of discovering new services and apps. With more apps adopting such an approach, we will see network effects and most likely increased activity. These interactions can play a part in moving towards a world in which the user experience is centered around actions and opportunities across chains rather than interacting with one particular network at a time.


They should not know about the chains :stuck_out_tongue:. Unless they want to of course. I actually liked a lot of the text of this thread but found the images in conflict. The first one, for example, shouldn’t show that the user’s DOT is on “Asset Hub” (no “s”) and show a bunch of other chains to send it to or their transport mechanism. It should just say, “you have 150 DOT”.

The application should handle the routing of assets as if it were a backend. If a user says they want to do something with DOT on an app in Moonbeam, they shouldn’t have to think about “transferring to Moonbeam”; the application should recognize that the user has enough DOT, just not in the right place, and take care of getting it to the right place for the user.

As a general principle: Applications should be application-first and figure out the appropriate chains and methods to use the applications, not chain first and figure out how to present those chains to the user.


This would be a very welcomed feature. Currently, it would be impractical for Ledger users (who will find a lot of impracticalities in the ecosystem, to be fair) because many chains are not supported by the cold wallet, and the ones that are supported may not update in a timely manner.


Absolutely agree with the “apps, not chains” approach.

they shouldn’t have to think about “transferring to Moonbeam”; the application should recognize that the user has enough DOT, just not in the right place, and take care of getting it to the right place for the user.

Love this. That would be the next step of abstraction. I was more thinking along the lines of users that are not aware of the range of apps out there and letting them explore possibilities through assets. In a similar way in which apps have “share via a”, “share via b” and “share via c”, even if you don’t know those social networks.