For infrastructure operators

Run the roles you want. Do not run keys you do not need.

d402 roles are intentionally separable. A machine can sell work, receive HTTP traffic, introduce peers, validate results, or maintain settlement. Production deployments should separate public ingress, worker sandboxes, validator keys, and upgrade authority.

Role selection

Participant goal	Role to run	Public HTTP?
Buy work from another app	User client only	No
Sell compute	Worker node with selected offers	No
Expose service to applications	Gateway / ingress	Yes, behind HTTPS
Improve reachability	Bootstrap / discovery	No
Improve correctness	Validator or comparator service	No
Keep settlement live	Maintainer / finalizer	No

Create or register a capability

A capability author publishes the manifest and optional creator commission terms. A worker can later run that exact manifest and implementation; compliant gateways split accepted revenue according to the signed terms.

signed registration with commission

d402 capability template --id example.extract_product --version 1 > capability.json
d402 capability validate --file capability.json
d402 capability register \
  --file capability.json \
  --state ./state/publisher \
  --namespace example \
  --creator-commission-bps 1000 \
  --creator-solana-wallet <CREATOR_SOLANA_WALLET> \
  --creator-evm-wallet 0x000000000000000000000000000000000000c0de \
  > capability.registration.json

1000 basis points means 10% of accepted gross worker payout.
Commission terms are signed with the registration and tampering changes the registration CID/signature.
Terms apply only to the exact manifest CID. Forks, new versions, and private manifests register their own terms.
Include recipient wallets for every rail a gateway may use, for example solana and evm.

Run a worker

A worker sells a capability to the peer network. It does not expose the public task API.

worker node

node src/cli.js node \
  --label worker-1 \
  --state .d402/worker-1 \
  --host 0.0.0.0 \
  --advertise-host <WORKER_REACHABLE_IP> \
  --port 9001 \
  --peer <BOOTSTRAP_PEER_IP>:9000 \
  --offer web.page_to_markdown@1 \
  --snapshotter playwright \
  --fallback-to-fetch true \
  --solana-payout-wallet <WORKER_SOLANA_WALLET>

The advertised host and port must be reachable by at least one bootstrap or gateway node.
The worker must advertise payout wallets compatible with the gateway payment rail.
Browser workers should run in a sandbox/container with CPU, memory, time, and egress limits.
Operators should explicitly choose which capabilities and runtime permissions they are comfortable selling.
For commission-bearing capabilities, workers still advertise their own payout wallet; settlement pays worker net after creator commission.

Run a gateway

A gateway bridges applications into the peer network. Put it behind HTTPS before exposing it publicly.

gateway node

node src/cli.js node \
  --label gateway-1 \
  --state .d402/gateway-1 \
  --host 0.0.0.0 \
  --advertise-host <GATEWAY_P2P_IP> \
  --port 9000 \
  --peer <WORKER_OR_BOOTSTRAP_IP>:9001 \
  --http-host 0.0.0.0 \
  --http-port 8080 \
  --payment solana-direct \
  --gateway-price '$0.01' \
  --gateway-budget 0.01 \
  --offer web.page_to_markdown@1 \
  --require-capability-registration true \
  --require-signed-capability-registration true \
  --max-creator-commission-bps 2000

Enforce server-owned price, capability, fanout, quorum, URL, and size policy.
Enforce accepted manifest CIDs, trusted namespaces, signed registrations, and commission caps before selling public work.
Validate payment challenges, replay protection, and idempotent retries.
Discover workers through bootstrap peers and peer exchange.
Coordinate bids, leases, claims, validation, settlement, and reputation.
Persist gateway state and run ops-monitor.

Direct provider payTo routes cannot enforce creator commission splits. If a selected manifest carries commission terms, use a split-settlement rail such as Solana task escrow, Solana channel escrow, Base task escrow, or the hybrid Base x402 to Solana channel path.

Discovery boundary

Current discovery is controlled bootstrap TCP. Nodes start with one or more --peer host:port addresses. Peers exchange reachable addresses during handshake. Known peer records persist in node state. A gateway can connect to one stable bootstrap node and learn the controlled graph.

Production discovery should add signed peer records, multiple independent bootstrap paths, capability rendezvous, NAT traversal, relay support, peer scoring, and eclipse/Sybil resistance.

Channel maintenance

For low-marginal-cost Solana channels, maintainers publish roots, retry withdrawals, and reclaim rent. They should not close channels automatically.

maintainer daemon

node src/cli.js solana-channel-maintainer \
  --state ./state/requestor \
  --claimants WorkerA,WorkerB \
  --interval-ms 30000

Operational rule

Adding nodes should make the network stronger. That means workers can join without operating a gateway, validators can sign without exposing HTTP, and maintainers can submit liveness transactions without custody of buyer or worker funds.