BUSTA was a gaming platform on Binance Smart Chain: a provably fair crash game live at crash.busta.gg, a token exchange with multi-route swaps and farming pools, an affiliate centre paying out on smart-contract referrals, and a dice game in build behind them.
Six organisations were building it at once. We held product direction, project management, DevOps and QA. The evidenced window runs March 2021 to June 2022. A lot of it is a wall of green. Four days of it, players could not deposit or withdraw.
Six companies were on the build: the product owners, a core game studio, an AMM team, a smart contract and wallet-connect shop, a gameplay interface team, and us. Trello and Asana both in play. Six companies can all do good work and the product still fails, because nobody is close enough to all of it to say out loud what state the thing is actually in.
Our job was the state of the thing.
Feature lists merged across vendors with per-task ownership and blocked or in-progress state, starting 7 July 2021. Copy for the platform homepage and the exchange landing page. A shortlist of 300 candidate partner tokens researched for listing.
Weekly status reports across the build. Four survive, August to October 2021. Sprint demos recorded on staging.busta.link from October to December 2021. Somebody had to hold the seam between five build teams and one product owner. That was us.
Mainnet go-live ran off a written list: exploit fix merged to production, secrets moved into a managed store, database rotation, network switched to mainnet, endpoint moved from crashbeta1.busta.gg to crash.busta.gg. Penetration testing on two beta endpoints, plus a smart-contract audit on pool delivery.
120 recorded production smoke runs on the live crash game. A 44-scenario mainnet pass on partner-token listing, driven end to end before any partner touched it. Mixpanel event test cases across eight entry paths. Dice beta feedback triaged into fixed and held.
Fig. 1 · Multiplier growth · plotted from m = floor(100 · e^(k · ms)) / 100, k = 0.00007 · constant recommended and adopted in the provably fair research doc, 31 Mar 2021 · redrawn from the formula, not a screenshot of the game
the user does not need to trust ‘the house’ to provide a fair game. Instead the user can verify, or prove, themselves that the game was fair.
Provably Fair & Multiplier Growth Function · 31 March 2021
With the new direction of unique DEX TX features, a re-brand from BUSTaBNB (R.I.P.) to BUSTA, and playable game and functional first version affiliate program, the original timeline became a steep learning curve for all of us.
Marketing proposal · 24 August 2021
There was also a character bible, because it was a game and it was supposed to be fun: Coin King the ape profiteer, Space Strider the dog, Howard the Coin Appraiser the robot, Emperor Gros Michel of the Banaliens, and a villain named Lord Ruggit of the Galactic Arthropods. The ship is a banana.
Diamond hands (for hodling), Code-ray sight (for deep layer code audits), 8 Bit colour screen for on-the-go trade visibility and five built-in hardware wallets.
Character bible · Howard the Coin Appraiser
For four days players could not deposit or withdraw on crash.busta.gg. The manual workaround did not work either. On 6 September we wrote the internal failed transactions report, and it is the least flattering document in the whole folder.
Every instance of the game shared a single database, from the beginning. The game had never been designed or planned to scale.
Blockchain operations were writing ten times a second and block processing was falling behind. A developer had flagged it two weeks earlier. The migration was scheduled for that same week.
A socket library had been upgraded from 2.3 straight to 4.0 instead of 2.4 or 3.0, against the auditors’ own recommendation. Rolling it back would have broken the client.
The DEX went live in the same window, pushing more users at the same servers. The instance ran out of memory and started bouncing.
All instances of the game were all using the same database, since the beginning, and the game was never designed or planned to scale.
Also, we were blindly increasing the amount of users, without knowing the servers capability.
Requests for performing load tests and to grant necessary access to RD Auditors on BUSTA CRASH Security Channel, from 1-2 Sep 2021, weren’t fulfilled.
The conclusion was in bold, in our own document.
This could be avoided with having Load Tests and knowing how much load the game could handle.
Failed Transactions Report · 6 September 2021
That report names a dependency upgrade and a set of unanswered requests. We wrote the failure down while it was still embarrassing, in enough detail that it could be fixed.
First formal load test, 24 September 2021: 120 safe concurrent users, roughly 4,200 http requests at 11.96 per second. Second, 21 October, same method and same author: 350 safe concurrent users, roughly 12,100 requests at 34.38 per second. Above the safe threshold the failure mode was consistent both times. Connections forcibly closed, connection timeouts, request timeouts, and third-party graph and library resources refusing to render.
120 safe concurrent users in September. 350 in October.
BUSTA is live today.
Checked 2026-09-06: busta.gg is up, and crash.busta.gg — the crash game itself, the one that went down in public for four days in September 2021 — is serving. Everything above this line is the story of getting it there, including the parts that went wrong in front of everybody. It is still running.
Load test 1 · 24 Sep 2021 · ~4,200 requests at 11.96/s · Load test 2 · 21 Oct 2021 · ~12,100 requests at 34.38/s · same test method, same author
The maximum of safe concurrent users is 350.
Load testing should be setup and periodically ran as soon as there is a skeleton of an app
Prioritize security, stability, and performance over functionality
A production smoke-test workbook for crash.busta.gg was opened on 3 November 2021 and last edited on 14 March 2022. Nine scenarios per run: connect via MetaMask, connect via TrustWallet, deposit, manual bet, manual eject, auto-eject bet, auto-eject trigger, withdraw, disconnect. Tested against both BNB and BUST. Against production, not staging.
First production run: 2 FAIL, 7 NOT TESTED. The wallet would not connect to the live server, so nothing downstream could be reached at all.
Then 119 more runs, and the sheet is mostly green from there. That is how QA works: the first run tells you the truth, and the next hundred prove you fixed it and did not break it again.
Fig. 2 · Every result cell, to scale · 1,422 cells across 120 recorded production runs of crash.busta.gg · workbook opened 3 Nov 2021, last edited 14 Mar 2022 · the nine failures are drawn at their real width
Against production, not staging — run on the live crash game.
The nine failures are still in the sheet, because that is what a test record is for.
Mainnet pass over the holidays: list the token, add liquidity, verify the contract, swap, price impact, fee calculation, add and remove liquidity, stake and unstake LP across three pools, claim rewards, then confirm the token renders correctly on the info site.
Nine items raised between 10 and 18 February 2022. Six fixed. Three held as change requests needing approval, including an admin interface matching the one crash already had.
The losses were written down as plainly as the wins.
An internal review in late November said out loud what a status deck would have buried: the platform had promised a game a month since September and there was still no playable dice alpha, delivery would deliberately slow down to buy testing time, and the exchange was mostly functioning well while the game was not.
Crash has been plagued with issues since launch, with only brief periods of things going smoothly.
As for profitability, since we re-launched we’ve been slowly losing bankroll and we’re not sure why.
The caveat is that the speed of delivery will slow down to accommodate more thorough testing to try avoid introducing new bugs etc. with new deployments.
The best line in any of the status reports is filed under Overview.
The house edge affiliate API finally works
Weekly status report · 13 October 2021
The last recorded smoke test is 14 March 2022. By June the internal document was no longer about shipping the next game. It was thirty questions about bankroll sizing across multiple games, oracles for a universal balance, which chains to open on, whether the games were certified-math and fully audited, and whether to fold two sites into one. That is the sound of a team deciding whether to keep building or to buy.
This page is taken from project documents dated 31 March 2021 to June 2022. The six companies on the build are named in a resource list dated 25 June 2021. Four status reports survive, August to October 2021. The 120-run workbook was opened 3 November 2021 and last edited 14 March 2022, and its counts — 1,312 pass, 9 fail, 101 not tested — are every result cell in it.
Disclosure. Part of this engagement was compensated in tokens. No figures, and nothing further.
What we did not find. No document in the folder shows the dice game going live with real BNB, so this page does not describe a dice launch — that is a statement about our files, not about what BUSTA shipped. There is likewise no wind-down document: the record simply stops, with the team mid-decision about universal balances, chains and certification.
Everything above this line is in a file somebody can open. Nothing below it is. This is how we would run the same engagement today, with AI in the work — written as an opinion, because that is what it is.
Six companies building against one game and one database is a coordination problem, and coordination is where AI pays now: an agent watching every vendor’s deploys, the integration matrix run on every build instead of on a schedule, the load ceiling measured continuously rather than after it broke in public on 3 September. The 120-run test sheet that failed at step one because a wallet would not connect is the kind of smoke test that should never again be run by a person at a keyboard.
It would make the score harder to keep, not easier.
More vendors shipping more code faster is what AI actually delivers to a project like this one, and the job on this page was never writing the code — it was knowing the state of the thing across six companies who each believed their part was done. That job gets bigger. It is why we load test before the doors open, and it is why somebody has to own the integration nobody’s model owns.
Measure the ceiling before you sell tickets, and write the failure down while it is still embarrassing enough to fix. When six companies build one product, somebody has to own the truth of what is actually working. That was the job then and it is the job now. The assessment is the same job pointed at yours. Two days, no charge, answered in writing.
Let’s find outPrefer the rest of the record first? Every wave, same job. Or take the Guide: the six rules, with checklists. Free. No email required.