compact_storage and create_proposal accept unbounded caller-supplied sizes with no resource-limit guard

[abayomicornelius]

Area

Project Registry / Gas & Resource Limits

Complexity

Easy

File(s)

project_registry/src/lib.rs:1031-1047 (compact_storage), :583-621 (cast_vote / create_proposal's voting_duration_secs)

Problem

update_impact_scores_batch explicitly caps input at MAX_BATCH_SCORE_SIZE (20) to prevent transactions that would exceed Soroban ledger resource limits — but compact_storage accepts unbounded project_ids: Vec and tokens: Vec

and does a full nested-loop persistent read/possible-remove for every combination, with no equivalent size guard. Separately, create_proposal computes voting_ends_at = env.ledger().timestamp() + voting_duration_secs with no upper-bound check on the caller-supplied voting_duration_secs; today overflow-checks = true turns a pathological value into a panic rather than a wrapped timestamp, which is an implicit reliance on a build-profile flag rather than explicit contract-level validation.

Scope

In:

• Add a MAX_COMPACT_STORAGE_SIZE-style bound to compact_storage mirroring MAX_BATCH_SCORE_SIZE; add an explicit sanity-check upper bound on voting_duration_secs in create_proposal with a dedicated error.

Out:

• Changing the batch-scoring pattern itself.

Acceptance Criteria

• compact_storage panics with a new bounded-size error for oversized inputs, tested
• create_proposal rejects an unreasonably large voting_duration_secs with a clear error rather than depending solely on the compiler's overflow-check panic

[drips-wave]

@abayomicornelius This issue could not be added to the Stellar Wave Program because the per-repo points budget would be exceeded (25000 / 25000 points already used). The label has been automatically removed.

The budget resets at the end of each Wave. You can review the remaining budget for your repos on the Orgs & Repos page.

ℹ️ Learn more about points budgets