Contracts: Migrate participant storage from instance to persistent storage

[joelpeace48-cell]

Summary

The campaign contract stores participant registrations in instance storage using (PARTICIPANT, participant.clone()) as the key. Instance storage in Soroban has a hard size limit of 64KB. A high-traffic campaign with thousands of participants will hit this ceiling and permanently brick the contract, silently failing new registrations.

Problem

In contracts/campaign/src/lib.rs:

let key = (PARTICIPANT, participant.clone());
env.storage().instance().set(&key, &true);

Per Soroban storage docs:

• Instance storage: shared with contract code, max ~64KB, cheaper TTL management but shared fate
• Persistent storage: per-key, appropriate for user-keyed data like participant records

Using instance storage for per-user data breaks at scale and makes the entire contract instance fragile.

Acceptance Criteria

• Migrate all participant record reads/writes to env.storage().persistent() in register() and is_participant()
• Add extend_ttl for persistent storage keys on each participant registration (with appropriate mainnet values)
• Keep PARTICIPANT_COUNT in instance storage (it's a single aggregate value, not per-user)
• Update all tests that verify participant registration to account for the new storage tier
• Add a test that registers > 100 participants to validate no size limit regression
• Add CHANGELOG entry and migration note in docs/upgradeability.md

Storage size risk

Each Address in XDR is ~35 bytes. At 64KB instance limit, a campaign caps out at ~1,800 participants — far below what a viral campaign might receive.

References

• contracts/campaign/src/lib.rs:292-300 (register function storage writes)
• contracts/campaign/src/lib.rs:332-336 (is_participant storage read)
• Soroban storage types

[Buchi-Einstein]

@Buchi-Einstein has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

can i work on this, I'll implement this efficiently and effectively

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Buchi-Einstein to this issue.

[Ejere]

@Ejere has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

can i work on this issue?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ejere to this issue.

[drips-wave]

Congratulations, @Ejere! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 2, 2026.

🧑‍💻 @Ejere: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[drips-wave]

This issue has been completed by @Ejere as part of the Stellar Wave Program's 5th Wave 🥳

😎 @Ejere: You earned 200 Points for completing this issue! After the current Wave ends, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.