Developers Forum for XinFin XDC Network: Rushabh Parmar

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.

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.

Building an AI Agent That Sends USDC on XDC Network Using Plain English

Rushabh Parmar — Thu, 11 Jun 2026 13:41:29 +0000

Introduction

Artificial Intelligence is evolving from a tool that generates information into a system capable of taking actions.

This new generation of software — often called Agentic AI — goes beyond answering questions. AI agents can understand user intent, make decisions, and interact with external systems to complete real tasks autonomously.

To explore this concept, I built Agentic XDC Payments: an AI-powered payment agent that enables users to send USDC on the XDC Network using simple natural language instructions.

Rather than interacting with wallets, smart contracts, or blockchain interfaces directly, a user simply types:

Send 1 USDC to xdc1abc...

The AI agent interprets the request, verifies the details, prepares the transaction, and executes it on-chain.

The result is a seamless bridge between human language and blockchain transactions.

What the Project Does

The application lets users initiate blockchain payments through conversation.

Instead of manually opening a wallet, selecting a token, entering an address, and configuring a transaction — users simply describe their intent.

The AI agent handles everything else:

Understanding the natural language request
Extracting the recipient address and amount
Validating the transaction parameters
Presenting a confirmation prompt
Executing the USDC transfer on XDC Mainnet

This creates an experience where blockchain payments feel as natural as messaging a digital assistant.

Technology Stack

The project combines four technologies that work together to create an end-to-end agentic payment workflow.

Claude AI

Claude serves as the reasoning engine. Its job is to analyze a natural language instruction and convert it into structured transaction data.

For example, given the input:

"Send 10 USDC to xdc123..."

Claude extracts:

{
  "action": "transfer",
  "amount": 10,
  "token": "USDC",
  "to": "xdc123..."
}

This transformation from human language into machine-readable instructions is the core of the agent.

Node.js

Node.js acts as the orchestration layer. It manages the full lifecycle — reading user input from the terminal, communicating with the Claude API, presenting confirmations, and triggering the blockchain interaction.

ethers.js

ethers.js handles all blockchain functionality: connecting to XDC Network, managing the wallet, constructing the ERC-20 transfer transaction, signing it locally, and broadcasting it to the network.

XDC Network

XDC Network is the execution and settlement layer. Once the transaction is signed, it is submitted to the XDC blockchain where it becomes a permanent, verifiable on-chain record.

How the Code Works

The project follows a clean, sequential workflow from input to on-chain settlement.

Step 1 — User Input

The terminal waits for a plain English instruction:

You > send 1 USDC to 0xB0EF2A0337A519d50780E33d268341CE75ce8383

Step 2 — AI Parsing

The instruction is sent to Claude AI. Claude analyzes the text and returns a structured JSON object containing the recipient address, token, and amount. No regex, no manual parsing — just natural language understanding.

Step 3 — Validation

Before any transaction is constructed, the application validates:

Recipient address format (supports both xdc and 0x prefixes)
Amount is a positive number within the safety limit
USDC contract is correctly loaded

This prevents malformed or unintended transactions from reaching the blockchain.

Step 4 — Confirmation

The agent displays a clear summary and requires explicit approval:

  ─────────────────────────────────────────
  To      : 0xB0EF2A...e8383
  Amount  : 1 USDC
  Gas     : ~0.01 XDC (legacy tx, 12.5 gwei)
  ─────────────────────────────────────────
  Confirm send? (yes / no):

The user remains in full control. Nothing executes without a yes.

Step 5 — Transaction Construction

Using ethers.js, the application constructs a USDC ERC-20 transfer.

Important XDC-specific settings:

const tx = await usdc.transfer(to, amountWei, {
  type: 0,                                  // Legacy tx — XDC does not support EIP-1559
  gasPrice: ethers.parseUnits("12.5", "gwei"), // XDC minimum gas price
  gasLimit: 100_000n,
});

Step 6 — Broadcast

The signed transaction is broadcast to XDC Mainnet. The blockchain validates and includes it in the next block.

Step 7 — Confirmation

The agent returns a success message with the transaction hash and a direct XDCScan link:

  ✓  Sent 1 USDC successfully!
  ✓  Tx hash : 0x17f26f8554f22a1ed2b018b584bf3f13cb2e222067a8bbdfbce7b7f0e5b5a874
  ✓  Explorer: https://xdcscan.com/tx/0x17f26f8554f22a1ed2b018b584bf3f13cb2e222067a8bbdfbce7b7f0e5b5a874
  ✓  Block   : 103647109

Live Demonstration

During testing, the agent successfully completed a live USDC transfer on XDC Mainnet.

Step	What Happened
1. Human intent	Typed: `send 1 USDC to 0xB0EF2A...`
2. AI understanding	Claude extracted address and amount
3. Safety check	Reviewed and typed `yes`
4. Autonomous execution	Agent signed and broadcast the tx
5. On-chain settlement	XDC Network confirmed in block 103,647,109

Verified transaction on XDCScan:
0x17f26f8554f22a1ed2b018b584bf3f13cb2e222067a8bbdfbce7b7f0e5b5a874

Real USDC moved on-chain through a conversational interface.

Project Structure

xdc-usdc-agent/
├── src/
│   ├── agent.js      ← CLI loop and user interaction
│   ├── parser.js     ← Claude AI intent parser
│   ├── usdc.js       ← USDC contract calls (balance + transfer)
│   └── wallet.js     ← Wallet loader (private key or mnemonic)
├── .env.example      ← Configuration template
└── package.json

Key Technical Notes for XDC Developers

If you are building on XDC Network, these constraints are important:

Use legacy transaction type 0 — XDC does not support EIP-1559 transactions
Minimum gas price is 12.5 gwei — transactions below this will be rejected
estimateGas can be unreliable — set gasLimit manually (100,000 is safe for ERC-20 transfers)
Address prefix — XDC uses an xdc prefix; convert to 0x for ethers.js using "0x" + addr.slice(3)
USDC contract on Mainnet — 0xfA2958CB79b0491CC627c1557F441eF849Ca8eb1

Why This Matters

Most AI demonstrations stop at content generation.

This project demonstrates something more meaningful: AI agents that take actions.

The future of AI is not just answering questions — it is helping users accomplish tasks. Blockchain networks provide a transparent and programmable execution layer for those tasks. By combining Claude's language understanding with XDC's on-chain settlement, developers can transform natural language directly into verifiable financial outcomes.

This pattern opens the door to more complex agentic workflows: scheduled payments, multi-step DeFi interactions, automated treasury operations — all triggered by plain English.

Open Source

The complete source code is available on GitHub:

github.com/RushabhParmar12/agentic-xdc-payments

Developers are encouraged to explore, fork, and extend the project for new agentic use cases on XDC Network.

Conclusion

Agentic AI represents a shift from software that provides information to software that performs actions.

This project demonstrates that shift in a direct, practical way:

A user expresses intent in plain English
Claude AI understands and structures the request
The application validates and confirms with the user
ethers.js signs and broadcasts the transaction
XDC Network settles it permanently on-chain

This is more than a payment application. It is a working example of how AI agents and blockchain infrastructure can combine to build the next generation of autonomous financial systems.

Built with Claude AI · ethers.js · Node.js · XDC Network

Disclaimer: This application uses AI to interpret natural language instructions. While safety checks are implemented, AI outputs may occasionally be incorrect or incomplete. Always review transaction details carefully before confirming. The user remains fully responsible for all transactions executed through this application.

Understanding the XDC Network Slashing Mechanism: Ensuring Network Stability

Rushabh Parmar — Tue, 05 May 2026 06:23:02 +0000

Introduction

The XDC Network, powered by its XDC 2.0 consensus mechanism, employs a slashing mechanism to maintain network stability and ensure validator accountability. Unlike punitive slashing systems in other blockchains, XDC's approach focuses on corrective measures that balance network efficiency with fairness to node operators.

This article explores how slashing works, its impact on network performance, and practical solutions for masternode operators to avoid slashing events.

Why Slashing is Critical for Network Performance

The Timeout Problem

In XDPoS, masternodes create blocks in a round-robin fashion. When a masternode fails to create a block during its designated turn, the entire network experiences a 10-second timeout before the next masternode proceeds.

Impact Example:

If 27 masternodes (25% of the 108-node network) are underperforming:

Wasted time per epoch: 27 nodes × 6 average turns × 10 seconds = 1,620 seconds
Normal epoch duration: 1,800 seconds
Performance degradation: 47.4%
Network throughput: Reduced from 2,000+ TPS to ~1,050 TPS

Without slashing, these underperforming masternodes would continue degrading network performance indefinitely. With slashing, the network automatically excludes them, restoring full operational efficiency.

How XDC Slashing Works

The Slashing Trigger

Primary Condition: A masternode that fails to sign any block during an entire epoch (900 blocks) will be slashed.

The system evaluates complete inactivity over an epoch, not isolated missed blocks. This prevents false positives from temporary network hiccups while identifying genuinely unresponsive masternodes.

The Slashing Cycle

Phase 1: Performance Monitoring

Each epoch consists of 900 blocks (approximately 30 minutes):

Epoch N (900 blocks, ~1800 seconds)
├── Masternodes take turns creating blocks
├── Block Signer smart contract records all signatures
└── Block 900 (Checkpoint): Performance evaluation

Phase 2: Detection and Slashing

At the checkpoint block:

for each masternode M in MasternodeSet {
    signatures = BlockSigner.getSignatureCount(M, currentEpoch);

    if (signatures == 0) {
        slashMasternode(M);
        addToSlashedList(M, currentEpoch + 4);
    }
}

Key Point: Zero signatures = automatic slashing. Partial participation = no slashing.

Phase 3: Exclusion Period (4 Epochs)

Once slashed, a masternode enters a 4-epoch exclusion period (~2 hours):

Epoch N: Masternode slashed (0 signatures)
├── Epochs N+1 to N+4: Excluded from block creation
│   └── Can still verify/sign blocks created by others
└── Epoch N+5: Eligible for reinstatement

During Exclusion:

Cannot create blocks
Can verify and sign blocks (demonstrates liveness)
This activity is required for recovery

Phase 4: Automatic Reinstatement

After 4 epochs, the masternode automatically rejoins if:

It signed blocks during the exclusion period
Stake remains locked in the smart contract
No additional slashing events occurred

Byzantine Fault Tolerance and Network Safety

The XDC Network maintains Byzantine Fault Tolerance through its 75% finality requirement:

BFT Parameters:

Finality requires: 81 validator signatures (75% of 108)
Network tolerates: Up to 27 faulty/offline masternodes
Critical threshold: If 28+ masternodes are slashed, finality becomes impossible

Slashed Nodes	Active Nodes	BFT Status
0-10	98-108	✅ Excellent
11-27	81-97	✅ Safe
27	81	⚠️ Critical
28+	<81	❌ Broken

Double Validation Integration

XDC's slashing mechanism integrates with its Double Validation system:

How It Works:

Block Creator: Creates block per round-robin schedule
Block Verifier: Randomly selected to verify and co-sign
Finalization: Requires both signatures

Slashing Impact:

Slashed masternodes are excluded from block creator rotation
Can still participate as random block verifiers
Allows demonstration of liveness for recovery

Solutions to Avoid Slashing

Alternative: Third-Party Masternode Services

If you do not have the technical resources, infrastructure, or time to maintain a masternode yourself, there are several third-party services and volunteers willing to provide professional masternode hosting and management services. These providers handle all technical aspects including:

Infrastructure setup and maintenance
24/7 uptime management
Security hardening and updates
Failover and redundancy
Technical support and troubleshooting

Available Third-Party Services:

IndSoft - Professional masternode hosting
NODE FORGE - Managed validator services
Zeeve - Enterprise blockchain infrastructure
BlockDaemon - Institutional-grade node operations
Tatum - Blockchain infrastructure platform
NOWNodes - Node hosting and API services
Asternodes - Validator management services
Ankr - Decentralized node infrastructure
thirdweb - Web3 infrastructure provider
GOLDSKY - Blockchain data infrastructure

Important Considerations:

When selecting a third-party service provider:

Research their track record and uptime history
Understand their fee structure
Verify their security practices
Check their support responsiveness
Review client testimonials
Ensure they have experience with XDC Network

DISCLAIMER: XDC Network does not officially endorse any third-party services. Please perform due diligence and research before proceeding with any service provider. You remain responsible for your staked XDC and masternode performance.

For Self-Hosted Masternodes:Infrastructure Requirements

Hardware Specifications

Minimum Requirements:

CPU: 12+ core
RAM: 32 GB
Storage: 2 TB NVMe SSD
Network: 100 Mbps (1 Gbps recommended)

Why This Matters:

Insufficient CPU → slow block processing
Insufficient RAM → system swapping and delays
HDD instead of SSD → missed signing windows
Unstable network → failed peer communication

Network Infrastructure

Critical Requirements:

Static Public IP (mandatory)
99.99%+ uptime SLA (use tier-3+ data centers)
DDoS protection
Low latency (<100ms to network peers)
Redundant connectivity

1. Proper Node Setup

Follow the official setup guide:

Repository: https://github.com/XinFinOrg/XinFin-Node

Setup Steps:

# Clone the official repository
git clone https://github.com/XinFinOrg/XinFin-Node
cd XinFin-Node

# Run the setup script
./setup.sh

# Key configuration parameters:
# - Static IP address
# - Port 30303 open for P2P
# - Proper keystore and password
# - Adequate system resources

Essential Configuration:

--syncmode "full": Complete blockchain sync
--mine: Enable block creation
Firewall: Open port 30303, restrict RPC access

2. Implement Hot Standby Architecture

Setup:

┌─────────────────────┐         ┌─────────────────────┐
│  Primary Masternode │         │  Hot Standby Node   │
│  - Active mining    │◄───────►│  - Synced, ready    │
│  - Signing blocks   │         │  - Not mining       │
└─────────────────────┘         └─────────────────────┘

Critical Rules:

Never run both nodes with same key simultaneously (causes double-signing → 100% rewards loss)
Keep standby fully synced at all times
Document failover procedure
Practice failover monthly
Target failover time: <5 minutes

3. Regular Maintenance

Update Schedule:

Critical patches: Within 24 hours
Protocol upgrades: Per XDC Team announcements
Regular updates: Monthly maintenance windows

Planned Maintenance:

# Update procedure
cd XinFin-Node && git pull origin master
docker-compose up -d

# Restart (target: <10 minutes downtime)
docker-compose down
docker-compose up -d

# Verify node is signing blocks within 5 minutes

4. Security Hardening

Firewall Configuration:

# Basic firewall setup
ufw default deny incoming
ufw default allow outgoing

# Allow P2P (essential)
ufw allow 30303/tcp

# Allow RPC only from localhost
ufw allow from 127.0.0.1 to any port 8545

# Allow SSH from trusted IPs only
ufw allow from YOUR_ADMIN_IP to any port 22

ufw enable

Key Protection:

Use strong passwords (25+ characters)
Store keys in encrypted files with restricted permissions (chmod 600)
Never store unencrypted private keys on servers

5. Verify Network Connectivity

Check Peer Connections:

# Check peer count (should be >10)
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'admin.peers.length'

# Add peers manually if needed
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'admin.addPeer("enode://PEER_ID@IP:PORT")'

Target: Maintain 15-30 peer connections for optimal resilience.

6. Ensure Continuous Sync

Verify Sync Status:

# Check current block number
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'eth.blockNumber'

# Compare to network: https://xinfin.network

# Check sync status
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'eth.syncing'
# Should return "false" if fully synced

Action Guidelines:

<10 blocks behind → Monitor
10-100 blocks behind → Check peers and connectivity
>100 blocks behind → Investigate immediately, may need restart

7. Pre-Launch Checklist

Before activating your masternode:

Hardware meets recommended specifications
Static IP configured and tested
Node deployed from official repository
Full blockchain sync completed
Firewall configured correctly
Hot standby node synced
Failover procedure documented and tested
Keys secured properly
10,000,000 XDC staked
KYC completed

8. Daily Operational Checks

Daily:

Verify sync status (within 10 blocks)
Check peer count (>10 peers)
Review system logs for errors

Weekly:

Verify standby node is synced
Test failover readiness
Check for software updates

Monthly:

Update node software
Test complete failover
Security audit
Backup configurations

Recovery After Slashing

If your masternode gets slashed, follow this recovery process:

Step 1: Confirm Slashing (5 Minutes)

Check your status:

Visit https://xdcscan.com
Enter your masternode address
Verify epoch performance shows 0 signatures

Step 2: Diagnose Root Cause (30 Minutes)

Issue	Check	Solution
Node offline	Service status	Restart service
Out of sync	Sync progress	Wait for completion
No peers	Peer count	Add peers manually
Disk full	Disk usage	Clear space
Memory issues	System resources	Restart, upgrade RAM

Step 3: Fix the Issue (1 Hour)

Restart Node:

docker-compose restart
docker-compose logs -f --tail 100

# Verify sync resumption
docker exec -it xinfinnetwork_xdcnode_1 geth attach /work/xdcchain/XDC.ipc \
  --exec 'eth.syncing'

Add Peers:

# Check firewall
ufw status

# Verify P2P port
netstat -tuln | grep 30303

# Add peers
bash peer.sh

Step 4: Demonstrate Liveness (4 Epochs)

During the 4-epoch exclusion:

Your node can verify and sign blocks (even though it can't create them)
This demonstrates operational status
Target: Sign >50% of blocks during exclusion

Step 5: Automatic Reinstatement (Epoch N+5)

Your masternode automatically rejoins if:

You signed blocks during exclusion
Stake remains locked
No additional slashing occurred

Verify Recovery:

Node creates blocks again within first few hundred blocks of epoch N+5
Check your signatures in Block Signer contract
Confirm address in active masternode list

Best Practices Summary

Do's ✅

Use tier-3+ data centers or reputable cloud providers
Maintain a fully synced hot standby node
Follow official setup guide: https://github.com/XinFinOrg/XinFin-Node
Keep software updated with security patches
Use strong security practices (firewall, key protection)
Verify sync status daily
Document all procedures
Test failover monthly
Maintain adequate system resources
Keep >10 peer connections

Don'ts ❌

Never run two nodes with same key simultaneously
Don't use unreliable infrastructure
Don't ignore software updates
Don't skip regular maintenance
Don't store unencrypted private keys
Don't let node fall >100 blocks behind
Don't operate without failover plan
Don't use insufficient hardware
Don't neglect firewall configuration
Don't skip pre-launch checklist

Conclusion

The XDC Network's slashing mechanism maintains network stability through:

Correction over punishment - Technical issues allow recovery
Transparent enforcement - Automated via smart contracts
Network efficiency - Excludes underperforming nodes to maintain throughput
Byzantine fault tolerance - Ensures security up to 25% faulty nodes

Key Takeaways

For Prevention:

Robust infrastructure eliminates slashing risk
Proper configuration and maintenance are critical
Hot standby provides failover capability
Regular checks catch issues early

For Recovery:

Slashing is temporary, not permanent
Demonstrate liveness during exclusion
Automatic reinstatement after 4 epochs
Fix root cause to prevent recurrence

By following these guidelines, masternode operators can avoid slashing while contributing to a stable, high-performance XDC Network.

Resources

Masternode Setup: https://github.com/XinFinOrg/XinFin-Node
Documentation: https://docs.xdc.network
Network Explorer: https://xdc.blocksscan.io/
Technical Whitepaper: https://xinfin.org/docs/whitepaper-tech.pdf
Community: https://xdc.dev
Telegram: https://t.me/xinfintalk

Integrating AI with Smart Contracts on XDC Network

Rushabh Parmar — Sat, 02 May 2026 05:44:09 +0000

🎯 What You Will Build

In this guide you will manually deploy a real, working AI-powered smart contract on XDC Apothem Testnet step by step. Here is the contract we deployed live while writing this article:


Contract Address	`0xE031843227668f530DC0E59Bb093ED6763Dcd84D`
Deploy TX	`0x7fa75b52...c7843`
Loan Application TX	`0xe95ba331...4387`
AI Score Submission TX	`0xcf230923...edf9`
Network	XDC Apothem Testnet (Chain ID 51)
AI Score	711 / 1000
Risk Category	MEDIUM
Decision	✅ APPROVED

You can verify every transaction right now on XDCScan Testnet.

Introduction

Blockchain and Artificial Intelligence are two of the most transformative technologies of our time. Separately they are powerful. Together they unlock entirely new possibilities — smarter contracts, automated decision-making, and decentralized intelligence.

XDC Network is a perfect platform for this combination:

EVM compatible — write contracts in Solidity, use standard tools like Hardhat
Near-zero gas fees (~$0.00001 per transaction)
2-second finality — AI decisions confirmed almost instantly
2,000 TPS — scales to high-frequency AI-triggered actions

What Are We Building?

An AI-Powered Loan Approval System — a real-world pattern used in trade finance and credit scoring:

[ User calls applyForLoan() on-chain ]
              ↓
[ AI model analyzes applicant off-chain ]
              ↓
[ Oracle submits credit score on-chain ]
              ↓
[ Contract automatically APPROVES or REJECTS ]
              ↓
[ Decision is permanent and publicly verifiable ]

This is called the oracle pattern — the standard way to connect AI (off-chain) with smart contracts (on-chain). The AI runs off-chain because it is too expensive to run ML models on-chain. A trusted "oracle" wallet then submits the result to the smart contract.

Prerequisites

Tool	Version	Install
Node.js	v18+	nodejs.org
Python	v3.10+	python.org
MetaMask	Latest	metamask.io
Git	Any	git-scm.com

Step 1 — Add XDC Apothem Testnet to MetaMask

Open MetaMask → Settings → Networks → Add Network and fill in:

Field	Value
Network Name	XDC Apothem Testnet
RPC URL	`https://erpc.apothem.network`
Chain ID	`51`
Currency Symbol	`TXDC`
Block Explorer	`https://testnet.xdcscan.com`

Then get free test XDC from the faucet:

👉 https://faucet.apothem.network

Important: You need two wallets for this tutorial — one as the Deployer (contract owner) and one as the Oracle (the AI result submitter). Create both in MetaMask and fund both from the faucet.

Step 2 — Set Up the Project

Open your terminal (Command Prompt on Windows) and run:

mkdir xdc-ai-demo
cd xdc-ai-demo
npm init -y
npm install --save-dev hardhat@2.22.19 @nomicfoundation/hardhat-ethers@3 ethers@6 dotenv --legacy-peer-deps

Once installed, initialise Hardhat:

npx hardhat init

When prompted, select "Create a JavaScript project" and accept all defaults.

Step 3 — Configure Hardhat for XDC Apothem

Create a .env file in the root of your project — never commit this to Git:

DEPLOYER_KEY=your_deployer_private_key_here
ORACLE_KEY=your_oracle_private_key_here

To export a private key from MetaMask: click your account → Account Details → Export Private Key. Use test-only wallets only.

Add .env to .gitignore:

echo ".env" >> .gitignore

Now update hardhat.config.js:

require("@nomicfoundation/hardhat-ethers");
require("dotenv").config();

module.exports = {
  solidity: "0.8.20",
  networks: {
    apothem: {
      url:      "https://erpc.apothem.network",
      accounts: [process.env.DEPLOYER_KEY, process.env.ORACLE_KEY],
      chainId:  51,

      // ⚠️  XDC-specific settings — required for successful deployment
      // After the XDC 2.0 upgrade, Apothem minimum gas price is 12.5 gwei
      // XDC does NOT support EIP-1559 — always use gasPrice (not maxFeePerGas)
      gasPrice: 12500000000,   // 12.5 gwei in wei
    }
  }
};

Step 4 — Write the Smart Contract

Delete the default contracts/Lock.sol and create contracts/AIScoreOracle.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @title AIScoreOracle
/// @notice AI-powered loan approval contract on XDC Network
/// @dev Live on Apothem: 0xE031843227668f530DC0E59Bb093ED6763Dcd84D
contract AIScoreOracle {

    address public owner;
    address public trustedOracle;     // Wallet that submits AI scores
    uint256 public approvalThreshold; // Minimum score to get approved (0–1000)
    uint256 public totalApplications;

    struct Application {
        address applicant;
        uint256 aiScore;          // AI credit score (0–1000)
        string  riskCategory;     // "LOW", "MEDIUM", "HIGH", "PENDING"
        bool    approved;
        bool    processed;
        uint256 timestamp;
    }

    mapping(address => Application) public applications;
    address[] public applicantList;

    event LoanApplied(address indexed applicant, uint256 timestamp);
    event AIScoreSubmitted(
        address indexed applicant,
        uint256 score,
        string  risk,
        bool    approved
    );

    modifier onlyOwner()  { require(msg.sender == owner,         "Only owner");  _; }
    modifier onlyOracle() { require(msg.sender == trustedOracle, "Only oracle"); _; }

    constructor(address _oracle, uint256 _threshold) {
        owner             = msg.sender;
        trustedOracle     = _oracle;
        approvalThreshold = _threshold;
    }

    /// @notice Any user can apply for a loan (once per address)
    function applyForLoan() external {
        require(applications[msg.sender].timestamp == 0, "Already applied");

        applications[msg.sender] = Application({
            applicant:    msg.sender,
            aiScore:      0,
            riskCategory: "PENDING",
            approved:     false,
            processed:    false,
            timestamp:    block.timestamp
        });

        applicantList.push(msg.sender);
        totalApplications++;
        emit LoanApplied(msg.sender, block.timestamp);
    }

    /// @notice Oracle submits the AI credit score for an applicant
    function submitAIScore(address applicant, uint256 score) external onlyOracle {
        require(score <= 1000,                          "Score must be 0-1000");
        require(applications[applicant].timestamp != 0, "No application found");
        require(!applications[applicant].processed,     "Already processed");

        Application storage app = applications[applicant];
        app.aiScore   = score;
        app.processed = true;
        app.approved  = score >= approvalThreshold;

        if      (score >= 800)               app.riskCategory = "LOW";
        else if (score >= approvalThreshold) app.riskCategory = "MEDIUM";
        else                                 app.riskCategory = "HIGH";

        emit AIScoreSubmitted(applicant, score, app.riskCategory, app.approved);
    }

    /// @notice Read the loan decision for any address
    function getDecision(address applicant) external view returns (
        uint256 score,
        string memory risk,
        bool    approved,
        bool    processed,
        uint256 appliedAt
    ) {
        Application memory app = applications[applicant];
        return (app.aiScore, app.riskCategory, app.approved, app.processed, app.timestamp);
    }

    /// @notice Total number of applicants ever
    function getApplicantCount() external view returns (uint256) {
        return applicantList.length;
    }
}

What each function does

Function	Who Calls It	What It Does
`applyForLoan()`	Any user	Registers a loan application on-chain
`submitAIScore(address, uint256)`	Oracle only	Submits AI score, triggers approve/reject
`getDecision(address)`	Anyone	Reads the stored decision for any address
`getApplicantCount()`	Anyone	Returns total number of applicants

Step 5 — Compile the Contract

npx hardhat compile

Expected output:

Compiled 1 Solidity file successfully (evm target: paris).

Step 6 — Write the Deploy Script

Delete scripts/deploy.js and recreate it:

// scripts/deploy.js
const hre = require("hardhat");

async function main() {
  const [deployer, oracle] = await hre.ethers.getSigners();

  console.log("Deploying AIScoreOracle to XDC Apothem...\n");
  console.log("Deployer :", deployer.address);
  console.log("Oracle   :", oracle.address);

  const deployerBalance = await hre.ethers.provider.getBalance(deployer.address);
  console.log("Balance  :", hre.ethers.formatEther(deployerBalance), "TXDC\n");

  // Deploy: pass oracle address and approval threshold of 700 out of 1000
  const AIScoreOracle = await hre.ethers.getContractFactory("AIScoreOracle");
  const contract      = await AIScoreOracle.deploy(oracle.address, 700, {
    gasLimit: 2_000_000,      // Set manually — XDC estimateGas is unreliable
    gasPrice: hre.ethers.parseUnits("12.5", "gwei")  // Apothem minimum after XDC 2.0
  });

  await contract.waitForDeployment();

  const contractAddress = await contract.getAddress();
  const deployTx        = contract.deploymentTransaction();

  console.log("Contract deployed!");
  console.log("Address  :", contractAddress);
  console.log("TX Hash  :", deployTx.hash);
  console.log("Explorer :", `https://testnet.xdcscan.com/address/${contractAddress}`);
  console.log("TX Link  :", `https://testnet.xdcscan.com/tx/${deployTx.hash}`);
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Step 7 — Deploy to XDC Apothem

npx hardhat run scripts/deploy.js --network apothem

You will see output like:

Deploying AIScoreOracle to XDC Apothem...

Deployer : 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5
Oracle   : 0xE65AbC44aa93B25320D9BB9eB6B5cEa3C0a21872
Balance  : 1000.0 TXDC

Contract deployed!
Address  : 0xE031843227668f530DC0E59Bb093ED6763Dcd84D
TX Hash  : 0x7fa75b52a379b20a1c3a4d8966a7c78f1ac29ba69eb25dded01185dcc66c7843
Explorer : https://testnet.xdcscan.com/address/0xE031843227668f530DC0E59Bb093ED6763Dcd84D
TX Link  : https://testnet.xdcscan.com/tx/0x7fa75b52a379b20a1c3a4d8966a7c78f1ac29ba69eb25dded01185dcc66c7843

Open the Explorer link — your contract is live on XDC Apothem! 🎉

Step 8 — User Applies for a Loan

Write an interaction script. Create scripts/apply.js:

// scripts/apply.js
const hre = require("hardhat");

const CONTRACT_ADDRESS = "YOUR_DEPLOYED_CONTRACT_ADDRESS";

async function main() {
  const [deployer] = await hre.ethers.getSigners();

  const AIScoreOracle = await hre.ethers.getContractFactory("AIScoreOracle");
  const contract      = AIScoreOracle.attach(CONTRACT_ADDRESS);

  console.log("Applying for a loan from:", deployer.address);

  const tx = await contract.applyForLoan({
    gasLimit: 300_000,
    gasPrice: hre.ethers.parseUnits("12.5", "gwei")
  });
  await tx.wait();

  console.log("Application submitted!");
  console.log("TX Hash  :", tx.hash);
  console.log("TX Link  :", `https://testnet.xdcscan.com/tx/${tx.hash}`);

  // Check pending status
  const [score, risk, approved, processed] = await contract.getDecision(deployer.address);
  console.log("\nOn-chain status:");
  console.log("  Risk      :", risk);       // PENDING
  console.log("  Processed :", processed);  // false
  console.log("  Score     :", score.toString());
  console.log("\nWaiting for AI oracle to score this application...");
}

main().catch((err) => { console.error(err); process.exit(1); });

Run it:

npx hardhat run scripts/apply.js --network apothem

Output from our live deployment:

Applying for a loan from: 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5
Application submitted!
TX Hash  : 0xe95ba3312aa0e710fb45cc6980c271a499570c65d89eb45cadda118719d64387
TX Link  : https://testnet.xdcscan.com/tx/0xe95ba3312aa0e710fb45cc6980c271a499570c65d89eb45cadda118719d64387

On-chain status:
  Risk      : PENDING
  Processed : false
  Score     : 0

Waiting for AI oracle to score this application...

Step 9 — AI Oracle Submits the Score

Now the oracle wallet submits the AI-generated score. Create scripts/submit_score.js:

// scripts/submit_score.js
const hre = require("hardhat");

const CONTRACT_ADDRESS = "YOUR_DEPLOYED_CONTRACT_ADDRESS";
const APPLICANT        = "THE_APPLICANT_WALLET_ADDRESS";
const AI_SCORE         = 711;   // Replace with your AI model's output (0–1000)

async function main() {
  // Use the second signer — the oracle wallet
  const [, oracle] = await hre.ethers.getSigners();

  const AIScoreOracle = await hre.ethers.getContractFactory("AIScoreOracle");
  const contract      = AIScoreOracle.attach(CONTRACT_ADDRESS);

  console.log("Oracle wallet     :", oracle.address);
  console.log("Applicant         :", APPLICANT);
  console.log("AI Credit Score   :", AI_SCORE, "/ 1000");
  console.log("Approval Threshold: 700 / 1000");
  console.log("Decision          :", AI_SCORE >= 700 ? "APPROVE" : "REJECT");
  console.log("\nSubmitting AI score to blockchain...");

  const tx = await contract.connect(oracle).submitAIScore(APPLICANT, AI_SCORE, {
    gasLimit: 300_000,
    gasPrice: hre.ethers.parseUnits("12.5", "gwei")
  });
  await tx.wait();

  console.log("\nAI score committed on-chain!");
  console.log("TX Hash  :", tx.hash);
  console.log("TX Link  :", `https://testnet.xdcscan.com/tx/${tx.hash}`);

  // Read final decision
  const [score, risk, approved, processed] = await contract.getDecision(APPLICANT);
  console.log("\nFinal decision from contract:");
  console.log("  AI Score   :", score.toString(), "/ 1000");
  console.log("  Risk Level :", risk);
  console.log("  Processed  :", processed);
  console.log("  Decision   :", approved ? "APPROVED ✅" : "REJECTED ❌");
}

main().catch((err) => { console.error(err); process.exit(1); });

Run it:

npx hardhat run scripts/submit_score.js --network apothem

Output from our live deployment:

Oracle wallet     : 0xE65AbC44aa93B25320D9BB9eB6B5cEa3C0a21872
Applicant         : 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5
AI Credit Score   : 711 / 1000
Approval Threshold: 700 / 1000
Decision          : APPROVE

Submitting AI score to blockchain...

AI score committed on-chain!
TX Hash  : 0xcf230923452c8d054435b685ce67f7ad138e4b37e1688e2e8a6852b8af12edf9
TX Link  : https://testnet.xdcscan.com/tx/0xcf230923452c8d054435b685ce67f7ad138e4b37e1688e2e8a6852b8af12edf9

Final decision from contract:
  AI Score   : 711 / 1000
  Risk Level : MEDIUM
  Processed  : true
  Decision   : APPROVED ✅

Step 10 — Verify Everything On-Chain

Open the live contract on XDCScan Testnet:

👉 https://testnet.xdcscan.com/address/0xE031843227668f530DC0E59Bb093ED6763Dcd84D

Transactions tab — all 3 transactions visible:

TX Hash	Action	Gas Used
`0x7fa75b52...`	Contract deploy	907,449
`0xe95ba331...`	`applyForLoan()`	161,014
`0xcf230923...`	`submitAIScore(711)`	83,122

Events tab — two on-chain events emitted:

LoanApplied(
  applicant = 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5,
  timestamp = 1746...
)

AIScoreSubmitted(
  applicant = 0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5,
  score     = 711,
  risk      = "MEDIUM",
  approved  = true
)

Read Contract tab — call getDecision(0x2D9305d0c20106beDA3C19d9B8ac8f8AD061b0D5):

score     → 711
risk      → MEDIUM
approved  → true
processed → true
appliedAt → 1746...

Every decision is permanent, immutable, and publicly verifiable — no central authority, no trust required.

Step 11 — Replace Demo AI with a Real Model

In submit_score.js the score is hardcoded as 711. In production, replace that with a real ML model call.

Python scikit-learn example:

# ai_model.py
import joblib
import numpy as np

model = joblib.load("credit_model.pkl")

def get_ai_score(applicant_address: str) -> int:
    """
    Fetch applicant data, run the model, return a score 0–1000.
    """
    features = fetch_applicant_features(applicant_address)
    probability = model.predict_proba([features])[0][1]
    return int(probability * 1000)

Then expose it as an API:

# oracle_api.py  (Flask)
from flask import Flask, jsonify, request
from ai_model import get_ai_score

app = Flask(__name__)

@app.route("/score", methods=["POST"])
def score():
    address = request.json["address"]
    return jsonify({ "score": get_ai_score(address) })

And call it from your Hardhat script:

// In submit_score.js — replace the hardcoded score:
const response = await fetch("http://localhost:5000/score", {
    method:  "POST",
    headers: { "Content-Type": "application/json" },
    body:    JSON.stringify({ address: APPLICANT })
});
const { score: AI_SCORE } = await response.json();

Everything else — the Solidity contract, the Hardhat scripts, the on-chain verification — stays exactly the same.

Important XDC Developer Notes

These are lessons learned from our actual deployment:

Issue	Root Cause	Fix
`under min gas price`	XDC 2.0 upgrade raised Apothem minimum	Use `12.5 gwei` minimum
`estimateGas` returns null	XDC Apothem doesn't support `eth_estimateGas` reliably	Set `gasLimit` manually
EIP-1559 tx rejected	XDC does not support type-2 transactions	Use `gasPrice` not `maxFeePerGas`

Full Live Transaction Summary

All transactions verified on XDCScan Testnet:

Step	TX Hash	Link
Deploy contract	`0x7fa75b52...c7843`	View ↗
Apply for loan	`0xe95ba331...4387`	View ↗
AI score (711) submitted	`0xcf230923...edf9`	View ↗

Key Takeaways

XDC is fully EVM-compatible — Solidity and Hardhat work exactly as on Ethereum
The oracle pattern is the standard way to bridge AI (off-chain) and smart contracts (on-chain)
XDC Apothem gas settings: minimum 12.5 gwei, always set gasLimit manually, avoid EIP-1559
XDC's near-zero fees make per-user AI-triggered actions economically viable at scale
Every decision is permanent, immutable, and verifiable on XDCScan Testnet

Resources

How to Speed Up XDC Network Node Sync Using Snapshots

Rushabh Parmar — Tue, 29 Jul 2025 14:01:27 +0000

Running a full node on XDCNetwork is crucial for decentralization, data verification, and direct interaction with the XDC Network. However, syncing a full node from scratch can be a time-consuming and resource-intensive process, potentially taking days or even weeks for archive nodes. This is where snapshots come in as a game-changer, offering a fast and efficient way to get your XDC Network node up and running.

This article will delve into what snapshots are, why they are essential for syncing, and provide a step-by-step guide on how to download and utilize them to set up a full node or archive node on the XDC Network.

What are Blockchain Snapshots?

In the context of blockchain, a *snapshot * is essentially a complete "photograph" of the blockchain's state at a specific block height. This snapshot captures all current account balances, smart contract states, and other relevant data, but crucially, it doesn't include the entire historical transaction data that led to that state. Think of it as having the finished painting without needing to re-watch every brushstroke.

Why are Snapshots Crucial for Syncing a Full Node or Archive Node on XDC Network?

The traditional method of syncing a full node or archive node on XDC Network involves downloading and verifying every single block from the genesis block (the very first block) up to the current one. This process requires significant computational resources and bandwidth. Snapshots offer several key advantages:

Faster Synchronization: By downloading a recent snapshot, your node can start from a pre-verified state, drastically reducing the sync time from days or weeks to hours. This allows new participants to join the network quickly and helps existing nodes recover faster from any disruptions.
Reduced Resource Consumption: Since you're not processing the entire blockchain history, snapshots minimize the CPU, memory, and bandwidth required for initial synchronization, making it more efficient to run nodes.
Improved Efficiency and Scalability: Faster node participation leads to a more distributed and robust network, contributing to overall network efficiency and scalability.
Enhanced Reliability: Snapshots provide a stable and verified starting point, reducing the potential for errors that can occur during a full blockchain download.

Essentially, snapshots provide a "shortcut" for nodes to quickly acquire the latest XDC Network state, enabling them to catch up and participate in the network much faster and with fewer resources.

Setting Up a Full Node on XDC Network with Snapshots: A Step-by-Step Guide

Prerequisites

A server or cloud instance (minimum 16 GB RAM, 1.5 TB storage)
Ubuntuoperating system
Basic Linux command-line knowledge

Setting up the Node Environment using Bootstrap

Its the primary options for setting up your XDC Network node environment: using the bootstrap.sh script for a quick setup

Using the Bootstrap Command for Quick Setup
This command automates the installation of necessary dependencies and sets up the basic node environment.

sudo su -c "bash <(wget -qO- https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/setup/bootstrap.sh)" root

You will be prompted to enter:

XinFin Network (mainnet/testnet/devnet): Type mainnet for the main XDC Network.
XinFin MasterNode Name: Provide a name for your node (e.g.,Rushabh-Snapshot-Node).
Generate new private key and wallet address. If you have your own key, you can change after this and restart the node: Enter y or Y and continue

Once the installation on your Ubuntu server is complete, attach to the node using the following command to verify that the blockchain synchronization has begun

bash xdc-attach.sh

You can monitor the status of your node using the above command or by visiting the official stats page at https://xinfin.network/#stats Once you've confirmed that the node has begun syncing from the genesis block, stop the node by running:

bash docker-down.sh

After stopping your node, proceed to delete the existing XDC directory to prepare for the snapshot data

After deleting the XDC folder, you can now proceed to download and apply the latest snapshot.

To download the XDC Network Mainnet snapshot, use the appropriate command based on the type of node you’re setting up:

For a Full Node (latest state only): https://download.xinfin.network/xdcchain.tar
For an Archive Node (complete history): http://downloads.xinfin.network/xdcchain_archive.tar

Note: Snapshots are updated approximately every 20 days.

Once the xdc.tar file has been downloaded, extract the snapshot by running the following command:

tar -xvzf xdc.tar

This will unpack the archive and create the XDC directory containing the necessary blockchain data.

Once the XDC folder has been extracted, navigate into it and perform the following cleanup steps:

Delete the nodekey file:

rm -rf nodekey

Delete the transactions.rlp file:

rm -rf transactions.rlp

After removing these files, return to the mainnet directory and open the .env file.
In the configuration, locate the ENABLE_RPC variable and set it to true to enable RPC access:

ENABLE_RPC=true

In the .env file, you’ll find the ENABLE_RPC parameter set to false by default. Update it to enable RPC access by changing it to: ENABLE_RPC=true

If you are setting up a full node, you can now start your node without any additional changes.

However, if you are configuring an archive node, you must modify the start-node.sh script by adding the following flag: --

gcmode=archive

Note: This flag is only required for archive nodes to retain full blockchain history.

Once you've made the necessary changes, start your node with:

bash docker-up.sh

You can monitor your node’s status by attaching to the console using the following command:

bash xdc-attach.sh

Alternatively, you can view real-time sync progress and network activity on the official stats page:https://xinfin.network/#stats

If your node is not connecting to peers or you're experiencing issues with peer discovery, run the following command to manually connect to the network:

bash peer.sh

This will help your node establish connections with other active nodes on the XDC Network.

After executing the command, your node will begin establishing connections with peers on the XDC Network, allowing it to sync and participate in the network more effectively.

Accessing the RPC Endpoint: Once your node is fully synced, you can use its dedicated RPC endpoint.

The RPC port used is 8989.
The WebSocket port used is 8888.

If you've configured your server's firewall to allow external access to these ports (which is necessary for dApps to connect from outside your server), you would replace localhost with your server's public IP address or domain name.

Conclusion

Setting up a dedicated RPC node on the XDC Network, especially for DApps requiring high performance and reliability, is greatly simplified by leveraging snapshots. By following this comprehensive guide, you can efficiently set up and synchronize your XDC full node, providing a robust and responsive gateway for your decentralized applications to interact with the XDC blockchain. Snapshots are an invaluable tool for maintaining a healthy and efficient decentralized ecosystem, ensuring seamless communication and robust data management for developers and network operators alike.

Securely Broadcast Offline-Signed Crypto Transactions Across XDC, Ethereum, Bitcoin, Solana & XRP

Rushabh Parmar — Fri, 23 May 2025 07:37:51 +0000

In the evolving landscape of cryptocurrency, ensuring the security of transactions is paramount. Broadcasting raw, offline-signed transactions stands out as a robust method to safeguard private keys while maintaining transaction efficiency. The XDC Network's Raw Transaction Broadcast Tool offers a streamlined, non-custodial solution to propagate these transactions across multiple blockchains, including XDC, Ethereum, Bitcoin, Solana, and XRP.

🔐 Understanding Raw Offline Transactions

A raw transaction is a serialized data structure, often in hexadecimal format, encompassing all necessary transaction details—sender, recipient, amount, fees, and signatures—ready for network broadcast. When these transactions are signed in an offline environment, they become offline transactions, ensuring that private keys remain isolated from internet-connected devices. This approach enhances security by mitigating exposure to potential online threats.

🛡️ Benefits of Offline Signing

Enhanced Security: Private keys never touch online systems, reducing vulnerability to hacks and malware.
Improved Privacy: Offline signing keeps sensitive data away from internet exposure.
Hardware Wallet Compatibility: Seamlessly integrates with devices like Ledger, Trezor, and D'CENT for secure transaction signing.
Cold Storage Integration: Facilitates transactions from air-gapped systems without compromising key safety.

🌐 Introducing the XDC Raw Transaction Broadcast Tool

Accessible at https://broadcast.xinfin.network/build/raw-tx, this web-based utility empowers users to broadcast raw, signed transactions across multiple blockchain networks. Key features include:

Multi-Chain Support: Compatible with XDC, Ethereum, Bitcoin, Solana, and XRP networks.
Transaction Decoding: Automatically parses and displays transaction details for verification before broadcasting.
QR Code Functionality: Enables scanning of transaction data from offline devices, facilitating secure and error-free broadcasting.
Non-Custodial Design: Does not require private keys or wallet access, ensuring user control over funds.

🧭 Step-by-Step Guide to Broadcasting Transactions

Prepare Your Signed Transaction Offline: Utilize your preferred wallet or tool to create and sign the transaction in an offline environment, generating a raw transaction hex string.
Access the Broadcast Tool: Navigate to https://broadcast.xinfin.network/build/raw-tx on an internet-connected device.
Select the Appropriate Network: Choose the blockchain network corresponding to your transaction.
Input the Raw Transaction: Paste the signed transaction hex into the provided field or scan the QR code if available.
Verify Transaction Details: Review the decoded information to ensure accuracy.
Broadcast the Transaction: Click the "Publish" button to send the transaction to the selected network.
Confirm Submission: Upon successful broadcast, the tool will display the transaction hash for tracking purposes.

📸 Leveraging QR Code Functionality

The tool's QR code feature enhances the offline-to-online workflow:

Scanning: Easily import signed transactions from offline devices by scanning QR codes.
Sharing: Generate QR codes for transactions to facilitate secure sharing and storage.

🔒 Security and Non-Custodial Design Emphasis

Security is paramount when handling cryptocurrency transactions, and the XDC broadcast tool is built with that in mind. It is a non-custodial tool, meaning it never takes control of your assets or keys at any point. You do not create accounts or input private keys; you only input signed transactions, which by design cannot be used to derive your private key or alter your balance except as intended. This ensures that you retain full custody of your cryptographic keys and coins at all times.

🚀 Conclusion & Call to Action

Broadcasting raw offline transactions is a smart strategy for anyone serious about crypto security. The XDC Network's multi-chain broadcast tool makes this process accessible and convenient, whether you're sending an XDC transaction broadcast from a cold wallet, pushing an Ethereum raw transaction from a safe offline signer, or handling Bitcoin, Solana, or XRP transfers. By incorporating offline signing and this broadcast utility into your workflow, you gain peace of mind that your keys are safe while still enjoying the flexibility to transact on major blockchains.

Call to Action: Ready to enhance your crypto transaction security? Start using the raw transaction broadcast tool today. Head over to https://broadcast.xinfin.network/build/raw-tx and give it a try with a small test transaction. Experience how straightforward it is to broadcast raw crypto transactions offline. By adopting this tool, you're taking control of your crypto in the most secure way possible. Developers and power users alike are encouraged to incorporate offline signing and broadcasting into their workflow—let's make the crypto ecosystem safer, one offline-signed transaction at a time.

Disclaimer

Cryptocurrency transactions involve significant risks, including but not limited to market volatility, technological failures, and regulatory changes. Users are strongly advised to conduct their own research and consult with qualified professionals before engaging in any cryptocurrency activities.

XDC Safe Transaction Builder: Streamlining Multisig Transactions

Rushabh Parmar — Tue, 11 Feb 2025 11:51:55 +0000

Introduction

XDC Safe is a multisig wallet built for the XDC Network, designed to enhance security and streamline transactions for teams and organizations. In our latest update, we have introduced the Transaction Builder, a powerful tool that allows users to batch multiple transactions into a single confirmation process. This makes interacting with smart contracts and performing complex operations significantly more efficient.

What is the Transaction Builder?

The Transaction Builder in XDC Safe enables users to create and execute multiple transactions in a single batch, reducing manual confirmations and improving efficiency.

Key Features

Batch Transactions: Group multiple actions (such as token transfers, approvals, and contract calls) into one transaction, reducing execution steps.
User-Friendly Interface: A visual interface allows users to easily add, edit, and review transactions before execution.
Smart-Contract Interactions: Interact with any verified smart contract directly from XDC Safe.
Simulation Capabilities: Users can simulate transactions to preview the expected outcome and gas fees before execution.
**Security & Efficiency: **Reduces the number of on-chain interactions, enhancing security and optimizing transaction costs.

Why We Added the Transaction Builder to XDC Safe

XDC Safe was developed to provide seamless multisig functionality for XDC users, ensuring secure and efficient management of assets and contract interactions. The Transaction Builder further enhances this experience by allowing users to interact with smart contracts in a more streamlined way, eliminating the need to confirm each transaction separately.

How to Use the XDC Safe Transaction Builder

1. Access the Transaction Builder

Navigate to the New Transaction section in XDC Safe and select Transaction Builder.

2. Select a Smart Contract

Enter the XDC address of the smart contract you want to interact with.

3. Specify the ABI

For contracts verified on XDCScan Explorer, the ABI will be automatically fetched.
If not, manually enter the ABI in the provided input field.

4. Select a Method

Choose the method you wish to execute from the available contract functions.
XDC Safe supports both read and write functions.

5. Define Parameters

The interface will display the parameters for the selected method.
If necessary, enter values such as token amounts or recipient addresses.

6. Add to Batch

Click Add Transaction to include it in the batch.
You can continue adding multiple transactions before executing them all at once.

7. Review and Execute

Before submission, review the batched transactions.
You can also bookmark, download, or share the transaction batch with other signers for approval.

8. Confirm and Sign

Once reviewed, confirm the transaction.

Depending on your multisig setup, other signers will need to approve before execution.

Advantages of Using the XDC Safe Transaction Builder

✅ Efficiency: Reduce the number of confirmations needed for multiple transactions.
✅ Security: Minimizes the number of interactions, lowering potential attack surfaces.
✅ Cost-Effective: Reduces overall gas fees by bundling transactions.
✅ Seamless Collaboration: Share and execute transaction batches easily with multiple signers.

Conclusion

With the addition of the Transaction Builder, XDC Safe has become even more powerful, allowing users to interact with smart contracts efficiently and securely. This update ensures that teams and organizations managing funds and contracts on the XDC Network can streamline their processes while maintaining top-tier security.

💡 For any questions regarding XDC Safe or the XDC Network, feel free to engage with the community at XDC.dev

🔗 Start using the XDC Safe Transaction Builder today: XDC Safe 🚀

While XDC Safe offers a robust multisig experience, users exploring multisig solutions on the XDC Network can also try other wallets like Orry and Yodaplus Vault. Both platforms provide secure, multi-signature wallet management tailored for teams, allowing users to safeguard assets, co-sign transactions, and maintain control in a decentralized manner. Exploring these alternatives can help users choose the best fit for their specific workflow and governance needs

Disclaimer:

The information provided in this article is for educational and informational purposes only. It does not constitute financial, investment, or legal advice. Users are encouraged to conduct their own research and exercise caution when interacting with smart contracts and multisig wallets. While we strive to keep content accurate and up to date, we do not guarantee the security, functionality, or availability of any third-party tools or platforms mentioned, including XDC Safe, Orry, and Yodaplus Vault. Use at your own risk.

Update: XDC Apothem Network Experiences Surge in Traffic: Public RPC Update

Rushabh Parmar — Thu, 05 Sep 2024 16:12:03 +0000

On 4th September, the XDC Apothem Network’s public RPC (https://erpc.apothem.network) experienced temporary downtime due to increased traffic. Over 24 hours, the public RPC saw 17.15 million hits, which made the service unavailable for some users.

In response, the DevOps team quickly addressed the issue. They started by adding a node balancer and deploying multiple additional nodes across all public RPC endpoints. This step aims to distribute traffic more evenly and avoid similar problems in the future.
A rate limit has been applied to the public RPC to protect the network from DDoS attacks further. If users encounter a rate limit when connecting, it is recommended that they set up a dedicated RPC for a more stable and reliable connection. For details on setting up a dedicated RPC, refer to the guide here: https://www.xdc.dev/ruslan_wing/setting-up-an-rpc-node-server-for-your-dapp-on-xdc-network-a-comprehensive-guide-3dm9.

For Non-Technical Users:
If you’re a non-technical user, you can also get a paid dedicated RPC (for Mainnet or Apothem Network) from third-party providers like Ankr, Indsoft, Blocksscan, NowNodes, Tatum, or Asternodes. These providers offer reliable services without the need to set it up yourself.
These steps should help prevent future downtime and improve the overall stability of the public RPC.