Security/design: permissionless VRF circuit breaker zeros global randomness provider (blast radius)

[Watchmeecryt]

Summary

One expired, unfulfilled VRF request can set the global randomness provider to address(0) and block every new E3 until governance calls setRandomnessProvider.

That E3 should fail. The provider should not.

Current behavior

After randomnessDeadline (1h on mainnet), anyone can finalizeCommittee(e3Id) or the requester can cancelE3(e3Id). Failure handling runs _tripRandomnessCircuitBreaker in RegistrySortitionLib:

• if the request expired and is not ready
• state.provider = address(0)
• emit RandomnessCircuitBreakerTripped

requestRandomness() then reverts on ZeroAddress(). Recovery is owner-only.

This is documented. The problem is blast radius, not a hidden exploit.

Why this is wrong

• One miss pauses the whole request path
• Trip is permissionless
• Pause is encoded as deleting the singleton provider
• Trigger is Chainlink/subscription liveness, not a broken seed
• A timely VRF word is still correctly bound and non-rerollable; keep that

Proposed fix

On timeout, fail only that E3. Do not write provider = address(0).

If a halt is still needed, use an explicit owner/guardian randomnessPaused flag, or trip only after K timeouts in a window. In-flight requests keep their frozen provider + requestId.

Acceptance

• Timeout fails E3 A
• randomnessProvider() stays set
• E3 B can request on the same provider
• Owner can still pause or rotate the provider
• A fulfilled word still cannot be discarded and replaced