Developers Forum for XinFin XDC Network

How to Publish and Monetise Your API on XDC AI Marketplace.

Vinn — Thu, 16 Jul 2026 12:47:53 +0000

Introduction

AI is advancing past chatbots into autonomous agents that can discover services, make payments, and complete tasks on their own. This new economy, known as AI Commerce, enables AI agents to automatically purchase APIs without human involvement.

XDC AI Tech enables developers to publish APIs that AI agents can discover, pay for using gasless USDC payments and consume instantly using the x402 payment protocol, all powered by the XDC Network.

The Rise of Agentic AI Commerce

AI is no longer limited to assisting users; it can independently discover services, negotiate prices, make payments, and complete tasks. This shift is giving rise to Agentic AI Commerce, in which self-operating AI agents transact directly with digital services via programmable payments, rather than traditional user-driven workflows. Unlike conventional AI assistants, agentic systems can execute multi-step actions across applications with minimal human intervention, enabling a new machine-to-machine economy.

Challenges with Traditional API Monetisation

Traditional API businesses rely on:

API keys and manual authentication
Monthly subscription plans
Credit card payments and invoicing
Geographic payment restrictions
Human-managed billing

These models create friction for autonomous AI agents that need instant, pay-per-use access.

Why the API Economy Needs to Evolve

The API economy has grown into a multi-billion-dollar industry, but most APIs still rely on subscriptions, API keys, invoices, and manual onboarding. These models work well for humans but introduce friction for autonomous AI agents that need instant, pay-per-use access. As AI agents become capable of executing workflows independently, developers need infrastructure that provides automated discovery, authentication, and micropayments without calling for human approval for every transaction.

Industry Momentum Behind Agentic AI

Enterprises are rapidly investing in agentic AI. Gartner predicts that 60% of brands will use agentic AI to deliver one-to-one customer communications by 2028, while spending on supply chain software with agentic AI capabilities is expected to grow from less than $2 billion in 2025 to $53 billion by 2030. These forecasts highlight how AI agents are moving beyond experimentation into real-life business operations.

What is XDC AI Tech?

XDC AI Tech is an AI API marketplace where developers are able to list APIs and AI services for autonomous agents.

Primary features include:

AI API Marketplace
Pay-per-request monetisation
Gasless USDC payments
x402 payment protocol
Blockchain settlement on XDC Network

Why XDC Network?

XDC Network provides:

Fast transaction finality
Low transaction costs
Enterprise-grade blockchain infrastructure
EVM compatibility
Native support for gasless USDC payments

Understanding x402

x402 is an open payment protocol that enables APIs to charge users automatically.

Instead of API keys:

AI requests an API.
API returns HTTP 402 Payment Required.
AI signs a USDC payment.
Payment is verified.
API returns the requested data.

This enables true machine-to-machine commerce.

Why x402 Matters

Traditional internet protocols never included a native payment mechanism, forcing developers to rely on API keys, subscriptions, and third-party billing systems. The x402 protocol brings programmable payments directly into HTTP by enabling APIs to request payment before returning a response. This allows AI agents to pay for services automatically on a per-request basis, making APIs both discoverable and instantly monetizable without manual billing workflows.

The Shift Toward Machine-to-Machine Payments

One of the biggest barriers to autonomous AI has been payments. While AI agents can analyse data, generate content, and orchestrate workflows, they traditionally could not complete purchases without human involvement. Emerging payment standards such as x402 and blockchain-based settlement are changing this by enabling secure, programmable, machine-to-machine payments that support autonomous digital commerce.

Reference:

Gasless USDC Payments

With XDC AI:

Agents only need USDC.
No XDC is required for gas.
A relayer submits the blockchain transaction.
Providers receive USDC payments seamlessly.

How to Publish Your API

Step 1: Prepare Your API

Ensure your API is:

Publicly accessible (HTTPS)
Stable and production-ready
Well documented

Step 2: Integrate x402

Configure your API to accept x402 payments, so AI agents can pay per request.

Step 3: Prepare Listing Details

Keep the following ready:

API name
Description
Endpoint
Documentation
Pricing
Category & Tags
Contact details

Step 4: Submit Your Listing

Visit the XDC AI Provider Submission page and complete the listing form.

Step 5: Review & Approval

The XDC AI team reviews your submission before publishing it on the marketplace.

Step 6: Start Monetising

Once approved:

Your API becomes discoverable.
AI agents can access it.
Payments are settled in USDC for every successful request.

Best Practices

Write a clear API description.
Keep documentation up to date.
Use open pricing.
Maintain high uptime.
Choose accurate categories and tags.

FAQs

Q. What payment currency is used?

USDC.

Q. Do I need XDC for gas?

No. Payments are gasless for users.

Q. Can I charge per API call?

Yes. XDC AI supports pay-per-request pricing.

Q. Can I list an existing API?

Yes, as long as it meets the marketplace requirements.

Disclaimer

This article is for informational purposes only. Platform features and submission requirements may change. Always refer to the official XDC AI documentation before publishing your API.

The Future of AI Commerce

Industry adoption is accelerating across sectors. Financial institutions are already deploying agentic AI for wealth management, treasury operations, client onboarding, and trading workflows under human supervision. At the same time, organisations are building marketplaces and payment infrastructure that allow AI agents to discover and purchase digital services autonomously. Together, these developments point heading toward a future where software agents become active participants in the global digital economy.

Conclusion

XDC AI Tech simplifies API monetisation by combining AI Commerce, x402 programmable payments, gasless USDC transactions, and the XDC Network. Instead of relying on subscriptions and API keys, developers can earn revenue from every API request while making their services accessible to autonomous AI agents worldwide.

What is the status of XDCDAO? (xdcdao.org appears to be offline)

Shayne Picard — Tue, 14 Jul 2026 15:55:00 +0000

While reviewing governance discussions here, I found https://www.xdcdao.org/ inoperable; it returns an HTTP 402 error, which I believe typically indicates a lapsed payment with the hosting provider. Before posting, I wanted to understand the timeline and what the outage means for any funds in the system. What I found raises questions that are broader than an unpaid hosting bill.

The timeline (per Internet Archive captures):
The site was serving normally as recently as March 5, 2026, and appears to have gone dark sometime between then and mid-July 2026. Archived captures suggest the front-end was rebuilt and redeployed at least once after the August 2024 launch. Someone was maintaining this site and then, within the last four months, it silently went offline. I am not aware of any public statement regard it's deprecation or abandonment.

What's on-chain (verifiable on xdcscan.io):
People's House deposits flow through the DaofinPlugin contract at 0xE514ca0B19B5bDBe01D60Be0879ed2cf4b2749E2, which forwards all XDC to the DAO treasury at 0xd7BF844A67954437593057b038b221485a2555C3. The record shows seven addresses joined at 10,000 XDC each between August and late 2024, alongside eight 1-XDC deposits consistent with test transactions. Three of the seven members resigned and withdrew--on October 8, November 15, and November 17, 2024--all while the site was operational. The treasury currently holds 40,138 XDC, and nothing has moved since November 17, 2024.
The transaction history shows nothing improper. Funds in equal funds out plus what remains, and the deposits have sat untouched throughout the outage. So this is largely an inquiry regarding stewardship, transparency, and the future function of XDCDAO.

An honest open question about those deposits:
I have not attempted to identify owners of the depositing addresses, and I don't want to assume facts. There are two readings of this data, and they lead to different, but equally important, conversations.
If the depositors are ordinary community members, then four people currently have 10,000 XDC each locked behind a website that no longer exists, with no published alternative for viewing or withdrawing their stake.
If, instead, most deposits came from people involved in building and testing XDCDAO, then the funds-access concern softens, but a different question sharpens: genuine community participation in the network's flagship decentralized governance initiative may have been minimal, and the DAO went dark without anyone noticing in part because there was hardly anyone positioned to notice.
I'd genuinely welcome clarification from anyone who knows which picture is accurate. Both are worth an honest conversation.

How I found the contract addresses — and why that's itself a finding:
I was unable to locate the mainnet contract addresses in any published source. I didn't see them in the launch announcement, the how-to articles here on xdc.dev, the XinFinOrg/osx-daofin repository (whose deployment records cover only Apothem testnet), the daofin-ui repository (which loads them from private build-time variables), or anywhere indexed by search engines. If they were shared somewhere (e.g. a Telegram channel, a Discord, a post I missed) I'd welcome the pointer, and I acknowledge that contract addresses are always technically recoverable on-chain by someone with the right expertise. But neither of those is user-friendly documentation.
I recovered the addresses by extracting an archived copy of the website's JavaScript bundle from the Wayback Machine and verifying candidates against the chain. (One caveat for completeness: the final version of the site's code was not archived, so I cannot rule out that later builds referenced additional contracts; but the chain confirms the 2024 member deposits remain in the treasury above.) The practical standard for a system holding member deposits should be that a depositor of ordinary technical ability can find the contracts from an official, durable source. Today, as far as I can determine, they cannot. And with the front-end dead, there may be no documented path to the two-step resign-and-claim withdrawal process.

Questions for anyone with visibility:

Who is responsible for xdcdao.org's hosting and maintenance, and is there a plan and timeline to restore it? Given the site was maintained as recently as this year, this may be as simple as a missed invoice.
Will the mainnet contract addresses and ABIs be officially published in a durable location, so depositors can verify their stake and withdraw without depending on a website?
Can anyone involved clarify the extent of genuine community participation in the People's House and Masternode Senate? How many proposals were ever put to a vote, and where can that history be viewed? I attempted to view the voting history on one matter I understood was subject to the XDCDAO vote but was not able to find anything.
There appears to be recent activity on the Apothem testnet contracts: deposits as recently as April 2026, i.e., around or after the time the production site went dark. Is development continuing? If so, what is the plan for the production governance layer: restore, relaunch, or formally wind down?

Why this matters:
An expired hosting bill is a mundane failure, not a scandal, and the on-chain record is clean. But governance infrastructure is only credible if it is reliably available and independently verifiable. A governance system that can go dark for months without public comment tells us something either about its stewardship or about its adoption; both are worth addressing openly, because both are fixable. The first steps are cheap: state plainly what XDCDAO's status is, publish the addresses and ABIs, and either restore the site or provide a withdrawal guide. Last I knew, XDCDAO was in hands more capable than my own, but I'm available to help in any way that would move things forward.

I'm genuinely interested in answers here, not blame. Tagging @0xbeny, who has been the most consistent and generous voice on XDCDAO in this forum.

WeAreXDC

TradeFi Network Goes Multichain: The RWA Analytics Layer Born on XDC Now Tracks Stellar

ruslan wing — Tue, 14 Jul 2026 13:50:36 +0000

Every maturing asset class eventually gets its Bloomberg terminal. Equities got tickers and screens. DeFi got DefiLlama. And tokenized real-world assets — the fastest-growing category in crypto — are getting theirs too.

For the XDC ecosystem, that layer is TradeFi Network. If you have read any recent analysis of XDC's RWA growth (including my own coverage of the $1.5 billion tokenized value milestone), the numbers came from TradeFi's dashboards. It has quietly become the single source of truth for what is actually happening on XDC — RWA issuance, DeFi TVL, staking, and ETPs, all in one place.

And now it is making its most significant move yet: TradeFi Network is going multichain, adding Stellar as its second tracked network — currently live in beta, with more chains on the roadmap.

In this article, I want to cover what TradeFi Network actually does, how its data methodology works, and why the Stellar expansion changes what kind of platform this is.

What Is TradeFi Network?

TradeFi Network describes itself as "cross-chain intelligence for tokenized assets." In practice, it unifies fragmented RWA, DeFi, and ETP data across networks into one dashboard — with comparable metrics, issuer coverage, and on-chain transparency.

If you have used it, you know the core surfaces:

Explore — the ecosystem overview: total tokenized value by segment, distribution charts, and per-asset-class breakdowns (Tokenized RWA, Stablecoins, Staking, ETP, DeFi).
RWA — the tokenized asset registry: issuers, individual instruments, tokenized values, and 7-day trends. This is where you can drill into issuer pages like Liqi and see nearly two thousand individual credit instruments tracked asset-by-asset.
Staking — validator counts, total staked value, estimated APY, and percentage of supply secured.
DeFi — protocol-level TVL across the network's DeFi landscape.
Pools — tracked liquidity and credit pools.

On XDC today, that adds up to a live picture of $1.6 billion in total tokenized value: $1.5B in tokenized RWAs across 1,936 assets from 14 issuers, $81.7M staked across 302 validators, plus ETP and DeFi segments. Issuers already integrated include Liqi, Mercado Bitcoin, and VERT Capital — the names driving XDC's Brazilian credit engine.

Who It Serves

TradeFi is built around three audiences, and this framing explains most of its product decisions:

Issuers — get discovered by capital. A verified on-chain presence, benchmarking against the market, and lower distribution cost than pitching investors one by one.
Investors — compare and track every RWA in one place, with on-chain validation and consistent metrics instead of scattered issuer PDFs.
The ecosystem — a single, standardized source of truth for TVL, flows, and growth, usable by builders, analysts, and journalists alike.

That third audience is the one I would emphasize. Before TradeFi, quantifying XDC's RWA activity meant stitching together issuer announcements, explorer queries, and third-party trackers that barely covered the network. Now there is one URL. That discoverability compounds: analysts cite it, articles reference it, issuers want to appear on it.

The Methodology: Labeled Data, Not Just Big Numbers

The RWA analytics space has a credibility problem: headline "tokenized value" numbers often blend incompatible things. TradeFi's answer is a published, versioned data methodology (currently v2026-06) with a five-tier source taxonomy:

Source Type	What It Means
On-chain indexed	Metrics derived from publicly verifiable on-chain state and transactions
Partner API	Structured data supplied directly by issuers and licensed product vendors
Open data	Established public market and reference data providers
TradeFi curated	Issuer, asset, and contract metadata verified and maintained by TradeFi
Computed	Aggregates and derived indicators built from the sources above

Every aggregate displays its metric label and an "as of" timestamp. Cross-network figures carry an explicit methodology disclaimer, because — as the methodology page itself puts it — totals across networks respect network-specific definitions and should not be read as a single homogeneous pool.

TradeFi also names its data infrastructure partner: Allium, the blockchain data platform used by major institutions for indexed on-chain data. That matters for anyone consuming these numbers downstream — the pipeline is not a black box.

This is the unglamorous work that separates an ecosystem marketing page from an analytics platform institutions can actually cite. Publishing what you measure, how you measure it, and where the data comes from is table stakes in traditional finance. It is still rare in crypto.

The Big Move: Stellar Goes Live in Beta

Until now, TradeFi was an XDC-native platform. That just changed. The Stellar dashboard is live in beta, tracking curated Stellar stablecoins, tokenized funds, and the 21Shares AXLM ETP — with RWA, DeFi, and ETP metrics and per-asset source attribution on detail pages.

Why Stellar as the second chain? Because in RWA terms, Stellar is one of the most serious networks in existence:

Stellar's tokenized RWA value recently crossed $3 billion, roughly 300% growth from early 2025.
It hosts Franklin Templeton's BENJI — the first US-registered mutual fund to use a public blockchain as its official system of record, live on Stellar since 2021 and representing over $650 million on the network, with the broader BENJI suite at ~$2B across nine chains.
Ondo's USDY, Spiko's money market funds, and WisdomTree's tokenized fund family round out a deep institutional asset stack.
Like XDC, Stellar's identity is payments, settlement, and regulated assets — not speculative DeFi.

That last point is the strategic tell. TradeFi is not chasing every chain; it is building coverage of settlement-and-RWA-first networks — the chains where tokenized value means credit instruments and registered funds, not looped leverage. XDC and Stellar are natural siblings in that thesis.

What Multichain Actually Unlocks

The obvious win is coverage. The deeper win is comparability. With XDC and Stellar side by side under one methodology, questions that used to require three browser tabs and a spreadsheet become one toggle:

How does XDC's issuance-driven Brazilian credit stack compare to Stellar's registered-fund stack?
Which network is attracting new issuers, and in which asset classes?
How do staking economics, DeFi depth, and ETP presence differ across RWA-focused chains?

For XDC specifically, this is a confidence play, not a dilution. Putting XDC's $1.5B RWA figure next to Stellar's numbers, under the same labeling rules, says: we are comfortable being measured against the best RWA chains in the industry, on neutral instruments. Ecosystems that only publish their own scoreboard invite skepticism. Ecosystems that build the league table invite comparison — and comparison is what institutional allocators actually do.

The homepage already signals "more chains coming soon." If TradeFi executes, the platform born as XDC's ecosystem showcase becomes something bigger: a specialized multichain RWA intelligence layer, in a market where the incumbents each cover only part of the picture that RWA-first networks care about.

Point of Comparison: TradeFi Network vs DefiLlama

The easiest way to understand what TradeFi adds is to look at the same network through both lenses.

Open DefiLlama and look up XDC: you will see roughly $7.5M in DeFi TVL across ~19 protocols. Open TradeFi's Explore dashboard: $1.6 billion in total tracked value. Both numbers are correct. They are measuring completely different things — and that gap is precisely the blind spot TradeFi exists to close.

DefiLlama is the gold standard for what it does: open-source, community-maintained adapters tracking DeFi protocol deposits, stablecoins, fees, and volumes across hundreds of chains. But its lens is protocol TVL — capital deposited into DeFi smart contracts. Tokenized real-world assets mostly do not live there. A Liqi receivables certificate or a VERT private credit pool is issued to investor wallets under regulated structures; it never touches a lending pool or DEX, so it is invisible to a TVL tracker. On a DeFi-first chain that distinction barely matters. On an RWA-first chain like XDC, it hides 99.5% of the economy.

Here is the side-by-side:

Dimension	DefiLlama	TradeFi Network
Primary lens	DeFi protocol TVL (capital in smart contracts)	Full tokenized-value view: RWA + stablecoins + staking + ETP + DeFi
XDC as it appears	~$7.5M (19 protocols)	$1.6B total tracked value
Issuer-level RWA registry	No — aggregate categories only	Yes — 14 issuer profiles with dedicated pages (e.g. Liqi with 1,800+ instruments)
Individual asset granularity	Protocol-level	Instrument-level: 1,936 individual tokenized assets tracked
Issuer-supplied data	No — on-chain adapters only	Yes — Partner API feeds directly from issuers, labeled as such
Staking dashboard	Not per-network validator economics	$81.7M staked, 302 validators, 15.1% of supply, est. APY
ETP tracking	Not covered	Covered — XDC ETP ($9.4M) and 21Shares AXLM on Stellar
Source labeling	Adapter code (open-source, technical)	Five-tier taxonomy on every metric + "as of" timestamps
Verified issuer identity	No	Verified listings backed by identity and on-chain data checks
7-day / trend view per asset class	DeFi-centric charts	Per-segment trends incl. RWA (+41.14% 7D at time of writing)

Two data points in that table simply do not exist anywhere on DefiLlama:

The instrument-level registry. Nobody else shows you 1,936 individual tokenized credit instruments, mapped to 14 verified issuers, with per-asset source attribution. That granularity is what a credit analyst or allocator actually needs — "XDC has RWAs" is a narrative; "here are Liqi's 1,800 active receivables certificates, sourced via issuer API" is due diligence material.
The hybrid data model. DefiLlama is deliberately on-chain-only. TradeFi combines on-chain indexing (via Allium) with Partner API data supplied directly by regulated issuers — because in RWA, the on-chain token is only half the story; the issuer's books are the other half. TradeFi labels which is which, so you know what you are reading.

To be fair to DefiLlama: it covers hundreds of chains, its fee/volume dashboards are unmatched, and for pure DeFi analysis it remains the reference. The point is not that one replaces the other — it is that RWA-first networks were being measured with a DeFi-first ruler, and chains like XDC and Stellar looked artificially small as a result. TradeFi is the ruler built for the actual asset class.

The Commercial Layer: How the Platform Sustains Itself

TradeFi is also building a real business around the data, with three clearly separated offerings:

Verified Listing — a verified badge on issuers and assets, backed by identity and on-chain data checks, with enhanced profile data and priority indexing.
Featured Placement — sponsored visibility on the market dashboard, always explicitly labeled "Sponsored."
Data & API Access — early-access programmatic endpoints for TVL, issuers, and assets, with CSV/JSON exports.

The design choice worth noting: paid placement is always labeled, and "Verified" reflects data checks, not endorsement. Keeping the editorial/commercial line explicit is exactly what a data platform needs to stay citable. And the API tier is the one I am most interested in as a builder — programmatic access to issuer-level RWA data opens the door to integrations, dashboards, agents, and research tooling built on top of TradeFi rather than around it.

Why This Matters for XDC

Three takeaways from where I sit:

1. XDC's growth is now independently legible. A $1.5B RWA figure means more when it lives on a platform with published methodology, source attribution, and a named data partner — one that also tracks a $3B competitor chain under the same rules.

2. The analytics layer is becoming an ecosystem export. XDC has always exported standards work (trade finance, ISO 20022 alignment). TradeFi extends that pattern: infrastructure incubated in the XDC ecosystem, now serving the broader RWA market — with XDC as the primary, most deeply covered network at its core.

3. Data is a distribution channel. Every analyst who opens TradeFi to check Stellar's numbers sees XDC's next to them. For a network whose story is issuance volume and asset count rather than token speculation, that ambient visibility is worth more than any campaign.

The RWA market is projected in the trillions by every major forecaster. Markets that size do not run on screenshots and Telegram announcements — they run on data infrastructure. TradeFi Network started by giving XDC its scoreboard. With Stellar live in beta and more chains coming, it is now building the scoreboard for the category.

Explore the platform: tradefi.network · XDC dashboard · Stellar dashboard (beta) · Data methodology. Figures as of July 2026. Not investment advice.

$1.5 Billion On-Chain: How XDC Network's Tokenized Value Just Rewrote Its Own Growth Curve

ruslan wing — Mon, 13 Jul 2026 10:37:18 +0000

If you have been watching the XDC ecosystem dashboards over the past week, you probably did a double take. According to TradeFi Network, the live analytics layer for XDC's RWA and ecosystem activity, tokenized Real-World Assets on XDC Network now stand at $1.5 billion, up +41.14% in just seven days. Total tokenized value across all segments, including stablecoins, now sits at $1.6 billion.

To put that in perspective: XDC entered 2026 with roughly $717 million in tokenized assets. It crossed $1.1 billion in early July. And within a single week, it added another ~$400 million on-chain. This is not a slow grind anymore. This is a step change.

In this article, I want to break down what is actually inside that $1.5 billion, where the growth is coming from, and why the composition of the number matters more than the number itself.

The Snapshot: XDC Ecosystem by the Numbers

Here is the current picture from the TradeFi Network Explore dashboard:

Asset Class	Value	Share	Count	Trend
Tokenized RWA	$1.5B	93.8%	1,936 assets / 14 issuers	+41.14% (7D)
Staking	$81.7M	5.2%	302 validators	Est. 10.0% APY*, 15.1% of supply
ETP	$9.4M	0.6%	1 ETP	+0.35% daily
DeFi	$7.5M	0.5%	19 protocols	—

When stablecoins are separated out in the distribution view, the split looks like this: Tokenized RWA 85.6%, Stablecoins 8.1%, Staking 5.2%, ETP 0.6%, DeFi 0.5% — against a total tokenized value of $1.6 billion.

(Per the dashboard methodology, figures combine on-chain balances and issuer-reported tokenized amounts, and totals may include some matured or closed instruments still shown in source data. APY is estimated, not guaranteed.)

Two things jump out immediately.

First, this is an RWA-dominated network by an overwhelming margin. Nearly 94 cents of every tracked dollar on XDC is a tokenized real-world asset, not speculative DeFi capital. Compare that with most Layer 1s, where TVL is dominated by circular DeFi leverage, and you see how structurally different XDC's on-chain economy is.

Second, the asset count is the underrated headline: 1,936 individual active assets from 14 issuers. This is not one whale fund inflating a chart. It is thousands of discrete instruments — receivables, credit rights, corporate bonds, commodity tokens — being issued, settled, and retired as part of live financial workflows.

The Growth Curve: From $717M to $1.5B in Six Months

Let's trace the trajectory, because the acceleration is the story:

Period	Tokenized Value on XDC	Milestone
2023	~$105M	Early RWA sector baseline
January 2026	~$717M	VERT Capital pools at ~$369M (53%), Liqi at ~15%, ComTech Gold ~$15M
Early July 2026	~$1.1B	~$860M of it in credit assets (corporate bonds, trade receivables)
Mid-July 2026	$1.5B	+41.14% in 7 days; 1,936 assets across 14 issuers

That is roughly a 2x in six months, with almost 40% of the total added in the most recent week alone. Growth like that in the RWA segment does not come from price appreciation — these are largely credit instruments and dollar-denominated pools. It comes from new issuance hitting the chain.

What's Actually Driving the Surge

1. Brazilian Credit Is the Engine

The single biggest theme behind XDC's RWA growth is Brazil. Two issuers anchor it:

VERT Capital — the Brazilian asset manager announced plans to tokenize up to $1 billion in debt and receivables (corporate debt, agribusiness receivables, structured credit) on XDC over a 30-month window. Its USDC-denominated private credit pools were already the majority of XDC's RWA value by January 2026 at ~$369M, and the continued drawdown of that $1B mandate is a primary contributor to the current numbers.

Liqi Digital Assets — the São Paulo fintech that partnered with XDC in April 2025 with a target of $500 million in RWA issuances. Liqi crossed $100M tokenized on XDC by early 2026, and as of its TradeFi Network issuer page, Liqi alone accounts for hundreds of millions in tokenized value across 1,800+ individual active assets, sourced directly via Liqi's API. Liqi's cumulative tokenized operations passed BRL 1.2 billion by early 2026 — including BRL 600 million in the first two months of the year — with a stated goal of exceeding BRL 5 billion across 2026.

What makes the Liqi number so interesting is its shape: it is not one large fund, it is nearly two thousand small-and-medium instruments. That is what automated securitization infrastructure looks like when it is running at scale — tokenized credit rights (TIDCs), receivables certificates, and FIDC-adjacent structures being issued and settled continuously.

2. Regulatory Tailwinds Made Brazil the Beachhead

None of this happens without regulatory clarity. Brazil's Central Bank finalized its stablecoin framework (effective February 2026), and the CVM's sandbox-friendly posture toward tokenized securities gave issuers like Liqi and VERT validated, regulated structures to work within. Meanwhile, in the US, the GENIUS Act gave regulated stablecoins like USDC — which now settles a large share of XDC's RWA pools natively — institutional legitimacy.

The result is a clean pipeline: regulated Brazilian credit → tokenized on XDC → denominated and settled in regulated stablecoins → visible on public dashboards. Every link in that chain matured in the last 18 months.

3. Stablecoin Liquidity Underpins Settlement

Stablecoins now represent 8.1% of tracked value (~$130M+) on XDC, anchored by native USDC. This is not idle capital — it is the settlement leg for the credit pools above. RWA issuance and stablecoin liquidity grow together, because tokenized credit needs an on-chain cash instrument to settle coupon payments, redemptions, and primary subscriptions.

4. The Long Tail: Commodities, ETPs, and DeFi

ComTech Gold continues to secure ~$15M in tokenized gold, giving XDC a commodity-backed RWA presence.
The network's first ETP ($9.4M) gives traditional investors regulated, exchange-listed exposure.
DeFi TVL ($7.5M across 19 protocols) remains small in dollar terms, but that is arguably the next frontier: connecting tokenized RWA collateral to on-chain lending and liquidity — the "second act" for every dollar already on the network.

Staking: The Quiet Security Story

While the RWA number grabs headlines, the staking dashboard tells its own story: $81.7M staked across 302 validators, representing 15.1% of supply, at an estimated 10% APY.

For a network settling $1.5B in institutional credit, validator economics matter. A growing validator set (including institutional entrants) and a meaningful staked supply are what make XDC credible as settlement infrastructure rather than just an issuance venue. As a masternode participant myself, I would argue the staking layer is the collateral behind the RWA layer — the economic security budget that institutional issuers are implicitly relying on.

Why the Composition Matters More Than the Headline

It is worth being precise about what "$1.5B TVL" means on XDC, because it is a different animal from DeFi TVL on most chains:

It is issuance-driven, not price-driven. Credit instruments and USDC-denominated pools do not 2x because a token pumped. They grow because new real-world obligations were originated, structured, and brought on-chain.
It is diversified across 1,936 assets and 14 issuers. Concentration risk is falling over time. In January, VERT alone was 53% of RWA value; the base has since broadened considerably.
It is productive capital. These are yield-bearing credit assets tied to working capital, agribusiness, receivables, and corporate debt — the "boring" instruments that actually move economies.
It is transparent. The entire point of platforms like TradeFi Network is that anyone — investor, regulator, competitor — can audit the composition in real time. That discoverability is itself an institutional feature.

The honest caveats: dashboard totals blend on-chain balances with issuer-reported amounts, some matured instruments may linger in source data, and a single large pool drawdown can move weekly percentages sharply in either direction. A +41% week is extraordinary, but weeks like that cut both ways — sustainable growth will show up in the quarterly trend, not any single candle.

The Bigger Picture: XDC's Thesis Is Playing Out

XDC Network has spent years positioning itself as the chain for trade finance and RWA — ISO 20022 alignment, MLETR compatibility, sub-$0.01 fees, ~2-second finality, and an XDPoS validator model designed for institutional participation. For most of that time, the thesis ran ahead of the numbers.

That gap is closing fast. With ARK projecting the RWA market at $11 trillion by 2030 and BofA at $16 trillion+, the question was never whether tokenization would scale — it was which networks would host it. Ethereum still dominates overall RWA share, but XDC's growth demonstrates something specific: for high-frequency, high-volume credit settlement — thousands of small instruments, not one big fund — fee-stable, fast-finality infrastructure wins. A $20 gas spike destroys the economics of settling a $5,000 credit installment. On XDC, that trade costs a fraction of a cent.

$1.5 billion is a milestone, not a destination. The pipelines already announced — VERT's remaining $1B mandate, Liqi's BRL 5 billion 2026 target, the RWA Accelerator cohort with Plug and Play — suggest the current number is a waypoint on a steeper curve.

The era of blockchain pilots on XDC is over. This is production.

Shipping a paid x402 API on XDC: NodeLens, a node-intelligence provider

Salomon Morales — Sat, 11 Jul 2026 20:05:33 +0000

I recently built and shipped a live provider on the XDC AI Marketplace. A REST API that offers XDC node and network intelligence per-call, settled in USDC via x402. This post covers what it does, how the pattern works at a high level, and the full endpoint list with working commands, in case it's useful to the next person building a provider on XDC.

Why

The XDC masternode staking contract locks 10M XDC for a 30-day unbonding period after resignation, calculated against network block production. Like any live network, real-world block timing has natural variation. I wanted a way to see that clearly and precisely in real time, rather than relying on the static assumption alone — so I built NodeLens to surface real, current unlock timing alongside network congestion and per-node performance data, all served as a paid API.

Stack

Node.js / Express — API server
XDC RPC — direct on-chain reads against the validator contract for candidate status and stake data
XDCScan API — mined-block history for performance scoring
x402 — HTTP payment protocol, settled via XDC AI's facilitator infrastructure
Claude (Anthropic) — powers a separate monitoring agent (more below)
Vercel — API hosting
Railway — monitoring agent hosting

How the payment flow works

The x402 pattern, at a high level:

Agent requests the endpoint with no payment
Server responds with a payment challenge — amount, asset, recipient, network
Agent signs a gasless USDC authorization for the exact amount
Agent resends the request with the signed payment attached
Server verifies and settles the payment through XDC AI's facilitator, then returns the data along with the on-chain transaction hash as proof

No gas token required on the caller's side — settlement is sponsored. No invoicing, no manual reconciliation. The transaction hash is the receipt.

Here's a live example — a real, paid call to the network congestion endpoint on NodeLens, settled on XDC mainnet:

Transaction: 0x636ba2cdede35731f8f8b73f45f7da4d28779d6c3cfa7e0047f74b898718c5b3

$0.01 USDC, requested, paid, and settled autonomously — no manual steps, confirmed on-chain within seconds.

The monitoring agent

Alongside the API, I built a second service — NodeLens Watchdog — that runs on a schedule, pulls a full snapshot from the NodeLens API (network congestion, unlock timing, and status for a configured list of node addresses), and has Claude evaluate the snapshot against configurable alert thresholds. If something crosses a threshold, it fires a Telegram message and/or webhook with a structured summary and recommendation. It's a small demonstration of stacking an LLM-driven decision layer on top of a paid data API — directly reusable for anyone building an agent that needs to act on x402 data, not just fetch it. This part has not been made public yet as I am testing it but will release soon. Stay tuned!

Full endpoint list

Base URL: https://nodelens-api.vercel.app

Method	Path	Price	Description
GET	`/v1/network/congestion`	$0.01	Rolling block-time averages (1h/24h/7d/30d) + congestion tier
GET	`/v1/network/unlock-risk`	$0.03	0–100 unlock predictability score + best/expected/worst unlock ETA
GET	`/v1/network/epoch`	$0.01	Current epoch, blocks to next boundary, reward schedule
GET	`/v1/node/:address/unlock-eta`	$0.05	Real unlock timing for a specific node if resigned now
GET	`/v1/node/:address/performance`	$0.05	Block production score/grade + block-production analysis
GET	`/v1/node/:address/status`	$0.02	Candidate status, stake amount, slashing flag
POST	`/v1/node/batch-status`	$0.25	Status for up to 20 node addresses in one call

Example responses from Claude XDCAI's integration

Example calls via the XDC AI CLI:

# Network congestion
npx xdcai call https://nodelens-api.vercel.app/v1/network/congestion

# Unlock timing outlook
npx xdcai call https://nodelens-api.vercel.app/v1/network/unlock-risk

# Epoch info
npx xdcai call https://nodelens-api.vercel.app/v1/network/epoch

# Specific node unlock timing
npx xdcai call "https://nodelens-api.vercel.app/v1/node/0xYourNodeAddress/unlock-eta"

# Specific node performance
npx xdcai call "https://nodelens-api.vercel.app/v1/node/0xYourNodeAddress/performance"

# Specific node status
npx xdcai call "https://nodelens-api.vercel.app/v1/node/0xYourNodeAddress/status"

# Batch status for a node fleet
npx xdcai call https://nodelens-api.vercel.app/v1/node/batch-status \
  --method POST \
  --data '{"addresses": ["0xAddr1", "0xAddr2", "0xAddr3"]}'

Every response includes the settlement txHash, verifiable on XDCScan. XDC Network's chain truth, not a dashboard claim. Go try it and let me know what other information regarding your node(s) you would like to see.

The Settlement Economy: Why Agent-to-Agent Payments Are Web3's Next Trillion-Dollar Category

Rushabh Parmar — Wed, 08 Jul 2026 13:02:12 +0000

The Token Economy

When people talk about AI today, tokens are king. Inference tokens — the raw units of compute an LLM burns through per query — have become the industry's default growth metric. Labs report monthly tokens processed. Analysts compare model adoption by token volume. Investors size the AI market by extrapolating token curves.

It's an understandable obsession. Tokens are legible: one number, trending up, easy to explain to anyone regardless of technical background. More users? Tokens go up. Reasoning models replacing single-pass completions? Tokens go up. Agents working in the background for hours instead of seconds? Tokens go up.

But tokens only measure half the picture. They tell you how much an agent thought. They tell you nothing about what happened when that agent tried to act — to pay for an API call, execute a trade, settle a bill with another agent, or prove that a piece of work it did was real and verifiable. That second half of the picture is where a much larger, much less discussed market is forming: the Settlement Economy.

The Settlement Economy

Over the last two years, AI agents have moved from answering questions to taking actions with economic consequences: querying paid APIs, executing on-chain trades, coordinating multi-agent workflows, and increasingly, paying each other directly without a human in the loop. Every one of those actions needs to be settled — value has to move, and both sides need proof that it moved correctly, cheaply, and irreversibly.

This is a fundamentally different problem than inference. An LLM call is stateless: you send tokens in, you get tokens out, and if it's wrong you just try again. A settlement is not stateless. If an agent pays for an API call and the payment fails, double-spends, or settles ambiguously, the damage is real and often can't be undone. Agents transacting autonomously need a settlement layer that behaves the way a bank wire behaves — final, auditable, and cheap enough to execute thousands of times a day — not the way a probabilistic model output behaves.

This is precisely the gap that emerging agent-payment standards are built to close. Protocols like x402 let an agent hit a paywalled endpoint, receive a "payment required" response, and settle the fee on-chain in the same request cycle — no subscriptions, no human checkout flow, just a machine paying a machine for a unit of work. This only works if the underlying chain gives you deterministic, low-cost finality every single time, because an agent making ten thousand of these calls a day cannot tolerate variable gas, unpredictable confirmation times, or a fee structure that eats the margin on a $0.001 API call.

This is where a purpose-fit settlement layer starts to matter as much as the model sitting on top of it.

A concrete example: XDC's AI framework as a settlement layer

Take the XDC AI framework being built out around XDC Network as a working example of what this looks like in practice, rather than in theory.

XDC AI is the clearest instance — payment rails built specifically so an agent can pay for APIs per call in USDC, with no gas, no seed phrase, and no credit card. An agent logs in with an email, gets a deterministic custodial XDC wallet, funds it with USDC, and from there the x402 loop runs itself: hit an endpoint, get a 402, sign an EIP-3009 authorization off-chain, get billed the exact price, get the result. A relayer covers the XDC gas, so the agent only ever reasons about one unit — USDC spent per call — the same way it reasons about tokens spent per inference. It ships as both an MCP connector (so Claude or ChatGPT can log in, check balance, and pay just by being asked) and a CLI for terminal agents like Claude Code, Cursor, and Codex. The marketplace already spans use cases from agent-to-agent transfers and stablecoin swaps to booking a hotel, ticketing a flight, or ordering a pizza — real-world commerce settled per call, not per subscription. This is the Settlement Economy with the plumbing exposed: not a thesis about what agent payments could look like, but a live 402 loop closing on-chain today.

Around that core payment rail sits the rest of the framework:

The XDC Developer Copilot — a RAG-based assistant split into an RPC/Integration agent and a Smart Contract/Dev agent — exists specifically because developers building agents need fast, accurate answers about how to integrate with a chain that has real quirks Legacy Type 0 transactions, no EIP-1559, a 12.5 gwei minimum gas floor). Those quirks aren't trivia; they're exactly the kind of deterministic behavior an autonomous agent needs in order to predict its own transaction costs before it acts.
A standalone x402 pay-per-call API server running on XDC is a further live instance of agent-to-agent settlement: a machine caller hits an endpoint, gets billed per call, and pays through an ERC-3009 receiveWithAuthorization flow rather than a subscription — the settlement-not-inference pattern described above, running outside the XDC AI product too.
ERC-8004 "Trustless Agents", deployed and tested on XDC Apothem Testnet, addresses the other half of the settlement problem: not just moving value, but proving which agent did the work and that its output can be trusted by another agent or contract downstream. Settlement without verifiable identity is just a payment; settlement with it is the beginning of an actual agent economy.

None of these pieces are exotic. They're the plumbing. But plumbing is exactly what the Settlement Economy is made of — not a single breakthrough model, but thousands of small, boring, correctly-executed transactions between agents that never involve a human clicking "confirm."

Why this compounds

Just as token growth compounds from multiple directions at once — more users, more reasoning steps, longer agent horizons — settlement volume compounds from its own stack of forces:

More agents move from advising humans to acting on their behalf, and every action has a settlement attached to it.
Pay-per-call models (x402 and similar) replace subscriptions, turning what used to be one settlement a month into potentially thousands a day.
Multi-agent systems mean agents increasingly pay other agents, not just APIs — a Dev Copilot querying a pricing oracle, a swap agent settling with a liquidity router, a monitoring bot paying a data agent for a whale alert feed.
As agents take on longer-horizon, higher-stakes tasks, the cost of a failed or ambiguous settlement rises, pushing serious builders toward chains that guarantee deterministic finality rather than "usually works" finality.

Every one of these forces pushes in the same direction: more settlements, of higher value, requiring more certainty per transaction. That's a very different growth curve than "more tokens," and it's one most of the market isn't tracking yet — largely because, like the earlier shift toward data-centric model improvement, there's no clean public number for "on-chain agent settlements per day" the way there is for tokens processed. That will change as agent-payment volume becomes something builders start reporting the way labs report token counts today.

Settlements will be king

Tokens measure how much an AI thought. Settlements measure how much an AI did — and did in a way that another party, human or machine, can trust and verify without walking it back. As agents graduate from chatbots to autonomous economic actors, the chains and frameworks that make settlement fast, cheap, and provably final — XDC AI's payment rails, the Developer Copilot's RPC layer, the Trustless Agents standard, the swap and monitoring agents — stop being infrastructure footnotes and start being the actual substrate the agent economy runs on.

Sometime soon, when people talk about what's driving AI's next leg of growth, it won't only be about how many tokens a model burned. It'll be about how many settlements its agents closed — and who they trusted to close them.

XDCAI : Agents can now invoice each other on XDC <> stateless x402 invoices + chain-truth payment verification

Abilash Senthilkumar — Tue, 07 Jul 2026 21:31:38 +0000

This week the XDC AI beta group debugged two payment mysteries by hand. In one, an agent paid for a call and got a 404 back. In another (from my last post), a payment settled on-chain while the provider reported "charged: unknown" and the wallet history said "failed." Both times, resolving it took humans, screenshots, and someone manually checking the explorer — and in one memorable moment, the source of truth was literally "the payment went through, as per Claude."

Three layers, three answers. Only one layer never lies: the chain.

So we shipped two tools that make the chain the first place agents ask — both live now on xforty Chain Tools via the XDC AI marketplace.

1. `payment/verify` — the answer to "charged: unknown"

npx xdcai call "https://api.xforty.xyz/api/x402/payment/verify?tx=0x…"

Give it any transaction hash, get back the chain-truth verdict: did USDC actually move, how much, from whom, to whom, in which block, at what time. $0.002 per call. This is the one-liner that would have resolved both of this week's debugging threads instantly — no screenshots, no "try calling it again," no trusting anyone's dashboard, including ours.

Verified against a live settlement:

{ "settled": true, "block": 104652620, "timestamp": "2026-07-07T21:04:42Z",
  "usdcTransfers": [{ "amountUSDC": "0.020246",
    "from": "0x0094ce…254d", "to": "0xb0f9…033b" }] }

2. Stateless invoices — agents billing each other

The bigger piece: any agent can now mint an invoice that any other agent can pay.

npx xdcai call "https://api.xforty.xyz/api/x402/invoice/create" \
  --method POST \
  --data '{"amountUSDC":"0.02","payTo":"0xYourAddress","memo":"design work"}'

Back comes a one-time x402-payable URL. The payer's agent calls it, gets a standard 402 challenge with the invoice's exact terms, pays through the normal flow — settlement goes directly to the invoice's payTo (any address you choose, not ours), gasless as always on these rails. A free status endpoint answers "has it been paid?" at any time.

Two design decisions worth explaining:

There is no database. The invoice is a signed token — amount, recipient, memo, and validity are HMAC-signed into the invoice ID itself. We can't lose your invoice, corrupt it, or edit it, because we don't store it.

The chain is the ledger. How do you match an on-chain USDC transfer to a specific invoice when EIP-3009 has no memo field? The invoice's amount carries a per-invoice fingerprint in its lowest digits — a $0.02 invoice becomes, say, 0.020246 USDC. The status endpoint scans USDC transfer logs for that exact amount to that recipient within the validity window. Payment attribution from pure chain data — no bookkeeping to trust, ours included.

We ran the full loop with real money before writing this: mint → agent pays the invoice → settlement on-chain → status flips to paid from the chain scan alone.

The pattern underneath

Both tools follow the same principles from our first writeup, which this week's incidents keep validating: validate before settling (bad input must be rejected before money moves — good to see LendWatch adopt the same fix), settle before responding (the agent should never wonder whether it paid), and never charge for your own failures. Agentic payments don't need more trust — they need less of it, replaced by verification.

What's next

These endpoints are the retail edge of a bigger piece we're building: guard — spend policies, human approvals, audit trails, and automatic settlement reconciliation for agent wallets, running on this same chain-truth engine. If your agent moves real money and you'd sleep better with limits and a kill switch, come talk.

xforty · xforty.xyz · api.xforty.xyz · npx xforty · built on XDC AI's rails

I tested XDC AI's x402 marketplace as both payer and provider. Here's everything I found

Abilash Senthilkumar — Mon, 06 Jul 2026 09:59:45 +0000

Yesterday I put XDC AI, the new x402 payments marketplace on XDC through a full test from both sides: as an agent paying for API calls, and as a provider building payable endpoints from scratch. This post is the complete log: what worked, what broke, and what we shipped because of it. Every claim links to a mainnet transaction.

TL;DR: the rails genuinely work — email → wallet → first paid API call in under 10 minutes, gasless. We shipped xforty Chain Tools as a live provider on those rails, found one serious settlement-reconciliation gap (with a double-charge repro), and are upstreaming XDC support to the official x402 SDKs.

The consumer side: paying for data as an agent

Onboarding is the smoothest I've seen in crypto: email OTP → a wallet exists → fund it with USDC → your agent can buy things. No seed phrase, no gas token (their relayer sponsors gas via EIP-3009).

My agent's first purchase is to fetch live DeFi rates from DeFi Watch, $0.005:
https://xdcscan.com/tx/0x54451b1ca87cd23c0692752e43351e4c8c0b4c427448798a96ea4ccfa6d1144d

Also genuinely good: payees are allowlisted, and approving a new recipient requires a browser login an automated agent cannot expand its own spending surface. That's real security design, not an afterthought.

The provider side: getting paid as an API

Here's where it got interesting. The official x402 npm packages (x402@1.2.0, @x402/core@2.17.0) don't include the xdc network in their registries yet, so there's no SDK path. I implemented the 402 flow from scratch against the live facilitator: challenge → X-PAYMENT (EIP-3009 authorization) → /verify → serve → /settle.

It interoperated with XDC AI's production CLI on the first try. The proof is my agent wallet paying my own endpoint, settled on-chain:
https://xdcscan.com/tx/0x381f791d13a2d094c506df20fca9d952b1f3aef8a46aa9fd319898cb14b42051

Two design choices I'd recommend to every provider:

Settle before responding the agent should never be in doubt about whether it paid.
Never charge for stale data. Public XDC RPCs load-balance across replicas, and I caught one serving blocks ~5 days old. Our endpoints validate the chain head's own timestamp per request and refuse to charge if freshness can't be proven.

The finding that matters: a three-way settlement disagreement

One $0.10 screening call produced the most instructive failure I've seen on agentic rails:

The service completed, but settlement timed out → the provider returned 502 with charged: "unknown".
My wallet history recorded the payment as "failed."
On-chain, it had actually settled: https://xdcscan.com/tx/0xf5413a271ec6626cd719a7d9d41cda20321e4c7fe53e90fdca9f7fb369e89232
Following the documented recovery ("retry — stored result, no recharge"), the retry carried a fresh authorization and charged again: https://xdcscan.com/tx/0xb272b13e641893985ed5874b420188fa1a6b9fbe6c115573be93ad7c97bae58d

One call. $0.20 paid. Three layers, three different answers — and the chain was the only honest one. To be clear: the provider's idempotent-retry instinct is right (dedupe just needs to key on the request, not the authorization), and the root cause looks like relayer/settle-window timing. Easy platform wins: history entries carrying the tx hash + chain-confirmed status.

But the general lesson is bigger than the bug: agentic payments need a reconciliation layer — something that answers "did money actually move?" from chain truth, not from whichever service timed out first. When agents spend autonomously at machine speed, "charged: unknown" is not an acceptable state.

Smaller notes

The @xdctaskman/x402-server package referenced on the providers page 404s on npm (hence the hand-rolling).
404s on paid routes return HTML error pages; agents would prefer JSON.
Catalog entries don't carry input schemas yet, so agents call-and-fail to learn parameters.

What we're building because of all this

xforty Chain Tools (live now): network stats + a contract inspector — pre-flight safety checks agents can buy for cents. Free taste: npx xdcai call https://api.xforty.xyz/api/x402/gas-price
The provider kit (npx xforty): everything I hand-rolled, packaged, so the next provider ships in minutes — plus an upstream PR adding xdc to the official x402 SDKs.
The trust layer: spend policies, human approvals, audit trails, and settlement reconciliation for agent wallets — the piece this testing convinced me the whole ecosystem needs before real money rides these rails.

The payment rails are XDC AI's, and they work — that's the headline. We're building what gets paid, and what keeps agent spending safe.

xforty · xforty.xyz · api.xforty.xyz · npx xforty

[Informative] June Insights: Key Highlights and Developments from Plugin’s Journey

Pooja Balaji — Fri, 03 Jul 2026 18:43:53 +0000

New month, new step closer and connected, Here's what the Plugin team has been working on. Expanding its data feed offerings and strengthen its presence within the Web3 and AI ecosystem. From new market data integrations to real-world industry engagement, here's what's been happening across the Plugin Decentralized Network.

📰 News

📊 ETF Price Feeds

Plugin has expanded its data feed offerings with the launch of Exchange-Traded Fund (ETF) price feeds on the Plugin Network on XDC.

ETFs are investment funds that hold a basket of assets, such as stocks or bonds, and trade on exchanges like individual stocks. By making ETF market data available on-chain, Plugin enables developers and DeFi protocols to access reliable pricing information for building financial applications that bridge traditional and decentralized markets.

Explore ETF Price Feeds : https://feeds.plugin.global/

🌉 Bridging Web2 and Web3

Plugin recently co-hosted an X Space discussion on Bridging Web2 and Web3, bringing together speakers from across the Web3 ecosystem to share their perspectives on connecting traditional technologies with decentralized networks.

The discussion featured valuable insights and experiences on the opportunities and challenges of Web2 and Web3 integration. As part of the conversation, the Plugin team also shared updates on its progress in cross-chain interoperability, highlighting that seamless communication between blockchain networks is just as important as bridging traditional and decentralized systems. Together, these advancements are helping build a more connected and interoperable digital ecosystem.

Listen to the X Space recap: https://x.com/GoPlugin/status/2071895851643867348

🤝Plugin at SPARK AI Innovation Park Event

The Plugin team recently attended the SPARK AI Innovation Park event, which brought together industry leaders and technology experts to discuss the latest developments in AI and emerging technologies.

The event provided an opportunity to connect with professionals, exchange ideas, and introduce attendees to Plugin's decentralized network and Web3 solutions. The team also shared how Plugin is leveraging AI-powered sentiment analysis within its data feeds to deliver real-time insights, highlighting the role of AI in advancing decentralized infrastructure.

🍽️ Food for Thought

Real-world adoption of blockchain doesn't happen through speculation, it happens through dependable infrastructure that businesses and developers can trust. Every new data feed, every industry conversation, and every real-world use case brings Web3 one step closer to functioning as seamlessly as the systems we rely on every day. The networks that succeed will be the ones that make trust invisible, built so reliably into the system that no one has to think about it.

🧠 Plugin Quiz :

What does "Proof of Reserve" mean in the context of decentralized networks?

👉 Reply with your answer in the comments!

The first test report of new PRC

Daniel Liu — Wed, 01 Jul 2026 23:05:50 +0000

Only a few JSONRPC APIs have been tested.

new RPC:

# mainnet
RPC="https://new.xdcrpc.com/"

# testnet
RPC="https://apothem.xdcrpc.com/"

Findings

does not support module XDPoS
supports some features of geth v1.17.x, eg:
- eth_getTransactionByHash returns timestamp in response
bug: eth_simulateV1 crash on mainnet rcp
a lot of methods are not in the public allowlist on testnet rpc

Module eth

Method eth_config

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_config",
  "params": []
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "current": null,
    "next": null,
    "last": null
  }
}

tesnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32004,
    "message": "method 'eth_config' is not in the public allowlist"
  }
}

Method eth_getBlockByNumber

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getBlockByNumber",
  "params": [
    "latest",
    false
  ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "baseFeePerGas": "0x2e90edd00",
    "difficulty": "0x1",
    "gasLimit": "0x1908b100",
    "gasUsed": "0x0",
    "hash": "0x0817159980348542bcc2c99f0b64f89045026e3c9a850da618976dbce211b3c9",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "miner": "0xd2fefdd118aa2bea5991dc079fd341d3e7a92caf",
    "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "nonce": "0x0000000000000000",
    "number": "0x638cf58",
    "parentHash": "0xdf89d6490e3ab62651f5c7e2649bb9eb0a8712faad29c42cd60c35ba6d215e00",
    "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "size": "0x15a9",
    "stateRoot": "0xb858c779bcb521cfeb3c472b8b3ab8c9c07b6bb3c9b9ff0a348db9a43ae0cfee",
    "timestamp": "0x6a44738f",
    "transactions": [],
    "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "uncles": []
  }
}

tesnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "baseFeePerGas": "0x2e90edd00",
    "difficulty": "0x1",
    "gasLimit": "0x1908b100",
    "gasUsed": "0x0",
    "hash": "0x881257407eba135ed469a33e1f1109f5310c98eb88c35d5d012b7a097bf80fb0",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "miner": "0x40964fcdd7cd130d6938976b06885d1a914480b4",
    "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "nonce": "0x0000000000000000",
    "number": "0x4fd6369",
    "parentHash": "0x93f96df53e3448d03b2e05f88ce0c014b17894d92f2f47164154ceb7a00b1878",
    "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "size": "0x701",
    "stateRoot": "0x727ac0fdd44dfded514650f8a96dad80d70b3ac523c96e8fb1b3ecae48ed5ed0",
    "timestamp": "0x6a447447",
    "transactions": [],
    "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "uncles": []
  }
}

Method eth_getTransactionByHash

# mainnet
hash="0x6317626e4dd852ccb4b5db4bc0b9e782c67f65a378490d14852b3992ee1c64fc"

# testnet
hash="0xcab346091b7552673b4a882f173cbf2605329c661e10ba44b81a9f55d978cbf0"

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 5001,
  "method": "eth_getTransactionByHash",
  "params": [
    "'"${hash}"'"
    ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 5001,
  "result": {
    "blockHash": "0x5a631d4139253caa97f2921e21810db8ab386ac65dde0aae6113d0fd1a8a80dc",
    "blockNumber": "0x638d111",
    "blockTimestamp": "0x6a4477ef",
    "from": "0x32530e32c573681d2075f0b0202972f91bf914a5",
    "gas": "0x30d40",
    "gasPrice": "0x0",
    "hash": "0x6317626e4dd852ccb4b5db4bc0b9e782c67f65a378490d14852b3992ee1c64fc",
    "input": "0xe341eaa4000000000000000000000000000000000000000000000000000000000638d10e0c6d9944c574b3f6d93366cb4280b52353ae98e2c09336f44f89d9e110cac6d1",
    "nonce": "0x2ce7",
    "to": "0x0000000000000000000000000000000000000089",
    "transactionIndex": "0x0",
    "value": "0x0",
    "type": "0x0",
    "chainId": "0x32",
    "v": "0x87",
    "r": "0xcfd42c827493e6e3d873aa100ba51c27464ba0b26e8549b66c5cf8412f97557f",
    "s": "0x45e98027873a402de259895bea0731222d4579dcbb435a1cabb51c4d9faa9697"
  }
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 5001,
  "result": {
    "blockHash": "0x8eb1dcfb293460b5ea519f46bda60624809b27bde82ab8589f9eb6b9bc8faf8b",
    "blockNumber": "0x4fd654e",
    "blockTimestamp": "0x6a447821",
    "from": "0xcd13ed39d35ffdcf3c6d982cfd75883517f392fb",
    "gas": "0x30d40",
    "gasPrice": "0x0",
    "hash": "0xcab346091b7552673b4a882f173cbf2605329c661e10ba44b81a9f55d978cbf0",
    "input": "0xe341eaa40000000000000000000000000000000000000000000000000000000004fd654d3acee6cb512394c130ffc3aa6057d872bce823ba2b01a9bb93671897b477ff95",
    "nonce": "0x1ac91c",
    "to": "0x0000000000000000000000000000000000000089",
    "transactionIndex": "0x0",
    "value": "0x0",
    "type": "0x0",
    "chainId": "0x33",
    "v": "0x89",
    "r": "0x1b11de8a8dd63cf3382b1808cf1a2c01b9e1b6d43abe9231ae13e6c0b3223fd",
    "s": "0x67d00ff50cb229a6822d32ed4c31770280a61dfebd21c2774ed4ffcd7775c2a5"
  }
}

Method eth_maxPriorityFeePerGas

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_maxPriorityFeePerGas",
  "params": []
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1002,
  "result": "0x3dc5d3d80"
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 1002,
  "result": "0xf4240"
}

Method eth_gasPrice

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_gasPrice",
  "params": []
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1003,
  "result": "0x6c56c1a80"
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 1003,
  "result": "0x2e91e1f40"
}

Method eth_feeHistory

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1004,
  "method": "eth_feeHistory",
  "params": [
    "0x3",
    "latest",
    [20,50]
  ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1004,
  "result": {
    "oldestBlock": "0x638d07d",
    "reward": [
      [
        "0x0",
        "0x0"
      ],
      [
        "0x0",
        "0x0"
      ],
      [
        "0x8c122780",
        "0x8c122780"
      ]
    ],
    "baseFeePerGas": [
      "0x2e90edd00",
      "0x2e90edd00",
      "0x2e90edd00",
      "0x2e90edd00"
    ],
    "gasUsedRatio": [
      0.01255987380952381,
      0.002998242857142857,
      0.0038277738095238096
    ],
    "baseFeePerBlobGas": [
      "0x0",
      "0x0",
      "0x0",
      "0x0"
    ],
    "blobGasUsedRatio": [
      0,
      0,
      0
    ]
  }
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 1004,
  "result": {
    "oldestBlock": "0x4fd6475",
    "reward": [
      [
        "0x0",
        "0x0"
      ],
      [
        "0x0",
        "0x0"
      ],
      [
        "0x0",
        "0x0"
      ]
    ],
    "baseFeePerGas": [
      "0x2e90edd00",
      "0x2e90edd00",
      "0x2e90edd00",
      "0x2e90edd00"
    ],
    "gasUsedRatio": [
      0,
      0,
      0
    ],
    "baseFeePerBlobGas": [
      "0x0",
      "0x0",
      "0x0",
      "0x0"
    ],
    "blobGasUsedRatio": [
      0,
      0,
      0
    ]
  }
}

Method eth_getLogs

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getLogs",
  "params": [
    {
        "fromBlock":"0x1",
        "toBlock":"latest",
        "topics":[]
    }
  ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32002,
    "message": "request timed out"
  }
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32002,
    "message": "request timed out"
  }
}

Method eth_simulateV1

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_simulateV1",
  "params": [
    {
      "blockStateCalls": [
        {
          "calls": [
            {
              "from": "0xD4CE02705041F04135f1949Bc835c1Fe0885513c",
              "to": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
              "value": "0x0"
            }
          ]
        }
      ],
      "validation": false,
      "traceTransfers": false
    },
    "latest"
  ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32603,
    "message": "method handler crashed"
  }
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32004,
    "message": "method 'eth_simulateV1' is not in the public allowlist"
  }
}

Method eth_getStorageValues

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getStorageValues",
   "params": [
    {
      "0x0000000000000000000000000000000000000088": [
        "0x0000000000000000000000000000000000000000000000000000000000000001",
        "0x0000000000000000000000000000000000000000000000000000000000000002",
        "0x0000000000000000000000000000000000000000000000000000000000000003",
        "0x0000000000000000000000000000000000000000000000000000000000000004",
        "0x0000000000000000000000000000000000000000000000000000000000000005",
        "0x0000000000000000000000000000000000000000000000000000000000000006",
        "0x0000000000000000000000000000000000000000000000000000000000000007",
        "0x0000000000000000000000000000000000000000000000000000000000000008"
      ],
      "0x0000000000000000000000000000000000000090": [
        "0x0000000000000000000000000000000000000000000000000000000000000009",
        "0x0000000000000000000000000000000000000000000000000000000000000001"
      ]
    },
    "latest"
  ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "0x0000000000000000000000000000000000000088": [
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x00000000000000000000000000000000000000000000000000000000000000e5",
      "0x0000000000000000000000000000000000000000000000000000000000000226"
    ],
    "0x0000000000000000000000000000000000000090": [
      "0x0000000000000000000000000000000000000000000000000000000000000000",
      "0x0000000000000000000000000000000000000000000000000000000000000000"
    ]
  }
}

tesnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32004,
    "message": "method 'eth_getStorageValues' is not in the public allowlist"
  }
}

Module web3

Method web3_clientVersion

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "web3_clientVersion",
  "params": []
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 9007,
  "result": "XDC/v1.17.3-stable-92291e95/linux-amd64/go1.24.0"
}

testnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "XDC/v1.17.3-stable/linux-amd64/go1.24.0"
}

Module XDPoS

Method XDPoS_getConfig

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1001,
  "method": "XDPoS_getConfig"
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1001,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getConfig does not exist/is not available"
  }
}

Method XDPoS_getBlockInfoByEpochNum

Request:

epoch=89300

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getBlockInfoByEpochNum",
  "params": [
    '"${epoch}"'
  ]
}' | jq

Response:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getBlockInfoByEpochNum does not exist/is not available"
  }
}

Method XDPoS_getEpochNumbersBetween

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getEpochNumbersBetween",
  "params": [
    "0x5439860",
    "0x5439c48"
  ]
}' | jq

Respons:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getEpochNumbersBetween does not exist/is not available"
  }
}

Method XDPoS_getLatestPoolStatus

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getLatestPoolStatus"
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getLatestPoolStatus does not exist/is not available"
  }
}

Method XDPoS_getMasternodesByNumber

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getMasternodesByNumber",
  "params": [
    "latest"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getMasternodesByNumber does not exist/is not available"
  }
}

Method XDPoS_getMissedRoundsInEpochByBlockNum

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getMissedRoundsInEpochByBlockNum",
  "params": [
    "latest"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getMissedRoundsInEpochByBlockNum does not exist/is not available"
  }
}

Method XDPoS_getSigners

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getSigners",
  "params": [
    "latest"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getSigners does not exist/is not available"
  }
}

Method XDPoS_getSignersAtHash

Request:

hash=0x5a701a8ba642a9b53475bb19cb9a313829f7afb4287caa76bebaea02f0219f89

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getSignersAtHash",
  "params": [
    "'"${hash}"'"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getSignersAtHash does not exist/is not available"
  }
}

Method XDPoS_getSnapshot

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getSnapshot",
  "params": [
    "latest"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getSnapshot does not exist/is not available"
  }
}

Method XDPoS_getSnapshotAtHash

Request:

hash=0x5a701a8ba642a9b53475bb19cb9a313829f7afb4287caa76bebaea02f0219f89

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getSnapshotAtHash",
  "params": [
    "'"${hash}"'"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getSnapshotAtHash does not exist/is not available"
  }
}

Method XDPoS_getV2BlockByHash

Request:

hash=0x5a701a8ba642a9b53475bb19cb9a313829f7afb4287caa76bebaea02f0219f89

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getV2BlockByHash",
  "params": [
    "'"${hash}"'"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getV2BlockByHash does not exist/is not available"
  }
}

Method XDPoS_getV2BlockByNumber

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getV2BlockByNumber",
  "params": [
    "latest"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getV2BlockByNumber does not exist/is not available"
  }
}

Method XDPoS_getRewardByAccount

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getRewardByAccount",
  "params": [
    "0x0000000000000000000000000000000000000000",
    "latest",
    "latest"
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getRewardByAccount does not exist/is not available"
  }
}

Method XDPoS_getBlockInfoByV2EpochNum

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_getBlockInfoByV2EpochNum",
  "params": [
    89300
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_getBlockInfoByV2EpochNum does not exist/is not available"
  }
}

Method XDPoS_calculateBlockInfoByV1EpochNum

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_calculateBlockInfoByV1EpochNum",
  "params": [
    100
  ]
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_calculateBlockInfoByV1EpochNum does not exist/is not available"
  }
}

Method XDPoS_networkInformation

Request:

curl -s -X POST -H "Content-Type: application/json" ${RPC} -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "XDPoS_networkInformation"
}' | jq

Request:

mainnet:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method XDPoS_networkInformation does not exist/is not available"
  }
}

ERC-8004: Building Trustless AI Agents on XDC Network

Rushabh Parmar — Tue, 30 Jun 2026 06:00:37 +0000

Introduction

The AI agent economy is coming, and it has a trust problem.

Autonomous AI agents can already call APIs, execute on-chain transactions, route payments, and coordinate with other agents across complex workflows. But there's no standard answer to a deceptively simple question: Who is this agent, and can I trust it?

ERC-8004, titled Trustless Agents, This article breaks down what ERC-8004 is, how its three registries work, and walks through a live Solidity smart contract that demonstrates agent registration and reputation on XDC Network.

What Is ERC-8004?

Imagine you're hiring a contractor for a big job. Before signing anything, you'd check their license, read reviews from past clients, and maybe ask for references who can vouch for their work. You wouldn't just hand over the keys based on a business card.

AI agents need exactly the same thing — and ERC-8004 is the standard that makes it possible on-chain.

.
ERC-8004, titled Trustless Agents,is an open standard that gives every AI agent three things: a verified identity, a track record, and proof that its work is correct.** It is not a token, not a payment protocol, and not a communication framework. It is purely a trust layer — the on-chain equivalent of a license, a review history, and a third-party audit, all in one.

Here is why this matters right now. AI agents today can call APIs, execute smart contracts, route payments, and coordinate complex workflows autonomously. But when Agent A from Company X wants to hire Agent B from Company Y to complete a task, there is no standard way to answer:

Is this agent who it claims to be?
Has it done this kind of work before, and done it well?
Can I verify that the work it just completed is correct, without trusting it blindly?

ERC-8004 answers all three questions through three lightweight on-chain registries:

Registry	What It Does	Think of It As
Identity Registry	Gives the agent a permanent, verifiable on-chain ID (as an NFT) linked to a metadata file describing its capabilities and endpoints	The agent's passport and business profile
Reputation Registry	Lets anyone who hired the agent post verified feedback — scores, tags, and evidence — that anyone can read on-chain	The agent's Trustpilot / review history
Validation Registry	Allows independent parties to confirm the agent's work was done correctly, using staked economic proofs, zero-knowledge proofs, or hardware attestations	The agent's third-party audit certificate

The Trade Finance DApp: What It Is and How ERC-8004 Powers It

To make ERC-8004 concrete, this article uses a Trade Finance Agent as the running example. Let's break down exactly what that dApp does and where ERC-8004 fits in each step.

What Is the Trade Finance DApp?

Trade finance is the infrastructure that makes international commerce work — letters of credit, invoice financing, shipping document verification, and cross-border payment settlement. Today this process is slow, paper-heavy, and requires trusting a chain of intermediaries: banks, brokers, freight forwarders, and compliance officers.

The XDC Trade Finance Agent is an autonomous AI agent that replaces several of these intermediaries. Here is what it does:

Step 1 — Quote Sourcing A buyer submits a trade request (e.g., "I need financing for a $500,000 shipment of electronics from Singapore to Dubai"). The agent autonomously queries multiple financing providers — banks, alternative lenders, tokenized credit pools — and returns a ranked list of quotes with rates, terms, and collateral requirements.

Step 2 — Document Verification The agent reads the submitted trade documents (Bill of Lading, Commercial Invoice, Letter of Credit draft) and verifies that they are consistent, correctly formatted, and match the terms of the financing request. This is work that currently takes compliance teams days to do manually.

Step 3 — On-Chain Settlement Once a quote is selected and documents verified, the agent triggers settlement on XDC — either releasing tokenized funds from a smart contract escrow, minting a tokenized invoice NFT, or initiating a cross-border XRPL/XDC bridge transaction. Payments flow via x402 micropayments so the agent earns fees atomically per task completed.

Step 4 — Feedback Loop After settlement, the counterparty posts a feedback entry to the Reputation Registry. Was the quote accurate? Were the documents verified correctly? Did settlement happen on time? This builds the agent's on-chain track record.

Where ERC-8004 Gets Used at Each Step

DApp Step	Which Registry	What Happens
Agent is deployed	Identity Registry	Developer calls register(), agent gets an NFT with agentId. Registration file published to IPFS listing MCP endpoint and x402 support.
Buyer discovers the agent	Identity Registry	Buyer queries the registry, reads the agent's registration file, sees its MCP endpoint and supportedTrust: ["reputation", "crypto-economic"]
Buyer evaluates trust	Reputation Registry	Buyer calls getAverageScore(agentId) and getFeedback(agentId), filters by tag1: "trade-finance". Sees 96.5 average from 40 past transactions.
Buyer sends payment	Identity Registry	Buyer reads getAgentWallet(agentId) to get the verified payment address. Sends x402 payment to that address.
Agent completes task	(Off-chain execution)	Agent sources quotes, verifies documents, triggers settlement
Buyer posts review	Reputation Registry	Buyer calls giveFeedback() with score, tags ("invoice-verified", "on-time"), and IPFS link to x402 payment receipt as evidence
High-value deal (>$1M)	Validation Registry	Stakers re-verify the document check results. Validation proof recorded on-chain before escrow releases funds.
Agent is sold/transferred	Identity Registry	NFT transferred. agentWallet auto-cleared. New owner sets new payment address with EIP-712 proof. All reputation history stays intact.

Why ERC-8004 Is the Right Fit for Trade Finance

Without ERC-8004, every new counterparty that wants to use the Trade Finance Agent has to trust it blindly — or build their own out-of-band verification process. With ERC-8004:

Banks and lenders can verify the agent's on-chain identity before exposing their quote APIs
Smart contract escrows can gate fund release on a minimum reputation score
Compliance systems can require Validation Registry proofs before accepting document verification results
Agent marketplaces can list and rank agents by their on-chain track record — no central rating authority needed

This is precisely why XDC Network is a strong home for this pattern. XDC already has the enterprise connections, the trade finance use cases, and the x402 payment infrastructure. ERC-8004 adds the trust layer that makes autonomous agent execution safe enough for institutional counterparties to accept.

Live Smart Contract: XDC Agent Registry

Below is a complete, deployable Solidity implementation of a simplified ERC-8004-compatible Identity + Reputation registry, designed for XDC Network. This is intentionally self-contained for demonstration purposes — production deployments should use the audited canonical contracts.

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";

import "@openzeppelin/contracts/access/Ownable.sol";

import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

import "@openzeppelin/contracts/utils/cryptography/EIP712.sol";

/**

 * @title XDCAgentRegistry

 * @notice ERC-8004 compatible agent Identity + Reputation registry for XDC Network.

 * @dev Implements Identity Registry (ERC-721 based) and Reputation Registry.

 *      Chain ID: 50 (XDC Mainnet), 51 (XDC Apothem Testnet)

 *      Gas: 12.5 gwei minimum. Legacy Type 0 transactions only on XDC.

 *      RPC: https://rpc.ankr.com/xdc (recommended over rpc.xinfin.network for VPS)

 */

contract XDCAgentRegistry is ERC721URIStorage, EIP712 {

    using ECDSA for bytes32;

    // ─── Events ───────────────────────────────────────────────────────────────

    event AgentRegistered(uint256 indexed agentId, string agentURI, address indexed owner);

    event AgentURIUpdated(uint256 indexed agentId, string newURI, address indexed updatedBy);

    event MetadataSet(uint256 indexed agentId, string indexed indexedKey, string key, bytes value);

    event AgentWalletSet(uint256 indexed agentId, address newWallet);

    event FeedbackGiven(

        uint256 indexed agentId,

        address indexed clientAddress,

        int128 value,

        uint8 valueDecimals,

        string tag1,

        string tag2,

        string endpoint,

        string feedbackURI,

        bytes32 feedbackHash

    );

    // ─── Storage ──────────────────────────────────────────────────────────────

    uint256 private _nextAgentId;

    // agentId => metadataKey => metadataValue

    mapping(uint256 => mapping(string => bytes)) private _metadata;

    // agentId => payment wallet (requires EIP-712 proof to set)

    mapping(uint256 => address) private _agentWallet;

    // agentId => list of feedback entries

    struct FeedbackEntry {

        address clientAddress;

        int128 value;

        uint8 valueDecimals;

        string tag1;

        string tag2;

        string endpoint;

        string feedbackURI;

        bytes32 feedbackHash;

        uint256 timestamp;

    }

    mapping(uint256 => FeedbackEntry[]) private _feedback;

    // EIP-712 typehash for agentWallet change authorization

    bytes32 private constant AGENT_WALLET_TYPEHASH = keccak256(

        "AgentWallet(uint256 agentId,address newWallet,uint256 deadline)"

    );

    // ─── Constructor ──────────────────────────────────────────────────────────

    constructor()

        ERC721("XDC Agent Registry", "XAGENT")

        EIP712("XDCAgentRegistry", "1")

    {

        _nextAgentId = 1;

    }

    // ─── Identity Registry ────────────────────────────────────────────────────

    /**

     * @notice Register a new agent and mint an ERC-721 token.

     * @param agentURI IPFS, HTTPS, or data URI pointing to the agent registration JSON file.

     * @return agentId The ERC-721 tokenId assigned to this agent.

     */

    function register(string calldata agentURI) external returns (uint256 agentId) {

        agentId = _nextAgentId++;

        _safeMint(msg.sender, agentId);

        _setTokenURI(agentId, agentURI);

        // Initialize agentWallet to owner address

        _agentWallet[agentId] = msg.sender;

        emit MetadataSet(agentId, "agentWallet", "agentWallet", abi.encode(msg.sender));

        emit AgentRegistered(agentId, agentURI, msg.sender);

    }

    /**

     * @notice Register without URI (set later via setAgentURI).

     */

    function register() external returns (uint256 agentId) {

        agentId = _nextAgentId++;

        _safeMint(msg.sender, agentId);

        _agentWallet[agentId] = msg.sender;

        emit AgentRegistered(agentId, "", msg.sender);

    }

    /**

     * @notice Update the agent's registration file URI.

     * @dev Only owner or approved operator may call.

     */

    function setAgentURI(uint256 agentId, string calldata newURI) external {

        require(_isApprovedOrOwner(msg.sender, agentId), "Not authorized");

        _setTokenURI(agentId, newURI);

        emit AgentURIUpdated(agentId, newURI, msg.sender);

    }

    /**

     * @notice Set arbitrary on-chain metadata for an agent.

     * @dev "agentWallet" key is reserved — use setAgentWallet() instead.

     */

    function setMetadata(

        uint256 agentId,

        string calldata metadataKey,

        bytes calldata metadataValue

    ) external {

        require(_isApprovedOrOwner(msg.sender, agentId), "Not authorized");

        require(

            keccak256(bytes(metadataKey)) != keccak256(bytes("agentWallet")),

            "agentWallet is reserved"

        );

        _metadata[agentId][metadataKey] = metadataValue;

        emit MetadataSet(agentId, metadataKey, metadataKey, metadataValue);

    }

    /**

     * @notice Read on-chain metadata for an agent.

     */

    function getMetadata(uint256 agentId, string memory metadataKey)

        external

        view

        returns (bytes memory)

    {

        return _metadata[agentId][metadataKey];

    }

    /**

     * @notice Update the agent's payment wallet with EIP-712 proof of new wallet control.

     * @param agentId The agent token ID.

     * @param newWallet The address to receive payments.

     * @param deadline Signature expiry timestamp.

     * @param signature EIP-712 signature from newWallet proving control.

     */

    function setAgentWallet(

        uint256 agentId,

        address newWallet,

        uint256 deadline,

        bytes calldata signature

    ) external {

        require(_isApprovedOrOwner(msg.sender, agentId), "Not authorized");

        require(block.timestamp <= deadline, "Signature expired");

        bytes32 structHash = keccak256(

            abi.encode(AGENT_WALLET_TYPEHASH, agentId, newWallet, deadline)

        );

        bytes32 digest = _hashTypedDataV4(structHash);

        address signer = digest.recover(signature);

        require(signer == newWallet, "Invalid wallet signature");

        _agentWallet[agentId] = newWallet;

        emit AgentWalletSet(agentId, newWallet);

        emit MetadataSet(agentId, "agentWallet", "agentWallet", abi.encode(newWallet));

    }

    /**

     * @notice Get the current payment wallet for an agent.

     */

    function getAgentWallet(uint256 agentId) external view returns (address) {

        address wallet = _agentWallet[agentId];

        return wallet == address(0) ? ownerOf(agentId) : wallet;

    }

    /**

     * @notice Clear the agent wallet (resets to owner address).

     */

    function unsetAgentWallet(uint256 agentId) external {

        require(_isApprovedOrOwner(msg.sender, agentId), "Not authorized");

        delete _agentWallet[agentId];

        emit AgentWalletSet(agentId, address(0));

    }

    // Override transfer to clear agentWallet (ERC-8004 requirement)

    function _beforeTokenTransfer(

        address from,

        address to,

        uint256 tokenId,

        uint256 batchSize

    ) internal virtual override {

        super._beforeTokenTransfer(from, to, tokenId, batchSize);

        if (from != address(0)) {

            // Clear payment wallet on transfer — new owner must re-verify

            delete _agentWallet[tokenId];

        }

    }

    // ─── Reputation Registry ──────────────────────────────────────────────────

    /**

     * @notice Submit feedback for an agent after an interaction.

     * @dev Caller must NOT be the agent owner or operator (prevents self-dealing).

     * @param agentId    The agent being rated.

     * @param value      Signed fixed-point score (e.g., 9500 for 95.00 with valueDecimals=2).

     * @param valueDecimals Decimal places of the value (0–18).

     * @param tag1       Optional tag (e.g., "trade-finance", "fast-delivery").

     * @param tag2       Optional secondary tag.

     * @param endpoint   Optional endpoint URI the feedback applies to.

     * @param feedbackURI Optional IPFS/HTTPS link to extended feedback JSON.

     * @param feedbackHash KECCAK-256 of feedbackURI content (0x0 if IPFS or omitted).

     */

    function giveFeedback(

        uint256 agentId,

        int128 value,

        uint8 valueDecimals,

        string calldata tag1,

        string calldata tag2,

        string calldata endpoint,

        string calldata feedbackURI,

        bytes32 feedbackHash

    ) external {

        require(_exists(agentId), "Agent does not exist");

        require(valueDecimals <= 18, "valueDecimals exceeds 18");

        // Prevent owner/operator from self-rating

        require(

            !_isApprovedOrOwner(msg.sender, agentId),

            "Agent owner/operator cannot give feedback"

        );

        _feedback[agentId].push(FeedbackEntry({

            clientAddress: msg.sender,

            value: value,

            valueDecimals: valueDecimals,

            tag1: tag1,

            tag2: tag2,

            endpoint: endpoint,

            feedbackURI: feedbackURI,

            feedbackHash: feedbackHash,

            timestamp: block.timestamp

        }));

        emit FeedbackGiven(agentId, msg.sender, value, valueDecimals, tag1, tag2, endpoint, feedbackURI, feedbackHash);

    }

    /**

     * @notice Get all feedback entries for an agent.

     */

    function getFeedback(uint256 agentId)

        external

        view

        returns (FeedbackEntry[] memory)

    {

        return _feedback[agentId];

    }

    /**

     * @notice Get feedback count for an agent.

     */

    function getFeedbackCount(uint256 agentId) external view returns (uint256) {

        return _feedback[agentId].length;

    }

    /**

     * @notice Compute a simple on-chain average score for an agent.

     * @dev Returns scaled integer: divide by (10 ** valueDecimals) for the float equivalent.

     *      This is a naive average — production systems should use off-chain aggregation.

     * @return avgValue Average score value

     * @return decimals The common decimal precision used (from first feedback entry)

     * @return count    Number of feedback entries included

     */

    function getAverageScore(uint256 agentId)

        external

        view

        returns (int128 avgValue, uint8 decimals, uint256 count)

    {

        FeedbackEntry[] storage entries = _feedback[agentId];

        count = entries.length;

        if (count == 0) return (0, 0, 0);

        decimals = entries[0].valueDecimals;

        int256 sum = 0;

        for (uint256 i = 0; i < count; i++) {

            sum += int256(entries[i].value);

        }

        avgValue = int128(sum / int256(count));

    }

    /**

     * @notice Get total registered agents.

     */

    function totalAgents() external view returns (uint256) {

        return _nextAgentId - 1;

    }

}

Deployment on XDC Network (Hardhat)

hardhat.config.js

****require("@nomicfoundation/hardhat-toolbox");

module.exports = {

  solidity: {

    version: "0.8.20",

    settings: {

      optimizer: { enabled: true, runs: 200 },

      viaIR: true // Required for complex contracts to avoid "Stack too deep"

    }

  },

    apothem: {

      url: "https://rpc.apothem.network",

      accounts: [process.env.PRIVATE_KEY],

      chainId: 51,

      gasPrice: 12500000000

    }

  }

};

XDC-specific reminders:

Chain ID: 50 (mainnet), 51 (Apothem testnet)
Minimum gas price: 12.5 gwei (12500000000 wei)
Use Legacy Type 0 transactions — XDC does not support EIP-1559 Type 2
estimateGas can be unreliable — set explicit gas limits for critical txns

deploy.js

****const { ethers } = require("hardhat");

async function main() {

  const [deployer] = await ethers.getSigners();

  console.log("Deploying from:", deployer.address);

  const Registry = await ethers.getContractFactory("XDCAgentRegistry");

  const registry = await Registry.deploy({

    gasPrice: ethers.parseUnits("12.5", "gwei"),

    type: 0  // Legacy transaction (required on XDC)

  });

  await registry.waitForDeployment();

  const address = await registry.getAddress();

  console.log("XDCAgentRegistry deployed at:", address);

  console.log("Agent Registry ID: eip155:50:" + address);

}

main().catch(console.error);

Live Deployment on XDC Apothem

The contract is deployed and live on XDC Apothem Testnet:

Field	Value
Contract Address	0x1B34Db6aCF3372db67B3E28abB10Bca54b966D91
Network	XDC Apothem Testnet (Chain ID: 51)
Agent Registry ID	eip155:51:0x1B34Db6aCF3372db67B3E28abB10Bca54b966D91
Explorer	testnet.xdcscan.com/address/0x1B34Db6aCF3372db67B3E28abB10Bca54b966D91
Compiler	Solidity 0.8.24, viaIR: true, EVM: cancun
Deployer	0x828dDD2139D59f7f324BDFE7E38FF74425DF1360

Interacting with the Registry

Register an Agent

****const agentRegistrationJSON = {

  type: "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",

  name: "XDCTradeFinanceAgent",

  description: "Autonomous agent for trade finance quote sourcing and settlement on XDC Network",

  image: "https://example.com/agent.png",

  services: [

    { name: "MCP", endpoint: "https://mcp.myagent.xdc/", version: "2025-06-18" },

    { name: "A2A", endpoint: "https://myagent.xdc/.well-known/agent-card.json" }

  ],

  x402Support: true,

  active: true,

  supportedTrust: ["reputation"]

};

// Upload JSON to IPFS (or encode as base64 data URI for fully on-chain storage)

const agentURI = "ipfs://QmYourCIDHere";

const tx = await registry.register(agentURI, {

  gasPrice: ethers.parseUnits("12.5", "gwei"),

  type: 0

});

const receipt = await tx.wait();

// Parse the AgentRegistered event to get agentId

const event = receipt.logs.find(l => l.fragment?.name === "AgentRegistered");

const agentId = event.args.agentId;

console.log("Agent registered with ID:", agentId.toString());

Submit Feedback After an Interaction

****// Score: 9750 with 2 decimals = 97.50 out of 100

const value = 9750n;

const valueDecimals = 2;

await registry.giveFeedback(

  agentId,

  value,

  valueDecimals,

  "trade-finance",          // tag1

  "on-time-delivery",       // tag2

  "https://mcp.myagent.xdc/", // endpoint

  "ipfs://QmFeedbackCID",   // extended feedback JSON (optional)

  ethers.ZeroHash,          // feedbackHash (0x0 for IPFS URIs)

  {

    gasPrice: ethers.parseUnits("12.5", "gwei"),

    type: 0

  }

);

Read On-Chain Reputation

****const [avgValue, decimals, count] = await registry.getAverageScore(agentId);

const humanScore = Number(avgValue) / Math.pow(10, Number(decimals));

console.log(`Average score: ${humanScore.toFixed(2)} (from ${count} reviews)`);

// Get full feedback history

const feedbackEntries = await registry.getFeedback(agentId);

feedbackEntries.forEach((entry, i) => {

  const score = Number(entry.value) / Math.pow(10, Number(entry.valueDecimals));

  console.log(`Review #${i + 1}: ${score.toFixed(2)} | tags: ${entry.tag1}, ${entry.tag2}`);

});

Verify Agent Identity

****// Construct the global agent identifier

const chainId = 51;

const registryAddress = await registry.getAddress();

const globalAgentId = `eip155:${chainId}:${registryAddress}`;

console.log("Agent Registry:", globalAgentId);

console.log("Agent ID:", agentId.toString());

console.log("Agent URI:", await registry.tokenURI(agentId));

console.log("Payment Wallet:", await registry.getAgentWallet(agentId));

console.log("Total Agents:", await registry.totalAgents());

The Trust Model in Practice

ERC-8004's trust is tiered by stake, not binary:

Low-stakes task (e.g., summarize a document)

└── Reputation Registry suffices

  └── Check average score, filter by tag

Medium-stakes task (e.g., route a DeFi swap)

└── Crypto-economic validation

  └── Stakers re-execute and stake tokens on correctness

High-stakes task (e.g., release escrow funds, medical diagnosis)

└── zkML proof or TEE attestation

  └── Cryptographic proof of correct model inference

For XDC's trade finance use case, this maps naturally:

Letter of Credit validation → Reputation (human reviewer feedback)
Invoice tokenization → Crypto-economic (staker-backed re-execution)
Cross-border settlement → TEE attestation (confidential computation)

Conclusion

ERC-8004 is to AI agents what ERC-20 was to tokens — foundational, composable, and deliberately minimal. By separating identity, reputation, and validation into lightweight on-chain primitives, it creates a neutral trust layer that any agent, on any EVM chain, can plug into.

For XDC Network, this is infrastructure that matters. As trade finance, RWA tokenization, and cross-border settlement increasingly involve autonomous agents — agents that hire other agents, negotiate terms, and execute transactions without human in the loop — the chain they anchor their identity on becomes their trust foundation.

The smart contract above is a starting point. Drop it on Apothem, register your first agent, and start building reputation from your very first x402 payment.

Please help

Dumitru Visan — Wed, 24 Jun 2026 16:18:34 +0000

I have on Base XDCE and I would like to know if it is still possible to swap it for XDC. If yes,I need help aswell for this.Thank you!

Developers Forum for XinFin XDC Network

How to Publish and Monetise Your API on XDC AI Marketplace.

Introduction

The Rise of Agentic AI Commerce

Challenges with Traditional API Monetisation

Why the API Economy Needs to Evolve

Industry Momentum Behind Agentic AI

What is XDC AI Tech?

Why XDC Network?

Understanding x402

Why x402 Matters

The Shift Toward Machine-to-Machine Payments

Gasless USDC Payments

How to Publish Your API

Best Practices

FAQs

Disclaimer

The Future of AI Commerce

Conclusion

What is the status of XDCDAO? (xdcdao.org appears to be offline)

WeAreXDC

TradeFi Network Goes Multichain: The RWA Analytics Layer Born on XDC Now Tracks Stellar

What Is TradeFi Network?

Who It Serves

The Methodology: Labeled Data, Not Just Big Numbers

The Big Move: Stellar Goes Live in Beta

What Multichain Actually Unlocks

Point of Comparison: TradeFi Network vs DefiLlama

The Commercial Layer: How the Platform Sustains Itself

Why This Matters for XDC

$1.5 Billion On-Chain: How XDC Network's Tokenized Value Just Rewrote Its Own Growth Curve

The Snapshot: XDC Ecosystem by the Numbers

The Growth Curve: From $717M to $1.5B in Six Months

What's Actually Driving the Surge

1. Brazilian Credit Is the Engine

2. Regulatory Tailwinds Made Brazil the Beachhead

3. Stablecoin Liquidity Underpins Settlement

4. The Long Tail: Commodities, ETPs, and DeFi

Staking: The Quiet Security Story

Why the Composition Matters More Than the Headline

The Bigger Picture: XDC's Thesis Is Playing Out

Shipping a paid x402 API on XDC: NodeLens, a node-intelligence provider

Why

Stack

How the payment flow works

The monitoring agent

Full endpoint list

Example responses from Claude XDCAI's integration

The Settlement Economy: Why Agent-to-Agent Payments Are Web3's Next Trillion-Dollar Category

The Token Economy

The Settlement Economy

A concrete example: XDC's AI framework as a settlement layer

Why this compounds

Settlements will be king

XDCAI : Agents can now invoice each other on XDC <> stateless x402 invoices + chain-truth payment verification

1. payment/verify — the answer to "charged: unknown"

2. Stateless invoices — agents billing each other

The pattern underneath

What's next

I tested XDC AI's x402 marketplace as both payer and provider. Here's everything I found

The consumer side: paying for data as an agent

The provider side: getting paid as an API

The finding that matters: a three-way settlement disagreement

Smaller notes

What we're building because of all this

[Informative] June Insights: Key Highlights and Developments from Plugin’s Journey

The first test report of new PRC

Findings

Module eth

Method eth_config

Method eth_getBlockByNumber

Method eth_getTransactionByHash

Method eth_maxPriorityFeePerGas

Method eth_gasPrice

Method eth_feeHistory

Method eth_getLogs

Method eth_simulateV1

Method eth_getStorageValues

Module web3

Method web3_clientVersion

1. `payment/verify` — the answer to "charged: unknown"