Proof of Provenance

Trading systems can selectively display favorable outcomes. BLEEEP makes a specific, testable claim: within a formally registered stream and its declared sequencing rules, disclosed records can be matched to registered cryptographic commitments. The registered-stream completeness controls defined below can expose certain gaps or unrevealed entries within that admitted scope.

Proof of Provenance is the layer that supports that claim. It commits each required artifact under its declared proof class, batches the commitments into a Merkle root, and lets anyone verify the commitment and Merkle inclusion proof after disclosure.

Under the production anchoring rules, a batch used for a pre-outcome timing claim must reach the required anchor finality before the applicable outcome deadline. An event-evidence batch may finalize afterward, but each record retains its event-evidence proof class and evidence-source label. Many cryptographic commitments can share one constant-size root transaction, while offchain processing and storage still scale with record count.

Why rejected and abstained records matter

Performance claims often omit the tested denominator, failed variants, or rules used to produce the result. A displayed return alone does not show whether the underlying record was changed, selectively presented, or statistically robust.

BLEEEP instead preserves registered abstentions and validation rejections, then publishes the view required by the registered disclosure rules. Over time, these records create a cumulative evidence base rather than a success-only showcase. The Evaluation and Decision Index supplies the admitted-record denominator for its declared scope and displays whether that denominator has reached registered-stream completeness verified; it does not prove that unregistered private experiments never existed.

The three parts

Proof of Provenance comprises three cooperating mechanisms:

1. Commit–reveal: seal a hash of each decision before the outcome, disclose the original afterward, and let anyone match the two as explained below.
2. Merkle anchoring: batch many seals into one root and anchor it onchain. This proves inclusion and makes alteration of anchored material detectable; completeness and ordering claims require the additional registered-stream controls described below. See Merkle anchoring.
3. NO-GO Archive: a filtered public view of registered strategy rejections and Trade Abstentions, with each entry carrying its applicable proof class and actual verification status. The broader Evaluation and Decision Index, not this filtered view alone, provides the admitted-record denominator and displays its actual completeness status. See the NO-GO Archive.

Three proof classes

Not every trading event can use the same timing claim.

A pre-outcome decision proof applies to signals, predictions, and TRADE_ABSTENTION records with a defined future outcome. It can establish that the disclosed record matches a commitment whose anchor reached the required finality before the predefined outcome deadline.

A computation-provenance record applies to strategy GO and NO_GO verdicts, validation reports, methodology outputs, score calculations, and ruleset snapshots. It can establish that the disclosed artifact matches the version committed by the accepted anchor time. Independent reproduction of correctness still requires the necessary inputs and computation.

An event-evidence record applies to forward-stream and execution-mandate lifecycle events, routing blocks, orders, acknowledgments, cancellations, fills, fees, funding-rate payments, paper-simulation outputs, and related account or venue events. Every record carries an evidence-source label:

• ON_CHAIN_TRANSACTION_RECORDS: demonstrated by finalized onchain transaction history that can be independently checked within the registered wallet or account, network, contract, and decoding scope;
• VENUE_AUTHENTICATED: supported by a venue- or broker-authenticated receipt;
• BLEEEP_GATEWAY_OBSERVED: supported by BLEEEP’s authoritative ingress or control-plane log but not independently confirmed by the venue;
• PAPER_SIMULATION: computed from a BLEEEP-accepted instruction, retained market evidence, and the frozen paper-execution model; or
• PARTICIPANT_ATTESTED: supplied by the participant without independent authoritative confirmation.

ON_CHAIN_TRANSACTION_RECORDS requires the relevant transaction and status to be independently checkable in finalized chain history within the declared scope. VENUE_AUTHENTICATED requires an integrity-protected receipt or authenticated account-history record obtained through the registered venue or broker path. Neither label proves offchain intent, beneficial ownership, or the absence of activity outside the registered scope.

For an execution-mandate lifecycle event, BLEEEP_GATEWAY_OBSERVED establishes only that BLEEEP’s control plane recorded the authenticated instruction or state transition. It does not independently prove that a venue enforced the mandate. Creation, scope change, suspension, resumption, detected expiry, automatic termination, and revocation records identify the actor, authentication method, mandate identifier and version, effective time, prior-version link, scope commitment, and recorded outcome under the applicable disclosure controls.

The evidence-source label defines the occurrence and timing claim that can be made. A PAPER_SIMULATION record establishes only that the disclosed simulated output matches the registered artifact under its stated evidence source. It does not establish that undisclosed inputs or computation were correct and never represents an actual venue fill. A later Merkle anchor makes alteration of the registered event-evidence record detectable from anchor finality onward, but it does not change the evidence-source label or enlarge the claim that label supports.

A batch root finalized only after an order or fill occurs cannot retroactively prove that the event existed before execution. A finalized onchain transaction record or venue-authenticated event receipt supports the disclosed occurrence, status, and time within its declared scope; the later Merkle anchor makes alteration of that registered record detectable from anchor finality onward. Public records must state the applicable proof class and, for event-evidence records, the evidence-source label rather than describing both the decision and the event as “pre-committed.”

Commit–reveal in depth

Commit to a decision before its predefined outcome deadline, then prove later that the disclosed record has not changed since that cryptographic commitment.

Each eligible pre-outcome decision, such as a signal, prediction, or TRADE_ABSTENTION, is encoded and hashed with a secret salt. A strategy-validation verdict instead uses the computation-provenance class. The following construction is conceptual; the canonical specification governs exact encoding and domain separation:

commit_i = keccak256( COMMIT_DOMAIN ‖ canonical_encode(record_i) ‖ salt_i )

The canonical encoding binds the schema version, proof class, stream identifier, sequence, and applicable network or deployment domain. At commit time, only the cryptographic commitment and ordering material enter the registered batch. The plaintext record and salt remain access-controlled under the registered disclosure, entitlement, and retention rules.

For an entitled Marketplace delivery, the subscriber receives the signal and the opening and verification material required by the entitlement after the accepted anchor reaches the required finality and before the later public reveal. The anchor establishes that the cryptographic commitment existed no later than the accepted anchor time, not the exact local moment at which a private decision was formed or what any person or system knew. A sufficiently random salt prevents practical dictionary guessing of a low-entropy record.

The lifecycle begins with commit: before the predefined outcome deadline, commit_i enters a batch for submission while the plaintext remains hidden from the public. An eligible Marketplace signal may then undergo entitled delivery after the anchor reaches the required finality, giving the authorized subscriber the signal and required verification material without making the record public.

Any resulting order, paper-simulation output, or venue event is observed or executed and recorded under the event-evidence proof class with its evidence-source label. After the outcome, public reveal discloses the original record_i and salt_i through the public disclosure surface. Anyone can then derive the cryptographic commitment and check its inclusion against the anchored root.

Verification succeeds only when three independent checks all pass:

• keccak256(COMMIT_DOMAIN ‖ canonical_encode(record_i) ‖ salt_i) equals the committed commit_i, so the record is unaltered;
• a Merkle proof places the derived leaf for commit_i inside the anchored root, establishing inclusion in that batch;
• the anchor reached the required finality before the predefined outcome deadline, so the disclosed decision record satisfies the registered pre-outcome timing rule.

If any required check fails, the record is not verified. After the batch root and manifest commitment reach onchain finality, replacing the disclosed record would break the commitment or inclusion check.

What is public, and what is not

Reveals disclose the committed decision record, not necessarily the full strategy logic. Disclosure schemas for private strategies limit revealed fields to those required by the registered rules because repeated disclosures may expose behavioral patterns. Any evaluator that executes or validates private logic must still have the access required by its declared architecture.

Only the required results, metrics, verdicts, and proof material reach the public surface. A cryptographic commitment proves the provenance of those disclosures; it does not let a public verifier reproduce a verdict from undisclosed code or inputs. See the architecture for that boundary and validation for how GO and NO_GO verdicts are formed.

An onchain transaction receives the ON_CHAIN_TRANSACTION_RECORDS label only when it can be independently checked within the registered wallet or account, network, contract, decoding, and chain-finality scope. A broker or centralized-exchange fill requires VENUE_AUTHENTICATED evidence; without it, the fill retains its actual lower-assurance evidence-source label even if BLEEEP later anchors the record. No proof class establishes that unregistered activity is absent or guarantees future returns.

Minimum public record and completeness boundary

Every admitted item represented in the public Evaluation and Decision Index, including an item with a late, invalid, withdrawn, interrupted, unresolved, unrevealed, corrected, superseded, or other non-result state, must expose a minimum public record. That record contains its durable identifier and version, admission-receipt identifier, proof class where applicable, registered scope, ruleset and manifest identifiers, current result or disposition, evidence-completeness status, reveal status, anchor status and reference, and any append-only superseding correction.

Personal data, private strategy logic, restricted evidence, and commercially sensitive fields may remain access-controlled. The minimum public record cannot omit an unfavorable admitted outcome merely because the underlying details are private.

An inclusion proof answers whether one disclosed record belongs to an anchored batch. A registered-stream completeness claim asks a different question: whether the stream contains every record required by its published admission rules. BLEEEP applies registered-stream completeness verified only when auditable admission-receipt, per-stream-sequencing, batch-boundary, expected-count, prior-root-link, reveal-deadline, correction, retention, and availability controls support the declared denominator. Where a required control or retained artifact is unavailable, individual records may be labeled inclusion verified, but neither the Index nor the stream is described as complete.

A registered stream becomes active only when its admission receipt and declared start condition are accepted. From activation through closure, every opportunity required by the admission rules produces an ordered decision, abstention, no-data, no-decision, or system-fault record. This supports the declared denominator after activation; it does not establish completeness for activity before admission or outside the registered scope.

Next: Merkle anchoring covers how commitments become one anchored root.