Efímero: Disposable Chains

Welcome to the comprehensive documentation for Efímero, a Polkadot parachain concept that enables high-volume, low persistence use-cases through disposable, temporary blockchain infrastructure.

What are Disposable Chains?

Disposable chains are ephemeral parachains with limited lifespan, designed to support high-volume use-cases without long-term state persistence. Unlike traditional chains designed for indefinite state, disposable parachains can be fully discarded after a set period, sidestepping typical storage constraints and enabling cost-effective operations like airdrops and user onboarding campaigns.

Key Features

• Zero Existential Deposits - Remove barriers for new users
• Cost-Effective Operations - Minimize storage and account creation costs
• High-Volume Support - Handle massive load of user transactions without permanent storage concerns
• Polkadot Native - Leverage XCM and Asset Hub integration
• Temporary by Design - Storage can be discarded without long-term implications

Documentation Structure

This documentation is organized into four main sections:

1. Introduction & Overview - Understanding disposable chains, their purpose, and project goals
2. Features & Architecture - Technical implementation details and core features
3. Use Cases & Examples - Practical applications and real-world scenarios
4. Implementation Guide - Setup instructions and deployment considerations

Getting Started

If you're new to Efímero, we recommend starting with the Introduction & Overview to understand the core concepts, then proceeding through the documentation in order.

For developers ready to implement an application example, jump directly to the Implementation Guide for practical setup instructions.

Introduction & Overview

This section covers the fundamental concepts behind Efímero: Disposable Chains, their purpose within the Polkadot ecosystem, and the project goals that drive this approach to blockchain infrastructure.

The Disposable Chain Concept

Introduction

There are several blockchain applications that aim to drive high-volume user interaction and attraction, such as token airdrops, which can be effective but often lead to storage bloat or require onboarding many new accounts. These use cases face unique challenges on Polkadot compared to other blockchains. This is largely due to Polkadot's focus on long-term scalability, security, and efficient state management. Polkadot enforces features like existential and storage deposits to maintain an optimized state, which can complicate the implementation of large-scale operations aimed at expanding and engaging the user base. However, these limitations are intentional and align with Polkadot's design philosophy.

The Solution: Ephemeral Parachains

One potential solution to make these operations more feasible is the concept of ephemeral, or disposable, parachains. Unlike traditional chains designed for indefinite use, a disposable parachain has a limited lifespan, allowing its state and data to be fully discarded after a set period. This approach sidesteps typical storage constraints by creating a temporary, efficient parachain that operates without existential deposits, reducing significant upfront costs, uses simplified fee structures, and is tolerant of high-volume storage needs, such as tracking user claims in airdrops or managing other onboarding activities.

References

The concept of Disposable Chains was introduced by Shawn Tabrizi (Polkadot Fellowship Member) in the following resources:

• Polkadot Forum Discussion
• Dropit Project

Project Goals

The goal of Efímero project is to explore a new parachain concept on Polkadot that enables high-volume use-cases, such as airdrops, to be implemented in a cost-effective, low-friction manner. This project introduces the idea of disposable parachains: a temporary, flexible structure designed to support high-volume interactions without long-term state commitments, looking to address the previously mentioned challenges that Polkadot's design presents.

Key Objectives

Cost Efficiency for All Participants

By using a disposable parachain, the project minimizes state storage and account creation costs for promoters and users, eliminating the need for existential deposits and simplifying fee structures to support high-volume needs without financial strain.

Reduced Friction for New Users

This concept lowers entry barriers by removing or reducing initial deposits and simplifying account setup, allowing new users to join with minimal effort.

Prioritizing User Experience over Scalability

Designed for short-term use, this parachain sacrifices indefinite scalability for a seamless user experience, making it ideal for high-engagement, interaction-focused cases.

New High-Engagement Solution on Polkadot

Disposable parachains offer an efficient, flexible model for rapid onboarding and value capture within Polkadot, promoting adoption by overcoming traditional storage and scalability constraints.

Leveraging Polkadot's Unique Features

This concept leverages Polkadot's architecture by leaving a minimal footprint on the Relay Chain and enabling cross-chain integration through XCM, allowing for persistent outcomes via Asset Hub and potential integrations with other system chains, further embedding these use cases within the Polkadot ecosystem.

Vision

This experimental parachain concept ultimately aims to make Polkadot a more flexible and attractive platform for high-engagement projects, positioning it to support innovative use cases and drive broader adoption within the blockchain space.

Features & Architecture

This section details the technical implementation of Efímero: Disposable Chains, covering the core features that enable cost-effective, high-volume use-cases while maintaining security and integration within the broader Polkadot ecosystem.

Core Features

Flexible Native Asset Configuration

The disposable parachain does not require a native token, which would add complexity by necessitating a valuation mechanism for use in fees, block production, and validator rewards. Instead, the parachain uses Polkadot's native Relay Chain token for transaction fees and other operational needs, including cross-chain transactions via XCM. It is also extremely straightforward to adapt it to use the native token of other chains or sufficient assets like USDC as the disposable native asset.

Zero Existential Deposit

To support cost-efficient and user-friendly interactions, the chain has a zero existential deposit. This removes the need for users to maintain a minimum native token balance for critical operations, thereby lowering barriers to entry and easing access for new accounts.

Asset Handling Without Issuance

The chain supports asset management through the pallet-asset, enabling asset handling without issuance capabilities. Because of the chain's temporary nature, it does not mint new tokens. Instead, asset issuance takes place on Polkadot-aligned chains such as Asset Hub, or on any "permanent" chain that chooses to attach a disposable chain for a specific use case. Tokens are then transferred to the disposable parachain via XCM for distribution and operation. When a token accrues significant value or importance, users are encouraged to migrate it to a permanent chain, such as Polkadot's Asset Hub, where it requires an existential deposit.

Configurable Asset Reserve Integration

The parachain accepts Asset Hub as the primary asset reserve, allowing it to handle Asset Hub's native assets efficiently. A dedicated transactor manages these assets, ensuring streamlined interactions within the Polkadot ecosystem. This concept can be expanded to any chain that would like to be set up as the Reserve, for example, Mythos could temporarily annex a disposable chain to it which accepts it as the reserve of MYTH.

Governance Control with Sudo Pallet

Currently, the chain implements the sudo pallet, allowing for direct administrative control. This authority could potentially transition to the Relay Chain's governance body, aligning it with other system chains and Polkadot's governance framework.

Merkle-Based Eligibility Verification

The parachain includes a specialized pallet for storing Merkle roots, which represent datasets with account-to-value mappings linked to asset IDs. This mechanism enables secure verification by allowing users to prove eligibility for specific actions, such as token claims. A practical application of this feature is pull-based token distribution, where users can claim assets by providing a Merkle proof that verifies against the stored root.

Fee-Free Onboarding for New Accounts

To reduce onboarding friction, the parachain enables whitelisted calls to be executed without fees with a configurable cooldown period. This allows new accounts to perform critical actions, such as submitting a claim extrinsic, without needing to acquire native tokens, further simplifying the user experience.

Implementation Details

Runtime Composition

pallet-balances

• Existential Deposit set to zero
• The insecure_zero_ed feature is enabled

pallet-pot-claim

• Implements a pot-based distribution mechanism for funds
• Extends the functionalities of pallet_assets and pallet_verify_merkle
• Utilizes pallet_verify validations to prevent double claims

pallet-verify-merkle

• Stores Merkle roots associated with item IDs, typically AssetId
• Provides a mechanism to validate proofs against selected Merkle roots by item ID
• Implements the proving_trie module based on sp_trie for merkle proof validation
• Assumes a dataset of account -> value, with both components extracted from proofs
• Tracks extracted accounts to prevent duplicate validations

pallet-free-txn

• Leverages the feeless_if pre-dispatch hook from pallet_skip_feeless_payment to enable fee-free transactions
• Implements a custom pre-dispatch that allows zero-balance accounts to call extrinsics
• Introduces a cooldown period for each origin to prevent rapid, repeated free transactions
• Applies a whitelisting filter to restrict fee-free calls to specific allowed extrinsics

Merklize Tool

The off-chain Merklize service provides essential functionality for the disposable chain stack:

• Root Generation: Provides an off-chain tool to generate merkle roots for given datasets
• Account Verification: Offers an endpoint to verify if a specific account holds a value (typically a balance) within the dataset
• Proof Calculation: Exposes an endpoint to calculate merkle proofs for valid accounts, enabling later verification against the root

Transaction Fee Checks

Following steps are performed in the Efímero: Disposable Chains transaction flow to determine if the user pays the fee or not:

1. Free Transaction Criteria: Checks whether it is a feeless or free extrinsic
2. Whitelist Verification: Checks if the inner call is whitelisted
3. Cooldown Check: Checks if the cooldown period is over
4. Execution: If all criteria are met, the user pays no fees

This flow ensures that new users can interact with the system without initial funding while preventing abuse through cooldown mechanisms and whitelisting restrictions.

In future, the transaction fee checks could be further extended by using a more robust sybil resistant mechanism using Proof of Personhood or an offchain verification system.

Design Nuances & Considerations

While the Efímero: Disposable Chains offer significant benefits for high-volume use-cases, some features introduce setup complexity and require careful security considerations.

Design Considerations

Asset Creation Requires Governance Control

Asset creation on the disposable chain is managed by sudo or the governance body, as these assets represent versions of tokens originally issued on the configured asset reserve like Asset Hub, Mythos, or any other chain. Only authorized entities can create assets on the disposable chain, ensuring that they are accurate representations for chain operations.

Governance Control for Merkle Root Storage

To maintain data integrity, Merkle roots used for validation must be stored by sudo or other governance authorities. This restriction ensures that only trusted parties can validate the data used for claim eligibility, protecting users and the system from potential inaccuracies or manipulation.

Flexible Native Asset Configuration

With no native token on the disposable chain, any configurable asset can serve as the native asset like the Relay Chain token, USDC, or the native token of the reserve chain. This requirement increases setup complexity, as initial funds must be transferred in to enable operations, and users may need an XCM transfer instead of a standard transfer to acquire the funds required for certain actions, such as moving assets back to the reserve chain.

Asset Issuance Managed by Trusted Reserve

All assets on the disposable chain are issued externally by the configured trusted reserve (such as Asset Hub, Energy Web, or any other designated chain) and then transferred in via XCM. This setup limits the chain's ability to independently manage asset issuance, relying instead on integrations with the configured reserve chain within or beyond the Polkadot ecosystem.

Non-Persistent Storage

Storage on the disposable chain is designed to be temporary. Actions taken on this chain should be viewed as ephemeral, and mechanisms must be in place to secure valuable assets or achievements. Users are encouraged to transfer claimed assets back to the configured reserve chain or other permanent chains for persistence, as the disposable chain's state may be flushed periodically.

Potential Vulnerabilities in Low-Friction Environment

The zero existential deposit and free transaction mechanisms for new users introduce potential vulnerabilities. For example, malicious actors could exploit free claim transactions by spamming mass-created accounts, sending failing transactions that, while not altering state, could burden RPC endpoints and impact node performance.

The initial whitelist filter mitigates these risks, and the mechanism can be disabled if administrators determine the risk outweighs the benefit. However, with adequate traffic control and proactive DDoS prevention, the low-friction environment can function as intended for user-friendly engagement.

Trade-offs Summary

These design decisions represent calculated trade-offs aimed at making the disposable chain viable for its intended purpose: enabling high-volume, low persistence use-cases within the Polkadot ecosystem while maintaining necessary security and operational integrity.

Use Cases & Examples

This section explores practical applications of Efímero disposable chains, demonstrating how they solve real-world challenges in token distribution, user onboarding, and high-volume engagement campaigns within the Polkadot ecosystem.

Suggested Use Cases

Asset Airdrops

Large-scale token distributions where recipients can claim assets without needing existing funds for transaction fees. The disposable chain handles the high-volume claiming process while valuable assets remain secure on permanent chains like Asset Hub.

Event Crediting Systems

Temporary chains for conferences, hackathons, or community events where participants earn credits or badges that can later be converted to permanent assets. The zero existential deposit enables frictionless participation for new users.

Competition Award Distribution

Prize distribution for contests or achievements where winners claim rewards through Merkle-proof verification. The temporary nature suits one-time events while XCM integration ensures prizes can be transferred to permanent storage.

Temporary Low-Friction Trading Environments

Short-term marketplaces or trading venues for specific assets where the zero existential deposit and fee-free onboarding enable broader participation without the setup complexity of permanent chains.

Airdrop Use Case: Pull-Based Token Distribution

We use an airdrop-based use case to demonstrate the unique advantages of disposable chains. Let's assume we want to conduct an airdrop of a newly created token to a set of users who meet specific eligibility criteria.

Traditional Push Model Challenges

In a traditional "push" model, tokens are distributed to each eligible user via direct transfers. Two immediate costs arise that can significantly limit the feasibility of such an approach: the cost of individual transfers and, in the worst-case scenario, the need to send an existential deposit to each user. These requirements can lead to upfront costs of thousands of dollars, constraining the viability of airdrops and diminishing their value as a tool, despite the utility they sometimes offer.

Pull Model Solution

Our solution to these challenges is to create an optimized environment for a "pull" model, enabling each eligible user to claim their airdrop independently with minimal friction.

Implementation Overview

Asset Setup

Two assets would be created: one on Asset Hub, serving as the trusted system chain for asset handling, and the other on our disposable chain. The asset IDs of these assets must match to allow the disposable chain's transactor to seamlessly map them. For instance, if the native asset created on Asset Hub has an ID of 3000, the asset on the disposable chain should be assigned the same ID. This requirement is also a key reason why asset creation on the disposable chain is restricted to sudo/governance.

Dataset and Merkle Root Generation

On a separate off-chain system, for which we also provide a working solution, a dataset is prepared containing beneficiary accounts and their corresponding balances to be claimed, based on specific criteria, such as Polkadot chain usage or messages sent via XCM. This tool calculates a merkle root for the provided dataset, which is stored in the disposable chain, associating it with the asset ID for which the asset was created.

This mapping of roots to asset IDs enables the disposable chain to run multiple airdrops simultaneously, as the root used for verification is determined by the asset being claimed. The storage of a new root associated with an asset ID must be executed by Sudo/Governance.

Asset Transfer and Pot Funding

Due to the ephemeral nature of the disposable chain, asset issuance is managed on Asset Hub. After minting, the amount designated for the airdrop is transferred as a reserve asset from Asset Hub into a pot account on the disposable chain. This approach ensures that the reserve remains secure on Asset Hub.

Claiming Process

Once the assets (technically derivatives of the original Asset Hub created asset) are transferred to the disposable chain and the pot is funded, users can start the claiming process as follows:

1. Merkle Proof Generation

Users must obtain a merkle proof from a provided off-chain tool, which will be validated against the stored root. This proof verifies eligibility, allowing the user to claim the corresponding balance.

2. Free Transaction Claiming

The chain offers a free transaction mechanism with the claim extrinsic whitelisted, enabling users to claim tokens even with newly created accounts, as neither an existential deposit nor transaction fees are required. These free transactions are gated by a cooldown period, so if a user makes an incorrect claim, they can try again after a specified number of blocks.

3. Verification and Distribution

Verifications are performed to ensure each beneficiary is genuinely eligible and part of the dataset, by validating the provided proof against the stored root. Each user can claim their tokens only once.

4. Making Assets Permanent

For the final step, a user who has claimed assets and wishes to make them permanent must reserve-asset transfer them back to Asset Hub. At that point, the assets become native to Asset Hub and will not disappear when the disposable chain is eventually discarded. To complete this transfer, the user must fund the sender account on the disposable chain to cover fees, and the receiving Asset Hub account must hold at least the existential deposit (ED) to accept asset transfers. An XCM asset transfer is then executed, with fees covered by the relay token, concluding the operation and securing the assets permanently on Asset Hub.

Additional Benefits

An additional benefit of the disposable chain setup is that it temporarily fosters a low-friction market environment. In this context, mechanisms can emerge where users accumulate more tokens, perhaps by consolidating small balances from other beneficiaries or exchanging different airdrops to increase their holdings, before transferring assets back to Asset Hub. This environment prioritizes smooth, low-cost transactions at the expense of storage, which, again, will ultimately be discarded.

Intuitive User Experience

If managed properly by a front-end application, this entire operation can be streamlined into a single "claim" button, providing a seamless experience even for newly registered accounts.

A key point worth highlighting is the mechanism to prevent double claims. This is achieved by tracking users who have already claimed, which could lead to significant chain storage usage if the user base is large. However, this potential bloating aligns with the purpose of the disposable chain, where temporary storage expansion is not a concern since the chain can later be discarded.

Workflow Diagram

Step-by-Step Process

The following diagram illustrates the complete workflow for using the disposable chain for token airdrops:

This workflow demonstrates the complete lifecycle from asset creation through claiming to permanent storage, showcasing how disposable chains integrate seamlessly with the broader Polkadot ecosystem while providing enhanced user experience for high-volume operations.

Implementation Guide

This section provides practical instructions for setting up and deploying Efímero: Disposable Chains, including step-by-step setup guides, configuration details, and operational considerations.

Quickstart Guide

This guide will walk you through setting up a complete Efímero: Disposable Chain environment for testing and development, focusing on the airdrop use case example.

Prerequisites

• Rust and Cargo installed
• Node.js and npm installed
• Git

1. Run an Efímero Node

Clone the repository

git clone https://github.com/blockdeep/efimero-node-template
cd efimero-node-template
git checkout master

Start the network with Zombienet

./run-zombienet.sh testnet_asset_hub

The script automatically checks your system and builds or fetches the required binaries. A local test network will launch with the following nodes:

• 2 Paseo Local Validators
• 2 Paseo Asset Hub Local Collators
• 2 Disposable Chain Local Collators

After a few minutes, all nodes should be producing blocks.

2. Run the Merklize Tool (Proof & Root Generation)

Clone the repository

git clone https://github.com/blockdeep/merklize
cd merklize
git checkout main

Prepare your dataset

• Navigate to test/data/test.csv
• Ensure that the account you plan to use for testing is included
• The file contains multiple real-world Substrate accounts. If you are using a freshly generated account, add it manually and assign yourself a balance.

Run Merklize CLI

cargo run --bin cli -- --input test/data/test.csv --key-column address csv

This starts the Merklize server. It provides both a library and HTTP API for generating Merkle proofs and roots based on datasets (in this example, CSV).

3. Run the Efímero UI

Clone the repository

git clone https://github.com/blockdeep/disposable-ui
cd disposable-ui
git checkout main

Set up the environment

npm run setup:env

This command executes setup-environment.ts, which automates critical initialization steps:

1. Open HRMP channel between Disposable Chain and Asset Hub (Zombienet does not automate this)
2. Fund the Disposable Chain's Sudo account with Relay tokens
   • While the genesis file currently allocates tokens to Sudo, in production the chain may start with no balances
3. Create and mint assets on Asset Hub to be bridged into the Disposable Chain
4. Create the derivative asset on the Disposable Chain (same ID mapping)
5. Transfer tokens via XCM from Asset Hub to the pot account on the Disposable Chain (tokens become claimable)
6. Retrieve the Merkle root from the Merklize server and store it on the Disposable Chain

Important: We highly recommend reviewing this script carefully, as it encapsulates the standard setup procedure most applications will follow when deploying ephemeral chains.

Start the development server

npm run dev

Open your browser and connect to the running application. You can now interact with the system using your preferred wallet (e.g., Polkadot.js, Talisman, Subwallet).

Complete Workflow

With all components running, you now have the complete workflow:

• Disposable chain running via Zombienet
• Merkle server generating proofs
• Front end enabling wallet-based claims and cross-chain transfers

Frontend Usage

The front end provides a streamlined workflow for testing and demonstrating the disposable chain airdrop process. This section details how to use the reference implementation to test airdrop claims.

Reference Implementation

This front end serves as a reference implementation example and a starting point for projects aiming to:

• Spin up an ephemeral chain
• Run onboarding campaigns such as airdrops
• Provide a low-friction user experience with wallet connection, proof generation, claim transactions, and cross-chain settlement

The complete source code is available in the Efimero Demo UI repository for reference and customization.

Integration Notes

This frontend serves as the user-facing layer in a three-component ecosystem:

Component Roles:

• Efímero Node: Provides gasless transactions and Merkle proof verification
• Merklize Server: Handles off-chain proof generation and dataset management
• Frontend: Abstracts blockchain complexity into familiar web interactions

Key Integration Points:

• Direct WebSocket connection to disposable parachain which also exposes XCM messaging for cross-chain asset bridging
• HTTP API integration with proof generation service
• Wallet abstraction using Polkadot ecosystem standards

Prerequisites & Setup

Before using the frontend, ensure the infrastructure is running:

• Efímero node: Running with custom pallets (potClaim, verifyMerkle, freeTxn)
• Merklize server: Loaded with your dataset and serving proofs
• Asset funding: Assets transferred to the pot account via XCM from Asset Hub

See Quickstart Guide for complete setup.

User Workflow

1. Connect Your Wallet

Link your Substrate-compatible wallet to the UI.

2. Check Eligibility and Balance

The application queries the Merklize server to verify if your account is included in the dataset. If eligible, it will display the corresponding claimable balance.

3. Generate a Merkle Proof

A proof is generated for your account in the context of the dataset. This proof is required for the claim and will be sent to the disposable chain for verification.

4. Claim the Asset

Submit a free whitelisted transaction that calls the claim extrinsic.

Parameters:

• Asset ID (preconfigured in this example)
• Merkle proof (generated in the previous step)

Once verified, the disposable chain transfers the asset to your connected account.

5. Cross-chain Transfer back to Asset Hub

After claiming, you can permanently secure your tokens by transferring them back to Asset Hub. The application exposes a cross-chain function that sends the necessary XCM message to move the asset back into Asset Hub, where it persists beyond the lifecycle of the disposable chain.

Common Issues

• "Account not found": Your address isn't in the test dataset (test/data/test.csv)
• "Already claimed": Each account can only claim once
• Transaction fails: Wait for the 10-block cooling period between free transactions