[Audit M-06] Validator-influenceable randomness selects security-critical committees

[hmzakhalid]

Finding

Severity: Medium

Confirmed against baseline commit d4277510d. Committee selection derived randomness from block.prevrandao in the request transaction, exposing security-critical sortition to proposer influence.

Full audit report

Required remediation

Consume fulfilled randomness from an explicit provider, bind it to chain/request/E3 context, and fail closed on missing or invalid fulfillment.

The dedicated fixing commit and remediation PR will be linked in a follow-up comment.

[hmzakhalid]

Fixed by commit 09e942e8a640ddac48eff1f74d2e3db78630cf20.

[hmzakhalid]

Validated against the intended protocol design. M-06 assumes committee selection requires unbiasable randomness, but the protocol only requires a value source and intentionally uses block.prevrandao. No source change or remediation commit is needed; closing as not planned.

[hmzakhalid]

Follow-up after tracing the seed through the current protocol implementation:

• The E3 seed is used for ticket scoring and committee sortition (keccak256(node, ticketNumber, e3Id, seed)). It is not used as the BFV key-generation/CRP seed; the current BFV CRP is constructed separately from the deterministic default seed.
• We are intentionally retaining keccak256(abi.encode(block.prevrandao, e3Id)) for the current implementation. No M-06 code change is being included in the audit remediation PR.
• Commit 09e942e8a640ddac48eff1f74d2e3db78630cf20 was an experimental implementation and has been discarded from the remediation branch. It introduced only an IRandomnessProvider abstraction and test mock, not a concrete production randomness integration.

This finding is being preserved as future committee-sortition hardening. If revisited, the design should first select a concrete chain-appropriate future/verifiable randomness source and address fulfillment binding, one-time consumption, selective aborts, liveness, and the race involved in binding a request to the anticipated next E3 ID. The previous interface-only, two-phase implementation should not be reapplied wholesale.

Leaving this issue closed as deferred future work rather than a current deployment blocker.