AuraEconomy: a points economy for Twitch chat built on Streamer.bot and SQLite

Chat activity turned into a tiered economy

AuraEconomy is a gamification system for Twitch streamers, built as a Streamer.bot C# Inline backend with a vanilla JavaScript overlay and a SQLite database in WAL mode. The goal is a small role playing layer over a chat: viewers earn points, points determine a rank, and rank unlocks what you are allowed to do with them.

The ranking runs through ten distinct tiers, from Wood at zero points up to Eternal, which is reserved for the top three. Each tier carries three things: a points threshold, a wager cap and an aura colour. The published thresholds start at Wood with a cap of 25, Bronze at 500 points with a cap of 50, Silver at 1,500 points with a cap of 100, and end at Eternal with a cap of 10,000.

What the streamer sees is the overlay, an HTML page with CSS and WebSockets, listed in the project layout as Overlay.html with a folder of SVG rank icons:

/
├── docs/
│   └── ImplementationGuide.md    # Simple step-by-step setup for non-technical users
├── src/
│   ├── bot/
│   │   └── EconomySystem.cs      # Core C# logic for Streamer.bot
│   ├── database/
│   │   └── schema.sql            # SQLite database structure & views
│   └── overlay/
│       ├── Overlay.html          # Vanilla JS Chat & Notification Overlay
│       └── icons/                # Rank icons (SVG)
└── README.md                     # Project overview

The separation is deliberate. Chat side effects live in the bot, durable state lives in the database, and presentation lives in a page the streamer's OBS runs as a browser source at 1920x1080.

The SQLite file is the shared state, not a local cache

The database is described as SQLite configured with WAL mode, and the reason given is access rather than speed. WAL mode is what allows simultaneous access by the bot and by external tools, with the project naming Minecraft plugins as an example of something else reading the same data while the bot is running.

That is the architectural decision that makes AuraEconomy more than a chat script. If the points table lives inside Streamer.bot's own storage, only the bot can read it, and anything else you build on top, a Minecraft plugin that pays out rewards, a dashboard, a leaderboard website, has to duplicate the numbers or poll a chat command. With a shared SQLite file in WAL mode, those tools read the same rows the bot writes.

The schema file is named schema.sql and is described in the project layout as the SQLite database structure and views, so the state is not just tables but includes views, which is how a derived value such as a current rank or a lifetime total can be read without every consumer recomputing it.

The practical consequence is that AuraEconomy assumes a single machine. The bot, the overlay and any external tool all open the same local file. The project does not describe a hosted database, a remote overlay host, or a multi-machine setup, and SQLite in WAL mode is not a good fit for a shared filesystem over a network, so treat the single machine assumption as part of the design rather than an accident.

Watch time accrual hangs on one Streamer.bot trigger

Points accrue at one point per minute of watch time, and the mechanism for that is where the project depends on its host most tightly. The accrual is described as verified, and it uses Streamer.bot's native 'Present Viewers' engine.

The setup instructions make the dependency explicit. When you create the Streamer.bot actions, you must ensure that the 'Watch Time' action uses the 'Present Viewers' trigger.

That is a small instruction with large consequences for the design. A system that awards points for watching depends on the host being able to enumerate who is currently in chat, and the project has chosen to take that list from the platform rather than from its own tracking. The result is accurate for viewers present in chat, and it is not a record of watch time for people watching without chatting, since the trigger fires on presence rather than on a client-side timer.

For a streamer, this is the behaviour you want, since it rewards the audience that is actually present. For someone adapting the system to a different platform, the watch time rule is the part that has to be rewritten, because everything else in the economy depends on a stream of point accrual events.

Escrow betting with a cap set by your own rank

Betting is part of the system rather than an add-on. The project describes it as an advanced escrow-based betting system, with win and loss outcomes and rank-based wager caps.

The cap mechanism is the interesting bit, because it links the economy back to the tier ladder. The wager cap is a property of the rank, so a viewer cannot bet more than their standing allows. Wood can wager 25, Bronze 50, Silver 100, and the top tier can wager 10,000. The escalation means the cap tracks the same points that earn the rank, which keeps the risk of the economy proportional to how much a viewer has actually contributed.

Escrow is what makes the mechanism safe to expose in chat. Points are held while the outcome is pending rather than being deducted and refunded, so a viewer cannot spend the same balance twice and an interrupted round does not leave the ledger inconsistent.

The second point sink is the !annuncio command, described as a premium command that broadcasts animated messages on screen. It spends points in exchange for a visible moment in the stream, and it feeds the same overlay that shows ranks. Together, betting and announcements give viewers two competing reasons to hold points, which is the mechanism that keeps a points economy from becoming a passive counter.

Monthly resets and the Legacy Aura that survives them

Seasonal resets run monthly. They clear the seasonal points but preserve lifetime statistics and the Aura status, and that distinction is the core of the ranking design.

Legacy Aura is described as a permanent visual badge of honour. A viewer keeps the coloured glow corresponding to their highest-ever rank, regardless of the monthly resets, so the overlay can show both a current tier and a permanent marker of what someone once reached. A viewer who peaked at Silver last month still shows that Silver aura this month even after their seasonal points fall back to a lower tier.

The design solves a problem that any seasonal economy runs into. Without it, resetting the points also resets the player's identity, and a leaderboard that wipes every month gives long term viewers no reason to keep showing up. With it, the reset becomes a fresh start for competition while the aura preserves recognition.

It also creates a policy question for the streamer. The aura is by definition monotonic, so a viewer who has reached Eternal keeps that colour permanently, and the seasonal tier can only ever be lower than the aura. That is a deliberate design choice rather than a bug, but it means the aura is a lifetime statistic wearing the costume of a rank.

Four setup steps, and one of them is manual code pasting

The quick start is four steps, and it is worth reading them closely because step three is not a normal install.

First, run schema.sql in a SQLite tool to create the database file. Second, open EconomySystem.cs and set your DB_PATH, which is how the bot code finds the file you just created. Third, in Streamer.bot, create the actions and paste the corresponding code regions from EconomySystem.cs, ensuring that the 'Watch Time' action uses the 'Present Viewers' trigger. Fourth, in OBS, add Overlay.html as a browser source at 1920x1080.

Step three is the defining constraint of the whole project. AuraEconomy is not a plugin you install. It is a set of code regions that a streamer pastes into Streamer.bot's own action editor, and the project ships an ImplementationGuide.md described as a simple step-by-step setup for non-technical users, which is the admission that the target audience is not developers.

That approach buys something real. Streamer.bot handles the Twitch connection, the command parsing and the action execution, so there is no separate service to run and no connection to maintain. It also means there is no package manager entry, no versioned release, and no upgrade path beyond pasting updated regions again.

The overlay in step four is the least demanding part. A browser source pointing at a local HTML file needs no server of its own, and the WebSocket connection in the page carries the updates the bot publishes.

The overlay is a plain HTML page talking over WebSockets

The overlay is described as vanilla HTML5, CSS3 with the Inter font and a glassmorphism look, and JavaScript over WebSockets. No framework, no build step, no bundler.

That choice has consequences for anyone extending the system. The page is opened by OBS as a browser source, which means it runs inside OBS's own Chromium instance rather than in a browser you can open and inspect easily. Debugging it takes a different route than the usual developer tools workflow, and the fact that it is a single file with no dependency graph means there is nothing to install, but also nothing to modularise without doing it yourself.

The WebSocket channel carries what the bot publishes: rank changes, chat and notification events, and the on-screen broadcasts triggered by commands such as !annuncio. The rank icons are separate SVG files in an icons folder, so the visual identity of a tier is a file you can replace rather than a value you configure.

Since the overlay is a local file served to OBS, the WebSocket endpoint it connects to has to be running somewhere. The project does not document a standalone overlay server in the repository layout, so the connection is presumably established by the bot process itself. That is worth confirming on your own setup, because the browser source is the part a streamer will notice first when it shows nothing at all.

No releases, an unknown licence, and a last push in June

The repository has no GitHub releases, and the last push was on 2026-06-30, a little under four months before this article. The project badges describe the status as complete, which is a claim about the author's intent rather than a release record.

The licence is listed as unknown, and there is no licence file among the top-level entries of the repository, which are README.md, add_logging.py, add_logging_p2.py, a backup directory, docs, reference, src.zip and src. That is a real constraint for anyone who wants to reuse the code. Running it for your own channel is one thing, and shipping a fork, bundling the overlay into a commercial product, or contributing a change whose licence status is unclear is another. The practical step is to ask the author which terms apply before you build on it, and this is not a legal opinion about who owns the code.

The two Python files at the top level, add_logging.py and add_logging_p2.py, suggest that logging was added to the C# sources by script rather than by hand, which is a useful clue about how the code base is maintained. The presence of src.zip next to src is less clear and may be a convenience archive for people who want to grab the code without the tools.

For a streamer, the upgrade story is simple: there is nothing to upgrade from, because there is no versioned release. You keep your own copy of the schema, your own database file, and your own pasted code regions.

Editorial conclusion

AuraEconomy fits a streamer who wants a points economy their viewers can bet with, where the chat commands live inside Streamer.bot and the display is a browser source in OBS. It is the wrong choice for a developer who wants to install a package and call an API, since the setup is a manual paste of code regions into Streamer.bot actions, and it is the wrong choice for a commercial deployment because the licence is listed as unknown and no release is published. Verify three things first: that your Streamer.bot installation can use the 'Present Viewers' trigger for watch time accrual, that the shared SQLite file is reachable by the overlay process on the same machine, and that you have settled the licence position with the author before you publish anything built on it.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/AuraEconomy on GitHub
2. Issues
3. README