How Monokulo is tested
Monokulo handles other people’s money, so it gets tested hard. Every change runs more than 2,600 automatic tests. Every night, two kinds of robot tester invent thousands of strange situations and check that no payment goes missing. This page rebuilds itself from those runs. Open any section to see the details.
4176f6b on 18 Oct 2026·Nightly properties 23 Oct 2026·Fuzzing 23 Oct 2026·Live network 22 Oct 2026Fuzzing tests
A fuzzer throws strange inputs at the code, keeps the ones that reach code it hasn’t seen before, and mutates those to go further. It isn’t only looking for crashes. Every target is wrapped in checks: the two big ones, portfolio and history, play a whole run of payments through the real engine and compare every balance with the money model, and the smaller ones each check one specific rule. If any check fails, the fuzzer counts it as a crash and saves the input that caused it.
- Targets
- 10 passed
- Executions
- 261 M
- Corpus inputs
- 54,358
- New last night
- 439
| Target | Time | Executions | Corpus | New | Code edges |
|---|---|---|---|---|---|
| portfolioPlays out payments to several wallets at once and checks every wallet’s money against the model insufficient-exploration | 39 min | 3,726 | 2,721 | 0 | 21,632 +0 |
| historyPlays out whole chain histories through the real scanner and database and checks the money against the model | 34 min | 6,723 | 3,978 | 38 | 16,518 +22 |
| inputsFeeds junk text to the CPU-list setting and checks the result is sorted, has no repeats, and reads back the same | 11 min | 1,855,128 | 36,164 | 253 | 6,584 +0 |
| mempoolChecks the cache of unconfirmed payments: who owns each entry, what gets thrown out, and that it stays within its memory budget | 9 min | 74,837 | 6,746 | 88 | 2,476 +15 |
| notificationsChecks the engine is woken when there’s work and never waits longer than its time limits | 16 min | 2,712,552 | 1,390 | 1 | 1,115 +0 |
| statusChecks each order’s status (paid, underpaid, expired and so on) follows correctly from the payments seen | 11 min | 5,094,775 | 1,161 | 6 | 357 +0 |
| dns_message | 9 min | 4,205,697 | 1,848 | 53 | 290 +0 |
| schedulerChecks scan scheduling: retries, waits and node time-outs all stay within their bounds | 9 min | 27,214,721 | 74 | 0 | 142 +0 |
| queueChecks work handed to the engine’s workers is dispatched correctly, even when queues fill up or close | 15 min | 30,588,449 | 267 | 0 | 112 +0 |
| resourcesChecks the scan budgets worked out from network speed stay inside their limits | 9 min | 189,398,723 | 9 | 0 | 62 +0 |
What the inputs reached
The targets that play out histories count the situations they land in, like the property tests. Open one to see last night’s.
portfolio3,726histories
Chain events generated
Each history is a random list of these steps. Sometimes a step can’t happen (there’s no waiting payment to drop, say), so it’s skipped. At the end the model works out what every wallet should have, and the engine has to match.
815 skipped “mine” steps had nothing to mine and extended the chain with an empty block instead.
Faults injected
Things broken on purpose in the middle of a history. After each one the engine has to report the problem, keep every balance right, and carry on.
Money rules checked
Results the model insists on. One mismatch fails the whole run.
Setups
How each history started: how many wallets and transactions, which way of scanning, and whether it used real recorded mainnet transactions.