XyncPay: Non-custodial protocol translation layer for AP2 + x402 + MPP via ElizaOS plugin

[XyncPay]

TL;DR: We're building XyncPay, a non-custodial protocol translation layer that lets autonomous agents transact across x402, MPP, and (planned) full AP2. Currently shipping with an AP2 inbound stub that routes through x402/MPP; full AP2 inbound parsing and outbound translation is the next major roadmap item. Just shipped our ElizaOS plugin (v0.1.0) with end-to-end production verification on Base mainnet. Looking for guidance and feedback from the AP2 community as we plan the full implementation.

What XyncPay is

XyncPay sits underneath the agent payment protocol stack and translates between x402, MPP, and AP2. The goal is to make incompatible protocols interoperable so an agent built on one framework can pay a service built on another, with USDC settlement on Base mainnet, no custody at any point.

Current AP2 status (honest)

We have a stub AP2 inbound adapter that recognizes AP2 protocol identifiers and routes payments through x402 or MPP for actual settlement. Full AP2 inbound parsing (proper mandate verification) and outbound translation (constructing AP2-native mandates) are explicitly marked as not implemented in our codebase. These are the next major roadmap items.

We want to do this right rather than shipping a partial implementation that misleads users. Our plan is to implement the AP2 x402 extension first since that aligns most closely with what we already do, then expand from there.

What just shipped

• ElizaOS plugin v0.1.0 published to npm as @xyncpay-org/plugin-elizaos
• Five composable actions covering the full payment lifecycle for x402 and MPP
• 71 of 71 unit tests passing
• 6 of 6 production end-to-end verification with real USDC settlement on Base mainnet
• Architecture: non-custodial. Agent wallet signs locally; XyncPay never holds funds.

Settlement contract on Base mainnet (verified): 0x1bd714Fbb90A6a7DbdE630d313bF7959e3e125Cb

Questions for the AP2 community

1. For teams implementing AP2 inbound parsing with cryptographic settlement, what's the canonical approach to mandate verification when settling on-chain via USDC? Specifically how Intent Mandate, Cart Mandate, and Payment Mandate signatures should be carried through the x402 facilitator flow.

2. We're a Circle Alliance Program member and our settlement is USDC-native. Is there interest in collaborating on a reference implementation showing AP2 + x402 + USDC settlement together? We're happy to open source the canonical translation logic once it's complete.

3. Are there specific test vectors or conformance criteria the AP2 working group plans to publish that we should target?

4. For implementations like ours that are stub-level today and planning full implementation: what's the recommended path for engaging with the AP2 spec and getting feedback as we build?

Links

• npm: https://www.npmjs.com/package/@xyncpay-org/plugin-elizaos
• Plugin repo: https://github.com/XyncPay/plugin-xyncpay-elizaos
• Homepage: https://www.xyncpay.com

Happy to answer questions about the architecture, the protocol translation approach, or anything else. Feedback genuinely welcome.

[chopmob-cloud]

@XyncPay -- the scope-honesty in the post is the right thing to publish; "stub AP2 inbound, full next, here's what we've actually shipped" is much more useful for AP2 maintainers and downstream consumers than a partial implementation dressed up as complete. Concrete responses to each of the four questions:

1. Canonical mandate verification under on-chain USDC settlement. The load-bearing primitive is open_mandate_hash: a SHA-256 over the JCS RFC 8785 canonical bytes of the unsigned mandate body. This is the question AP2 #265 addresses, and the v0 conformance vectors there are cross-validated across five language runtimes by three organisations plus two independent third-party re-runs. For full AP2 inbound parsing, computing open_mandate_hash correctly is the gate: a verifier resolving a mandate reference must get byte-identical canonical bytes from the same input as the issuing agent, or signature verification breaks before the chain reaches settlement. The same JCS substrate composes cleanly with x402 payment receipts and MPP settlement records, so a translation layer like XyncPay can verify all three mandate types under one canonicalisation rule rather than implementing three.

2. AP2 + x402 + USDC reference implementation. AlgoVoi ships this in production on Base mainnet via the x402 facilitator path with USDC-native settlement, no custody at any point in the flow (gateway signs nothing on behalf of the payer). A reference implementation showing AP2 mandate inbound -> x402 settlement -> categorical receipt emission is a natural artefact to assemble between XyncPay and an existing producer like AlgoVoi; the receipt-format side is already specified across five IETF Internet-Drafts. Happy to coordinate on that if useful.

3. AP2 conformance test vectors. AP2 maintainers have not published a normative vector corpus yet. The AP2 #265 open_mandate_hash v0 set is the closest publicly-citable vector resource at this point. PEAC Protocol just adopted it as upstream-tracked (peacprotocol/peac/specs/conformance/interop/ap2-open-mandate-hash) including both positive scenario-shaped cases and explicit composition-failure cases (non-SHA-256 digest, non-JCS canonicalisation), which is exactly the discipline-anchor failure modes a translation layer needs to fail-closed on.

4. Engagement path for stub-level builders. What PEAC did is the cleanest pattern: implement against existing vector sets (AP2 #265 + the receipt-format conformance corpus at chopmob-cloud/algovoi-jcs-conformance-vectors), publish your own complementary fixtures explicitly marked complementary-not-replacement, document the boundary clearly ("AP2 defines X, XyncPay records Y"), and surface the adoption on the relevant AP2 thread. Downstream-adopter visibility tracks adoption against published canonical-version pins.

For the categorical receipt that XyncPay would emit on the settlement side of an AP2 -> x402 -> USDC flow, the algovoi-settlement-attestation format records the per-chain settlement event with settled_payment_ref content-addressed back to the original AP2 mandate open_mandate_hash. That closes the audit chain from mandate to on-chain settlement under one canonicalisation pin.

A Substrate Adopters Registry at docs.algovoi.co.uk/adopters records downstream parties publishing under the shared canon_version: jcs-rfc8785-v1 pin. PEAC and Supership are the current entries; XyncPay would qualify once full AP2 inbound lands.

-- AlgoVoi

---

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition