Root + Impact

Description

The factory owner configures the shared trust anchors that every future pool inherits at creation: the SafeHarbor registry (the source of truth for whether an agreement is valid and what on-chain state it is in), the pool implementation that is cloned into each new pool, and the default outcome moderator baked into each pool. Stakers rely on these being honest when they deposit into a pool created afterward.

Each of setSafeHarborRegistry (ConfidencePoolFactory.sol:134), setPoolImplementation (:145) and setDefaultOutcomeModerator (:154) is a single onlyOwner SSTORE guarded by a zero-address check only. There is no timelock, no two-step propose/accept, and no delay, so a compromised or coerced owner key repoints the registry to an attacker contract, swaps the pool implementation, or installs a malicious default moderator in one transaction, and every pool created after that block silently inherits the malicious trust anchor with no on-chain window in which stakers could observe the change and stay away.

Risk

Likelihood:

• The change lands the instant the owner (or a compromised owner key) sends the transaction. There is no queue, delay, or two-step in which stakers could observe the pending change and avoid pools created under the new trust anchor.

• Every pool created after the change reads the new registry / implementation / moderator at createPool with no per-pool opt-in, so the exposure grows with each subsequent pool.

Impact:

• A malicious registry can validate a bogus agreement or misreport an agreement's on-chain state, corrupting resolution for every future pool; a malicious default moderator controls those pools' outcome flags; a swapped implementation changes the code that future stakers' funds sit in.

• Existing pools are unaffected because they snapshot their trust anchors at creation, so the blast radius is future pools only. That bound is what keeps this at Low rather than higher.

Proof of Concept

The test deploys the real factory, swaps the registry with setSafeHarborRegistry in a single call (no elapsed time), and shows a pool created afterward inherits the attacker registry while an already-deployed pool keeps the honest one.

Output (forge test --match-contract TimelockRegistrySwap -vv, forge 1.7.1):

Recommended Mitigation

Put the three trust-anchor setters behind a timelock (queue with a delay, then execute) or a two-step propose/accept, so any change to a registry / implementation / default moderator is observable on-chain before it takes effect and stakers can decline pools created under a pending change.