ODDBOUT Showrunner

Sponsors pay via PayPal, an AI producer runs a fighter tournament show around their promo, and PayPal Payouts pays the fighters' creators.

Comment

Inspiration

ODDBOUT is a fighting game where players bring characters created with AI. Once fighters existed, the question became who pays for the show built around them. Small brands lack an easy way to buy a few minutes on a live broadcast, and players earn nothing when their fighters appear. We built a system where one payment does three things: buys airtime, runs the show without a human producer, and sends a share to the featured creators.

This system requires an AI agent that manages the show and nothing else. It can schedule fights, but it must never move money. PayPal handles payments, verification, and payouts. We built the layer in between.

What it does

Sponsors pay with PayPal. An AI producer runs the show. Creators get paid.

  1. The sponsor pays. They sign in with Google and purchase DON, our Sandbox credit, through PayPal Checkout (USD 10 = 1,000 DON). DON is credited only after our server verifies the capture.
  2. They buy a Spotlight ticket. One hour costs 300 DON and assigns four fighters. They upload a short MP4 and a promo URL, and a model writes the paid sponsor introduction.
  3. The AI producer runs the show. The On-Air Agent reads the ticket's lineup and remaining time, then decides turn by turn when to host the next cup. It can only act through our MCP tool host_cup, scoped to that specific broadcast. It cannot pay, approve payouts, or change prices.
  4. Viewers watch. The public watch page plays the sponsor break and replays the verified bouts run by the producer.
  5. The payment is checked with PayPal. After the show, Check settlement uses the official PayPal MCP server to call get_order for the exact top-ups funding the ticket and compares them with our ledger. A model reads the same read-only results and explains them to the owner. The server's comparison determines the final result, not the model.
  6. Creators get paid. The owner approves the appearance fees, and PayPal Payouts sends them. The ticket displays "Paid" only when every recipient item reports SUCCESS.

The ticket page displays five steps: Paid, Scheduled, On air, Settled, Creators paid. The video's final minute shows the complete loop on the hosted site using a new account: 0 DON, a $10 top-up, three AI-produced cups, Matched, and a Payouts batch where every recipient shows SUCCESS.

The ledger keeps paid agent tasks active through disruptions. If the checkout tab never returns, the signed webhook still credits the payment, once. If the customer's agent drops, it resumes the same paid task from another device. If our server restarts or the producer outputs an invalid answer, the show continues on the same payment. The animated first half of the video demonstrates these cases.

How we built it

  • PayPal Orders v2 ยท Checkout: Handles creation, buyer approval, and server capture. Before crediting, we verify the completed capture against the order ID, payee, amount, currency, and the account's top-up record. Each capture ID credits once.
  • PayPal webhooks: Signatures are verified with verify-webhook-signature. Approval and capture events use the same credit path as the return tab, preventing late or repeated events from crediting twice. Refund and reversal events freeze spending.
  • Official PayPal MCP server (@paypal/mcp): Runs as a child process with only get_order, list_transactions, and get_refund enabled. We reject the connection if it offers any other tool.
  • PayPal Payouts: Our batch ID serves as PayPal's sender_batch_id and request ID, preventing duplicate batches if a retry occurs.
  • AI producer: A model called through the OpenAI Responses API proposes one structured decision per turn (host a cup, wait, or stop). The server validates the decision and executes it through ODDBOUT's MCP server using a broadcast-specific grant. Model calls are capped per broadcast and per day.
  • Ledger: A separate Supabase Sandbox project. One debit per ticket, one credit per capture, and each cup result applies once.
  • Arena: Fights run on our open-source tournament renderer (Phaser, TypeScript) hosted on a macOS machine with OBS. Each result is reported back once.
  • Hosting: The demo server and arena run on Render (deploy/broadcast.render.yaml).
  • Development: We built Showrunner using AI coding agents (OpenAI Codex and Claude Code) inside the repository and logged each Sandbox rehearsal in docs/records/.

Tools: which AI we used and how

  • On-Air Agent (the AI producer): An OpenAI model called through the Responses API, set by the operator in ODDBOUT_BROADCAST_MODEL without a fallback model. Our Nov 4 record identifies Sol 6.1 as the model that produced its cups. It decides when to host each cup and calls our MCP tool host_cup. It cannot spend beyond the ticket limit or access payments.
  • Sponsor introduction writer: The same API writes a 25 to 45 word paid sponsor introduction using only the promo URL's hostname. The prompt forbids product claims. The owner reviews the text before launch.
  • Settlement auditor: Following the server's comparison, a model can call the read-only PayPal MCP tools to review mismatched or pending rows, then explains the output to the owner.
  • Official PayPal MCP server: Provides read-only access for the auditor to inspect the exact orders funding the ticket.
  • Development: OpenAI Codex and Claude Code served as coding agents. ElevenLabs generated the demo video's narration and music.

Challenges we ran into

  • "Paid" had to mean paid. Our first Payouts adapter treated a successful batch header as completion, but a batch can succeed while individual items remain unclaimed or missing. Now a batch counts as paid only when PayPal returns a full set of item results with every recipient showing SUCCESS.
  • The return tab lost the session. Sign-in lives in per-tab storage, so the tab PayPal returns to opens signed out. The top-up now resumes after Google sign-in in that tab, and the webhook covers cases where a tab never returns.
  • Models sometimes answer badly. An unusable producer answer displays Retry Agent. It continues the same ticket, session, and call count at no extra cost. An uncertain cup is held for review and never retried blindly.
  • An AI near money. We kept the agents able to act, but only through scoped tools. Every financial movement goes through the server's own checks, and creator payouts always await human approval.
  • Where PayPal works. We are based in Korea, and PayPal does not allow payments between Korea-registered accounts. We test with a US Sandbox buyer, and our rollout plan for a live service targets overseas business sponsors.

Accomplishments that we're proud of

  • The full loop runs on the hosted demo: PayPal Checkout, an AI-produced show, a PayPal MCP check, and Payouts with every recipient showing SUCCESS. We ran it again on Nov 5 with an account that had never signed in.
  • The AI producer maintains operational autonomy inside hard limits. It decides the show flow but cannot spend beyond the ticket, approve anything, or touch payouts.
  • One payment produces exactly one credit and one debit through retries, late webhooks, closed tabs, and server restarts.
  • The code is open source under the MIT license, accompanied by dated rehearsal records for review.

What we learned

  • PayPal's official MCP server works reliably as an independent auditor. The model reads the same records our server checks, allowing its explanation and our ledger to be compared directly.
  • Agent autonomy is easiest to trust when the ledger, rather than the prompt, enforces the limits.
  • Payment success contains multiple layers: order versus capture, and batch versus item. Displaying each layer on screen made the product clearer and the codebase more accurate.

What's next

  • Sell tickets directly through PayPal Checkout without a prepaid wallet balance, starting with overseas business sponsors.
  • Enable live creator payouts once PayPal Payouts support is confirmed for the creators' countries.
  • Stream to Twitch or YouTube and verify full 24-hour operational runs. Neither is verified yet.

Built during the submission period

The ODDBOUT game, its fighters, and the fighter creator kit existed before this hackathon and are not part of this entry. Showrunner's code first appears on Nov 2, 2026: broadcast/ and api/commerce/ have no earlier history. The full, dated list of pull requests is available in docs/HACKATHON.md.

Honest limits

  • PayPal Sandbox only. No live payments or real customers.
  • One graphical runner serves the demo, meaning one broadcast runs at a time.
  • The watch page replays verified bouts on the web. It is not a Twitch stream.
  • A full hour, including the second sponsor break, is not yet verified on the hosted demo.

Built With

Share this project:

Updates

Submission history