Your paid API works on a laptop. The payment request appears, a test wallet signs it, and the job returns a result. Then the production rollout settles a payment on the wrong network, or accepts a payment while the worker is offline, or exposes a private job without the authorization rule you thought you deployed.
A paid service deployment has separate payment, queue, worker, and result states. The HTTP server, payment network, facilitator, service registry, provider runtime, execution queue, and result path can all report different states. The launch test is concrete: a known payer must discover the right price, receive the right payment request, settle on the intended network, enqueue exactly one job, and observe a separately verified result.
This production deployment checklist follows that launch test through dev, staging, and mainnet. It covers the health, stats, price, authorization dry-run, and paid-job routes documented by the current Tangle runner for x402, an HTTP payment protocol, plus accepted-token, quote-TTL, and job-policy fields from the public configuration.
Start with x402 payments for the request flow and confidential execution for the confidential-execution boundary.
The protocol, runner, and payment gateway roles
Tangle is a protocol for registering and coordinating services run by independent operators. A Blueprint is the deployable definition of a service, including its jobs and operating rules. An operator is the person or service that runs a Blueprint instance. A runtime is the process that loads the Blueprint, exposes its interfaces, receives jobs, and produces results. The Blueprint Runner is the runtime component that receives and dispatches typed job calls. A TEE, a trusted execution environment, isolates code and data from parts of the host; an attestation is the signed evidence used to check the deployed measurement.
x402 is an HTTP payment protocol. When a client requests a paid resource without a valid payment, the server returns HTTP 402 with the amount, asset, recipient, and network needed for payment. The client signs a payment and retries. A facilitator verifies payment payloads and returns the payment scheme’s settlement result before the gateway enqueues work. The Tangle gateway’s current behavior enqueues the job after settlement. The current x402 seller flow describes the 402, signed retry, verification, settlement, and response sequence.
Tangle’s x402 gateway is an optional payment ingress for Blueprint jobs. It exposes health and price discovery, checks payment through a facilitator, and enqueues a job call after settlement. A JobCall is the typed runner record created for an accepted invocation. The current Tangle x402 runner documentation documents these endpoints:
| Endpoint | Meaning |
|---|---|
| GET /x402/health | The gateway can answer a health request |
| GET /x402/stats | Gateway counters and operating statistics |
GET /x402/jobs/{service_id}/{job_index}/price | Discover the configured price for one job |
POST /x402/jobs/{service_id}/{job_index} | Pay for and enqueue one job invocation |
POST /x402/jobs/{service_id}/{job_index}/auth-dry-run | Test authorization without mutating job state |
The POST route returns HTTP 402 when payment is missing or invalid. After a valid payment is settled, it returns HTTP 202 Accepted and enqueues a JobCall. 202 means accepted for processing, not completed. Your client needs a polling endpoint, callback, or result retrieval job after the payment response.
The payment network is not automatically the same network that runs the Tangle service. For example, a Blueprint can use Base for USDC settlement while its service registration and operator coordination use another network. Treat the payment chain, asset contract, recipient address, service ID, job index, and runtime endpoint as separate configuration values. CAIP-2, short for Chain Agnostic Improvement Proposal 2, is the standard notation that combines a namespace and chain reference into one network identifier. An RPC (remote procedure call) endpoint is the network node interface used to read or submit chain requests.
Dev, staging, and production configuration differences
Diff environment manifests and require approval for each changed field before promotion. Keep the typed job schema invariant across environments, and make the build check reject environment-specific schema changes. Require an approved diff for network, token, recipient, policy, and worker-capacity fields:
| Concern | Dev | Staging | Production |
|---|---|---|---|
| Payment network | Local or disabled | Testnet with test assets | Intended mainnet |
| Token contract | Test deployment or none | Testnet token address | Mainnet token address |
| Recipient | Non-custodial test account | Staging operator account | Independently verified production account |
| Facilitator | Local or test facilitator | Trusted testnet endpoint | Trusted HTTPS production endpoint |
| Invocation policy | Disabled by default | Explicit test job policies | Explicit public or restricted policies |
| Rate and markup | Small, obvious test values | Recorded test values | Approved rate and markup with a refresh policy |
| Worker capacity | One disposable worker | Isolated worker pool | Monitored, restartable pool |
| Confidential jobs | No secrets | Synthetic secrets only | TEE and attestation policy if required |
| Recovery | Resettable state | Repeatable test data | Documented rollback and customer response |
Do not promote a configuration by changing every field at once. First prove the route with payment disabled. Then prove testnet settlement with one inexpensive job. Then enable the smallest production job set and expand only after the complete payment-to-result path has been observed.
The configuration facts that need proof
The current Tangle x402 configuration includes a bind address, facilitator URL, accepted token definitions, a conversion rate, a markup in basis points, an invocation mode, and per-job policies. Basis points are hundredths of a percent, so 200 basis points means a 2 percent markup. The public Blueprint source defines a quote TTL with a current default of 300 seconds, but a deployment should make its chosen value visible and test it.
An illustrative configuration fragment shows the shape without pretending that an example wallet or facilitator is yours.
This fragment omits deployment-specific facilitator_url and pay_to values.
Validate every value against the release’s public source and inject sensitive values outside the file.
bind_address = "0.0.0.0:8402"
quote_ttl_secs = 300
default_invocation_mode = "disabled"
[[accepted_tokens]]
network = "eip155:84532"
asset = "0x036CbD53842c5426634e7929541eC2318f3dCF7e"
symbol = "USDC"
decimals = 6
rate_per_native_unit = "3200.00"
markup_bps = 200
transfer_method = "eip3009"
eip3009_name = "USD Coin"
eip3009_version = "2"
[[job_policies]]
service_id = 1
job_index = 0
invocation_mode = "public_paid"The example uses the current public array shapes for accepted_tokens and job_policies; the network, rate, service, and job values are illustrative.
Use the current public x402 configuration source and the matching release documentation when constructing the complete file.
Do not infer that a field is accepted merely because an older example contains it.
Before enabling a token, verify all of these as one record:
- The network identifier uses the intended CAIP-2 form, such as eip155:8453 for Base or eip155:84532 for Base Sepolia.
- The token contract is the official contract for that network.
- The token decimals match the contract.
- The recipient address is controlled by the intended operator or treasury.
- The conversion rate has a source, timestamp, and refresh policy.
- The markup is expressed in basis points and has an approved maximum.
- The transfer method is supported by the deployed facilitator and token.
For USDC (USD Coin), Circle’s official contract address list currently identifies Base mainnet as 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 and Base Sepolia as 0x036CbD53842c5426634e7929541eC2318f3dCF7e. Verify the address again at release time and in the target chain explorer. An address copied from a different network can be syntactically valid and still be the wrong asset.
Payment-disabled development loop
Dev should answer whether the Blueprint can load, expose its routes, validate a job body, and produce a result without involving real money. Set the default invocation mode to disabled and allow only the local path needed for development. Use synthetic inputs and a disposable operator account.
The first check is the health endpoint:
curl -fsS "$X402_BASE_URL/x402/health"
curl -fsS "$X402_BASE_URL/x402/stats"The X402_BASE_URL environment variable should point to the process under test. The health response proves that the gateway answered. It does not prove that the worker is healthy, the facilitator is reachable, the token is correct, or the job can finish.
Next, call one known job through the normal runtime path. Record the service ID, job index, request identifier, queue acceptance, worker start, worker completion, and result retrieval. If the job is asynchronous, the client should never treat an HTTP response from the gateway as the result unless the API explicitly says it is synchronous.
Dev is also where you test malformed input. Send an unknown service and job pair, an invalid body, an oversized body, a missing caller, and a repeated idempotency key. The desired behavior is an explicit rejection with no payment attempt and no duplicate queue item.
Testnet payment cell
Staging should use a real remote path and a test asset. A testnet payment has no production value, but it verifies the selected chain and token, the facilitator response, the settlement record, and the single enqueue record before mainnet.
Begin with discovery:
curl -fsS "$X402_BASE_URL/x402/jobs/$SERVICE_ID/$JOB_INDEX/price"
curl -fsS -X POST "$X402_BASE_URL/x402/jobs/$SERVICE_ID/$JOB_INDEX/auth-dry-run" \
-H "content-type: application/json" \
--data "$AUTH_DRY_RUN_BODY"The environment variables in this block should be populated with the staging gateway URL, a real test service ID, a real job index, and a test authorization body. The commands are useful because they separate route discovery and authorization from payment settlement. Do not use a production wallet to make the first testnet call.
Then exercise the payment state machine:
POST /x402/jobs/{service_id}/{job_index}
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: value omitted from this state diagram
POST /x402/jobs/{service_id}/{job_index}
HTTP/1.1 202 Accepted
PAYMENT-RESPONSE: value omitted from this state diagramHeader names depend on the x402 integration version. The current generic x402 documentation recommends the v2 payment headers, including PAYMENT-SIGNATURE and PAYMENT-RESPONSE. The current Tangle Blueprint x402 crate README documents its Axum integration with X-PAYMENT and X-Payment-Response. Do not mix a client from one header version with a server from the other. Use the headers documented by the exact Tangle crate and facilitator versions deployed together. The x402 migration guide explains the v1 and v2 difference, and the public Tangle x402 crate shows the current Blueprint integration.
The staging proof has four independent observations:
| Observation | What it proves | What it does not prove |
|---|---|---|
| Price response | The service and job are discoverable | The price is economically correct |
| 402 response | The route requires payment | The facilitator can settle |
| Settlement response | The payment was accepted by the payment path | The worker completed the job |
| Result record | The runtime produced a result for the accepted job | The result is semantically correct |
A correctness check must validate the output schema, required invariants, or a fixture comparison separately. Save the transaction or payment identifier with the job identifier. Map an idempotency key to the payment identifier and assert one JobCall per key. A timeout can then recover the existing payment and job state instead of creating a second invocation.
The mainnet promotion: narrow the blast radius
Production should begin with one job policy and one operator account. Enable only jobs with an explicit price, input validation, queue capacity, result path, and customer-facing failure policy.
Set the default invocation mode to disabled or to the least permissive mode that matches the product. Use public-paid only for jobs that are safe for any payer to invoke. Use restricted-paid when the caller must be authorized. The current Tangle gateway documents caller binding through payer-is-caller or delegated caller signatures, with a contract-side permitted-caller check for the restricted path.
The distinction between payment authorization and job authorization should be visible in the trace. A payer may be allowed to settle while the requested caller is not allowed to invoke the job. The auth-dry-run endpoint exists to test that decision without creating a job. Use it in deployment checks and in regression tests for every restricted job.
Production should also use a trusted HTTPS facilitator and a documented rate source. The Tangle documentation recommends fresh conversion rates, input validation, pinned RPC and contract settings, and a facilitator that the operator trusts. If the rate is stale, the quote can be economically wrong even when every signature and address is valid. If the RPC or contract is unpinned, a deployment can appear healthy while reading a different chain state than the client expects.
Confidential jobs need a separate proof
An attestation is signed evidence about the environment and the software measurement that ran. The evidence can help a buyer decide whether to release sensitive input, but it must be checked against an explicit policy.
Payment success does not prove attestation. An HTTP 202 does not prove attestation. An operator’s claim that it uses a TEE does not prove attestation. If confidentiality is part of the job contract, verify the attestation before sending the secret and record which measurement and provider policy passed.
The current public Tangle TEE support covers providers such as AWS Nitro, Azure SNP, Google Confidential Space, TDX, and SEV-SNP, and exposes a required TEE mode in the Blueprint library. Provider availability and measurement policy vary by deployment. Read the current Tangle TEE implementation for the provider and runtime mode you use. A production measurement policy must name the image, code, and configuration it authorizes; re-check it instead of carrying staging values forward.
A deployment evidence record
Before promotion, create one short record for each environment. It should be sufficient for another operator to answer what was paid, where it settled, what job was accepted, and whether the result was produced.
| Evidence field | Proof to capture |
|---|---|
| Environment | Staging or production label and release identifier |
| Payment network | CAIP-2 identifier for the settlement chain |
| Asset and contract | Token symbol, decimals, official contract address, and explorer link |
| Payment recipient | Ownership or authorization evidence for the operator account |
| Service and job | Registered service ID and job index |
| Price source | Rate source, value, timestamp, and markup policy |
| Facilitator | HTTPS endpoint and the version supported by the gateway |
| Invocation mode | The tested public-paid or restricted-paid policy |
| Payment, job, and result IDs | The identifiers that let another person reconcile the full path |
| Attestation | Required, passed with measurement and policy, or not part of this job |
The deployment owner should capture each field from the target environment and link the public contract or transaction where appropriate. The point of the record is reconciliation, not paperwork.
The runtime should expose enough events to build a trace: price discovered, payment required, payment verified, settlement accepted, job enqueued, worker started, worker finished, result available, and failure or refund decision. An evaluation is a repeatable check of whether the result meets the job’s stated requirement. An evaluation should replay the trace with missing, duplicated, delayed, and malformed events. This catches errors that a health check cannot see.
Rollback is a payment decision
Rolling back code is not the same as rolling back a settled payment. If a payment has settled and the worker is then disabled, the product still needs a result, refund, retry, or dispute policy. Write that policy before the first mainnet payment.
| Failure | Immediate action | Customer-facing state |
|---|---|---|
| Gateway starts with wrong network | Disable paid invocation and fix configuration | Payment unavailable |
| Token contract is wrong | Reject all payment and rotate the configuration | Payment unavailable, no job accepted |
| Facilitator is unreachable | Fail closed or pause paid jobs | Payment pending or unavailable |
| Payment settles but enqueue fails | Preserve payment and request identifiers, then reconcile | Payment received, job pending investigation |
| Worker dies after 202 | Keep the job pending until timeout policy fires | Accepted, not completed |
| Result is wrong | Preserve evidence and invoke the service’s quality or dispute path | Completed technically, under review |
| TEE attestation fails | Do not release confidential input | Confidential execution unavailable |
Fail closed at the money boundary. A process that cannot verify the network, asset, recipient, or payment status should not accept a request because it hopes the missing check will resolve later. Queueing after confirmed settlement is safer than queueing before settlement, but it still needs idempotency and reconciliation.
The final launch sequence
The production checklist is short when expressed as a sequence:
- Load the Blueprint with paid invocation disabled.
- Confirm health, stats, and one local job result.
- Confirm the target network, asset contract, decimals, recipient, rate source, and facilitator independently.
- Run authorization dry-runs for every job policy.
- Use one testnet payment to observe 402, settlement, 202, queue, worker, and result.
- Confirm the client uses the header version supported by the deployed Tangle integration.
- Enable one mainnet job for one operator account.
- Inspect the first payment, job, result, and trace as separate records.
- Expand the job set only after the first production path is reconciled.
The order matters because each step makes a smaller claim than the next. A health response is cheaper to obtain than a settlement. A testnet settlement is cheaper to investigate than a mainnet payment. A single production job is easier to reconcile than an entire public catalog.
Promote one reconciled path
An x402 Blueprint is ready for production when its payment state and execution state can be observed separately and reconciled together. The deployment must know which network and asset it accepts, where money goes, which callers may invoke which jobs, what 202 means, and how a failed or confidential job is handled.
The checklist is not a promise that every job will succeed. It is a way to make the remaining failures visible before they become silent money or trust failures. Promote one known path, keep the policy narrow, and expand only when the evidence record says the complete path works.
Does an x402 payment mean the job is complete?
No. In Tangle’s current gateway, a valid payment can produce HTTP 202 and enqueue a JobCall. The client still needs the result or status path.
Can I use any USDC address on Base?
No. The token contract is network-specific. Verify the address against the issuer’s official documentation and the target chain before enabling payment.
Should paid invocation be public by default?
No. Start disabled, then enable only tested job policies. Use restricted-paid when the caller or delegated identity needs authorization.
Does x402 provide TEE attestation?
No. x402 handles payment communication and settlement. TEE attestation is a separate execution and evidence policy.
What should be pinned in production?
Pin the payment network, token contract, recipient, facilitator, RPC or contract addresses, Blueprint and gateway versions, rate source, and job policy. Record those values with the first production payment.
For the product-level decision about making those payments native to an agent workflow, see payment-native AI agent infrastructure.