x402eCash — x402 on XEC, Tonalli & Agent Payments

Protocol primer

What is x402?

x402 is an open, transport-agnostic internet payment standard. Version 2 separates core payment types and logic from their representation over transports such as HTTP, MCP and A2A.

Request

A client or agent requests a protected resource.

Requirements

The resource server signals payment requirements, including acceptable scheme, network, amount, asset and destination.

Payload

The client selects an accepted option and creates the appropriate signed payment payload.

Retry

The client retries through the transport with payment information attached.

Verify & settle

The resource server verifies locally or through a facilitator and follows the selected scheme's settlement flow.

Return resource

After successful processing, the protected result and settlement response can be returned.

Protocol language follows the official x402 v2 specification at the inspected commit. x402-XEC currently uses v1-era shapes; this site does not present them as v2-compatible yet.

Research substrate

Why XEC?

The research question is practical: how can native UTXO money participate in machine-readable payment workflows while keeping authorization, policy and custody boundaries explicit?

01

Native UTXO money

XEC provides a direct transaction model for studying exact-value, on-chain settlement without introducing a synthetic application balance.

02

Small-value economics

eCash is relevant to micropayment-style experiments where the cost and operational shape of small transfers matter. No performance number is assumed here.

03

Read and verify

Chronik supplies indexing and read interfaces for controlled UTXO discovery, transaction inspection and eventual confirmation evidence.

04

Wallet boundary

Tonalli is the intended user-agent boundary: exact details are displayed, approval is explicit, and key material remains wallet-owned.

05

Policy before money

The CAE and Agentic Contract V1 model intent, policy, human approval, signing, broadcast and confirmation as separate states.

06

Machine-native workflows

HTTP, paid APIs and later MCP/A2A adapters provide a path to investigate commerce between software agents without pretending it is live today.

Verified components

What xolosArmy Network has already built

Each card is scoped to repository evidence. “Implemented” means code exists at the linked revision; it does not automatically mean production deployment or live-fund execution.

Implemented · Experimental

x402-XEC protocol scaffold

Strict invoice and authorization schemas, deterministic resource binding, replay controls, local facilitator verification, Axios and Express adapters, offline payment preparation and transaction construction.

Inspect x402-XEC at 8696c28

Tested · Dry run

Browser HTTP 402 dry-run

The recorded flow received 402, requested mock approval, attached PAYMENT-SIGNATURE, retried and returned the protected resource. The result explicitly reports broadcasted: false.

Read the recorded result

Integrated · Authorization dry run

Tonalli authorization boundary

Tonalli exposes an explicit approval modal and wallet-owned signing for the authorization message. The adapter rejects prepared-transaction signing as unsupported.

Inspect the Tonalli adapter

Implemented

Agentic Contract V1

A strict state machine separates intent, policy decision, wallet approval request, human approval, signed transaction, broadcast and confirmation. Optional x402 context is metadata—not permission.

Read the canonical contract

Implemented · Money execution frozen

CAE / Tonalli Agents

Fail-closed decisions, kill switch, destination allowlists, cumulative daily limits and replay controls are implemented. Even an approved policy path stops before signing and broadcast.

Inspect Cycle 1 security

Adjacent experimental infrastructure

Tonalli Commerce Relay

Order, identity, reputation, evidence and dispute scaffolding explores a broader XEC commerce lifecycle. Real XEC escrow, broadcast and confirmation tracking remain pending.

Read production-readiness boundaries

System view

Architecture with boundaries

The diagram is a target integration map, not a live execution trace. Solid gold, solid blue and dashed neutral boundaries intentionally distinguish current evidence from integration and future real-money work.

Evidence snapshot · 2026-08-25

Status matrix

Current source truth wins. “Pending” and “not enabled” are deliberate engineering statuses, not omissions hidden behind marketing language.

Current implementation status for x402eCash capabilities
Capability	Status	Evidence / boundary
HTTP 402 protocol scaffold for XEC	Experimental implementation	Package workspace
Core invoice and HTTP resource binding	Implemented	Canonical hash model
Replay protection	Implemented	Atomic nonce boundary; the in-memory store remains single-process.
Local facilitator verification	Implemented	Fixture-backed default, real read adapter opt-in
Offline XEC transaction construction	Implemented	No network or broadcast API
Read-only Chronik adapters	Implemented · opt-in	Explicit endpoint required; fixtures remain the default.
Browser HTTP 402 E2E	Tested in dry-run	`broadcasted: false`; mock approval and signature.
Tonalli approval UI	Implemented	Exact public metadata is displayed
Tonalli authorization-message signing	Dry-run integration	All-zero funding outpoint placeholder; no transaction created.
Real Tonalli transaction signing for x402	Not yet proven	`signPreparedTransaction` returns unsupported.
Automatic x402 mainnet payment	Not enabled	Broadcast is separate, opt-in and not wired to Axios or the demo.
Autonomous agent real-fund spending	Frozen	Money-freeze tests
x402 v2 semantic alignment	Pending	Current scaffold uses v1-era shapes and provisional `xec:mainnet`.
Standardized XEC network identifier	Pending	Upstream v2 requires CAIP-2; inspected upstream support docs contain no XEC entry.
MCP transport integration	Research / pending	Upstream v2 transport reference
A2A payment integration	Research / pending	Upstream v2 transport reference
Paid production API	Pending	This GitHub Pages portal is static and has no settlement backend.
Bazaar / discovery integration	Pending	Upstream extension inspected

No invented dates

Evidence-driven roadmap

The ordering follows dependency and safety boundaries: modernize the protocol contract first, then prove signing and controlled settlement before adding paid services or agent transports.

A

Protocol modernization

Compare x402-XEC with current x402 v2.
Migrate wire semantics where required.
Establish a standardized XEC network identifier and document the (scheme, network) pair.
Update compatibility and security tests.

B

Tonalli execution boundary

Preserve explicit approval.
Add real prepared-transaction signing inside Tonalli.
Keep wallet secrets outside x402-XEC.
Bind invoice, resource, amount and payTo exactly.

C

Controlled XEC E2E

Read-only UTXO discovery and deterministic plan.
Tiny controlled value with explicit approval.
Exact signing and separately authorized broadcast.
Chronik verification, confirmation and reproducible evidence.

D

First paid API

Create a real x402-protected resource using XEC.
Deploy the settlement backend separately.
Keep this GitHub Pages portal honest about its static role.

E

Agent payments

Connect AgentIntentV1 to CAE.
Bind x402 requirements to Tonalli policy and approval.
Deliver the protected resource only after verified payment state.

F

MCP / A2A

Track current upstream transport specifications.
Build adapters only after the v2 XEC scheme is stable.
Preserve the same policy and custody boundaries across transports.

G

Discovery

Explore Bazaar metadata for XEC-paid resources.
Validate catalog claims against live evidence.
Publish no discoverable endpoint before the paid API exists.

Build in public

Evidence Ledger

Milestones are classified as code, dry-run, staging authorization or frozen. A live classification requires transaction and network evidence; none is claimed below.

Dated x402eCash research evidence ledger
Date	Milestone	Classification	Immutable evidence
2026-07-01	Browser HTTP 402 flow completed with protected resource returned and `broadcasted: false`.	Dry-run	Result · 21f20d4 tested
2026-07-02	Tonalli browser wallet boundary added with explicit authorization approval and wallet-owned message signing.	Code	a743f904
2026-07-02	Tonalli payment approval modal added; approval does not transmit or pay a transaction.	Code	b74631b5
2026-07-03	Trusted staging authorization route added with origin/path allowlisting and an authorization-only result.	Staging authorization	4d5ee146
2026-07-18	Commerce Relay documented order and trust scaffolding while real escrow and XEC broadcast remained pending.	Adjacent scaffold	5a820dce
2026-07-30	Agentic Contract V1 merged with strict intent-to-confirmation ordering and display-safe x402 handoff.	Code	cfe4cb15
2026-07-30	CAE Cycle 1 merged with fail-closed policy and explicit money-execution freeze.	Frozen	7b90c805
2026-08-25	Official x402 v2 specification and HTTP, MCP, A2A, CAIP-2 and Bazaar sources re-inspected for this portal.	Upstream research	f8a3682d

Inspected repositories

x402-XEC8696c28 RMZWallet176fe40 tonalli-corecfe4cb1 tonalli-agents7b90c80 commerce-relay5a820dc x402 upstreamf8a3682

Research direction

Evidence before autonomy.

The next meaningful proof is not a dashboard counter. It is a v2-aligned, explicitly approved, tiny-value XEC payment with reproducible signing, broadcast and Chronik confirmation evidence.

Follow the lab ↗