BattleChain Confidence Pools
Cyfrin
FoundrySolidityLayer 2
7.25 ETH
View all submissions
Previous Next
Submission Details
Impact: high
Likelihood: high

Moderator-controlled immediate settlement allows fund seizure

Author Revealed upon completion

Root + Impact

Description

  • Normal behavior: A ConfidencePool lets stakers deposit funds and sponsors add a bonus; a moderator or expiry backstop determines the pool outcome and the contract distributes payouts to participants according to that outcome.

  • Specific issue: The settlement logic grants unilateral power to the moderator (a single privileged account) to finalize outcomes and trigger transfers without multisig, timelock, or strict recipient validation, allowing the moderator (or anyone controlling the moderator key) to cause immediate, irreversible redirection or seizure of pooled funds.

// Root cause in the codebase with @> marks to highlight the relevant section
// (excerpted and annotated conceptually based on the repository's settlement design)
contract ConfidencePool {
address public moderator; // @> privileged single-signer role
​
enum Outcome { Undecided, SponsorWins, StakersWin, Split }
​
Outcome public outcome;
bool public settled;
​
// stakeholders: mapping of staker balances, sponsor bonus, etc.
​
// @> moderator can call this to finalize outcome and trigger payouts
function flagOutcome(Outcome _outcome, address payoutRecipient) external {
require(msg.sender == moderator, "only moderator"); // @> single-key gate
require(!settled, "already settled");
outcome = _outcome;
// @> direct transfer of funds or call into payout logic immediately follows
_distribute(payoutRecipient);
settled = true;
}
​
function _distribute(address payoutRecipient) internal {
// payout math that moves sponsor bonus + staker funds based on outcome
// @> lacks timelock, multisig check, and restricts recipient to participants
// e.g., (conceptual)
// uint256 total = address(this).balance;
// payable(payoutRecipient).transfer(total);
}
}

Risk

Likelihood:

  • The moderator key is exposed through common real-world scenarios such as a compromised developer/maintainer account, insecure key storage, or a malicious/compromised relayer, making moderator-controlled settlement likely to be abused in practice.

  • The project design intentionally permits moderator-triggered settlement without additional on-chain safeguards or multi-party confirmation, enabling straightforward exploitation once moderator access exists.

Impact:

  • Complete or partial loss of staker and sponsor funds across affected pools due to immediate on-chain transfers to attacker-controlled addresses.

  • Severe reputational damage and economic loss for the protocol and users; pooled bonus and staked capital can be drained with high-speed on-chain execution once the moderator key is misused.

Proof of Concept

  • Expected result: After the call, pool.settled() is true and contract balance is transferred (in whole or part) to attacker.

// POC (high-level): attacker uses moderator key to seize pool funds
// NOTE: This is a conceptual PoC illustrating the call sequence an attacker would make.
// 1) Attacker controlling `moderator` account calls flagOutcome with a malicious recipient.
// 2) Contract distributes funds immediately to the supplied recipient.
​
interface IConfidencePool {
enum Outcome { Undecided, SponsorWins, StakersWin, Split }
function flagOutcome(Outcome _outcome, address payoutRecipient) external;
function settled() external view returns (bool);
}
​
contract ModeratorPoC {
IConfidencePool pool;
address attacker;
​
constructor(address _pool, address _attacker) {
pool = IConfidencePool(_pool);
attacker = _attacker;
}
​
// This function is called by the actor controlling the moderator private key
function seize(address poolAddress) external {
// As moderator: finalize outcome and set payoutRecipient to attacker
pool.flagOutcome(IConfidencePool.Outcome.SponsorWins, attacker);
// After this call, funds are transferred per contract logic to `attacker`.
}
}

Recommended Mitigation

- remove this code
+ add this code
​
// Replace single-signer immediate-settle design with multi-step, multi-signer, and timelock-protected flow.
// Conceptual patch (diff-style) — adapt variable and function names to actual contract.
​
- address public moderator;
- function flagOutcome(Outcome _outcome, address payoutRecipient) external {
- require(msg.sender == moderator, "only moderator");
- require(!settled, "already settled");
- outcome = _outcome;
- _distribute(payoutRecipient);
- settled = true;
- }
​
+ // Use a ModeratorRegistry (multisig-managed) and a pendingOutcome with timelock.
+ IModeratorRegistry public moderatorRegistry; // multisig/contract that authorizes moderators
+ uint256 public disputeWindow = 48 hours;
+ struct PendingOutcome {
+ Outcome outcome;
+ address payoutRecipient;
+ uint256 proposedAt;
+ bool exists;
+ }
+ mapping(uint256 => PendingOutcome) public pendingOutcomes; // per-pool id or single pool
+
+ function proposeOutcome(Outcome _outcome, address payoutRecipient) external {
+ require(moderatorRegistry.isAuthorized(msg.sender), "not authorized moderator");
+ require(!pendingOutcomes[0].exists, "pending exists");
+ // Restrict payoutRecipient to known participants (stakers or sponsor) or zero for internal distribution
+ require(isParticipant(payoutRecipient) || payoutRecipient == address(0), "invalid recipient");
+ pendingOutcomes[0] = PendingOutcome({
+ outcome: _outcome,
+ payoutRecipient: payoutRecipient,
+ proposedAt: block.timestamp,
+ exists: true
+ });
+ emit OutcomeProposed(_outcome, payoutRecipient, block.timestamp);
+ }
+
+ function finalizeOutcome() external {
+ PendingOutcome storage p = pendingOutcomes[0];
+ require(p.exists, "no pending outcome");
+ require(block.timestamp >= p.proposedAt + disputeWindow, "dispute window active");
+ require(!isDisputed(), "outcome disputed");
+ // Optionally require multisig confirmation via moderatorRegistry (N-of-M)
+ outcome = p.outcome;
+ _distribute(p.payoutRecipient);
+ settled = true;
+ delete pendingOutcomes[0];
+ emit OutcomeFinalized(outcome, p.payoutRecipient);
+ }
+
+ // Helper: prevent arbitrary recipient abuse
+ function isParticipant(address addr) internal view returns (bool) {
+ // check staker mapping or sponsor address
+ }
+
+ // Add dispute raising
+ function raiseDispute() external {
+ // allow stakers/sponsor to raise dispute within disputeWindow
+ }

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!