When developing a new protocol, the default assumption is nearly always that a new native token must follow. Most blockchains and Web3 frameworks rely on
However, deploying a new Web3 application as a "rollup" or "Layer Two" solution has been common in recent years. Whether implemented as a rollup on Ethereum, a parachain on Polkadot, or a subnet on Avalanche, the primary objective is to leverage the parent network's robust economic security, utilizing its substantial validator pool and security guarantees.
The Obstacles: Justification for a Separate Token
Currently, the technical challenge of building a blockchain has been significantly mitigated through the availability of numerous SDKs and frameworks. Tools such as the Polkadot SDK and Cosmos SDK allow developers to utilize templates and rapidly launch a functional network, complete with all the standard features one would expect from any standard Web3 protocol.
Despite these advancements, a major barrier remains: identity, namely, ensuring we have some semblance of sybil resistance.
We still need a way to ensure bad actors can’t utterly spam or harm our network, which is most of the main reasons why economic aspects of cryptoeconomic systems like Proof of Work or Proof of Stake exist.
Tokenomics then becomes a subsequent concern: if a project's token model is flawed or poorly conceived, it can undermine the entire effort, regardless of the quality of the underlying technology.
The necessity of designing and securing an entirely separate cryptoeconomic network presents a considerable hurdle for developers and startups whose core mission is building a superior, more resilient application or infrastructure, not managing a monetary policy.
Fortunately, the landscape is evolving, providing a solution to this complexity.
The Solution: Utilizing the “Parent” Network's Token
If a new protocol builds upon an existing network and deploys as a rollup/Layer Two, they (should) inherently, well, inherit their security from the parent network.
This raises a critical question: why not simply use the parent network's native token for all operations? Everything is already set up; we just need to make sure that we can safely perform checks and balances when transferring to and from the parent network. In the future, it might be possible to launch a rollup without a token at all, if we solve the Sybil problem, and assuming we have a parent network that provides security for our rollup/service.
Polkadot permits the launch of a “tokenless” parachain. The parachain can instead use the Layer One's token (such as DOT on Polkadot) to facilitate all operations, including transaction fees and security mechanisms.
This approach frees up the team to concentrate on building solutions and core application logic. In other words, you focus more on getting your protocol running so you can build your resilient application/infrastructure rather than being bogged down by token mechanics.
A Live Example: EduChain
This concept is not merely theoretical. The Web3 Foundation's Technical Education team (of which I am a part of!) has experimented with it with EduChain, which serves as a live demonstration of this tokenless configuration. It utilizes the parent network’s token, specifically the PAS token on the Paseo testnet, as its functional currency.
The EduChain configuration operates via a reserve-backed transfer using XCM, which functions as follows:
- Zero initial supply: the chain commences with a zero total supply of its own potential token. To fund a network account, a cross-chain transfer via XCM must be initiated from the parent network (Paseo).
- The reserve and the sovereign account: The parachain designates a system parachain (such as the Paseo Asset Hub) as a reserve for the parent token (PAS). Upon the parachain's creation, a specialized account, known as a sovereign account, is automatically generated on the parent chain exclusively for the parachain.
- Transferring PAS:
-
When a user sends PAS from their account on the parent chain (Paseo) to the parachain (EduChain), the PAS is deposited into the parachain's sovereign account on the parent chain, where it functions as the reserve.
-
Simultaneously, a new, local asset representing PAS is minted on the parachain and credited to the user's account there.
-
When a user sends this local asset back to the parent chain, the local asset is burned on the parachain, and the corresponding PAS amount is unlocked and transferred from the sovereign account back to the beneficiary's account on the parent chain.
-
This XCM mechanism ensures that every unit of PAS on the parachain is fully backed 1:1 by actual PAS held in a secure reserve on the parent network, thereby eliminating the necessity for a distinct, project-specific token.
As a general note, a parachain controls its own local representation of an asset and could, in principle, change those balances according to its own governance. However, Asset Hub — as the reserve location — maintains the canonical reserve‑backed accounting for that asset across the network, and parachains are expected to use XCM instructions via Asset Hub so that this accounting remains correct and consistent.
For comprehensive details on EduChain and its operational mechanics, documentation is available at:
Conclusion
This article aimed to highlight the significant potential of delegating the economic and security concerns of a rollup or Layer Two to the parent network itself. By employing reserve-backed XCM transfers, a project can completely circumvent the substantial difficulties associated with launching a new Web3 protocol, allowing the team to dedicate its full effort to building a superior application and addressing real-world problems.
Individuals interested in implementing this solution can explore launching a parachain on Paseo, as well as the EduChain repo for more information: