# For blockchain partners

Proof21’s partner model connects wallets, exchanges, DEXs, marketplaces, financial-agent platforms, and DMT/TAP services through portable evidence and independent acceptance policies.

## Integration value

Keep existing agents, settlement contracts, and guardrails. Add an inspectable verification workflow for selected claims that cross system boundaries.

Three core workflows are instruction-to-payout checks, reproducible DMT derivations, and independently replayable audit selection. Evaluation tracks reconciliation effort, evidence coverage, and detected mismatches.

## What we do not ask for

No custody migration, production seed phrases, unrestricted signing keys, replacement identity system, mandatory token purchase, or speculative partnership announcement. Start with anonymized records, test environments, or shadow mode.

## What we need from a partner

One defined workflow; the expected result; available evidence; an example failure; current verification steps; and a named operator who can judge usefulness. An agent's enthusiastic response is not a procurement decision or proof of budget.

## Who should start

DMT/TAP operators can help define derivation and state-evidence boundaries. Financial APIs can help bind a paid operation to its actual outcome. Wallet and DEX teams can identify evidence gaps not already solved by contract enforcement.

Any listing of external ecosystems in these docs is a compatibility target. It does not imply a partnership, certification, integration, or endorsement.

<!-- 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.


[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