[Referendum: 14] Request Process for Moonriver Native XCM Enabled ERC-20 (XC-20) MBF Dapp Listing

Request Process for Moonbeam/Moonriver Native XCM Enabled ERC-20 (XC-20) MBF Dapp Listing

Polkassembly Post


In an upcoming Runtime upgrade(2400 or 2500) the capability will be added for any native ERC-20 to be bridged from Moonbeam/Moonriver to any other parachain in the relay chain’s network - given that the receiving chain supports the ERC-20 and has opened a bidirectional XCM channel with Moonbeam/Moonriver.

Although the ERC-20 does not require any permission from Moonbeam/Moonriver to be XCM enabled, a process is necessary for ERC-20s to be listed in the MBF Dapp, which is proposed here.

Regardless of the process used to determine a listing, a token’s listing in the MBF Dapp should not be taken as an endorsement by the Moonbeam Foundation nor a testament to the future performance or safety of the token.


XCM enables cross-chain collaboration between parachains and is a hallmark feature of Kusama / Polkadot as well as an important aspect of Moonriver’s/Moonbeam’s growth.

Along the same lines, ERC-20 tokens are a fundamental building block of the decentralized finance (DeFi) ecosystem as well as others. Enabling the transfer of ERC-20 tokens across different blockchains is crucial to ensure the continued growth of the DeFi and other ecosystems that rely on them.

As an EVM Moonbeam/Moonriver is uniquely positioned to be a home for ERC-20 tokens and the MBF Dapp is positioned to be a nexus for moving ERC-20s into the broader Polkadot/Kusama ecosystem. A listing in the MBF Dapp is inherently useful, providing the project visibility to the broader Moonbeam/Moonriver community on a trusted and fully supported platform while demonstrating the token’s XCM status and availability for cross chain transfers. Alongside the Dapp listing, the open-source XCM SDK maintained by the MBF will be extended with support for the token, accelerating project adoption by other applications.

To ensure the community has the opportunity to weigh in on which tokens are listed and quality information on the tokens already listed in MBF Dapp this proposal addresses:

  1. A lightweight process for requesting a listing in the Dapp
  2. A standard template for Requests to list an ERC-20 token in the MBF Dapp

MBF Dapp Listing Process

Important: ERC-20 listing on the dApp should be requested only when the token has been registered by another Parachain team and not before that.


A complete Request must be posted by a member (Requestor) of the team controlling the ERC-20 contract to the Moonbeam Forum in an “Dapp Listing” Category for the community and Foundation to review, ask questions and provide suggestions. The post must be tagged to either Moonbeam or Moonriver.

While there is no required time the Request should be available in the Forum before a decision to list or not is made, there is benefit in gathering community engagement, feedback and support in this stage. In addition, community members and forum moderators can highlight to the Requestor if required information is missing allowing the Requestor to amend and refine the Request. While the period of review time is variable, it should be no more than two weeks after all questions are answered by the Requestor.

Absent missing information in the Request, or negative feedback and unanswered questions by the project, a listing Request will generally be accepted.

In all cases, the Moonbeam Foundation retains the authority to list, not list or delist a token at any time, providing details in the existing thread to the community.

Listing Request Template

Request for a ERC-20 Listing must follow a standardized Listing Request Template

a. Team/Project Overview

  1. Title: [ERC-20 Name] Request to list in MBF Dapp
  2. Contact: Email/TG/Discord handle to communicate with Requestor
  3. Overview: One sentence summarizing your ERC-20 and relevant links to your website, Twitter and social channels.

b. Token Info

  1. Token Name:
  2. Token Symbol :
  3. Decimals:
  4. Total Supply (at time of Request, note if variable):
  5. Number of Holders (at time of Request):
  6. Active Daily Users:
  7. Tokenomics (URL):
  8. Art Assets (URL):
  9. Have you completed full testing of this token on the Moonbase Alpha TestNet?

c. Token Pricing Information (if available)

  1. Listing URL (CMC, Coingecko etc.):
  2. Total Market Cap (at time of Request):

d. Etherscan Token Profile

  1. Token Profile URL Profile should be completed
  2. Verified Contract Token Contract Source Code must be verified
  3. Reference: Add Token Information on Moonscan | Moonbeam Docs

e. Signed Message

Using View, Sign, & Verify Message Signatures | Moonbeam or similar, the Requestor should include the following message as signed bytes:

[Moonbeam ChainID 1284/Moonriver ChainID 1285] I hereby declare that I am the creator of contract address[contractAddress]

This message will serve to show that the actual owner/deployer of the contract is submitting the Listing Request.

f. Key Disclosure

Requestor for a ERC-20 Dapp listing must provide the following as part of the Request:

  1. Is the Contract Code Open-Source (and include GitHub link)? If parts of the code are not open source: please provide information on why not
  2. (For Moonbeam Proposals Only) Does your token have a Moonriver deployment? *If yes, please provide token details and whether your Moonriver deployment has already integrated with other Parachains in Kusama
  3. Is your Contract Code audited? If yes, please provide:
  • The name of Auditors,
  • Dates of audit reports and, if available,
  • Links to audit reports

g. Network Support

  1. For each Parachain Supporting ERC-20 XCM Transfer: This section determines which parachains are listed as transfer destinations in the Dapp.
  • Destination chain:
  • Sufficient Asset Qty (minimum balance allowable:
  • Asset remote id:
  • Status (is parachain currently accepting token):

All projects must make a good-faith effort to keep this up to date so long as they are supported by the Moonbeam Dapp. In particular the Network Support section must be accurate in order for the Dapp to correctly list parachains the token may be sent to.


I vote in favor of this proposal!


Link to the on-chain proposal: