Polkadot Facade Feedback

[kianenigma]

We are working towards building better APIs to simplify the interacting with "Polkadot Network".

What do we mean here by Polkadot Network? Foremost Polkadot Relay Chain and System Chains (everything DOT related), and then other Parachains.

In a few months (and after gathering feedback via such issues), more details of this project will be shared. To give it a name for now, we are calling it "Polkadot Facade".

The aim of this issue is to learn about the instances where you had to interact with Polkadot Network (as defined above), and you found it difficult. This interaction can be in any form, but to help give you a mental model, I can categorize it as such:

1. 🤓 read: You had/wish to read something from the chain (most likely a pallet's storage / runtime-api), and you found it difficult.
2. ✍️ write: You had/wish to compose a transaction to do something, and you found it difficult.

A few notes:

1. I used the "had/wish" intentionally: I would like to hear both about scenarios that you had to do something, and they were hard, and those that you couldn't even figure out how to do because it was too hard.
2. You can focus both on single-network interactions, and multi-network (involving XCM) interactions. That being said, we will likely first consider single-network cases.
3. When it comes to reading, don't limit yourself to what can be read from the state of a certain block, historical queries also count.

Please feel free to reach out to me on Matrix (@kianenigma:parity.io) if need be.

[ERussel]

Hey Kian! Thank you for opening the issue. We are gathering the feedback from our and once ready will publish it here.

[filvecchiato]

Hey! We are currently looking into responses for this issue, do you have any feedback by any chance? thanks! @ERussel

[ERussel]

Hey! Sorry for the delay. While gathering information, I realized that we already have a channel with Substrate developers where most of the issues are reported. However, I still decided to compile them here for better visibility. The list may not be complete and will likely be updated over time.

Assets

The app allows users to view their account balances for each asset in the Assets pallet and transfer them to another account. However, we face the following challenges:

• The Assets pallet is currently missing the transfer_all call, which exists in the Balances pallet. It is already available in the SDK and would be beneficial to have it on-chain as soon as possible.
• We have implemented fungibility logic (Fungible trait) to calculate transferable balances. However, not all pallets have adopted it yet, leading to inconsistencies in available balances across features. For instance, the Proxy pallet has not yet adopted it, causing confusion for users.

Governance

The app enables users to view active referendums, track progress, vote, and delegate their tokens. However, we face the following challenges:

1. Fees for OpenGov delegation and vote extrinsics are currently overestimated when requested via payment.queryInfo RPC. This misleads users into thinking fees are higher than they actually are.
2. The app allows users to delegate tokens across multiple tracks. For example, if a user delegates to tracks 1–5 and later wants to switch to tracks 6–10, they must first undelegate from the old tracks and then delegate to the new ones. The Conviction Voting pallet only supports delegate and undelegate calls for one track at a time. This forces the app to construct a batch of calls, which may exceed the block’s limit due to overestimated weights (for example Kusama has a 50% block usage limit) and the app must also implement logic to break transactions into multiple extrinsics. This complexity feels excessive for a fundamental feature like track delegation.

Staking

The app allows users to stake, unstake, and earn rewards through direct staking or nomination pools. However, we face the following challenges:

• Validators can freely change their commission, potentially scamming users. Many users stake once and do not check the app for months, allowing malicious validators to increase their commission to 100% after accumulating a significant number of nominations.
• When a chain reuses the Staking/Nomination Pools pallets and requests staking support, we often need to reimplement APY estimation (maximum and for a given pool/validator) from scratch. Each chain has its own inflation logic, requiring us to study pallet configurations. It would be beneficial to have a runtime API interface that chains must implement, simplifying integration for wallets.

XCM

The app facilitates cross-chain asset transfers but faces the following challenges:

1. When users pay a delivery fee, their account must remain alive, which complicates transactions. For example, transferring DOT from AssetHub to Hydra requires an intermediate transfer to Polkadot, where the user must pay a delivery fee and maintain an existential deposit (1 DOT on Polkadot and 0.1 DOT on AssetHub). This is cumbersome and confusing.
2. A transfer_all feature would improve the user experience.
3. Users need separate fee estimations for each chain (extrinsic fee, delivery fee, cross-chain fee). The runtime provides calls for estimating XCM weight, weight-to-fee conversion, and delivery fees, but calling them separately is inefficient. A single runtime call like queryCrosschainTransferFee(dest, amount, assetId) would simplify this process.
4. It is hard to trace cross-chain messages. The app currently tracks a transfer from chain A to chain B using the Deposited event, but this approach has edge cases. A dedicated event for message arrival would provide more robust tracking.
5. There is no efficient way to determine whether tokens can be safely transferred between chains. Even if a channel between parachains is open, token transfers may not always be safe.
6. Atomic XCM transactions are lacking. A common use case involves sending X tokens from chain A to B, swapping them for Y on chain B, and then transferring Y to chain C. However, due to fee fluctuations and swap rate changes, tokens can become stuck at intermediate steps.

Proxy

The app automatically detects when another account has granted proxy access to the user and allows transactions on behalf of that account. It also supports adding and removing staking proxies. However, we face the following challenges:

• There is no efficient way to retrieve all proxied accounts and their proxy types for a given proxy account ID.
• Wallets and dApps would benefit from runtime methods to:
  1. Determine whether a RuntimeCall passes an InstanceFilter for a specific ProxyType.
  2. Check if one ProxyType is a superset of another ProxyType.

Multisig

Nova Spektr currently supports complex multisig use cases, but improvements are needed:

• The as_multi call requires a call parameter, which is not stored on-chain. Subsequent signatories cannot fetch it, forcing wallets to maintain off-chain indexers. Storing this data in the Preimage pallet with an additional reserve requirement could provide a more sustainable solution.

[filvecchiato]

hey @ERussel, the summary you provided is extremely useful! Thanks very much for taking the time to write this all done! We are currently looking into multiple sets of the APIs you mentioned here, we hope to have some more info very soon about it!

I'll keep tracking this issue in case something more comes up!