`UserVerifications(Address)` is an unbounded persistent `Vec<u64>` — same O(n) storage corruption class as the fixed `CreatorTasks` bug

[cybermax4200]

Why this matters now:
Issue #52 fixed CreatorTasks(Address) from an unbounded Vec to indexed persistent entries. The exact same bug exists in DataKey::UserVerifications(Address) in reward-engine/src/storage.rs. A user who submits many proofs accumulates an ever-growing Vec<u64> that is read in full on every push_user_verification_key call, and eventually the serialized Vec will exceed transaction limits, permanently bricking that user's ability to submit new proofs. This directly blocks the mainnet launch goal.

Problem / What:
push_user_verification_key reads the entire Vec<u64> for a user from persistent storage, appends one entry, and writes it back. read_user_verification_tasks loads the entire Vec to serve any paginated query. As a user accumulates verifications (one per task attempt), the Vec grows without bound. At ~100+ entries, the Soroban 100-entry footprint limit will be approached; beyond that the transaction will panic with a resource exhaustion error. The fix pattern is identical to #52: replace with UserVerificationCount(Address) + UserVerification(Address, u64) indexed storage.

Key Challenges:

• Must migrate the storage layout without breaking existing on-chain data (any deployed instance with existing UserVerifications Vecs needs a migration strategy or clear deprecation path).
• get_verifications_by_user slicing logic must be rewritten to use indexed reads.
• The old DataKey::UserVerifications(Address) variant must be retained in the enum to prevent key-space collisions on deployed contracts.
• Write a regression test that creates 500 verifications for one user and confirms the 500th does not panic (mirroring the test_500_task_regression_creation_succeeds pattern from CreatorTasks Vec in task-registry grows unboundedly; prolific sponsors can cause storage exhaustion #52).

Acceptance Criteria:

• push_user_verification_key does exactly 1 persistent read + 2 persistent writes regardless of existing verification count (O(1)).
• get_verifications_by_user(user, cursor, limit) reads only limit indexed entries, not the full history.
• A regression test with 500 verifications for a single user passes without panic.
• DataKey::UserVerifications(Address) is marked deprecated in the enum with a comment explaining the migration.
• All existing get_verifications_by_user tests still pass.

Relevant files/functions:

• contracts/reward-engine/src/storage.rs — push_user_verification_key, read_user_verification_tasks, DataKey::UserVerifications
• contracts/reward-engine/src/verification.rs — RewardEngine::get_verifications_by_user

Out of scope: Changing verification business logic, TTL management (Issue 1), VerificationList fix (Issue 3).

[daveedAJ]

Hi maintainer, I’m interested in taking on this issue. I can investigate the unbounded UserVerifications(Address) vector, identify the storage-growth and corruption risks, and implement a safe bounded approach consistent with the fix applied to CreatorTasks. I’ll also add the necessary tests to verify the fix and prevent regressions.

[greyhe0x]

I'd like to take this.

I checked contracts/reward-engine/src/storage.rs on current HEAD. push_user_verification_key still reads the full DataKey::UserVerifications(Address) Vec<u64>, appends, and writes it back — the same unbounded pattern #52 fixed for CreatorTasks.

Plan:

• Mirror the indexed layout from CreatorTasks Vec in task-registry grows unboundedly; prolific sponsors can cause storage exhaustion #52: UserVerificationCount(Address) plus UserVerification(Address, index) -> u64.
• Rewrite push_user_verification_key and read_user_verification_tasks / get_verifications_by_user to do O(1) writes and page only limit indexed entries.
• Keep the old UserVerifications(Address) enum variant deprecated to avoid key-space collisions on deployed instances.
• Add a test_500_user_verification_regression that submits 500 proofs for one user without panic.

please assign this to me if that works.

[nyuiela]

I'd like to take this.

On current HEAD, push_user_verification_key in reward-engine/src/storage.rs still does a full persistent read/modify/write of UserVerifications(Address) on every proof submission. That Vec grows with every task attempt and will eventually hit Soroban footprint limits — same failure mode as the CreatorTasks bug fixed in #52.

Plan:

• Replace the Vec with indexed persistent storage (UserVerificationCount + UserVerification(user, n)), matching the CreatorTasks Vec in task-registry grows unboundedly; prolific sponsors can cause storage exhaustion #52 pattern.
• Update get_verifications_by_user paging to read only the requested window instead of loading the full history.
• Mark DataKey::UserVerifications(Address) deprecated in the enum and document the migration path.
• Regression test: 500 verifications for one user completes without resource exhaustion.

please assign this to me if that works.

[Santia2004]

Hi! I would like to work on this issue for the GrantFox campaign. I have experience with this stack, understand the requirements, and I'm ready to submit a clean, well-tested PR once assigned. Could you please assign it to me?

[grantfox-oss]

🦊 GrantFox — @nyuiela has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

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

Good luck! Track your progress on GrantFox.