Asset‑Based Storage Deposit Payments for Polkadot & Kusama

Tech Talk
, ,
1

1. Motivation

Transaction fees in Polkadot Hub and Kusama Hub can already be settled in non‑native assets via the asset‑conversion‑tx‑payment mechanism. However, storage deposits —the funds temporarily locked to compensate for on‑chain state growth—must still be paid in the native token. The current implementation poses a limitation where users would be required to be aware of deposit costs before interacting with chains.

A better mechanism should assist users to be able to transparently pay for storage deposits using non-native assets in the same way they use them to cover transaction fees. As a result, we’ll see several improvements:

  • Seamless end‑user experience — wallets can pay fees and deposits with a single asset, so users don’t need to think about acquiring DOT/KSM (but doing it transparently).
  • Simpler dApp engineering — builders can rely on one asset flow, specifying a single asset for both fees and deposits; so front‑ends no longer need special code paths for reserving (via acquisition or conversion) native tokens to use, simplifying developer experience.
  • Designed for the Bridge — this mechanism can also enable transactors for the same asset‑denominated deposit logic to operate over bridges (e.g., Snowbridge to Polkadot, and the Polkadot ↔ Kusama bridge), delivering consistent UX for cross‑ecosystem dApps.

2. Background

Polkadot Hub and Kusama Hub already let callers settle transaction fees in arbitrary assets thanks to the asset‑conversion‑tx‑payment TransactionExtension, which converts the user‑nominated asset into the native balance on the fly. Storage deposits have not yet reached feature parity: they are still reserved in DOT/KSM because most pallets express their balance requirements with the legacy Currency / ReservableCurrency traits, or because they manage reserves manually.

FRAME is converging on two building blocks that unlock multi‑asset deposits (see the design rationale in FRAME core issue #207):

  • Fungible traits — the asset‑agnostic successors to Currency, introduced in June 2020 and backed by the formal deprecation of Currency in March 2023 (substrate#12951).
  • Consideration — a lightweight API that treats every deposit as a portable ticket, so pallets can create, update, or release storage collateral without touching balances directly.

Once pallets adopt these two pieces, reserving any fungible asset—rather than just the native token—becomes straightforward, making it natural to extend the existing fee‑conversion path to storage deposits as well.

3. Proposal Overview

Phase 1 – Upgrade Balance Interfaces

Goal

Replace direct Currency/ReservableCurrency bounds with the modern fungible traits (MutateHold, MutateFreeze, etc.).

Deliverables

  • PRs to core pallets (e.g. Identity, Multisig, Proxy) replacing trait bounds.
  • Maintain a progress checklist aligned with polkadot‑sdk#226 to track pallet migration status.
  • Storage migration and benchmarking updates.

Phase 2 – Adopt Consideration Across Pallets

Goal

Migrate pallets that still handle deposits manually to the Consideration API.

Deliverables

  • Replace bespoke reserve/unreserve logic with ticket‑based accounting.
  • Regenerate weights; write end‑to‑end storage‑refund tests.

Phase 3 – New Pallet: pallet-asset-conversion-consideration-handler

Goal

Provide an opt‑in mechanism to pay storage deposits in any supported asset, using the same conversion pipeline that currently services transaction fees.

Key Functions

  1. PreferredAssetId runtime storage item (per-storage, a ticket would be stored to make the conversion when refunding a specific consideration ticket).
  2. A TransactionExtension that injects the chosen asset_id into Consideration.
  3. A set of Runtime APIs to allow interfaces to estimate the storage pricing based on some known parameters (i.e. items, item length).
  4. The implementation of a Consideration implementation that:
    • Computes the deposit in terms of fungible::HoldConsideration.
    • Converts and reserves the equivalent amount via pallet-asset-conversion.
    • Falls back to native when unable to convert.
    • Emits the corresponding events.

Deliverables

  • New pallet inside polkadot-sdk.
  • Mock runtime + CI tests showing round‑trip reserve and refund.

Phase 4 – Staged Deployment

  1. Westend testing: open a public testing phase to allow signer builders (like polkadot.js, Nova, Polkadot-API, etc) to adjust and include the extension on their flows.
  2. Kusama – runtime upgrade via OpenGov after ≥ 2 months of stable testing.
  3. Polkadot – final audit, then OpenGov upgrade motion.

4. Developer Experience Research

This plan also runs a parallel spike whose output will be a set of DX proposals. Exact deliverables TBD, but might include, for example:

  • A procedural macro helper (#[derive(ConsideredStorage)]) that auto‑generates boilerplate for simple storage maps.
  • Alternative design patterns (traits, wrapper types) for integrating Consideration with minimal code changes.
  • Cookbook examples and best‑practice guides.

5. Benefits

  • Seamless Multi‑Asset UX — dApps can denominate both fees and deposits in a single user-facing asset (e.g. USDT).
  • Composable Security — aligns with Polkadot’s vision of asset‑agnostic parachain economics.

6. Roadmap

Start date: July 2025 (P0)

Period Calendar (approx.) Focus & Milestones
P0 Jul - Aug 2025 Final polishing of proposal. Publishing this document.
P1 Aug – Dec 2025 Refactor phase: replace legacy Currency/ReservableCurrency bounds with fungible‑traits; identify (catalogue) pallets still using the old API using tracking issue polkadot‑sdk#226 as the authoritative list; regenerate benchmarks. In parallel, run the Developer Experience Research spike to develop DX proposals (e.g. macro helper, wrapper patterns).
P2 Dec 2025 – Feb 2026 Consideration migration: move pallets to Consideration—initially via the already‑available HoldConsideration; update weights and write storage‑refund tests.
P3 Mar – May 2026 Implement & test pallet‑asset‑conversion‑consideration‑handler; integration tests across conversion paths; runtime feature‑flag wiring.
P4 Jun – Sep 2026 (expected) Public testing on Westend / AssetHub; coordinate third‑party tooling support (e.g. Polkadot‑JS); prepare OpenGov motions for Kusama & Polkadot (deployment timing depends on ecosystem readiness).

7. Compatibility and Requirements

  • Requires runtimes to already include pallet-asset-conversion (or another compatible conversion oracle).
  • Requires signers to implement the usage of the pallet-asset-deposit-transaction-extension (pallet name TBD).
3 Likes