VDM NexusDocs

FAQ

Common questions about VDM Nexus, signed inference, and the SDKs.

What does Nexus store about my calls?

Per call we keep a metadata row in inference_logs:

  • The agent's public key (already public on-chain)
  • Upstream provider and model slug (e.g. openrouter, openai/gpt-4o-mini)
  • Token counts (prompt + completion)
  • Cost, latency, status
  • The Solana tx_signature (for idempotency)

What we do not keep: the prompt text, the response text, IP addresses, user agents, device fingerprints, location data. The receipt itself contains hashes of the prompt and response — not the content.

The agent is the sole keeper of the actual prompt/response strings. See Security & Privacy for the full model.

Is what I send to the model private?

The model provider sees everything. Today the model runs on OpenRouter's upstream providers (OpenAI, Anthropic, etc.) and they see the full prompt. Their logging and training policies are theirs, not Nexus's.

Nexus itself does not store prompt or response content — only metadata and hashes.

If you need privacy of prompt content from the model provider, that's a different product category (private inference via TEE or ZKML). That's a planned upstream integration; see Security & Privacy for the full breakdown.

What's the difference between the two SDKs?

@vdm-nexus/sdk@vdm-nexus/x402
FlowPrepaid balance, debited per callPay-per-call, settled on-chain per call
AuthEd25519-signed request bodyx402 USDC transfer signature
Runtime deps2 (tweetnacl, bs58)~6 (adds Solana + x402 stack)
Latency overheadNone~2-5s for Solana settlement
When to useHigh-volume, low-latency, sub-cent per callAudited spend, one call at a time, no prepaid setup

X402Agent extends Agent, so the same keypair works for both.

When does mainnet ship?

The blocker is the facilitator's signing key. It currently lives in a Vercel env var — fine for devnet, unacceptable for mainnet. The migration is:

  1. Move the key to a KMS (AWS / GCP / Vercel secrets vault / HSM)
  2. Replace the inline signer with a KMS-backed one
  3. Validate on mainnet at small volume for ~1 week
  4. Announce

Realistic timeline: weeks, not months.

Do you have a token?

Not yet. Pricing today is in USDC and the receipt format is token-agnostic, so adopting Nexus doesn't lock you into any particular asset.

We're designing a token for a later phase — but utility-first. The token will exist only once it does something the current architecture can't, and the launch will follow demonstrable usage, not the other way around. We'd rather ship a token that earns its place than ship one that asks for it.

More detail will live here when we're ready to share it.

Why Solana and not Ethereum (or [chain]) ?

Three reasons we'd defend:

  1. 400ms finality. Settlement happens inside a single user-visible API call. Ethereum L1's ~12s blocks would make this UX impossible; L2s have settlement-finality gaps that defeat the verifiability property.
  2. $0.0001 transaction fees. Per-call settlement at sub-cent amounts only makes economic sense on a cheap chain.
  3. Ed25519 keys. The same keypair format used everywhere else in modern crypto. Agents can sign requests AND payments with one identity.

The x402 protocol itself is chain-agnostic; we picked the chain that made the wedge ship.

Does Nexus run the model itself?

No — today we proxy to OpenRouter. The inference still happens at OpenAI, Anthropic, Together, Groq, etc. via their normal APIs. "Decentralized inference" or "TEE-attested inference" providers are on the roadmap as alternative upstreams, not replacements.

Is streaming supported?

Not in v0.1. The endpoint rejects stream: true with a 400. Streaming requires a different receipt model (per-chunk hash binding); planned for post-v0.1.

Can I run the facilitator myself instead of using yours?

Yes — see Self-host the facilitator. Anyone with a Solana keypair, some SOL for fees, and the @x402/svm package can run their own. The SDK doesn't care.

What's the relationship between VDM Nexus and Coinbase x402?

x402 is an open HTTP payment protocol (github.com/coinbase/x402). Coinbase originated and stewards the spec; VDM Nexus is one implementation of an x402-compliant inference endpoint, with our own self-hosted facilitator (we don't depend on Coinbase's CDP service).

How does this compare to Grace Protocol?

Grace is a payment-protocol gateway — one API call across x402 and MPP and other protocols. They abstract the payment layer. VDM Nexus is a service that uses x402 — we live at the destination end of the flow. An agent could route through Grace's gateway to land at our endpoint.

How does this compare to 0G or Inference Labs or Ambient?

Those are decentralized AI substrate projects (new L1s, DePIN networks, ZK / TEE attestation layers). They're at a different layer of the stack from us. We're not trying to be a substrate — we're a single service that gives you cryptographic receipts on your inference calls, today, on a chain that already works.

Where do I report bugs / ask questions?

Self-host the facilitator

Run your own x402 facilitator backed by @x402/svm.

On this page

What does Nexus store about my calls?Is what I send to the model private?What's the difference between the two SDKs?When does mainnet ship?Do you have a token?Why Solana and not Ethereum (or [chain]) ?Does Nexus run the model itself?Is streaming supported?Can I run the facilitator myself instead of using yours?What's the relationship between VDM Nexus and Coinbase x402?How does this compare to Grace Protocol?How does this compare to 0G or Inference Labs or Ambient?Where do I report bugs / ask questions?