Ecosystem Grant Draft Proposal: moonbeam-xcm-lens

Governance Grant Proposals
1

Title: moonbeam-xcm-lens

Author: ILE Labs Date: May 2026

TLDR

Primary Goal: Building Connected Contracts Use Cases (using XCM and other message passing protocols)

Project Description: moonbeam-xcm-lens is an open-source CLI tool that reconstructs the full execution path of a Moonbeam connected contract transaction — from the initial EVM call through XCM precompiles into Substrate message hops and downstream parachain execution — with human-readable labels at every step.

Requested GLMR Grant Amount: [GLMR equivalent of $24,500 USD at time of payment]

Use of Grant: Grant funds will be used to build, document, and release moonbeam-xcm-lens as a free, open-source developer tool available to the entire Moonbeam ecosystem. All code will be published under MIT/Apache-2.0 license.

Motivation for Grant Amount: Moonbeam’s connected contracts capability is its core differentiator, yet no dedicated tool exists to trace and debug cross-chain XCM execution paths. This grant enables ILE Labs to deliver that missing infrastructure to every developer building on Moonbeam, strengthening the Connected Contracts ecosystem at a cost comparable to a single developer-month at market rates.

Project Overview and Relevant KPIs

What moonbeam-xcm-lens does

When a connected contract transaction fails or behaves unexpectedly on Moonbeam, developers currently debug by manually cross-referencing three separate systems: Moonscan for EVM traces (which stop at the XCM precompile boundary), Subscan for raw Substrate events (which show hex-encoded XCM message bytes with no context), and the destination parachain’s own explorer (which has no back-link to the originating Moonbeam transaction).

moonbeam-xcm-lens eliminates this process. One command. Full path. Every hop labeled.

$ moonbeam-xcm-lens trace 0x4f2a...b201

XCM Execution Path
==================
[1] EVM Entry (Moonbeam)
     Contract:  0xAlice_DApp
     Function:  transferToParachain(dest: Astar, amount: 100 DOT)
     Status:    OK

[2] XCM Precompile → Substrate
     Precompile: XcmTransactor
     Instructions: [WithdrawAsset, BuyExecution, DepositAsset]
     Status:    OK

[3] Relay Chain Routing
     Message ID: 0x8b2f...e019
     Status:     OK

[4] Astar Parachain Execution
     Status:     FAILED
     Reason:     TooExpensive — fee asset not accepted
     Fix:        Use ASTR as fee asset when targeting Astar

Traction on Moonbeam to date

ILE Labs is a new applicant to the Moonbeam ecosystem. We are applying based on our established track record of shipping the exact category of tool we are proposing here — cross-chain execution tracers — on other ecosystems:

  • solana-cpi-lens — reconstructs full CPI call trees from any Solana transaction with human-readable program labels. Live on GitHub, actively used by Solana developers.

  • zeta-trace — cross-chain message tracer for ZetaChain Universal Apps, reconstructing the full 3-hop message path across source chain, ZetaChain, and destination.

  • stylus-debug-suite — production Rust debugging toolkit for Arbitrum Stylus, live on crates.io with 25+ downloads.

We are building moonbeam-xcm-lens because the same problem we solved on Solana (opaque cross-program execution) and ZetaChain (opaque cross-chain message routing) exists on Moonbeam and has not been solved here yet.

Team Experience

ILE Labs is a blockchain infrastructure and developer tooling company that builds open-source tools across multiple ecosystems.

Charles Emmanuel — Project Lead Blockchain engineer and company lead. Grant coordination, documentation, stakeholder communication. Prior ecosystem work spans Arbitrum, Filecoin, Solana, Starknet, and ZetaChain. GitHub: CodexEmmzy

Gospel Ifeadi — Lead Engineer Rust and TypeScript systems programmer. Led development of stylus-debug-suite (Arbitrum Stylus, live on crates.io). Focus on WASM runtimes and blockchain infrastructure.

Akinyemi Saheed Akinwale — Senior Backend Engineer TypeScript, Go, JSON-RPC, gRPC, distributed systems. Core contributor to stylus-debug-suite and solana-cpi-lens.

Bolaji Ahmad — Blockchain Engineer Rust, Substrate/Polkadot, cryptographic primitives. Built Smart Contract Cryptography Dev Tool on Polkadot Asset Hub. Direct Substrate knowledge for XCM event parsing. GitHub: bolajahmad

Relevant shipped work:

Timeline and Milestones for Use of Grant

Total Duration: 3 months Start: Upon grant approval

Milestone Period Deliverable
M1 Weeks 1–4 Core XCM parser: EVM trace extraction via debug_traceTransaction, XCM precompile decoding, Substrate extrinsic correlation, raw message tree output
M2 Weeks 5–8 Human-readable decoder: contract name resolution, plain-English XCM labels, relay chain routing trace, destination parachain execution status, failure reason classification
M3 Weeks 9–12 CLI release: polished terminal output, --json flag, 10+ working examples, full documentation, open-source release under MIT/Apache-2.0

M1 KPI: CLI parses 95%+ of XCM v3 messages from Moonbase Alpha testnet. 15+ integration tests passing.

M2 KPI: Full human-readable output for major connected contract patterns — asset transfers, remote EVM calls, batch XCM. Top 10 failure types classified with fix suggestions.

M3 KPI: External developer traces a failed XCM transaction and identifies root cause in under 2 minutes following the README.

Vision of Success

What success looks like

A Moonbeam developer encounters a failed connected contract transaction. Instead of spending 30-90 minutes manually correlating three different block explorers, they run one command and see exactly which hop failed, why it failed, and what to change. That debugging session goes from an hour to two minutes.

That is the immediate success metric: time-to-root-cause reduced to under 2 minutes for any XCM transaction failure.

Measuring success

  • Developer adoption: GitHub stars, downloads, and issues opened by the community

  • Ecosystem reach: referenced in Moonbeam documentation or developer guides

  • Community feedback: positive responses in the Moonbeam Discord #developers channel

Sustainability after the grant

moonbeam-xcm-lens will be maintained as a community open-source tool for a minimum of 12 months post-delivery. This includes:

  • SDK compatibility updates when Moonbeam or Polkadot XCM versions update

  • Community contribution acceptance

  • Bug fixes and issue response

The tool is self-sustaining because it has no operational costs — it is a local CLI that developers run on their own machines. No servers, no subscriptions, no ongoing infrastructure costs.

2 to 5 year vision

ILE Labs’ goal is to become the reference infrastructure tooling team across multiple blockchain ecosystems — the team that ships the debugging and observability layer that other developers depend on. moonbeam-xcm-lens is one node in that network. A successful delivery here creates the foundation for:

  • Phase 2: GMP bridge integration — extending the tracer to cover Hyperlane, LayerZero, Axelar, and Wormhole message paths originating from Moonbeam

  • VS Code extension for inline XCM debugging

  • AI-powered fix suggestion engine extending our cairo-debug pattern to XCM error classification

  • Expansion to other Polkadot parachains that face the same XCM debugging challenge

Rationale

How this advances Connected Contracts use cases

Connected Contracts is Moonbeam’s primary differentiator. No other EVM-compatible chain natively routes smart contract calls to Polkadot parachains via XCM. The better that capability works from a developer experience perspective, the more teams choose Moonbeam for their cross-chain applications.

Currently, when a connected contract fails at the XCM layer, it is effectively a black box. Developers can see that the EVM transaction succeeded (or failed) but have no visibility into what happened in the XCM message that followed. This opacity discourages adoption of connected contracts — developers avoid cross-chain calls they cannot debug.

moonbeam-xcm-lens removes that opacity. Every XCM hop becomes visible. Every failure has a plain-English explanation. Developers gain the confidence to build more complex connected contract architectures knowing they can debug them when something goes wrong.

Why the Moonbeam community should support this

Developer tooling creates leverage. One tool benefits every developer who uses it, across every application built on Moonbeam. A DeFi protocol that saves 45 minutes per debugging session, multiplied across a team of five developers, multiplied across dozens of teams building connected contracts, represents a significant multiplier on the value delivered relative to the grant size.

This tool is also a signal to the broader developer ecosystem that Moonbeam is a serious environment for cross-chain application development — one where the debugging infrastructure matches the ambition of the connected contracts feature itself.

Steps to Implement

Step 1: Core XCM Parser (Weeks 1–4)

What: Build the Moonbeam RPC integration layer that extracts EVM transaction traces and correlates them with Substrate XCM events.

Technical work:

  • Integrate Moonbeam’s debug_traceTransaction RPC endpoint

  • Identify and decode XCM precompile calls by address (XcmTransactor, Batch, etc.)

  • Parse XCM instruction sets from precompile input data

  • Correlate EVM transaction with corresponding Substrate extrinsic using block-level event mapping

  • Extract outbound XCM message ID, weight, and destination specification from Substrate storage

Resources: 2 engineers (Gospel, Akinyemi), 120 hours combined

Step 2: Human-Readable Decoder and Destination Resolution (Weeks 5–8)

What: Add the intelligence layer that turns raw XCM data into something a developer can act on.

Technical work:

  • Contract and program name resolution via Moonbeam and destination chain APIs

  • Plain-English labels for XCM instruction types (WithdrawAsset, BuyExecution, DepositAsset, etc.)

  • Relay chain routing trace using Polkadot RPC

  • Destination parachain RPC integration for execution result retrieval

  • Failure reason classification covering the most common XCM error types (TooExpensive, Barrier, AssetNotFound, WeightLimitReached, etc.)

  • Fix suggestion generation for each classified failure type

Resources: 2 engineers (Gospel, Bolaji), 120 hours combined. Bolaji’s Substrate/Polkadot experience leads the relay chain and parachain integration.

Step 3: CLI Release and Documentation (Weeks 9–12)

What: Package everything into a polished tool that any Moonbeam developer can use immediately.

Technical work:

  • Terminal output formatting with color and hierarchy

  • --json flag for CI/CD pipeline integration

  • decode subcommand for standalone XCM precompile call decoding

  • explain subcommand for tracing from message ID

  • README with quickstart guide

  • 10+ documented examples covering common connected contract patterns

  • GitHub Actions workflow template for integration testing

  • Open-source release under MIT/Apache-2.0

Resources: 2 engineers (Akinyemi, Gospel), 80 hours combined

Telegram — @charlesCode — contact@ilelab.org

2

hey, did some digging on this before forming an opinion. honestly doesn’t look credible to me. the domain was registered 4 months ago, the website looks ai generated

also noticed you’ve submitted proposals to at least 6 ecosystems in the last 3 months - Zcash, Polkadot, Filecoin, Arbitrum, Sia, and now Moonbeam

went through the GitHub too. the proposal references zeta-trace as shipped work but it’s a 404 on GitHub. solana-cpi-lens is called “actively used” but has 0 stars, 0 forks, last commit March 10. your most recent repo lightning-payjoin-kit has 8 commits and zero actual source code - just markdown files, and you’re still listing it as prior work

doesn’t feel like something that will get used in the ecosystem

3

Hi @Aleksandr,

To clarify: ILE Labs as a company is brand new (formed January 2026), but our engineers are not. We are a group of independent developers who recently grouped together to build dedicated infrastructure.

Concerning the empty repos like lightning-payjoin-kit: they are currently just architectural scopes while we seek our first grant runway to fund the actual coding. Calling them “shipped” was a mistake by our intern who was tasked with submitting the proposal. We’ll get that corrected.

As for applying everywhere: Yes, we are pitching multiple ecosystems because our collective has grown and we have dedicated sub-teams ready to execute. We are hunting for our initial runway to get started.

Since our company GitHub is new, our credibility lies in our individual profiles. We have exactly 4 dedicated engineers assigned to this Moonbeam project who have shipped real code:

We’ve also structured this to be zero-risk for the DAO:

  1. We operate on strict milestones. We only receive payment after the committee reviews and approves the delivered code across the milestones.
  2. We are committed to hosting local developer meetups to actively ensure people use the tool.
  3. After every project, we commit to 6 months of maintenance and patching for the open-source tool.
4

your org has 11 repos with a combined 3 stars and 1 fork across all of them. the “actively used by Solana developers” claim on solana-cpi-lens doesn’t match reality

you say applying everywhere is because you have sub-teams ready to execute. but you have 8+ proposals across 6 ecosystems in 3 months and 0 confirmed grants. the pattern suggests you’re throwing templates at every treasury and hoping something sticks

if you want to prove it, ship a working prototype on Moonbase Alpha first

5

Small clarification on the proposal wording:

Some sections of the proposal describe the architectural direction and prior research basis for the tool rather than implying a fully production-complete implementation already exists today.

The current repositories reflect ongoing infrastructure and proof-of-concept work related to execution tracing, debugging, and cross-chain tooling across multiple ecosystems. moonbeam-xcm-lens itself is the proposed Moonbeam-native implementation we are seeking to build and open-source through this grant process.

We wanted to clarify this distinction to avoid overstating the current implementation status while still communicating the technical direction and prior experience behind the proposal.

Thanks again for the feedback and review.

6

This topic was automatically closed after 5 days. New replies are no longer allowed.