# Scale and Bitcoin timing

P21 separates agent execution from Bitcoin commitment timing. Reusable block data, cached evidence, and local verification keep ordinary checks off-chain. A fresh Bitcoin transaction, inscription, or mint is not required for each request.

## Separate the fast and slow paths

Ordinary supported checks can complete without waiting for a new Bitcoin block. An optional timestamp can remain PENDING until independently verifiable. A selection requiring future Bitcoin data must wait for its specified source and confirmation policy. Approximate block cadence is not a deadline.

## Batch commitments

A Merkle commitment can represent many report digests in one root. An illustrative balanced binary tree of one million SHA-256 leaves has a 32-byte root and roughly 20 sibling hashes per inclusion path: approximately 640 bytes before other proof metadata. This is arithmetic, not a throughput benchmark.

Batching reduces commitment overhead; it does not eliminate storage, bandwidth, indexing, backups, or data availability. At an illustrative 2,000 bytes per report, one million reports per day require about 2 GB/day before evidence and replicas.

## Shared-source risk

Generating many outputs from one public seed does not generate independent entropy. A common seed can create aggregate incentives to influence many jobs. Selection profiles must assess total value affected, not just the fee for one request.

## Performance measurement

Performance reporting separates evidence-fetch latency, cache hit rates, evaluation time, local verification time, payload size, cost per job, and reorganization recovery. Published results identify the exact implementation, method, and workload; illustrative arithmetic is not a throughput claim.

Sources: [Bitcoin block reference](https://developer.bitcoin.org/reference/block_chain.html), [OpenTimestamps](https://opentimestamps.org/), [Bitcoin Beacon research](https://arxiv.org/abs/1605.04559).

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

## Cache definitions, validate chain status

Once validated under a pinned profile, element content can be cached by inscription ID and content digest. Fetch each required block once and reuse it across off-chain jobs. Revalidate canonical-chain status, index coverage and applicable rules; reorganizations invalidate affected cache entries and pending outcomes. A cached name is not permanently valid regardless of chain history.

Receipt throughput is primarily an application-compute, storage and delivery concern, not one Bitcoin transaction per proof. Fresh Bitcoin-dependent selection still waits for the specified source and confirmation policy. Optional Merkle batches anchor receipt digests; anchoring records prior existence, not correctness, completeness or data availability. There is no published P21 throughput benchmark.


## 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