Integrate Paxeer X from the stack you already run. Every client verifies a receipt locally, so you check it in your language instead of trusting the node that answered. Shared conformance vectors hold the clients to one canonical wire layout. Coverage is uneven: only Rust exposes register, funding and send-activity as methods, Python reaches two of them through a generic RPC call, and the other clients list them without a callable method. Each quickstart page names what it carries.

What it does

Paxeer X ships client libraries in Rust, TypeScript, Python, Go, JVM, Swift and .NET. Each one carries its own sources and tests, and each one can verify a receipt locally without trusting the node that served it. Shared conformance vectors under platform/sdk/conformance check that the clients agree byte-for-byte on the wire layout. Coverage of the register, faucet and send calls is not the same in every language, and the per-language quickstart page states which of those four steps a package carries.

Key capabilities

• Seven language clients: Rust, TypeScript, Python, Go, JVM, Swift and .NET.
• Local receipt verification in every client, so a receipt is checked without trusting the responding node.
• Shared conformance vectors that hold the clients to one canonical wire layout.
• Joined account reads through one network endpoint: identities, balances and unified history.
• Rust exposes register, request_funds and send_activity as direct methods.
• Each quickstart page names exactly which calls its package carries and which it does not.

Differentiators

All seven clients verify receipts locally, and platform/sdk/conformance holds shared fixtures that bind every client to the same canonical bytes. The suite's own README limits that to wire-layout and state-transition agreement; it is not execution, finality or checkpoint-inclusion evidence.

Outcomes

• Verify receipts in your own language, without trusting the responding node.
• Read joined identities, balances and unified history through one endpoint.
• Check the quickstart table before you code, so parity gaps surface early.

Technical notes

• Runtime floors: Node.js 22 or newer, ESM-only, for TypeScript; Python 3.11 or newer, with account derivation behind a derivation extra; the Rust toolchain is pinned to 1.91.1.
• All seven clients are at version 0.1.0, and the Python package still declares Development Status :: 3 - Alpha.
• Parity is uneven. Only Rust carries register, request_funds and send_activity as real methods. Python reaches them through PaymentRpc.call("lx_register", …) and PaymentRpc.call("lx_requestFunds", …). The TypeScript JsonRpcClient carries neither. Go, JVM, Swift and .NET list them as catalog entries with no callable method.
• AgentHttpTransport in TypeScript, Python and Swift is programs-only: agent.register, faucet.claim, prepare and submit return unavailable-capability. Go ships no agent-plane HTTP transport.
• TypeScript depends on @noble and @scure, not on ethers or viem.
• Conformance runners exist for Go and JVM (run-go.sh, run-jvm.sh); there is no Swift or .NET runner.
• Install paxeer-xdk for the network-wide client and layerx-sdk for the agent domain; both are published for TypeScript and Python.

import { PxClient } from "paxeer-xdk";

const px = new PxClient({ endpoint: process.env.PX_GATEWAY! });
const ids = await px.resolveAccount("0x1111111111111111111111111111111111111111");
const page = await px.getUnifiedHistory(ids.evmAddress!, { limit: 25 });

for (const row of page.items) {
  console.log(row.side, row.asset, row.amount);
}

More in Developers