Proposal: pluggable x402 backends for a Kaspa TN10 adapter

[KaspaScopio]

We have a TN10-validated community adapter that connects EmDash x402 enforcement to a Kaspa x402 DirectModeServer:

https://github.com/KaspaScopio/emdash-kaspa-x402-adapter

Before taking this further, I’d really appreciate a sanity check from the EmDash side: are we overlapping anything already planned for x402 extensibility, and does this API shape feel like a good fit?

The adapter itself is intentionally external. On the EmDash side, the prototype is deliberately small: allow @emdash-cms/x402 to load a backend factory by static Vite import, plus optional static imports passed into that factory for non-serializable deployment values such as a serverFactory.

Prototype config shape:

backend: {
  module: "@kaspascopio/emdash-kaspa-x402",
  export: "createKaspaX402Backend",
  imports: {
    serverFactory: { module: "./src/kaspa-x402-server.ts", export: "createKaspaServer" },
  },
  options: { serverOptions: { deployment: "tn10" } },
}

What has been validated:

• real Astro/Vite virtual-module loading;
• HTTP 402 + PAYMENT-REQUIRED → PAYMENT-SIGNATURE → 200 + PAYMENT-RESPONSE;
• real Kaspa Testnet-10 settlement;
• identical replay returns the same settlement without re-running protected work;
• tests/typecheck/build and standalone install all pass.

Latest TN10 proof transaction:
340712f53d687c89e294ca4df807be0d599acba64c6052caa90013f357b34956

A few things I’d especially value feedback on:

1. Is a pluggable x402 backend mechanism something EmDash wants in @emdash-cms/x402, or would you prefer protocol-specific integrations to live elsewhere?
2. If extensibility belongs here, is module/export/options/imports the right boundary, or would you prefer a different static-import API?
3. Are there lifecycle / SSR / Cloudflare constraints we should account for before turning the prototype into a PR?

This is still experimental and TN10-only. We’d rather get the architecture right with maintainer input before opening a feature PR.

[KaspaScopio]

Hardening update after the initial proposal: I exercised the adapter in a real local Cloudflare workerd runtime via Wrangler 4.131.2 (compatibility date 2026-09-14) without nodejs_compat.

The Worker generated a schema-valid Kaspa PAYMENT-REQUIRED, the adapter decoded/validated it inside workerd, and the HTTP request returned the expected 402. So the current adapter shape itself is workerd-compatible in this setup.

One separate limitation showed up: a generic esbuild platform=browser bundle fails because the currently published @kaspa-x402/core@0.1.0-alpha.10 imports Node crypto. Wrangler/workerd handles the package successfully, but I would not claim generic browser compatibility yet.

I also added concurrency/negative-path tests on the adapter branch: 17/17 now pass, including single serverFactory initialization under 20 concurrent first requests and fail-closed malformed payment headers.