I agree with all the points shared by @alice_und_bob, and I’d like to add one more point that’s equally crucial.
The Polkadot ecosystem is undeniably complex, featuring numerous parachains offering services to the ecosystem. For instance, you have Zeitgeist offering prediction markets and Oak Network providing automation. If dApp developers on Moonbeam wish to build applications that leverage the services provided by these parachains, the prescribed path is through XCM.
Here’s the crux of my argument:
** Building on top of Polkadot parachains can be quite challenging. - This statement is a generalization and doesn’t always hold true. However, I want to zoom in on what is perhaps the flagship Polkadot technology: XCM.
If a dApp developer wants to utilize Oak’s automation, they need to understand the weight of the XCM message, the weight of the Transact , the weight-to-fee ratio, and also how to construct the XCM message itself. Terms like BuyExecution , WithdrawAsset , and HoldingRegister are terminologies that dApp developers shouldn’t necessarily have to grapple with. The usability of XCM is filled with so much complexity that it’s essentially broken. We’ve been creating tutorials around XCM for over 1.5 years, and they are, by far, the most challenging ones to create and follow.
Now, let’s compare this to building on top of other cross-chain technologies like Axelar/Wormhole, where their SDK is exceptionally user-friendly and encourages developers to build on the technology while abstracting away as much complexity as possible. With XCM, it often feels like we intentionally want things to be extremely intricate, viewing complexity as a feature rather than a problem.
As the Polkadot ecosystem matures, XCM is poised to be the primary driving force behind seamless cross-chain interactions. We often hear about BridgeHub and AssetHub being the key drivers for assets and bridging to other ecosystems. Furthermore, at Sub0, we gained some insight into how Snowfork was going to function (more or less). All three of these projects will rely on XCM to thrive. Therefore, it’s crucial that XCM’s usability becomes more accessible and welcoming; otherwise, it’s likely to face challenges.
A Suggested Solution
One straightforward example is to provide a way for the source chain to request the destination chain to calculate the necessary weight and fee for an XCM message. This could be achieved through a runtime API call, making the use of XCM significantly more user-friendly. Then, individual teams could develop SDKs that abstract away as much of the complexity as possible.
Wdyt?