Polkadot protocol proposals (RFC process)

31

PPP: Deterministic Resolution of Assets on Account Reaping

Summary

Substrate-based runtimes support account reaping via existential deposits while also allowing permissionless receipt of arbitrary assets.
This proposal defines protocol‑level semantics for resolving assets owned by an account when that account is reaped.

The goal is to ensure deterministic, infallible, and auditable handling of all asset holdings without requiring user interaction, while preventing grieving and eliminating undefined behavior across asset‑holding pallets.

Background

Substrate defines clear semantics for:

  • When an account exists

  • When it is reaped

  • Which balances participate in existential deposit (ED) checks

However, the protocol does not define what happens to:

  • Non‑native or foreign assets

  • Assets received without recipient consent

  • Assets without a valid transfer or burn path

As a result, account lifecycle semantics are currently incomplete and pallet‑specific.

At the same time, Substrate allows:

  • Permissionless inbound transfers

  • Arbitrary asset types

  • Account reaping based solely on native balances

This creates an unresolved interaction between reaping and multi‑asset ownership.

Motivation

Account lifecycle is already a protocol concern

Account creation and destruction are core protocol responsibilities.
Leaving asset resolution undefined makes account death:

  • Ambiguous

  • Implicit

  • Difficult to reason about or audit

Unwanted assets are unavoidable

In a permissionless system:

  • Any account can receive assets

  • Recipients may be unwilling or unable to interact with them

  • Assets may be malicious, spammy, or non‑transferable

This problem arises from protocol properties and cannot reliably be solved at the application or wallet layer.

Reaping + multi‑asset = undefined behavior

When an account is reaped:

  • Native balance falls below ED → account is destroyed

  • Yet foreign assets may still reference that account

The protocol does not clearly define whether:

  • Reaping must consider all assets

  • Foreign assets block reaping

  • Assets are burned, preserved, transferred, or orphaned

Different pallets implicitly answer this differently today.

Tooling and security implications

Undefined semantics lead to:

  • Asset‑based griefing vectors

  • Dead accounts accumulating state

  • Divergent indexer and wallet heuristics

  • Difficulty reasoning about issuance, accounting, and state growth

Goals

This proposal aims to:

  • Define deterministic behavior for assets on account reaping

  • Avoid requiring user interaction with unwanted assets

  • Preserve permissionless asset transfers

  • Prevent foreign assets from blocking reaping

  • Provide a common abstraction usable across asset pallets

  • Keep reaping cheap, safe, and infallible

Non‑Goals

This proposal does not aim to:

  • Prevent inbound transfers

  • Introduce opt‑in receive semantics

  • Define wallet or UI behavior

  • Enforce a single economic policy across all assets

Design Overview

Core Principle

Account reaping is a system‑level decision and must fully resolve all dependent state.

When an account is reaped, all asset holdings associated with that account must be resolved internally by the runtime, without user involvement.

Specification

Asset Resolution on Account Reap

Introduce a standardized runtime hook invoked exactly once when an account is reaped.

Conceptual flow:

  1. Runtime determines account is below existential deposit

  2. Account is scheduled for reaping

  3. All registered asset providers are invoked to resolve holdings for that account

  4. Account storage is removed

Resolution Requirements

Resolution logic must:

  • Be deterministic

  • Be infallible

  • Not dispatch extrinsics

  • Not depend on signatures or user input

  • Not depend on ordering between pallets

Asset Resolution Strategies

Each asset‑holding pallet must define one resolution strategy from a small, explicitly enumerated set.

This proposal does not mandate a single default, but enumerates protocol‑compatible options.

1. Burn on Reap

Remove the asset balance and reduce issuance (or mark as destroyed).

Properties

  • Strong anti‑griefing guarantees

  • No state accumulation

  • Mirrors “inert asset” semantics

Recommended default for non‑consensual assets.

2. Return to Issuer / Admin

Transfer assets to a deterministic issuer or admin account.

Properties

  • Suitable for permissioned or regulated assets

  • Requires stable issuer resolution

3. Transfer to System Sink

Move assets to a predefined runtime account (e.g. treasury, dust sink).

Properties

  • Preserves total supply

  • Centralized cleanup point

  • Potential governance policy surface

4. Remove Without Supply Change (Ignore)

Delete the balance entry without modifying issuance.

Properties

  • Simplest fallback

  • Assets become effectively lost

  • Avoids dependency on asset internals

Consensual vs Non‑Consensual Assets (Optional Extension)

Asset pallets may optionally classify assets as:

  • Consensual: User explicitly opted‑in (e.g. asset creation, local mint)

  • Non‑consensual: Transferable by arbitrary third parties

Suggested defaults:

  • Non‑consensual → Burn or Ignore on reap

  • Consensual → Pallet‑defined policy

This classification is advisory and does not affect transfer semantics.

Interaction with Existential Deposit

  • Native balance alone determines account existence

  • Foreign assets must never block reaping

  • Asset resolution occurs after the reaping decision

This ensures:

  • No reaping deadlocks

  • Predictable account lifecycle

  • A clear mental model for developers and auditors

Implementation Sketch (Conceptual)

Introduce a common trait implemented by asset pallets:

trait OnAccountReaped {

fn on_account_reaped(account: &AccountId);

}

  • Invoked by frame_system once per reaped account

  • Failures are not permitted

  • No external dispatch allowed

Backwards Compatibility

  • Existing pallets default to a conservative strategy (Ignore)

  • Behavior remains unchanged until pallets explicitly opt in

  • Migration can be introduced gradually via governance

Security Considerations

This design:

  • Eliminates asset‑based account griefing

  • Prevents unbounded state growth from dead accounts

  • Reduces wallet and indexer attack surface

  • Makes account death semantics explicit and auditable

Comparisons

  • Ethereum avoids the issue by never reaping accounts

  • Substrate does reap accounts and therefore must define corresponding asset semantics

This proposal formalizes behavior that is currently implicit or pallet‑specific.

Open Questions

  • Should there be a global default strategy?

  • Should burning reduce issuance or mark assets as lost?

  • Do NFTs require special handling?

  • Should governance override per‑asset policies?

  • Does this hook belong in frame_system or a shared asset abstraction?

Conclusion

Substrate defines when an account ceases to exist but does not define how dependent assets are resolved.

This proposal completes the account lifecycle by making asset resolution on reaping:

  • Explicit

  • Deterministic

  • Protocol‑enforced

This removes ambiguity, prevents griefing, and improves correctness across the ecosystem.