Root + Impact

Description

A project creator deploys a ConfidencePool for their agreement and intentionally includes a hidden vulnerability inside one of the scoped contracts. After stakers deposit significant funds (including bonus contributions), the creator uses a second wallet to exploit the backdoor. Because the exploit originates from a scoped contract, the Registry transitions to CORRUPTED. The creator then presents themselves as a “good‑faith attacker,” claims the bounty, and drains the entire pool.

This behavior is economically catastrophic for stakers but is not prevented by the ConfidencePool design because the system assumes honest project creators and relies on off‑chain trust and governance rather than on‑chain enforcement of developer honesty.

Risk

Likelihood:

Reason 1 — When project creators control contract code

This occurs whenever the agreement owner has unilateral control over the scoped contracts and can insert malicious logic, hidden backdoors, or intentionally vulnerable code during deployment. Since ConfidencePool does not verify contract safety, any creator with malicious intent can prepare an exploit before stakers join.

Reason 2 — When stakers rely solely on Safe Harbor for security guarantees

This occurs when stakers assume that Safe Harbor or ConfidencePool provides protection against insider attacks. In reality, the system only insures against external exploits, not creator‑inserted vulnerabilities. If stakers do not audit the scoped contracts, they unknowingly expose themselves to creator‑driven CORRUPTED events.

Impact:

• The creator can drain 100% of staked principal + bonus pool by claiming good‑faith CORRUPTED bounty.

• Stakers have no on‑chain recourse because the exploit is technically valid and the Registry correctly marks the contract as CORRUPTED.

• Moderator may be unable to distinguish a malicious creator from a legitimate whitehat attacker.

• The attack undermines trust in the Safe Harbor model and can cause systemic reputational damage.

Proof of Concept

1. Creator deploys an agreement and builds a ConfidencePool with scoped contracts.

2. Creator inserts a hidden backdoor or subtle vulnerability in one of the scoped contracts.

3. Stakers deposit funds, and bonus contributions accumulate (e.g., $10,000 total).

4. When the risk window opens and deposits peak, the creator uses a second wallet to exploit the backdoor.

5. Registry transitions to CORRUPTED.

6. Creator claims to be a good‑faith attacker, providing proof of exploit.

7. ConfidencePool assigns the entire pool (principal + bonus) to the attacker as bounty.

8. Creator drains all staker funds.

Recommended Mitigation

1. Governance‑Controlled Agreement Validation

Move isAgreementValid() to a DAO‑controlled process rather than trusting the creator. This prevents malicious creators from self‑approving unsafe agreements.

2. Moderator Multi‑Sig or Committee

Replace single‑moderator authority with a multi‑sig or committee to reduce the chance of collusion or misjudgment in CORRUPTED classification.

3. On‑Chain Attacker Identity Constraints

Disallow good‑faith bounty claims from addresses linked to the agreement owner or any address with prior interactions with the agreement. This reduces creator self‑exploitation.

4. Scope Integrity Checks

Require that scoped contracts be immutable, non‑upgradeable, and verified on-chain to prevent hidden backdoors.