From token to useful product.

Node402 connects token launches and digital products on Robinhood Chain. Create a token, attach a service, and charge for each request with x402. Every transaction is explicit, and every released result has a payment receipt.

Overview

A token launch and a product launch are separate actions. The token exists onchain. A product defines what a customer receives, its price, the accepted payment asset, and the creator’s payout wallet. Attaching a token does not automatically make that token a supported payment asset.

Launch a token

1. Connect your EVM wallet and switch to Robinhood Chain.
2. Choose Launch → Create token. Add the name, ticker, description, and image URL or upload.
3. Choose a configured paired asset. Optionally enter a developer buy, a minimum token output, and creator-tax options.
4. Review the actual launch fee, target contract, paired asset, and developer buy. Node402 checks the factory’s current economics and simulates the transaction.
5. For an ERC-20 developer buy, approve only the exact quote amount to the pons router. Then review the launch again.
6. Submit the launch through your wallet. Node402 records success only after confirmations and a matching factory event prove your launch.

Factory: 0x7ed598bcef8bd9edd8c97a195c6d13f40801ec7e. Launch-and-buy router: 0xe33e9e479df8802cb0866d5d05258bec4cf62948. These are pons contracts, not contracts operated by Node402. Launch terms are never inferred from a screenshot.

Configuration availability is checked at runtime. If a verified ABI, current economics hash, fee, or paired-asset configuration is unavailable, the launch stops before a transaction is offered. An image served from a private Node402 site will not be accessible to outside indexers; use a public or IPFS image URL until the site is public.

Publish a product

1. Choose Launch → Connect a product.
2. Verify an existing ERC-20 or pons token onchain. Node402 reads its name, symbol, decimals, and supply.
3. Set a unique slug, describe the product, and choose what a paid request delivers.
4. Add a configured payment asset and exact price. The payout address is your verified wallet.
5. Save a draft or publish. A published product appears in Discover and exposes /api/x402/<slug>.

You can pause, republish, or edit the price and response from Dashboard. A draft stays private. Paused products stop accepting new payments. Changing a product’s price invalidates new submissions with the old price. An already accepted payment retains its saved amount and result for retries.

Product types

External hostnames require operator approval. Redirects, IP literals, localhost, private-style hostnames, embedded credentials, and custom ports are rejected. Do not expose a valuable upstream API publicly without its own access controls.

The payment handshake

An unpaid request receives HTTP 402 and a base64 JSON PAYMENT-REQUIRED header. The client reviews the asset, amount, recipient, and network, then signs a payment authorization: an EIP-3009 transferWithAuthorization for tokens that support it, or a Permit2 PermitWitnessTransferFrom for every other ERC-20 (the quote's extra.assetTransferMethod says which). USDG on Robinhood Chain settles through Permit2, so a payer approves the canonical Permit2 contract once; until then the resource answers 412 permit2_allowance_required. The client retries the same request with PAYMENT-SIGNATURE. Node402 verifies the signature, balance, expiry, and nonce, submits settlement through the x402 exact Permit2 proxy or the token itself, checks the receipt, and releases the output.

GET /api/x402/research-feed

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 JSON>

{
  "x402Version": 2,
  "resource": {
    "url": "https://YOUR_PUBLIC_HOST/api/x402/research-feed",
    "description": "Research data",
    "mimeType": "application/json"
  },
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:4663",
    "asset": "<configured token address>",
    "amount": "10000",
    "payTo": "<verified creator wallet>",
    "maxTimeoutSeconds": 300,
    "extra": {"name": "<token domain name>", "version": "1"}
  }]
}

Amounts are decimal strings in token base units. For an asset with six decimals, 10000 represents 0.01 tokens. Prices use integer arithmetic. The legacy X-PAYMENT input header is accepted for compatibility; new integrations should use the standard v2 headers.

{
  "x402Version": 2,
  "resource": {"url": "https://YOUR_PUBLIC_HOST/api/x402/research-feed"},
  "accepted": {"...": "the selected payment requirement, unchanged"},
  "payload": {
    "signature": "0x...",
    "authorization": {
      "from": "<payer>", "to": "<creator>", "value": "10000",
      "validAfter": "<unix time>", "validBefore": "<expiry>",
      "nonce": "<random bytes32>"
    }
  }
}

The returned PAYMENT-RESPONSE contains success, transaction hash, network, and payer. X-Node402-Receipt identifies the saved receipt. Your agent should impose its own price and asset limits before signing.

Client examples

Inspect a resource

curl -i https://YOUR_PUBLIC_HOST/api/x402/research-feed

# Retry after your wallet signs the returned requirements.
curl -i https://YOUR_PUBLIC_HOST/api/x402/research-feed \
  -H 'PAYMENT-SIGNATURE: <base64 signed PaymentPayload>'

JavaScript request flow

const response = await fetch(resourceUrl);
if (response.status !== 402) throw new Error("Expected a quote");
const requirements = JSON.parse(atob(response.headers.get("PAYMENT-REQUIRED")));

// Verify the quoted asset, network, recipient, and maximum cost.
// Sign with your wallet (EIP-3009 or Permit2, per extra.assetTransferMethod); never send a key to the website.
const signedPayload = await signWithYourWallet(requirements);
const paid = await fetch(resourceUrl, {
  headers: {"PAYMENT-SIGNATURE": btoa(JSON.stringify(signedPayload))}
});

// 202: retry this exact payload. Do not create a second payment.
const result = await paid.json();

signWithYourWallet is an integration placeholder for your wallet’s EIP-712 signing method, not an installed Node402 SDK. The Playground implements that signing flow with an injected wallet.

Discover machine-readable products

GET /api/v2/system
GET /api/v2/products
GET /api/public/rwa/<slug>

Facilitator API

POST /api/facilitator/verify
Content-Type: application/json

{"paymentPayload": {"...": "the signed v2 payload"}}

200 {"isValid": true, "payer": "0x..."}
402 {"isValid": false, "invalidReason": "invalid_signature"}

For POST products, send the signed request directly to the resource endpoint. This binds settlement to the HTTP method and body and delivers the result in the same flow. The standalone settle endpoint binds an empty-body GET request.

Permit2 settlement uses the canonical Permit2 contract and the x402 exact proxy at 0x402085c248EeA27D92E8b30b2C58ed07f9E20001 on Robinhood Chain. The witness binds the recipient, so the relayer can only broadcast the transfer the payer signed. Direct-transfer proofs are not accepted.

Wallet verification

Creator actions require a verified wallet. On the Railway deployment, signing the verification message creates your account session. Your wallet address identifies your products across browsers; a secure cookie keeps each browser signed in. Node402 issues a five-minute challenge containing the site, chain, nonce, and expiry. It verifies the signature server-side and consumes the challenge atomically. Wallet verification lasts 24 hours. Account and network changes clear the local connection.

POST /api/node402/wallet/challenge
{"address":"0x..."}

POST /api/node402/wallet/verify
{"id":"<challenge id>","signature":"0x..."}

GET /api/node402/session
POST /api/node402/wallet/disconnect

RWA records

A creator can attach an issuer, custodian, jurisdiction, declared valuation, valuation date, and public document to a product. A verification request fetches the approved document URL and compares its SHA-256 hash with the declared digest.

A matching hash verifies document integrity only. It does not establish legal ownership, reserves, issuer identity, asset value, or a token holder’s rights. Those remain creator declarations. Editing a record clears its previous document-match status.

The public attestation returns canonical JSON and an HMAC-SHA256 signature when the internal signing secret is configured. HMAC is a shared-secret signature; independent verification requires the verifier to possess the corresponding secret.

Signed webhooks

Create a webhook in Integrations. Its secret is shown once and stored encrypted. Node402 sends a payment.settled event after successful resource delivery, with the receipt ID, transaction, payer, product, asset, and amount.

X-Node402-Signature: t=<unix-seconds>,v1=<hex signature>
Idempotency-Key: <webhook-id>:<receipt-id>

signature = HMAC-SHA256(secret, timestamp + "." + rawBody)

Check the timestamp, compare signatures in constant time, and deduplicate the idempotency key. The first delivery is recorded atomically. Failed notifications appear in the dashboard; this release does not automatically retry webhook notifications. Paid webhook actions also use a receipt idempotency key; an uncertain upstream response is never automatically executed a second time.

API keys

Generate a named read-only or read/write key after verifying your wallet. Copy it once. The database stores only its SHA-256 hash. Keys are scoped to their owner and wallet and can be revoked immediately.

curl https://YOUR_PUBLIC_HOST/api/node402/dashboard \
  -H 'Authorization: Bearer n402_...'

A read/write key can manage the associated creator’s products, keys, and integrations. Keep it on your server; do not include it in frontend JavaScript.

Errors and recovery

Operator configuration

Secrets belong in server environment settings. They are never requested in a wallet form or exposed in status responses.

NODE402_RPC_URL=https://rpc.mainnet.chain.robinhood.com
NODE402_PUBLIC_ORIGIN=https://YOUR_PUBLIC_HOST
NODE402_MIN_CONFIRMATIONS=2
NODE402_RELAYER_KEY=<dedicated funded relayer private key>
NODE402_SECRET=<at least 32 random characters>
NODE402_ORIGIN_ALLOWLIST=api.your-domain.com,files.your-domain.com

NODE402_ASSETS=[{
  "address":"<ERC-20 payment asset>","method":"permit2",
  "symbol":"<symbol>","decimals":6,
  "name":"<EIP-712 domain name, used for eip3009 only>","version":"1"
}]

NODE402_PONS_ABI=<verified factory ABI JSON; optional explorer fallback>
NODE402_PONS_ROUTER_ABI=<verified router ABI JSON; optional explorer fallback>
NODE402_PONS_CONFIG=<array of verified paired-asset launch configurations>

Each launch configuration contains configId, launchFeeWei, pairToken, pairSymbol, pairDecimals, expectedEconomics, curveFeeBps, graduationThreshold, snipeTaxBps, snipeTaxSeconds, maxCreatorTaxBps, and the verified feeGetter and economicsGetter ABI method names. Node402 rereads fee and economics and simulates before offering a transaction.

Storage uses D1 for records and R2 for images and larger delivery results. A publicly reachable origin and public site access are required for third-party agents and launchpad indexers. Setting the public-origin environment variable does not itself change site access.

Security and limits

• Amounts are exact integer base-unit strings; no floating-point settlement arithmetic.
• Payment signatures bind the configured token domain, chain, payer, payee, nonce, amount, and validity window.
• Proofs and transaction hashes are unique in storage. The same payment is bound to one product and request body.
• The signed raw transaction is recorded before broadcasting, so retries reuse its exact nonce and transaction hash.
• Resource output is released only after the required confirmations and a matching onchain Transfer event.
• External actions reserve delivery before execution; uncertain outcomes require reconciliation instead of blind retries.
• Hosted JSON and incoming resource bodies: 64 KB. Origin API responses: 1 MB. File responses: 10 MB. Token images: 2 MB.
• Resource and verification requests: 60 per minute per client. Settlement: 20 per minute. Wallet challenges: 20 per minute.
• Creator reads and writes enforce server-side ownership. API-key secrets are hashed; webhook secrets are encrypted.

Release status and integration boundaries

The application includes executable backend handlers for product management, wallet verification, x402 exact payment verification and settlement (EIP-3009 and Permit2), token transaction preparation, launch receipt verification, RWA document checks, API keys, and webhook notifications. Their live readiness depends on configuration, available upstream contracts, and real chain testing.

The pons V2 factory economics and explorer ABI could not be verified in the build environment. No token was launched and no mainnet payment was sent during development. This release must not be described as having verified 1:1 production parity until those integrations have passed real transaction tests. The earlier demo-credit sandbox remains available at /sandbox; its receipts are separate from onchain payments.

References: Robinhood Chain, x402 HTTP transport, pons documentation, and indexed pons V2 contract interface. Node402 is independent of Robinhood Markets, pons, and the x402 authors.