Hackathon submit() has no submission cap or content_uri length limit

[0xdevcollins]

Severity: MEDIUM · Contract · boundless-events

Surfaced by the Almanax scan of e1f17937. Closes Hackathon submissions can bloat persistent storage.

Files

• contracts/events/src/event_ops.rs:505-562 — submit

Problem

Applicants (MAX_APPLICANTS_PER_EVENT = 5_000) and contributors (MAX_CONTRIBUTORS_PER_EVENT = 5_000) are capped, but Hackathon events have needs_application = false, so any address can create a persistent EventSubmission(event_id, applicant) entry with an arbitrarily long content_uri, with no cap on the number of distinct submissions. An attacker spamming submit from many fresh addresses grows the contract's persistent state / rent burden and degrades indexers.

Fix

• Add a per-event submission counter with a MAX_SUBMISSIONS_PER_EVENT cap; reserve the slot before writing (matching the contributor append_* pattern so a cap-exceed reverts cleanly).
• Enforce a MAX_CONTENT_URI_LEN bound on content_uri.
• New typed errors as needed — mind the 50-variant contracterror cap; reuse existing variants where sensible.

Tests

• Submission at cap+1 reverts.
• Oversized content_uri reverts.
• Re-submission by an existing applicant (update in place) does not increment the counter.

[coderabbitai]

🔗 Related PRs

#46 - test: hackathon pillar — select_winners distribution + claim [merged]
#47 - test(events): added bounty pillar — apply / withdraw_application + c… [merged]
#54 - test(coverage): add 9 test modules for contract test coverage push [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[SudiptaPaul-31]

May I be assigned to this issue please my name is Sudipta Paul a active open source contributor with more than 50+ merged pr's and also an active contributor of GrantFox from begining and would love to work on this issue and get a pr merged

[bamiebot-maker]

kindly assign this issue to me,i am ready to work on it and create a quality pr as soon as possible

[armandocodecr]

Hi, I'm Armando, a Full-Stack Developer with solid experience in Soroban smart contracts in Rust, including persistent storage caps, rent/DoS considerations, and typed contract errors.

My plan would be: add a per-event submission counter (following the existing contributor append_* pattern) that's read and reserved before writing the EventSubmission(event_id, applicant) entry, enforcing a new MAX_SUBMISSIONS_PER_EVENT cap so it reverts cleanly on cap+1; add a MAX_CONTENT_URI_LEN check on content_uri in submit; and make sure re-submission by an already-existing applicant updates the entry in place without incrementing the counter. I'll reuse existing error variants where they fit and only add new ones if needed, keeping the 50-variant contracterror limit in mind. Tests will cover the three scenarios: cap+1 reverting, oversized content_uri reverting, and re-submission not incrementing the counter.

[grantfox-oss]

🦊 GrantFox — @armandocodecr 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 #71)
2. Your PR will be reviewed by the boundlessfi maintainers

Good luck! Track your progress on GrantFox.