[Discussion] x402-native settlement layer for QVAC inference — bring-your-own-payment for downstream consumers

[srotzin]

QVAC team — first off, congrats on the SDK release. We've been integrating @qvac/sdk into the Hive agent stack since April 9 and the cross-platform inference story is genuinely best-in-class for agentic workloads.

Surfacing a discussion topic that came up while building on top of QVAC: how downstream consumers pay for QVAC inference.

Right now the SDK assumes the QVAC node and the consumer share trust (same machine, same operator, or pre-arranged contract). For agent-to-agent inference markets — where the QVAC operator and the consuming agent don't know each other beforehand — there's a missing payment-and-receipt layer.

We've been running a working prototype: HiveCompute QVAC Provider Agent — wraps a QVAC node, exposes inference behind an x402 (HTTP 402 Payment Required) gate, settles in USDC or USDT on Base/Solana, returns the inference result + a cryptographic settlement receipt. The QVAC binary itself is untouched; the wrapper handles auth, payment verification, and metering.

Live endpoint shape:

• POST /v1/inference/request/public returns 402 challenge
• Agent signs EIP-3009 transferWithAuthorization (no gas, no ETH/SOL needed)
• Retry with X-PAYMENT header returns inference result + receipt

What I'd love to discuss with this repo:

1. Is x402 a pattern you'd want first-class in the SDK (e.g., a qvac-pay sibling module), or does it stay external as a wrapper layer?
2. Receipt format — would you want QVAC inference receipts to include a model-version + input-hash commitment so consumers can verify "this output came from this exact model on this exact input"?
3. EIP-3009 across rails — we cover USDC+USDT on Base, USDC+USDT-SPL on Solana. Is there a Tether-internal preferred default, or is "agent picks based on holdings" the right policy?
4. Provider discovery — would QVAC core want to maintain a directory of "verified providers" or is that explicitly outside scope?

Happy to share our wrapper code, regression tests, and load-test numbers if it's useful. We're also fine just running this externally and pointing users at it — but feels like it might be worth a first-class consideration given the agent-economy direction QVAC is clearly aimed at.

Hive QVAC Provider repo: https://github.com/srotzin/hivemorph (the wrapper lives in hive_x402/ and hive_forge/)
HiveForge listing: https://hivemorph.onrender.com/v1/forge/listings

— Steve @ Hive

[srotzin]

For x402-native settlement under QVAC inference, the missing primitive most facilitators don't ship is per-response attestation. Without it, the buyer pays for inference but has no cryptographic record of what was inferred.

HiveCompute is a metered inference router with Spectral-ZK attestation on every response — $0.05/call, USDC on Base, EIP-3009 settlement to a single canonical treasury (no mocks). Each response carries a non-removable ticket header binding intent-hash to receipt, so downstream consumers get bring-your-own-payment AND bring-your-own-audit in the same call.

If QVAC wants to expose its inference surface through an x402 facilitator that also returns a verifiable receipt, the wiring is straightforward: QVAC announces the offer, HiveCompute meters + attests, settlement lands on Base. Agent-card: https://hivetrust.onrender.com/.well-known/agent-card.json. x402 surface: https://hivetrust.onrender.com/.well-known/x402.

[victorchimakanu]

The delegate flow (provider/consumer) connects a consumer directly to a provider over the Hyperswarm DHT by public key. There is no discovery phase. Both parties need to know the provider's public key before connecting. For inference between parties with no prior relationship, the SDK has no mechanism for key exchange, payment, or receipt.

Wrapping a QVAC provider node behind an x402 gate is architecturally clean. The payment layer sits outside the SDK and QVAC serves inference normally to the wrapper. The per-response attestation is the harder part. QVAC does not ship cryptographic receipts for inference outputs, so Spectral-ZK would operate on the response payload after the fact, which covers transport integrity but not the computation itself.

Flagging this to the team. One thing that would help them understand the use case: when a consuming agent has no prior relationship with the QVAC operator, how does HiveCompute handle the initial key exchange or session authentication?