Build saga-style tournament lifecycle (create → join → lock → settle → payout)

[josephchimebuka]

Summary

Replace thin mock/Prisma tournament fragments with a full lifecycle service: create tournament, atomic joins, lock entries, settle based on linked rounds, and payout winners.

Why this matters

Tournaments are campaign-visible features but still lack a coherent end-to-end domain workflow.

Where to work

• src/services/tournament.service.ts
• src/routes/tournaments.routes.ts
• Prisma Tournament / participants
• seed scripts

What to implement

1. Model tournament states and transitions.
2. Implement create/list/join/lock/settle endpoints or jobs.
3. Tie settlement to resolved rounds/leaderboard rules.
4. Atomic join capacity (already partially done) extended to settlement.
5. Integration tests for full happy path + full tournament.

Acceptance criteria

• Tournament can be created and joined in DB mode.
• Settlement produces deterministic winners/payouts.
• Illegal actions in wrong state rejected.
• Tests cover lifecycle.

Done when

Tournaments work as a complete product flow, not isolated endpoints.

Metadata

Field	Value
Difficulty	advanced
Complexity	high
Good first contribution?	no

[Caerlower]

Allow me to work on this, I can fix this.

pinging on this, let me know!

[kalbliz]

Hi maintainers,

I would love to work on this issue. I have experience building production-ready backend applications and working with TypeScript, APIs, databases, Prisma, and GitHub-based development workflows. I enjoy working on features where the main challenge is not just implementing individual endpoints, but designing a reliable end-to-end domain workflow.

For this task, I would carefully study the existing tournament, round, participant, and leaderboard implementations before making changes. My approach would be to establish a clear tournament state machine and ensure that every transition is validated and performed safely.

I would focus on:

• Implementing the complete create → join → lock → settle → payout lifecycle.
• Ensuring tournament state transitions are explicit and illegal actions are rejected.
• Making participant joins and tournament capacity handling atomic and transaction-safe.
• Connecting settlement to the existing resolved rounds and leaderboard rules.
• Making winner selection and payout calculations deterministic and testable.
• Preserving the existing DB/Prisma architecture rather than introducing unnecessary complexity.
• Adding integration tests covering the complete happy path, full tournament capacity, settlement, payouts, and invalid state transitions.

I understand this is a high-complexity feature, so I would prioritize understanding the existing domain model first, keeping the implementation incremental, and avoiding changes that could introduce inconsistencies across the existing tournament and round flows.

I'll thoroughly test the implementation, review the changes for edge cases and transactional issues, and submit a clean PR that is easy for maintainers to review.

Thank you for your consideration.

[Akanjioladayo5]

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

I'm interested in taking on this issue and contributing to the Stellar ecosystem. I've reviewed the requirements and understand the expected outcome. I can investigate the existing implementation, identify the best approach, and deliver a clean, focused solution that follows the project's standards.

I'll make sure the implementation is properly tested, maintainable, and doesn't introduce unnecessary changes. I'm ready to start working on this and would appreciate being assigned the issue if it's available.

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