23. Security Model and Threat Analysis

23.1 Threat Matrix

Security Guarantee: At full Phase 4 deployment, no single party can control all fifteen entropy sources, and the protocol's randomness is designed to be infeasible to bias by any known attack. During Phases 0–3, fewer sources are live and the genesis keeper set is federated, see Section 24.1 for the current trust model and Section 26 for the entropy-source activation schedule.

23.1.5 How RandProof Prevents Committee Takeover

RandProof does not run its own blockchain, so a "51% attack" in the classic sense -- rewriting transaction history by outvoting honest validators -- does not apply to it directly. The actual risk is structurally different and is stated precisely here rather than left implicit: can a party that controls a majority, or a large minority, of the signing committee force a biased outcome through, or repeatedly censor outcomes it does not like? This subsection consolidates that answer in one place, pulling together the Nakamoto-coefficient analysis, the committee-scaling plan, the stake cap, and a new mechanism (AV-112) that directly hardens the part of this picture that was previously only a disclosed limitation: censorship at small committee size.

What a Captured Committee Can and Cannot Do

This distinction is the most important fact in this subsection, and the rest of the document is built to keep it true at every phase: a keeper, or a colluding group of keepers, controlling the signing threshold cannot fabricate or bias the entropy VALUE -- that is secured independently by the 15 external entropy sources (Section 3.3), none of which any keeper controls. What a captured committee CAN do, absent the mitigations below, is attack LIVENESS AND ORDERING: choose which events get signed promptly, delay or refuse to sign events whose likely outcome it dislikes (the selective non-fulfillment risk named in AV-48), or consistently occupy the signing slots so that no outcome can be produced without its cooperation. RandProof treats these as two different security properties with two different defenses, rather than one undifferentiated "takeover" risk.

Defense 1: Committee Size Scales With the Network, Closing the Small-N Gap

At Genesis (Phase 0), the committee is small by necessity -- 12 nodes, threshold t=3 -- and the Nakamoto coefficient of 4 reflects that honestly rather than asserting a decentralization level the network has not yet reached. This is the phase where committee capture is genuinely possible if a small number of parties control most of the genesis node set, and the whitepaper does not claim otherwise (Section 24.1, AV-50, AV-72).

The committee-scaling formula (AV-58 mitigation, Section 29 audit log) is the actual fix for this over time, not a cosmetic randomization: at Phase 2+, committee size scales with total registered keepers as n = min(25, floor(sqrt(totalKeepers x 3))), and at Phase 4 target scale the committee is drawn at random, per event, from the full registered keeper pool at n=25, t=9. The table below restates the comparison already documented in Section 29's decentralization benchmarking, because it is the single clearest piece of evidence that this is a real plan with a real target, not a promise without a number attached.

The mechanism matters as much as the endpoint: at Phase 4, a fixed committee size (n=25) drawn randomly from a much larger pool (1,000+) means an attacker's chance of dominating any single event's committee depends on what share of the TOTAL pool they control, not on the committee size alone. Controlling 9 of 25 randomly assigned seats requires controlling roughly 36% of the entire keeper population in expectation -- a fundamentally different and harder bar than controlling 3 of a fixed 12.

Defense 2: The 15% Stake Concentration Cap

Network growth alone is not sufficient if one party can simply buy a majority of the larger pool. AV-58's stake concentration cap addresses this directly: no single entity, or address cluster identified through on-chain stake-aggregation analysis, may control more than 15% of total network stake. New registrations that would push an address or linked cluster over this threshold are rejected at the contract level, not merely discouraged by policy. IP/ASN diversity monitoring (alerting if more than 20% of nodes share the same autonomous system number) and an optional Gitcoin-Passport-style verified-operator badge add further, independent friction against a single party quietly accumulating a controlling share through Sybil registration rather than direct stake purchase.

Defense 3 (New): Censorship Has a Cost and a Ceiling, Even at Small Committee Size

Defenses 1 and 2 both depend on the network actually growing past Genesis. They do not, by themselves, stop a captured Genesis-phase committee from censoring specific events today, since random selection among a small, attacker-dominated pool does not meaningfully dilute attacker control the way it does at 1,000 nodes. AV-48 already closes the related but distinct risk of a keeper privately computing an outcome before deciding whether to publish it (selective non-fulfillment with foreknowledge). It does not close the simpler case of a keeper, or a colluding group, simply refusing to sign -- because today, refusing to sign costs the censoring keeper nothing beyond a delayed event for the requester. AV-112 closes that gap directly with two mechanisms, now implemented and tested as LivenessGuard.sol (see Status below for test coverage and the adversarial pass run before this was called real rather than documented).

Mechanism A -- Disjoint fallback committee on timeout: If the first assigned committee fails to fulfill a request within a defined sub-window (proposed: 64 blocks, one quarter of the existing 256-block FULFILLMENT_TIMEOUT), the request does not simply continue waiting for the same committee or fall through to a refund. It automatically reassigns to a SECOND committee drawn from the keeper pool EXCLUDING every member of the first, failed committee. At Genesis (12 nodes, first committee of 3), the fallback draws from the other 9 -- an attacker who dominates the first committee draw must ALSO control enough of the remaining 9 to block the second attempt, which is a meaningfully harder bar than controlling one fixed group of 3. If the second committee also fails, the existing 256-block timeout and cancelRequest() refund remain as the final fallback, so no client is ever left permanently unable to recover their fee -- this mechanism adds a real liveness path, it does not remove the existing one.

Mechanism B -- Non-fulfillment accounting, slashable independent of fraud: Today, a keeper assigned to a committee who simply never responds faces no on-chain consequence beyond the requester's inconvenience -- there is no fraud to slash, because silence is not a false claim. AV-112 adds a non-fulfillment counter, tracked per keeper independently of any fraud-dispute outcome: every time a keeper is part of an assigned committee that times out (sub-window or full timeout) without that keeper having submitted a signature, the counter increments. A keeper whose non-fulfillment rate crosses a defined threshold within a rolling window is flagged publicly (the same kind of visible, on-chain signal already used for confirmed entropy mismatches in EntropyAttestation.sol), and repeated crossings result in the same bond-forfeiture-then-slash escalation already built and tested for false-report mismatches (Section 29, AV-108-111) -- applied here to sustained silence rather than to a false value. Whoever calls the stall-detection function earns a 5% share of the forfeited bonds, the same resolver-incentive shape AV-108's resolveDispute() uses -- "anyone may call this" only works in practice if calling it is worth someone's gas. This makes censorship-by-non-participation carry a real, escalating cost for the first time, rather than being free for the censoring party.

Status: IMPLEMENTED, PRE-AUDIT, both mechanisms are written and tested as LivenessGuard.sol, a standalone module mirroring EntropyAttestation.sol's own integration posture (not yet wired into KeeperCoordinator.sol, which now exists as a tested MVP -- see Section 19 -- but does not yet call into this contract). 22 passing tests cover the full request lifecycle (Pending, Stalled, Fulfilled, Exhausted), the disjoint fallback committee enforcement (a single overlapping address from a prior attempt is rejected outright, not merely discouraged), the non-fulfillment strike and rolling-window slash escalation, withdrawal interactions, and the pause switch. A dedicated pre-deployment adversarial pass (6 targeted probes, same discipline applied to EntropyAttestation.sol before its own testnet deployment) found no exploitable gap in this round, though see the project README for one disclosed, measured limitation: gas cost for a new strike grows roughly linearly with a keeper's own lifetime strike count, a real cost rather than a free operation, bounded in practice by the slashThreshold removing repeat offenders from eligibility before this becomes expensive. The contract pays whoever calls the stall-detection function a 5% share of forfeited bonds, the same resolver-incentive shape AV-108's resolveDispute() uses, added specifically because "anyone may call this" without a real incentive risks nobody actually calling it. LivenessGuard.sol is staged for Base Sepolia testnet deployment but has not yet been integrated with EntropyAttestation.sol or KeeperCoordinator.sol, and has not had an external security audit. The residual risks disclosed in Section 23.1.5 remain accurate and are restated, not resolved, by this implementation: disjoint exclusion does not by itself make the FIRST committee's assignment unpredictable, the strike mechanism is symmetric and does not distinguish honest infrastructure failure from deliberate censorship, and none of this fixes a Genesis phase where one party already controls most of a 12-node network -- that remains a governance fact addressed under AV-72, not a smart-contract problem this contract claims to solve.

What This Does Not Solve, Stated Plainly

No signing-mechanism design, including the two above, fixes a Genesis phase where one party already controls most of a 12-node network -- that is an operational and governance fact about who is running nodes today, not a smart-contract problem with a smart-contract fix. The actual mitigation for that specific risk is the one already disclosed under AV-72: distributing genesis keeper operation to 3 or more independent parties, and constituting the 3-of-5 treasury multisig described in Section 22.2, before any deployment carries meaningful value. AV-112's fallback committee and non-fulfillment accounting reduce how much damage a captured committee can do and for how long, at every phase including Genesis -- they do not substitute for genesis keeper diversity, and this document does not claim they do.

23.2 Economic Security Analysis: Why Low Stakes Are Safe

RandProof’s security model differs fundamentally from traditional Proof-of-Stake systems. In most blockchains, staking secures consensus—compromising 51% of stake allows an attacker to rewrite history. RandProof’s staking does not secure the randomness itself; that is the role of the 15 independent entropy sources.

23.2.1 Node-Level vs. Protocol-Level Security

Key Insight: Even if an attacker gains 100% control of RandProof nodes, they cannot manipulate the final randomness output without also simultaneously controlling:

• DRAND network (requires attacking DRAND’s $10M+ staking)

• NIST Randomness Beacon (U.S. government-operated, effectively impossible)

• Chain-native VRF (requires 51% attack on underlying chain: $10M+ for Ethereum)

• Commit-Reveal participants (requires compromising all users in a request)

• Block timestamps (requires controlling chain validators)

• Ethereum RANDAO (requires controlling Ethereum’s entire validator set)

• Bitcoin Merkle Root (requires controlling majority of Bitcoin’s global hash rate: $50B+)

• Multi-Chain Block Hashes (requires simultaneously attacking multiple independent blockchains)

• ANU QRNG (requires compromising physically isolated quantum measurement hardware at an academic institution)

• Tor Consensus Hash (requires compromising 5+ of 9 geographically distributed Tor directory authorities: $100M+)

• Polkadot BABE VRF (requires compromising the Polkadot validator set: hundreds of independent validators across 6 continents)

• drand Quicknet (requires attacking the League of Entropy on a separate BLS12-381 network with independent round state from Source 1)

Conclusion: Node-level attacks are economically irrational because they cannot compromise the protocol’s core security. At full deployment (15 independent sources across 7 domains, Phase 4), modeled total attack cost exceeds $100B. RandProof does not claim to be the most secure randomness protocol in the world; the claim is that this entropy architecture is, by design, among the most diverse and costly to attack of any documented randomness protocol once fully deployed.

23.2.2 Attack Cost Analysis

Why These Costs Are Sufficient:

• Sybil attacks are deterred by the $2K–60K cost for 1,000 nodes, with zero benefit (cannot override 15 entropy sources).

• 51% node attacks are meaningless—the attacker gains no ability to manipulate randomness.

• At full Phase 4 deployment, protocol-level attacks require compromising all 15 entropy sources, with modeled cost exceeding $100B (prohibitive). Fewer sources are live in earlier phases, see Section 26 for the current count.

23.2.3 Decentralization vs. Security Tradeoff

Traditional PoS: High stakes = fewer nodes = centralization risk. RandProof: Low stakes = thousands of nodes = maximum decentralization.

RandProof’s advantage: The 15 entropy sources allow us to sacrifice node-level staking security for maximal decentralization without compromising protocol security.

23.2.4 Game Theory: Incentives Favor Honesty

Slashing Rules (Recommended):

• Double-signing: 100% stake loss

• Offline >24h: 10% stake loss + temporary ban

• Invalid signature: 50% stake loss

• Byzantine behavior: 100% stake loss + permanent ban

Result: Economic incentives strongly favor honest participation.