Track 02 · Omega payouts — Global payouts and prize transparency

Build an Omega agent that decides who gets paid from a prize fund, routes the payouts, and keeps a public ledger anyone can check.

Who you are building for

BASIX.MARKET runs hackathons and buildathons with builders across Lisbon, Nairobi and Chennai. Winners are judged, placed and paid. As events grow, organisers need prize funds that are transparent and payouts that reach people on different continents reliably.

The problem

Prize funds are usually a spreadsheet and a promise. Participants cannot see how much was received, how much was paid, what fees went where, or what was carried forward. Cross-border payouts fail, duplicate, or get stuck, and nobody can trace why.

Your build

Two parts that work together:

1. A payout coordinator — an Omega agent that applies a published funding rule, proposes payouts, waits for organiser approval, then sends them on Stellar testnet.
2. A public prize-fund ledger — a page or feed showing funds received, paid, fees and the reserve carried to the next event, each line linked to a receipt.

Use Raven for Stellar development help. Any NEAR Intents cross-chain leg is simulated with a dry quote, because NEAR Intents has no testnet.

What Omega does here

Role	Payout coordinator that applies the rule, proposes, and executes only after approval.
Memory and reasoning	Remembers every request and payout; reasons over the funding rule; detects duplicates and failures.
Tools	Stellar testnet, the ledger store, a simulated NEAR Intents quote.

Example funding rule

Release funds in proportion to eligible teams. 20 eligible teams out of a 50-team target is 40%. A $1,700 fund then gives $680 for awards and $1,020 reserved for the next event, before fees. Publish the rule before registration.

Demo script (3 minutes)

1. Show the published rule: target, eligible count, cutoff and organiser attestation.
2. The agent proposes payouts: recipient, asset, quote and fees. The organiser approves.
3. Payouts settle on testnet. Each appears on the ledger with a receipt.
4. Submit a duplicate request and a failing one. Show both handled and recorded.
5. Show the reserve carried forward to the next event.

Showcase checklist

• Funding rule published and recorded
• Approval before any transfer
• Every payout linked to a receipt on the ledger
• Failed and duplicate requests handled
• Carry-forward to the next event traceable

Boundaries

Testnet and simulation only. No live funds, no real wallet keys in your repository or on screen.

HackMeridian note

HackMeridian runs 25–26 October in Lisbon. If you plan a separate entry there, document your architecture, findings and tests now, and record your baseline.

Stretch ideas

Payouts to people without a wallet yet; refunds; a public audit view for participants.

Best for

Builders comfortable with payments and ledgers.