# Usage economics and token roadmap **No token is issued or offered by this documentation. No eligibility, allocation, yield, or token conversion is promised.** ## Product revenue The service model covers hosted evidence collection, supported evaluations, selection workflows, monitoring, and integration support. Local verification remains independent of a P21-operated server when the required evidence and accepted keys are available. Public Bitcoin data does not carry a compulsory P21 royalty. Price against actual costs: data access, compute, payment settlement, storage, bandwidth, backups, and support. Microfees need sufficient paid volume and appropriate settlement batching; a tiny API fee is not automatically profitable. Measure paid jobs, independent paying operators, repeat usage, gross revenue, provider costs, and contribution margin. Do not count grants, investment, internal agent purchases, free verification, or refunded/subsidized calls as organic product revenue. ## Product before token Token ownership is not a prerequisite for the evidence model. Any network incentive mechanism has separate technical, economic, and legal requirements, including objectively enforceable conditions for bonding or slashing. No token issuance, supply, distribution, eligibility, returns, or launch date is offered here. Venice is a historical product-before-token reference, not a template that proves P21 needs identical economics or allocations. Source: [Venice token introduction](https://venice.ai/blog/introducing-the-venice-token-vvv). ## 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. ## 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] ## Cost model Reading public Bitcoin data and evaluating a supported element do not require a protocol mint fee. A voluntary new registration is an inscription with network fees and potentially a service charge; its acceptance and uniqueness must be checked before spending. Budget using quoted transaction virtual size times current sat/vB, plus service fees and the output value kept as inscription postage. Do not publish a stale dollar fee as a live quote. Ordinary off-chain receipts incur infrastructure costs, not a compulsory inscription each. NAT funding has its own Bitcoin/TAP settlement costs, amortized across service-credit usage; USDC has its chosen network/facilitator costs. API hosting, index operation or provider access, storage, bandwidth, security review, monitoring and support remain real costs. [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 ## 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](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882)