Summary

The protocol appears to establish an incentive model that rewards users for committing capital before observable risk begins. This is evidenced by the _clampUserSums() mechanism, which normalizes all pre-risk deposits to riskWindowStart, ensuring that no participant receives additional credit for depositing significantly earlier than the beginning of the risk window while still preserving an advantage over users who join after risk becomes observable.

However, this economic objective is partially weakened during SURVIVED resolution. When the registry reaches PRODUCTION, the protocol sets:

instead of

Because _bonusShare() uses the quadratic function

Score=Stake×(T−EntryTime)^2

extending T from expiry to riskWindowEnd increases every participant's score, but disproportionately benefits participants who entered after the risk window had already begun, thereby reducing the reward premium initially established for early participants.

As the duration between expiry and riskWindowEnd increases, the reward gap between pre-risk and post-risk participants progressively narrows.

Vulnerability Details

The protocol contains two separate mechanisms governing bonus allocation.

1. Rewarding Early Commitment

When users deposit before the risk window begins, _clampUserSums() rewrites their effective entry time to riskWindowStart.

Rather than rewarding users for staking weeks or months before any risk existed, the protocol rewards participation from the beginning of observable risk.

Consequently,

• all pre-risk participants begin earning from the same timestamp (riskWindowStart);

• participants joining after the risk window begins receive a later effective timestamp and therefore a lower score.

This creates a deliberate economic distinction between:

• participants who committed capital before observable risk, and

• participants who waited until risk was already visible.

2. Reward Calculation

Bonus allocation is determined by _bonusShare().

The effective score is mathematically equivalent to

Score=Stake×(T−Entry)^2

where

The value of T depends on the final resolution.

For SURVIVED:

For EXPIRED:

This means that identical participants receive different reward distributions solely because the protocol selected a different terminal timestamp.

Example

Impact

1. For a successful resolution:

   
   
   if (state == IAttackRegistry.ContractState.PRODUCTION) {

   outcome = PoolStates.Outcome.SURVIVED;

   outcomeFlaggedAt = riskWindowEnd;

   }

   For an expired resolution:

   
   
   else {

   outcome = PoolStates.Outcome.EXPIRED;

   outcomeFlaggedAt = expiry;

   }

   Because _bonusShare() is proportional to (T−Entry)^2

   extending T to riskWindowEnd progressively increases the relative reward of participantswho joined after the risk window began.

   Consequently, the outcome representing successful protocol survival gradually reduces the reward premium initially granted to early participants.

   Ironically, the EXPIRED path—which merely represents expiration of the coverage period while the registry remained non-terminal—preserves the early-entry premium more effectively than the SURVIVED path.

   
   

Recommended Mitigation