x402 and commercial evidence

The commercial interface separates service payment from evidence verification. A programmatic payment rail pays for hosted work; the protocol does not require a P21 token. Local verification uses supplied evidence and accepted keys independently of that payment.

Reuse existing artifacts

x402 already defines signed offer/receipt artifacts. Preserve their issuer, original bytes, terms, and settlement references. A payment artifact does not by itself prove that an arbitrary financial task was completed correctly.

PEAC is another existing portable interaction-record implementation. Treat it as a possible carrier or input rather than assume P21 must replace every record format. Verify linked evidence under its own rules.

Paid-job contract

An agent requests a supported job and receives explicit payment terms. After an authorized payment, P21 performs the agreed evidence collection/evaluation and returns a report or job identifier. Bind payment, operation, input digest, and response without confusing the service fee with the financial transaction being checked.

The payment contract binds idempotency to the caller and request digest. Retries retain the original job identity; a repeated request does not create a second charge. Missing data, provider failures, and incompatible inputs have distinct outcomes and service-policy treatment.

Economics

Measure realized price, settlement costs, data costs, storage, compute, and support. Fractions-of-a-cent pricing is not automatically profitable. Use supported batching or prepaid usage where appropriate; do not describe a planned mode as universally supported.

References: x402 introduction, offers and receipts, PEAC.

<!-- p21-source-payment-v08 -->

Initial payments: native NAT and USDC

Native NAT is a required initial commercial-launch payment method, alongside USDC on the validated x402 rail. It is not relegated to a later optional integration. The evidence protocol remains payment-agnostic: a customer chooses a supported method and independent receipt verification never requires buying NAT or a P21 token.

The native NAT profile identifies Bitcoin mainnet, TAP, the original NAT deployment inscription and its normalized fungible ticker. A token with the same symbol on another chain is a different asset unless a separately reviewed profile identifies it explicitly. Transferring a UNAT mint inscription does not transfer its fungible NAT balance. [3][4]

NAT invoices and prepaid service-credit top-ups are asynchronous: confirm an executed fungible transfer under the pinned TAP rules, then credit usage once. Subsequent small jobs consume internal non-transferable service credits; they do not each create a NAT transfer or inscription. Those credits are a service accounting record, not a P21 token, yield product or claim of trustless custody. Direct larger-job invoices can use the same settlement checks.

NAT support does not require an automatic DEX conversion. Quote fixed NAT amounts for a defined service package, or use a separately approved price policy with quote expiry and rounding. Publish network fees, minimum top-up, late/partial/overpayment, cancellation and refund rules before accepting money. No exchange rate or minimum is invented by this specification.

Payment evidence and exactly-once accounting

An invoice binds caller, request digest, idempotency key, exact network and asset identity, merchant recipient, integer atomic amount, service-credit entitlement, expiry and settlement policy. A payment adapter checks an executed transfer event and its destination, amount, deployment identity, canonical block, confirmations, index coverage and supported rule revision. A transaction ID, mempool observation, inscription creation or wallet balance screenshot is not payment settlement.

Store event uniqueness using network, asset deployment, transaction and operation/inscription identity. Bind invoice ownership to the caller through the invoice contract rather than accepting any submitted transaction hash. Use atomic ledger transactions and unique constraints for settlement crediting, job reservation, consumption and release. Network retries and webhook replay never create another credit or charge. Missing evidence, lagging/conflicting indexers and reorganizations remain pending or require review. Define a compensating journal and operator-loss policy for a deep reorganization; do not silently debit another customer payment.

Separate service fees, checked actions and treasury trades

Keep the service payment, the financial action being checked and any later treasury conversion as three separate records. Treasury conversion is optional and separately authorized after revenue settles, preferably batched. Approved routes require an executable quote, minimum output, slippage and fee limits, exact asset identities and explicit bridge/custody assumptions. A failed treasury trade does not erase a settled customer payment, duplicate the charge or alter a proof result.

USDC uses a validated x402 scheme and facilitator path; the standard's ability to express an asset does not establish production settlement. Native TAP-NAT is a separate payment adapter, not an unsupported claim of stock x402 compatibility. Neither an arbitrary wrapped token nor a generic DEX API substitutes for native NAT acceptance. [5]

Commercial activation and implementation status

NAT and USDC are both required for the initial commercial-launch acceptance test. Public documentation, source code and policy fixtures are not live payment endpoints. The static payment-policy resource lists required launch methods with enabled: false, no recipient and no live endpoint until each rail passes end-to-end settlement, accounting, failure/reorganization, security and owner-approval gates. Do not advertise a USDC-only release as the completed initial payment scope.

No token has been issued, no source element is announced, and no mainnet inscription, customer charge, treasury swap or wallet authorization is performed by this release. Production service availability remains separate from website publication. No Trac partnership, hosted SLA or independent cryptographic audit is implied.

[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559

<!-- p21-ecosystem-payments-v09 -->

NAT across networks

NAT has cross-chain representations; it is not confined to a Bitcoin-only user interface. The reviewed records identify an Ethereum representation, a Solana asset labeled dmt-nat (Wormhole), and a BNB Smart Chain bridge-token contract. This broadens the routes through which the NAT community can access services. These records establish identifiable representations, not a P21 audit of bridge backing, origin mapping, redemption or current bridge availability.

Native Bitcoin TAP-NAT remains a required initial method. Cross-chain NAT is a first-class adapter target, with each network and contract or mint approved separately. A representation must preserve its exact origin/deployment reference, bridge route and version, destination identity, decimals, finality and pause/redemption assumptions. A ticker match is never sufficient; neither is an exchange listing alone. An approved representation can pay on its destination network without making each P21 job perform a bridge or treasury swap.

The representation review does not change DMT source resolution: Bitcoin remains the source of a Bitcoin/DMT claim even when its service fee arrives elsewhere. The P21 source element remains to be announced. No NAT bridge is activated by this publication.

Stablecoins matched to each integration

The initial core requires native NAT and USDC on Base. Each additional commerce integration launches with an explicit asset/network/method allowlist, rather than assuming every ecosystem uses the same stablecoin. Provider documentation reviewed on 9 September 2026 establishes the following implementation targets; it does not establish that P21 already operates them.

Binance's published BSC mainnet entries use 18 decimals, including its USDC and USDT contracts. Base USDC uses a different contract and 6 decimals. Never copy decimal assumptions between networks or confuse testnet assets with mainnet assets. Do not add FDUSD or another coin merely because it is associated with an exchange; verify the specific payment product.

Before advertising an available method, intersect the owner's allowlist with the configured provider's current supported capabilities. Pin the network, token, decimals, payment method and recipient; validate permitted spender/signer addresses and preserve required authorization metadata. Refresh capability data without letting it silently expand the allowlist. B402 production access requires provider onboarding. All P21 routes remain disabled until implementation, settlement tests and approval are complete.

Multi-asset accounting and treasury boundaries

Let customers choose among explicitly supported assets; do not force a NAT purchase or a swap before every call. Price service entitlements with an expiring quote, exact atomic units and a stated rounding rule. Record both the received asset quantity and the service entitlement. Stablecoin labels do not eliminate issuer, depeg, bridge or network risks; review those per route and provide a pause policy.

Keep payment settlement, service-credit consumption, the action under inspection and any treasury conversion separate. Settle directly into approved merchant recipients. A later conversion is optional, separately authorized and preferably batched; failed conversion cannot erase settled customer credit or change an evidence finding. Adding a rail is implementation work, not a token partnership or an automatic claim of wallet compatibility.

Binance assets and methods · Binance integration · Coinbase facilitator · PayAI assets · Virtuals ACP · NAT Ethereum listing · NAT Solana record · NAT BNB Chain contract