16. RandProof Audit: Continuous Contract and State Monitoring

Every product specified so far attests a single event: a random value was generated, a condition was met, a computation occurred, a data point was tru

[Layer 1: Core, Design Stage]

Every product specified so far attests a single event: a random value was generated, a condition was met, a computation occurred, a data point was true at a moment in time. RandProof Audit attests something different in kind: that a contract’s declared invariants have held continuously over a period of time, producing a streaming, on-chain record of “still safe” rather than a one-time certificate. This is structurally closer to Sentinel’s Conditional Trigger (Section 12.2) than to a one-shot attestation, but the product being sold is the continuous monitoring and its historical record, not a single triggered execution.

16.1 The Problem: Point-in-Time Audits Go Stale Immediately

A traditional smart contract security audit certifies a contract’s code as of a specific commit hash, at a specific point in time. The moment the contract’s on-chain state evolves, or the moment any upgradeable component changes, that certificate no longer describes the live system. Institutional depositors, insurers, and integrating protocols currently have no trustless way to know whether a protocol they audited six months ago still behaves as audited today. RandProof Audit addresses this gap directly: rather than certifying code, it continuously certifies that a declared, checkable invariant about the contract’s live state has not been violated.

16.2 Execution Flow


Phase	Description
1. Invariant Registration	A protocol registers one or more InvariantSpecs: a view function or computed check (e.g., “total collateral value must exceed total liabilities”), a check_interval, and min_keepers required for each periodic attestation.
2. Periodic Independent Check	On each interval, N keepers independently evaluate the registered invariant against current on-chain state, the same independent-verification pattern used throughout RandProof Oracle and RandProof Identity.
3. Commit-Reveal and Publication	Keepers commit and reveal their findings; consensus produces a timestamped AuditAttestation, holding or violated, appended to an on-chain history specific to that protocol and invariant.
4. Violation Handling	A consensus-confirmed violation triggers an on-chain event that external consumers, insurers, integrating protocols, or front-end warning systems, can subscribe to, and the violation remains permanently part of the protocol’s audit history even if the underlying issue is later fixed.

16.3 Relationship to Sentinel

RandProof Audit’s invariant-checking mechanism is structurally the same Conditional Trigger pattern Sentinel already specifies (Section 12.2), with two differences: Audit checks run on a recurring interval rather than once, and Audit’s purpose is to produce a permanent historical record rather than to trigger a one-time execution. A protocol could, in principle, register the same invariant with both products: Audit for continuous public record-keeping, and Sentinel if a violation should also trigger an automatic protective action, such as pausing deposits.

16.4 Threat Model


Threat	Mitigation
A poorly chosen invariant gives false assurance	RandProof Audit verifies that a declared invariant held; it does not validate that the invariant itself is a sufficient definition of protocol safety. This is disclosed explicitly as the registering protocol’s responsibility, the same trust boundary already disclosed for Sentinel’s target_selector registration (Section 12.6).
Keeper collusion suppresses a true violation	Same VRF-seeded rotation and slashing model as all other RandProof products; a keeper falsely reporting “holding” when independent peers report “violated” is detectable and punishable.
Gas cost of frequent on-chain checks	check_interval is configurable per invariant, allowing protocols to balance monitoring frequency against on-chain cost; this mirrors the same tradeoff already disclosed for RandProofAutomation’s scheduled triggers (Section 10.4).

16.5 Use Cases

[Layer 3] Insurance protocols (Nexus Mutual-style) requiring continuous, trustless evidence that an insured protocol’s safety invariants currently hold, rather than relying on a stale point-in-time audit.
[Layer 3] Institutional DeFi depositors requiring an ongoing, on-chain safety record before allocating capital, in lieu of repeated manual due diligence.
[Layer 3] Lending protocols publishing a continuous solvency attestation to differentiate themselves to risk-conscious integrators and aggregators.
[Layer 2] BIT5050’s own raffle contracts publishing a continuous “prize pool fully funded” invariant, giving entrants a trustless, real-time guarantee rather than a one-time audit claim.

16.6 Honest Status

RandProof Audit exists as an architectural design in this addendum. It depends on Sentinel’s Conditional Trigger mechanism (Section 12), itself unimplemented and unaudited as of this writing, and additionally requires new historical-record storage logic not specified in any existing RandProof contract. This is the least mature of the four products introduced in this addendum.