Base x402 plus low-cost Solana

Payment rails

One rail will not fit every price point. d402 keeps x402 compatibility for wallets and standards, while adding Solana paths for sub-cent/high-volume economics and escrow paths for unknown-recipient settlement.

Rail matrix

Rail	Use when	Payment destination known before work?	Custody model
Base x402 direct	Compatibility with x402 wallets and Base USDC when no split payout is required.	Yes, when the gateway preselects a single worker.	Buyer pays worker payout wallet directly.
Base task escrow	Workers are selected after payment or multiple outcomes need refund/payout routing.	Escrow address yes, final recipients no.	Non-custodial contract routes by validator settlement.
Base x402 to Solana channel	Buyers pay with Base USDC/x402 while workers and creators are paid from low-cost Solana channel claims.	Base recipient is known; final Solana recipients are decided after validation.	Base receipt plus prefunded Solana liquidity, reconciled by gateway/rebalancer.
Solana direct	Cheap single-worker tasks where one worker can be selected before payment and no split payout is required.	Yes.	Buyer transfers USDC to worker payout wallet.
Solana task vault	x402-equivalent exact payment with unknown final recipients.	Vault PDA yes, final recipients no.	Program-enforced vault finalizes to workers/refund.
Solana channel	Many low-value tasks from the same buyer.	Channel vault yes, per-task recipients later.	Buyer-funded vault, validator roots, worker pull withdrawals.

Timing problem and solution

In x402-style flows, the payment challenge needs a destination before work starts. But distributed execution may not know which worker deserves payment until validation completes. d402 solves this with deterministic router destinations.

If exactly one worker is selected before payment, payTo can be that worker's payout wallet.
If worker recipients are unknown, payTo is a deterministic escrow or vault address bound to task terms.
After validation, a signed settlement routes funds to worker payout wallets, creator wallets, validator wallets, and/or the buyer refund wallet.
The gateway verifies and coordinates, but should not custody task funds.
If a selected manifest has creator commission terms, direct provider payTo is ineligible because it cannot enforce the split.

Creator commission splits

Creator commissions are included in the buyer-facing price. Settlement starts from the accepted gross worker payout and splits it into worker net plus an aggregated creator payout.

$0.01 gross, 10% commission

[
  {
    "account": "WorkerSolanaWallet...",
    "amount": 0.009,
    "grossAmount": 0.01,
    "reason": "accepted-result"
  },
  {
    "account": "CreatorSolanaWallet...",
    "amount": 0.001,
    "reason": "creator-commission",
    "rateBps": 1000,
    "manifestCid": "sha256:..."
  }
]

Commissions are paid only for accepted work. Solana task vaults, Solana channels, Base escrow, and hybrid x402-to-Solana channel flows can carry the multi-recipient payout list. Direct Base x402 and direct Solana transfers should be used only for capabilities without commission splits.

Base x402

Network: eip155:8453
Asset: native Base USDC, 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Best for: existing x402 buyers, standards compatibility, higher-value tasks.
Low-cost mode: direct provider payTo.
Higher-assurance mode: deterministic d402 task escrow.

Solana direct

Network: solana:mainnet-beta
Asset: native Solana USDC mint, EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v
Best for: simple single-worker tasks and very low unit prices.
Proof: SPL token transfer plus required d402: memo. Legacy dnc: memos remain accepted.

challenge flow

1. Buyer posts task.
2. Gateway returns 402 with a d402-solana-transfer requirement.
3. Buyer sends Solana USDC to the worker payout wallet with the required memo.
4. Buyer retries with Authorization: Payment <base64-json>.
5. Gateway verifies transaction, mint, amount, owner, destination, memo, and replay status.

Solana x402-equivalent task vault

This mirrors the useful timing property of x402 exact while supporting unknown final recipients. The gateway can tell the buyer a deterministic vault PDA before work starts. Validators decide final distribution later.

Buyer posts task with payment.refundAddress.
Gateway derives immutable task-vault terms and PDA.
Gateway returns PAYMENT-REQUIRED with a Solana exact payment requirement.
Buyer signs/submits PAYMENT-SIGNATURE.
Facilitator settles USDC into the vault.
Workers run.
Validators finalize worker payouts and buyer refund.

Solana channel escrow

Channel escrow is the high-volume path. The buyer funds a durable channel vault once, signs per-task debit authorizations, and workers withdraw cumulative claims from validator-published roots. This avoids one on-chain payment per task.

Buyer funding: durable channel vault token account.
Per-task payment: buyer-signed channel debit authorization.
Settlement: validator-published epoch root.
Worker payout: pull withdrawal from cumulative claim.
Cleanup: fully claimed claim PDA rent and closed channel PDA rent are reclaimable.

Auto rail selection

gateway with auto payments

node src/cli.js node \
  --http-port 8080 \
  --payment auto \
  --evm-payout-wallet 0xYourBaseWallet \
  --solana-payout-wallet YourSolanaWallet \
  --gateway-price '$0.01' \
  --gateway-budget 0.01 \
  --offer web.page_to_markdown@1

For $0.01 single-worker tasks without commission terms this should usually select Solana when a Solana payout wallet is available. For commission-bearing manifests, unknown recipients, or buyer refunds, use a split-settlement router instead of direct payout.