xProof: output integrity layer built on MX-8004 - live implementation report

[jasonxkensei]

Context

We built xProof as a proof primitive for AI agents and humans on MultiversX. The service is live at xproof.app and implements the full MX-8004 validation lifecycle. This document shares our implementation details and what we learned building on the standard - feedback from the team is welcome.

What we built - Technical flow

xProof implements the complete MX-8004 validation loop. Every certification triggers an asynchronous 5-step on-chain registration via a PostgreSQL-backed transaction queue with exponential backoff retry:

Step 1: init_job(jobId, agentNonce)
  → Registers the certification as a new job in the Validation Registry
  → Links to xProof's soulbound agent identity (NFT nonce)

Step 2: submit_proof(jobId, proof)
  → proof = "hash:{fileHash}|tx:{transactionHash}"
  → Submits the SHA-256 hash + MultiversX transaction reference as job evidence

Step 3: validation_request(jobId, validatorAddress, requestUri, requestHash)
  → requestUri = "https://xproof.app/proof/{certificationId}.json"
  → requestHash = SHA-256(proof)
  → xProof self-validates (the certifying agent is also the validator)

Step 4: validation_response(requestHash, 100, responseUri, responseHash, "xproof-certification")
  → response score = 100 (fully validated)
  → responseUri = "https://xproof.app/proof/{certificationId}"
  → responseHash = SHA-256("verified:{fileHash}")
  → tag = "xproof-certification"
  → Job reaches "Verified" status on-chain

Step 5: append_response(jobId, responseUri)
  → responseUri = "https://xproof.app/api/certificates/{certificationId}.pdf"
  → Attaches the PDF certificate as a permanent response artifact

Smart retry

The transaction queue persists currentStep in PostgreSQL. If any step fails (nonce collision, gateway timeout, contract revert), the job retries from the failed step — not from the beginning. This saves gas and time.

MX-8004 contracts used

Contract	Environment variable	Role
Identity Registry	MX8004_IDENTITY_REGISTRY	Soulbound NFT agent identity
Validation Registry	MX8004_VALIDATION_REGISTRY	Job lifecycle (init → submit → validate → verify)
Reputation Registry	MX8004_REPUTATION_REGISTRY	On-chain reputation scoring + ERC-8004 feedback

API endpoints exposed for MX-8004 data

Endpoint	Description	Auth
GET /api/mx8004/status	MX-8004 configuration status + agent identity	Public
GET /api/agent/{nonce}/reputation	Agent reputation score + total jobs	Public
GET /api/mx8004/job/{jobId}	Job data from Validation Registry	Public
GET /api/mx8004/validation/{requestHash}	Validation response details	Public
GET /api/mx8004/feedback/{agentNonce}/{clientAddress}/{index}	ERC-8004 feedback signals	Public

ERC-8004 feedback methods implemented

• giveFeedback(agentNonce, value, valueDecimals, tag1, tag2, endpoint, feedbackUri, feedbackHash) - Full ERC-8004 raw feedback
• giveFeedbackSimple(jobId, agentNonce, rating) - Simplified feedback
• revokeFeedback(agentNonce, feedbackIndex) - Revoke previous feedback
• readFeedback(agentNonce, clientAddress, feedbackIndex) - Query feedback

Where xProof fits in the MultiversX agent stack

┌─────────────────────────────────────────────────┐
│            MultiversX Agent Stack                │
├─────────────────────────────────────────────────┤
│                                                  │
│  MX-8004 Identity Registry                       │
│    └─ Agent identity (soulbound NFT)             │
│                                                  │
│  MX-8004 Validation Registry                     │
│    └─ Job orchestration + validation lifecycle   │
│                                                  │
│  MX-8004 Reputation Registry                     │
│    └─ On-chain scoring + feedback signals        │
│                                                  │
│  ┌─────────────────────────────────────────┐     │
│  │  xProof — Output Integrity Layer        │     │
│  │                                         │     │
│  │  What it adds:                          │     │
│  │  • Output-level proof (SHA-256 on-chain)│     │
│  │  • Tamper detection post-production     │     │
│  │  • Timestamped proof of existence       │     │
│  │  • Cross-agent output verification      │     │
│  │  • Webhook notifications on confirmation│     │
│  │  • Verification badges (SVG)            │     │
│  │  • x402 payment (USDC on Base)          │     │
│  │                                         │     │
│  │  What it does NOT replace:              │     │
│  │  • Agent identity (MX-8004 does this)   │     │
│  │  • Job orchestration (MX-8004 does this)│     │
│  │  • Reputation scoring (MX-8004 does this│     │
│  │                                         │     │
│  │  How it integrates:                     │     │
│  │  Each certification → full MX-8004      │     │
│  │  validation loop (5 on-chain txs)       │     │
│  │  → Job reaches "Verified" status        │     │
│  │  → Builds agent reputation              │     │
│  └─────────────────────────────────────────┘     │
│                                                  │
└─────────────────────────────────────────────────┘

What we learned building on MX-8004

• The 5-step validation loop works well for certification use cases. The separation between submit_proof and validation_request lets us decouple the proof payload from the validation logic cleanly.
• Nonce management across 5 sequential transactions required a persistent queue with step-level retry. Our implementation uses PostgreSQL with exponential backoff - happy to share specifics if useful for other builders.
• Self-validation (where the certifying agent is also the validator) is a valid pattern for proof-of-existence. For cross-agent validation scenarios, we expose public endpoints so external validators can query job and proof data.
• The Reputation Registry creates a natural incentive loop: agents that certify more build verifiable track records. We see this as a foundation for trust-based agent discovery.

Try it

The service is live. You can test the full flow, from certification to on-chain verification, without an account using x402 (USDC on Base):

curl -X POST https://xproof.app/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"discover_services","arguments":{}}}'

Links

• Live service: https://xproof.app
• GitHub Action (Marketplace): https://github.com/marketplace/actions/xproof-certify
• OpenClaw skill: https://github.com/jasonxkensei/xproof-openclaw-skill
• Main repo: https://github.com/jasonxkensei/xProof
• MCP server: POST https://xproof.app/mcp (JSON-RPC 2.0, Streamable HTTP)
• Agent discovery: https://xproof.app/.well-known/agent.json
• LLM documentation: https://xproof.app/llms.txt
• MX-8004 spec: https://github.com/sasurobert/mx-8004/blob/master/docs/specification.md
• Agent explorer: https://agents.multiversx.com

We'd appreciate any feedback on our MX-8004 usage — especially around validation patterns, reputation integration, or areas where we could align more closely with the standard's direction.

---

Document generated from xProof codebase — server/mcp.ts, server/mx8004.ts, server/txQueue.ts, server/routes.ts
Version 1.2.0 — February 19, 2026

[jasonxkensei]

Update — March 2026

When I filed this issue I had just finished building the on-chain certification loop and
posted it on X. I wasn't sure yet how to structure a PR against a core MultiversX repo. This issue was my first step toward getting xProof visible in the MultiversX JS ecosystem. Here's where things stand today.

What xProof is now

xProof is the on-chain notary for AI agents — a trust primitive that anchors verifiable
proofs of agent identity, intent, and output on MultiversX mainnet.
The evolution from document certification to a full agent audit trail was driven by a core
architectural question: how do you prove that reasoning existed before execution?
The answer is the 4W Framework, now an open CC0 spec:

• WHO — agent identity (MultiversX wallet, DID, or any persistent identifier)
• WHAT — SHA-256 hash of the action output, anchored after execution
• WHEN — MultiversX block timestamp (chain-written, not agent-declared)
• WHY — SHA-256 hash of the instruction/reasoning, anchored before execution
  This means intent_preceded_execution: true/false becomes a cryptographically verifiable
  on-chain claim, not a self-reported log.

---

JavaScript/TypeScript integration surface

npm SDK (npm install @xproof/xproof, v0.1.0, zero dependencies beyond fetch):

import { XProofClient } from '@xproof/xproof';
const client = new XProofClient({ apiKey: 'pm_...' });
// Certify any content with 4W metadata
await client.certifyHash({
  fileHash: sha256(content),
  fileName: 'agent-output.json',
  author: 'my-agent',
  who: 'my-agent',
  what: sha256(content),
  when: new Date().toISOString(),
  why: 'Quarterly analysis certification',
});
Vercel AI SDK middleware (@xproof/xproof/vercel):

import { xproofMiddleware } from '@xproof/xproof/vercel';
import { openai } from '@ai-sdk/openai';
const model = xproofMiddleware(openai('gpt-4o'), {
  apiKey: 'pm_...',
  why: 'Customer support response',
});
// Every generateText / streamText call auto-certifies on MultiversX
const { text } = await generateText({ model, prompt: '...' });
ElizaOS Plugin (xproof-eliza-plugin v2.0.0):

AUDIT_BEFORE_EXECUTE — blocks execution until WHY proof is anchored
CERTIFY_CONTENT, CERTIFY_HASH, CERTIFY_BATCH, VERIFY_PROOF
MCP server (POST /mcp, JSON-RPC 2.0):
Tools: certify_file, verify_proof, audit_agent_session,
investigate_proof (x402-gated: $0.05 USDC on Base)

Payment integration
xProof supports two payment paths relevant to the MultiversX JS stack:

EGLD — standard wallet-signed transactions for certifications
x402 (HTTP 402) — per-request USDC payments on Base,
no account or API key required. Machine-to-machine, self-contained.
The x402 path lets any JavaScript agent certify on MultiversX mainnet
with a single HTTP call and a USDC microtransaction — no MultiversX wallet setup needed.

Production traction
Bot running 24/7 on Moltbook, certifying every action (WHY + WHAT pair)
Incident Report API: GET /api/agents/:wallet/incident-report?proof_id=<uuid> —
reconstructs the full 4W audit timeline, shareable with auditors/regulators
Trust Score & public Leaderboard with Transparency Tiers (1–3)
Violations layer: auto-confirmed faults, permanent breach penalties
Registered on Schelling Protocol (services.verification cluster)
Open PRs on MultiversX repos:

multiversx/mx-moltbot-starter-kit #1
multiversx/mx-openclaw-skills #1
The Agent Proof Standard v1.0 spec is CC0, chain-agnostic, and open for adoption.
Free format validation at POST https://xproof.app/api/standard/validate.

Happy to answer any questions or adapt this for whatever format works best for listing
in the official MultiversX AI agent hub.