get_dashboard_metrics` reads every campaign in `core/lib.rs` — quadratic in storage cost

[P3az3]

Problem Statement

crates/contracts/core/src/lib.rs::get_dashboard_metrics walks id from 1..=total_campaigns reading each one:

let mut active_campaigns: u64 = 0;
let mut id: u64 = 1;
while id <= total_campaigns {
    if let Some(c) = env.storage().persistent().get::<_, Campaign>(&campaign_key(id))
    { if c.active { active_campaigns += 1; } }
    id += 1;
}

This is O(N) reads. For platforms with 10,000 campaigns, this is 10,000 reads per view call. Soroban resource limits will exceed under non-trivial calls.

Why it matters

This is in the legacy core contract, but the same logic may propagate to campaign over time. Currently, campaign is single-campaign-per-instance, so the problem is structural in core.

Expected Outcome

Either:

(a) Maintain a separate ActiveCampaignCount storage key, incremented/decremented on status transitions, returning active_campaigns in O(1). Recommended.

(b) Add an explicit pagination cap (e.g., max 256 campaigns per view) so the view call stays within budget.

Acceptance Criteria

• New storage key ActiveCampaignCount (in core contracts).
• create_campaign increments it (campaigns start active).
• withdraw / approve may not change the active flag in core; revisit.
• get_dashboard_metrics reads the counter in O(1).
• New test asserts increment/decrement behavior.

Implementation Notes

• If core is being deprecated, this fix may be unnecessary — Issue 17.

Affected Files / Modules

• crates/contracts/core/src/lib.rs

Dependencies — Issue 17 (deprecating core simplifies this).

[divinemike019]

Hi, I'd like to work on this issue. Since get_dashboard_metrics in core/lib.rs currently reads every campaign to compute dashboard metrics, the storage cost scales quadratically as the number of campaigns grows — this becomes a real bottleneck as the platform scales, so it's worth fixing properly rather than patching around it.

My plan is to:

1. Review how dashboard metrics are actually derived from campaign data to identify what can be precomputed or incrementally maintained instead of recalculated from a full scan each call.
2. Refactor storage so relevant aggregates (counts, sums, etc.) are updated incrementally at write time — when a campaign is created/updated — rather than recomputed by reading every campaign on each metrics read.
3. Ensure the refactor preserves correctness exactly (metrics must match what a full scan would produce) with tests comparing old vs. new results across various campaign counts.
4. Benchmark storage cost before and after to confirm the fix actually removes the quadratic behavior.

I have experience with Rust and performance-focused smart contract optimization, and I'm happy to share my proposed approach early for feedback before committing to the full refactor.

[grantfox-oss]

🦊 GrantFox — @divinemike019 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #24)
2. Your PR will be reviewed by the MillestoneX maintainers

Good luck! Track your progress on GrantFox.