Add amount to WinnerSpec and make select_winners payload-driven

[0xdevcollins]

Allocation moves out of create and into payout. select_winners reads the amount from the payload rather than deriving it from a percentage of base_escrow.

Done when

• WinnerSpec carries amount: i128
• select_winners uses it directly, amount > 0 enforced
• base_escrow snapshotting and EventPrizeBaseEscrow are no longer read on this path
• The pre-1.3.0 push-model branch keyed off its absence is removed

See plan 3.1 and 3.4.

---

Plan: boundless-bounty-programs-implementation-plan.md

[coderabbitai]

🔗 Related PRs

#83 - feat(events): replace push-based select_winners with pull-model claim_prize for unlimited winners [open]
#90 - feat(events): pull-model prize claims for Single-release events [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!

[Bosun-Josh121]

Hello @0xdevcollins,

I am an active open-source contributor and I have a strong background in backend and smart contract engineering (specifically Stellar/Soroban), and I would like to tackle this issue.

This issue aligns perfectly with my skillset.

My approach: add amount: i128 to WinnerSpec and make select_winners read the amount directly from the payload with amount > 0 enforced, then remove the base_escrow snapshotting and EventPrizeBaseEscrow reads on that path along with the pre-1.3.0 push-model branch keyed on its absence. I've reviewed the escrow flow and the select_winners / base_escrow path, so I can make this change cleanly without new error variants, and I understand how it sets up the owed-amount handling in the follow-ups.

I can commit to delivering a clean, tested solution within 24 hours, with tests covering payload-driven payouts, the amount > 0 rejection, and confirmation that base_escrow is no longer read on the path. I value clear communication and i'm happy to iterate on any feedback during the review process.