# Choice and audit sampling

**Experimental. Not suitable for high-value randomness or automatic fund release until reviewed.** The product is a verifiable selection workflow, not access to a nonce.

## Selection state machine

`DRAFT → COMMITTED → WAITING_FOR_SOURCE → SOURCE_CONFIRMED → DERIVED → COMPLETE`

Terminal exceptions are EXPIRED, CANCELLED_BEFORE_COMMITMENT, SOURCE_UNAVAILABLE, and INVALIDATED_BY_REORG. Cancellation after commitment does not create a free reroll. The state machine records source and derivation history for the consumer.

## Bind before the source is known

Commit the request ID, eligible items and their deterministic ordering, weights if supported, policy/algorithm version, requested sample size, future source rule, finality threshold, and deadline. Commitments must be observable under an identified trust model; a server's unsigned timestamp is not evidence of precommitment.

Define exact source selection and fallback behavior in advance. No operator-selected favorable block, post-result candidate edits, silent beacon switching, modulo-bias shortcut, or discard-and-retry loop.

## Sampling is not completeness

A verifiable sample of 10,000 committed jobs does not establish that all eligible jobs were included. Completeness needs a separate event ledger, independent observation, or business control. Likewise, selecting an evaluator fairly does not prove evaluator competence or independence.

## Source modes

Historical Bitcoin data supports reproducibility, not fresh unpredictability. Future Bitcoin sources have latency and miner/operator influence assumptions. An established external beacon can be a separate adapter with its own proof and trust model. Height and bits must not be marketed as fresh random values.

## Launch gates

Publish source/mapping test vectors; model aborts, selective disclosure, reorganizations and total value at risk; review weighted selection and repeat sampling; obtain independent review before economic use. Return the committed inputs and exact derivation evidence so a consumer can reproduce the result.

Sources: [Bitcoin Beacon](https://arxiv.org/abs/1605.04559), [Chainlink VRF security considerations](https://docs.chain.link/vrf/v2-5/security).

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

## Reproducibility is not unbiased randomness

A public nonce is not a private or uniform randomness source. Hashing a nonce, or adding the block hash, does not remove miner influence or create independent entropy. Different request contexts produce different deterministic outputs, not newly independent randomness. [7]

For future-source selection, bind the eligible set, ordering, weights, request ID, context, algorithm, source profile, exact future-block rule and confirmation policy before the source is known. Preserve externally checkable evidence of that commitment's timing; a hash created afterward cannot prove precommitment. Define one accepted request, retries, cancellations, withheld outcomes, late publication and reorganization recovery so an operator cannot choose among rerolls. Assess aggregate value across jobs sharing a source. Historical replay and future-source selection must not share the same assurance label.


[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

