> For the complete documentation index, see [llms.txt](https://jordan-7.gitbook.io/jordan-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jordan-7.gitbook.io/jordan-docs/internal/briefs/2026-07-25.md). # MegaChat brief — 2026-07-25 ## Objectives today * Stop MegaChat burning money on video infrastructure * Prove the fix actually works * Build the fan bounty mechanic (fans record clips for streamers who aren't on the platform yet) ## What happened * Found the leak. The overlay page connected to the video service the moment OBS opened and never disconnected. A crash-reload loop then stacked ghost users on top. One session ran 30 hours with nobody in it. * Fixed it. Overlay now stays disconnected until someone actually pays to join. * Added guardrails: a timer that releases people who bail mid-payment, a spending circuit breaker, and an alarm on any long session. That alarm would have caught the 30-hour one on day one instead of month one. * Built the bounty system end to end with fake money. Escrow, claims, payout, admin. * Caught a design flaw in the spec: it paid streamers for having the logo on screen, not for playing the fans' clips. Park it for three hours, collect. Rewrote so the proof code only exists while a clip is playing. ## Problems and how we handled them * Quota was half-rejecting connections for most of the day. The agent refused to run the verification rather than produce a green result that meant nothing. Right call. A prorated paid plan was purchased the same day, and it is unclear whether it was active during the measurement, so the test needs re-running either way. * No way to pull LiveKit's usage numbers programmatically at this plan tier. Workaround: their webhooks push the data to us instead, which is why activating that URL matters. * Ledger could corrupt on a crash and silently change everyone's balances. Rewritten so it refuses to start rather than serve wrong numbers. ## Outstanding * Owner: paste the webhook URL into LiveKit. Two minutes. Protection is off until then. * Diagnose whether the rejections clear now that a paid plan is active. The measurement predates the purchase. * Four bounty fixes flagged, none urgent. * Run B (real streamer sign-in, real video verification) needs platform apps registered and a test stream. * Product call for the owner: what happens to money fans contributed for clips under 3 seconds, which are too short to verify. ## Outlook: mid, leaning bullish * Bullish: the expensive bug is fixed and understood, guardrails exist, the bounty mechanic is built and its worst design flaw was caught before real money touched it. * Mid: the core cost claim has still never been tested against LiveKit's own numbers, only against a local test server. It's believed to work, not shown to. * Bearish only if: the 50% rejection turns out to be something structural rather than a leftover quota state. That would block real testing entirely. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://jordan-7.gitbook.io/jordan-docs/internal/briefs/2026-07-25.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.