The Stability Pool is operating at 94.5% of its maximum accounting capacity:
- Total Deposits: 0.097 BTC (≈ $9,700 at $100k/BTC)
- Reward Token: fxSAVE (0x7743e50F534a7f9F1791DdE7dCD89F7783Eefc39)
- Distribution Rate: ~75 tokens per week
- Accounting Capacity Used: 5.933×10⁵⁷ out of 6.277×10⁵⁷ maximum (94.5%)
- Exponent: 0 (no significant loss events have occurred)
The Problem: The next reward distribution will add 7.73×10⁵⁶ to the accounting number, which exceeds the maximum by 4.28×10⁵⁶. This causes a Panic 0x11 integer overflow, freezing ALL pool operations.
Time to Failure: 1-2 weeks (next reward distribution)
Instead of letting the pool break, we queue rewards when the accounting number would overflow:
// When integral would overflow:
if (newIntegral > uint192.max) {
// Don't break - just queue the rewards
rewardData[token].queued += amount;
return; // Skip accumulation for now
}Key Point: This is a contract-level bank, not user-level balances. When rewards are queued:
- They don't accrue to individual user accounts
- Users see 0% APY for fxSAVE (not earning)
- The contract holds the tokens until conditions improve
Everything works normally:
- ✅ Deposits work
- ✅ Withdrawals work
- ✅ fxSAVE rewards accumulate at current APY
- ✅ Users can claim all rewards
Behind the scenes: Accounting capacity at 94.5% and rising
Operations continue, but fxSAVE rewards pause:
- ✅ Deposits work (and help!)
- ✅ Withdrawals work
- ✅ Can claim other reward tokens (if any)
⚠️ fxSAVE rewards show 0% APY⚠️ New fxSAVE tokens don't accrue to user balances- 📊 Dashboard shows: "fxSAVE rewards temporarily queued - deposit to resume"
What users experience:
Current fxSAVE balance: 100 tokens (example)
After 1 week of queueing: Still 100 tokens
After 2 weeks of queueing: Still 100 tokens
The rewards are being collected by the contract (queued), but not distributed to users.
Normal operations resume:
- ✅ All queued tokens distribute to users
- ✅ fxSAVE APY returns to normal
- ✅ Users receive backlog of queued rewards proportional to their deposits
What users experience:
Week 0: 100 tokens, 0% APY (queue active)
Week 3: Deposits arrive, queue clears
Week 4: 175 tokens (100 original + 75 from queue), APY restored
The queue clears when EITHER of these happens:
Target: Increase total deposits from 0.097 BTC to 2.5 BTC
| Current | Required | Additional Needed | USD Value (@$100k/BTC) |
|---|---|---|---|
| 0.097 BTC | 2.5 BTC | +2.4 BTC | $240,000 |
Why this number?
Current growth rate: 7.73×10⁵⁶ per week (causes overflow)
Safe growth rate: 0.30×10⁵⁷ per week (50% headroom)
To achieve safe rate:
totalShare = (75 tokens × 1×10¹⁸ × 1×10¹⁸ × 1×10³⁶) / 0.30×10⁵⁷
= 2.5 BTC
At different BTC prices:
- @ $95k/BTC: $228,000 additional
- @ $90k/BTC: $216,000 additional
- @ $80k/BTC: $192,000 additional
Gradual deposit scenarios:
| Week | Total Deposits | Weekly Growth | Status |
|---|---|---|---|
| 0 (now) | 0.097 BTC | 7.73×10⁵⁶ | ❌ Overflow! Queue starts |
| 1 | 0.35 BTC | 2.14×10⁵⁷ | ❌ Still too high |
| 2 | 0.60 BTC | 1.25×10⁵⁷ | ❌ Still too high |
| 3 | 1.10 BTC | 0.68×10⁵⁷ | |
| 4 | 2.50 BTC | 0.30×10⁵⁷ | ✅ Safe! Can resume |
Important: Even at 2.5 BTC, we can't dump all queued rewards at once. If 3 weeks of rewards are queued (225 tokens), distributing them all would cause another overflow. Must distribute gradually:
- Week 4: Distribute 75 tokens (1 week worth)
- Week 5: Distribute 75 + 75 queued
- Week 6: Distribute remaining queued rewards
What is a loss event? When the pool experiences a liquidation loss, the internal accounting resets:
- Exponent increments: 0 → 1
- Integral resets to 0 at new exponent
- Overflow problem solved immediately
How likely is this?
- ❌ Cannot control or predict
- ❌ Not desirable (losses hurt users)
⚠️ May never happen- ✅ If it happens, unblocks immediately
Impact if it happens:
Before loss: integral[exponent=0] = 5.933×10⁵⁷ (overflow!)
After loss: integral[exponent=1] = 0 (fresh start)
Queued rewards: Can now distribute safely
Timeline:
- Week 0 (now): Everything works, integral at 94.5% capacity
- Week 1: depositReward called → Panic 0x11 overflow → POOL FREEZES
- Ongoing: ALL operations fail
User trying to deposit 0.5 BTC:
Transaction → calls deposit() → calls _accumulateReward()
→ tries to add 7.73×10⁵⁶ to integral
→ PANIC 0x11 (arithmetic overflow)
→ Transaction reverts
User trying to withdraw their 0.05 BTC:
Transaction → calls withdraw() → calls _accumulateReward()
→ PANIC 0x11 → Transaction reverts
Business impact:
- Users cannot access their funds (frozen, not lost)
- Emergency support burden
- Requires urgent upgrade under pressure
- Reputational damage
Timeline:
- Week 1: Queue starts, 75 tokens queued
- Week 2: 150 tokens queued (cumulative)
- Week 3: 225 tokens queued
- Week 4: 300 tokens queued
- Ongoing: Queue grows at 75 tokens/week indefinitely
User with 0.05 BTC deposited (50% of pool):
| Week | Their fxSAVE Balance | Expected (if no queue) | Difference |
|---|---|---|---|
| 0 | 100 tokens | 100 tokens | 0 |
| 1 | 100 tokens | 137.5 tokens | -37.5 |
| 2 | 100 tokens | 175 tokens | -75 |
| 3 | 100 tokens | 212.5 tokens | -112.5 |
| 4 | 100 tokens | 250 tokens | -150 |
What they see on dashboard:
Your fxSAVE Balance: 100 tokens
Current APY: 0% (rewards queued)
Queue Status: 225 tokens queued
Deposits Needed: +2.4 BTC to resume
Progress: 0.097 / 2.5 BTC (3.9%)
Communication needed:
"fxSAVE rewards are temporarily queued due to the current reward-to-deposit ratio. Your existing rewards are safe, but new rewards won't accrue until the pool reaches 2.5 BTC total deposits. Depositing helps restore reward distribution for everyone."
Timeline:
- Weeks 1-3: Queue active, 225 tokens accumulated
- Week 4: Large deposit brings totalShare to 2.5 BTC
- Week 4-7: Gradual distribution of queued rewards
Week-by-week breakdown:
| Week | Event | Integral Change | Queue | Status |
|---|---|---|---|---|
| 1 | 75 tokens queued | +0 (queued) | 75 | Paused |
| 2 | 75 tokens queued | +0 (queued) | 150 | Paused |
| 3 | 75 tokens queued | +0 (queued) | 225 | Paused |
| 4 | 2.5 BTC deposit arrives | +0 | 225 | Ready! |
| 4 | Distribute 75 tokens | +0.30×10⁵⁷ | 150 | OK |
| 5 | Distribute 75 + 75 queued | +0.60×10⁵⁷ | 75 | OK |
| 6 | Distribute 75 + 75 queued | +0.60×10⁵⁷ | 0 | ✅ Cleared! |
| 7+ | Normal operations | +0.30×10⁵⁷/week | 0 | Normal |
User with 0.05 BTC deposited (now 2% of 2.5 BTC pool):
| Week | Their fxSAVE Balance | Notes |
|---|---|---|
| 0-3 | 100 tokens | Queue active, 0% APY |
| 4 | 101.5 tokens | Received 2% of 75 distributed |
| 5 | 104.5 tokens | Received 2% of 150 distributed |
| 6 | 107.5 tokens | Received 2% of 150 distributed, queue cleared |
| 7+ | Growing | Normal APY restored |
With 5 BTC total deposits:
- Growth rate: 0.15×10⁵⁷ per week (very safe)
- Can distribute large batches of queued rewards
- 300 tokens (4 weeks queued): Only adds 0.60×10⁵⁷
User experience:
Week 4: 5 BTC deposit arrives
Week 4: All 225 queued tokens distributed immediately
Week 5: Normal operations, sustainable APY
- Deposit more: Helps everyone by increasing totalShare
- Withdraw funds: Full access to principal
- Claim other rewards: If other tokens are active
- View balances: All existing balances visible
- fxSAVE accrual: Shows 0% APY
- fxSAVE claims: Only get existing balance, no new rewards
- Dashboard: Shows queue status and progress
If we don't implement queueing:
- Cannot deposit (transaction reverts)
- Cannot withdraw (transaction reverts)
- Cannot claim (transaction reverts)
To team:
"Deploying upgrade to handle edge case in reward accounting. fxSAVE rewards may temporarily pause if reward-to-deposit ratio exceeds safe limits. Preparing user communications."
Dashboard banner:
"ℹ️ System upgrade deployed. All operations normal."
No user action needed - everything works normally.
Dashboard banner (prominent):
"
⚠️ fxSAVE rewards temporarily queued due to current pool size. Your funds are safe and accessible. Deposits help restore reward distribution."
Detailed page:
fxSAVE Reward Status: Queued
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Current Situation:
• Your funds are completely safe
• All deposits and withdrawals working normally
• fxSAVE rewards are being collected but not yet distributed
Why is this happening?
• Current pool size: 0.097 BTC ($9,700)
• The reward-to-deposit ratio exceeds safe accounting limits
• This is a protective measure to ensure pool stability
What happens to my rewards?
• Existing fxSAVE balance: Unchanged and claimable
• New fxSAVE rewards: Queued (not lost, just delayed)
• Queued amount: 75 tokens (updated weekly)
When will rewards resume?
• Target pool size: 2.5 BTC ($250,000)
• Current progress: ▓░░░░░░░░░ 3.9%
• Or: If a natural liquidation event occurs
How can I help?
• Depositing BTC helps everyone
• Each 0.1 BTC deposited: +4% progress
• At 2.5 BTC: All queued rewards distribute
Questions? [Contact Support]
Weekly update email:
Subject: Stability Pool Update - Week [X]
fxSAVE Reward Queue Update:
Pool Size: 0.15 BTC (↑ from 0.097 BTC)
Queued: 150 tokens (2 weeks)
Progress: 6% toward 2.5 BTC target
Status: Deposits/withdrawals working normally
Your deposits help restore reward distribution for the entire community.
[Deposit Now] [Learn More]
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Code bug in queue logic | Very Low | High | Thorough testing, simple code (10 lines) |
| UUPS storage corruption | Very Low | Critical | No storage changes required |
| Overflow in queue counter | Very Low | Medium | uint96 max = 7.9×10²⁸ tokens |
| Gas cost increase | None | N/A | No new transactions required |
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| User confusion | High | Medium | Clear messaging, FAQ, support |
| Users withdraw funds | Medium | High | Transparent communication, emphasize safety |
| Deposits never arrive | Medium | High | Incentive programs, reduce reward rate |
| Negative perception | Medium | Medium | Proactive communication, funds always safe |
| Competitor advantage | Low | Low | Industry-standard protective measure |
| Scenario | User Type | Impact | Communication |
|---|---|---|---|
| Can't claim new fxSAVE | Active user | High | "Rewards queued, not lost" |
| Sees 0% APY | Potential depositor | High | "Temporary, helps resume" |
| Wants to withdraw | Concerned user | Low | "Works normally" |
| Wants to deposit | New user | None | "Helps everyone" |
Question 1: What happens if we do nothing?
- Pool breaks in 1-2 weeks
- ALL operations fail (deposits, withdrawals, claims)
- Emergency upgrade required under pressure
- User funds safe but inaccessible
Question 2: What happens with queueing?
- Pool operations continue (deposits, withdrawals work)
- fxSAVE rewards pause (0% APY)
- Rewards resume when deposits reach 2.5 BTC OR loss event
- Users may not understand, requires communication
Question 3: Can we get $240k in deposits?
- If YES: Queue clears in weeks/months, normal operations resume
- If NO: Queue persists indefinitely, but pool still functional
- Alternative: Reduce fxSAVE distribution rate via governance
Question 4: Are we comfortable with the trade-off?
- Paused rewards (degraded UX) vs Frozen pool (critical failure)
- Temporary 0% APY vs Cannot access funds
- Need communication vs Emergency upgrade
- Review this analysis
- Make go/no-go decision
- Approve communication strategy
- Alert support team
- Deploy queue mechanism upgrade
- Test on testnet (if possible)
- Prepare dashboard changes
- Draft user communications
- Monitor integral capacity (currently 94.5%)
- Queue likely activates
- Deploy dashboard updates (queue status, progress bar)
- Send user notifications
- Monitor user reactions
- Track queue growth
- Consider deposit incentives
- Weekly updates to users
- Track deposit progress
- Adjust communication as needed
- If deposits arrive: Communicate queue clearing timeline
- If no deposits: Evaluate alternative options
- Reduce reward rate if queue persists (requires governance)
- Design incentive program for deposits
- Monitor for loss events (automatic unblock)
- Plan for next distribution period
The Math:
Current: 0.097 BTC deposits + 75 tokens/week = 7.73×10⁵⁶ growth
Overflow at: 6.28×10⁵⁷ maximum
Time to failure: 1-2 weeks
Safe: 2.5 BTC deposits + 75 tokens/week = 0.30×10⁵⁷ growth
Unblocks at: $240k additional deposits OR loss event
The Trade-off:
- Without queueing: Pool completely breaks, all operations fail
- With queueing: Pool works, but fxSAVE rewards pause until unblocked
The Recommendation: Deploy queueing mechanism. It prevents catastrophic failure while maintaining core functionality. Users experience degraded service (0% fxSAVE APY) instead of complete failure (cannot access funds).
The Communication: Be transparent: "Your funds are safe, rewards are temporarily queued, deposits help resume distribution."
The Risk: Low technical risk (simple code, no storage changes), medium business risk (user perception, need good communication).
Next Step: Approve deployment and communication strategy.
For technical implementation details, see SOLUTION_ANALYSIS.md.