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

Finding: Inequitable Weight Clamping for Early Stakers

Author Revealed upon completion

Root + Impact：

Inequitable Weight Clamping for Early Stakers

Description

  • The ConfidencePool contract utilizes a quadratic time-weighted bonus mechanism where the bonus weight is calculated based on the duration a deposit has been held relative to the pool’s resolution time . To prevent the manipulation of time-weighted scores after an active risk event has been identified, the contract employs the _clampUserSums() function to "clamp" the entry time of all funds deposited before riskWindowStart to the riskWindowStart timestamp itself.

    The issue arises because _clampUserSums() performs this clamping on a user's aggregated userSumStakeTime rather than evaluating individual deposit records. Consequently, the distinct time-weighted benefits of multiple, well-timed early deposits are homogenized and diluted, causing early stakers to lose the time-weight advantage they were intended to receive for their long-term commitment.

// Root cause in the codebase with @> marks to highlight the relevant section
function _clampUserSums(address u) internal {
uint256 start = riskWindowStart;
uint256 stake_ = eligibleStake[u];
if (start == 0 || stake_ == 0) return;
// @> The aggregated sum is overwritten, discarding the original entryTime of individual deposits
if (userSumStakeTime[u] < stake_ * start) {
userSumStakeTime[u] = stake_ * start;
userSumStakeTimeSq[u] = stake_ * start * start;
}
}

Risk

  • Reason : Users who perform multiple staggered deposits prior to the risk window will consistently see their bonus weights reduced by this aggregation logic.

    This occurs automatically whenever riskWindowStart is observed, making it a deterministic outcome for any user with a non-monolithic deposit history.

Impact:

  • Impact 1:Reward Dilution: Early depositors receive a lower bonus than mathematically warranted by their actual duration of risk exposure, effectively penalizing long-term users.

  • Impact 2:Incentive Misalignment: The design discourages early, proactive staking, as the benefit of "time-in-market" is erased by the aggregation mechanism.

Proof of Concept

- Expected Behavior:
- The protocol's design goal is to reward high-confidence, long-term participants.
- Early deposits (lower entryTime) should maintain a larger time-weight ((T - entryTime)^2)
- compared to late-stage deposits.
​
+ Actual Behavior (Logic Flaw):
+ 1. Scenario: T=1000, start=500. User stakes 50 tokens at t=100 and 50 tokens at t=400.
+ 2. Prior to start=500, the user's weighted score is accurately calculated based on individual entry times.
+ 3. When _clampUserSums triggers at t=500, the contract forces the aggregate entry time to 500.
+ 4. Result: The time-weight benefit of the first deposit (t=100) is discarded. The early
+ deposit effectively "becomes" a late-stage deposit. This causes a non-linear loss in
+ bonus potential, as the quadratic benefit (400^2 vs 500^2) is unfairly truncated.

Recommended Mitigation

- Current Implementation:
- Uses aggregated sum (`userSumStakeTime`) to clamp weights, which homogenizes
- all previous deposits to the `riskWindowStart` timestamp, diluting early-staker rewards.
​
+ Proposed Mitigation:
+ 1. Maintain Per-Deposit Records: Instead of aggregating, store an array of deposit objects,
+ each with its own timestamp. Apply the clamping logic only to individual deposits
+ that occurred strictly before `riskWindowStart`, preserving individual time-weights.
+ 2. Explicit Disclosure: If gas constraints prevent per-deposit tracking, the protocol
+ should explicitly document the "averaging effect" of `_clampUserSums` in the
+ `docs/DESIGN.md` file to ensure users are aware that subsequent deposits will
+ dilute the time-weight benefit of their previous, earlier stakes.

Support

FAQs

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

Give us feedback!