From Pentests to Continuous Security with Pixels

Pixels is a browser-based MMO and one of the largest web3 games by daily active users. The game runs on an authoritative Colyseus server, and carries a live on-chain economy: $PIXEL, land NFTs, a player marketplace, wallet withdrawals. Every trade and every item is settled server-side.

Before Borg

Pixels was not starting from zero. They ran pentests on a schedule and had operated a public bug bounty for years, which already put them ahead of most companies their size. The problem was fit rather than effort. A game that ships every week is a different product by the time a scheduled report is written up, and a bounty brings in whatever researchers happen to look at rather than what the team most needs checked.

How the relationship started

Pixels came to us looking for a security partner that could stay close to the product over time, rather than step in for a single assessment.

At that point, Borg was still a five-person team. Pixels became one of our earliest clients, and the way the engagement developed ended up shaping the model we now call Forward Deployed Security.

What we've worked on

The live game server and its API, tested continuously rather than at scheduled intervals, because the build in production is rarely the build that was last assessed.

Stacked, Pixels' own analytics, offerwall and shop platform. A webhook that grants items and currency into player accounts is a path to minting value, and it gets treated as one.

OtterAuth, the authentication system Pixels built in-house. Taking auth on yourself means sessions and accounts sit behind code you own. That is a large thing to build and a large thing to have tested.

Pixels as an OAuth provider. They wanted third-party apps to offer sign-in with a Pixels account, which turns Pixels into an identity provider that other applications trust on their users' behalf.

Pixel Dungeons, A fast-paced game within the Pixels ecosystem, running on its own stack and paying out in the same $PIXEL the main economy depends on.

The open source review, reading the client and server codebases in 2026 before Pixels published them under AGPL-3.0, so the code was gone over ahead of publication rather than after it.

Looking Back

As Pixels evolved, the security work evolved with it. That experience helped shape how we approach long-term security engagements today: staying close to the product and adapting the testing as the system changes.