d402distributed 402
Capped beta posture

Security and production readiness

d402 has live payment paths, but the safe launch posture is deliberate: bounded capabilities, capped balances, monitored operations, separated keys, and explicit beta language until external audits and decentralized discovery are complete.

Critical constraint

You cannot make arbitrary code execution fully trustless by sending it to many nodes. Every capability needs a validation model. Redundancy improves availability and comparison data, but it does not replace verification.

Validation classes

ClassExamplesRequired controls
Exactly verifiableProof checks, deterministic transforms.Exact checker, signed evidence, reproducible inputs.
CanonicalizableMarkdown from frozen HTML, normalized JSON extraction.Canonicalizer, content hash, quorum compare.
ScoreableQuality ratings, search results, summaries.Comparator service, benchmarks, human/AI review policy.
Non-verifiableOpen-ended judgment.Reputation, stake, dispute windows, lower assurance claims.

Pre-launch checklist

  • npm test passes.
  • npm run lint passes.
  • Local Solana channel smoke passes.
  • Base and Solana live smoke tests pass with capped funds.
  • Program/contract addresses and binary hashes are recorded.
  • Alerting is configured for gateway, finalizer, maintainer, and fee-payer balances.
  • Upgrade authority and validator keys are controlled by the intended operator process.
  • Creator commission policy is configured with D402_MAX_CREATOR_COMMISSION_BPS and trusted namespaces before honoring commission-bearing manifests.
  • Public docs clearly state audit status, caps, and experimental limits.

Capability and commission policy

  • Require signed capability registrations for public paid traffic.
  • Prefer exact accepted manifest CIDs and implementation CIDs for production routes.
  • Use trusted namespaces and namespace proofs to reduce lookalike manifest risk.
  • Reject creator commission rates above the gateway cap. The default cap is 2000 basis points.
  • Reject commission-bearing manifests when the selected payout rail lacks the required creator wallet type.
  • Do not use direct provider payTo routes for commission-bearing manifests; use split settlement.
  • Treat creator commissions as gateway-enforced and receipt-auditable in v1, not as global anti-fork rights.

Balance caps

  • Configure D402_SAFETY_MAX_TASK_BUDGET for every public gateway.
  • Configure D402_SAFETY_MAX_OPEN_TASK_ESCROW_BUDGET for per-task escrow rails.
  • Configure D402_SAFETY_MAX_CHANNEL_INITIAL_FUNDING_ATOMIC_UNITS and D402_SAFETY_MAX_CHANNEL_BALANCE_ATOMIC_UNITS for Solana channels.
  • Use small channel balances for early buyers. Top up frequently instead of storing large balances.
  • Reject new challenges when a configured cap would be exceeded.

Key custody

  • Do not run validator signing keys in the same process as public HTTP ingress for production.
  • Prefer threshold signing, remote signer, HSM, or multisig-controlled validator operations.
  • Move upgrade authority from local keypairs to multisig or threshold-controlled processes before large balances.
  • Keep deployer and upgrade authority keys out of gateway hosts.
  • Record every root, settlement, close authorization, and signer identity.

Monitoring

ops status
node src/cli.js ops-status \
  --state ./state/requestor \
  --solana-address <fee-payer-wallet> \
  --min-solana-balance-sol 0.005
ops monitor
node src/cli.js ops-monitor \
  --state ./state/requestor \
  --interval-ms 30000 \
  --alert-file ./ops-alerts.jsonl \
  --alert-webhook-url <https-alert-endpoint>

Alert on stuck task escrows, pending payment attempts, stale channel roots, failed finalizations, failed withdrawals, duplicate payment attempts, replay rejections, and low fee-payer balances.

Incident shutdown

  • Stop issuing new payment challenges.
  • Keep workers running long enough to finish already-paid tasks or refund them.
  • For task escrow, run finalizer/refund scanners until all funded vaults are settled or expired.
  • For channel escrow, publish final roots, let workers withdraw, reclaim claim PDAs, close channels, then reclaim closed channel state.
  • Rotate compromised gateway, validator, facilitator, and deployer keys.
  • Preserve logs, payment payloads, task records, roots, transaction signatures, and evidence CIDs.