Before an exchange holds anyone's money, someone should try to steal from it. That is what happened to KOB, the Kaspa order book that Ross Ku has spent months building. Kaspero Labs, a Kaspa tools studio with no stake in KOB, built 23,874 hostile transactions against its contracts and had the Kaspa network's own rules judge every one. It found no bug.
That result is real, and it is also narrower than it sounds. KOB has had no external security audit, and its author decided not to wait for one before launching. The test was not an audit, and both sides say so. This article explains what the attack run checked, what it found, what it left out, and what the people behind it say you should do with it.
KOB opened its testnet version on Thursday, where the tokens are test tokens with no value (launch post). It has not launched on mainnet, and no date has been given. Its own security page says the mainnet version will start as a "canary", an early release with a warning on every page, and tells users to use it "at your own risk, and only with funds you can afford to lose" (SECURITY.md).
The contract is the only guard
On a normal exchange, a company holds your coins and its servers decide who gets paid. KOB has no company in the middle. When you place an order, your tokens or KAS move into a coin on Kaspa that is locked by a small program, called a covenant. The covenant holds the price, the amount and your key. It allows only three things. Someone fills the order and pays you what the price says. You cancel it with your own signature. Or, after the order expires, anyone can send the funds back to you (FAQ).
Anyone can run the program that matches buyers with sellers, and keep the small price gap for doing it. There is no admin key, no pause button and no way for KOB to move, freeze or reprice an order.
That design removes the operator you would otherwise have to trust. It also means the covenant is the only thing standing between your order and everyone else. If one of its checks is missing, there is nobody to call. So the question that matters is simple. Can someone build a transaction that the covenant accepts but that pays them instead of you?
How you attack a contract on purpose
Kaspero Labs answered that question with kaspa-redteam, an open-source tool it released at the end of October (announcement). Its method is easy to picture. Take a transaction that is honest and valid. Change one thing that the contract should forbid. Then hand it to the real validation code from Rusty Kaspa, the main Kaspa node software, and see whether it would be accepted on chain (how it works).
The changes are the moves a thief would try. Send a payment to the attacker instead of the seller. Keep the first payment as it is and skim a later one. Cut a payment to a tenth of its value. Halve every payment and let the rest go to the miner as a fee. Spend two order coins in one transaction so that one payment counts for both. That last trick is not hypothetical. The tool's own example is a bug in a real mainnet contract, MinerDrip v1, where two coins shared one payment and the whole second coin could end up with a miner.
If the network's rules reject the changed transaction, the contract held. If they accept it, that is a possible finding, and the tool saves the exact transaction so anyone can replay it.
What was thrown at KOB
The test, dated 9 November, attacked KOB from three angles (report).
First, the contract code itself. The tool searched the order, router and token contracts for every path it could find and attacked them with 963 transactions. Consensus accepted none of them.
Second, 1,913 transactions from KOB's own test setup, covering every kind of action, from placing and matching orders to cancels, refunds and stop orders. Kaspero Labs was also given the keys of the buyer, the matcher and the helper programs, so it could attack from those seats too. That produced 21,402 hostile transactions.
Third, 114 real transactions that had already gone through on testnet. These were attacked as an outsider would, with no keys, in 1,509 more attempts.
The tool also checked that the contracts it tested were the same ones running on testnet, by comparing their fingerprints.
What got through, and why it isn't theft
Out of 23,874 attempts, consensus accepted 75. The report's verdict is "no bug found", and the reasons are spelled out one by one.
Another 907 accepted attempts are not counted as findings at all. In each of them, the only money that moved was a tip the order itself offers, such as the small fee for whoever sends back an expired order, or money that already belonged to the person signing.
Sixty of the 75 come from one feature. KOB includes a router that lets someone pay for something with any token, for example a website or an AI agent paying per request through x402, a way to charge for things over the web. When you pay that way, you sign a worst-case amount of extra KAS, called max_extra. Whoever executes the payment can keep up to that amount. The report confirms the contract never lets them take more than you signed for, and the maintainer confirmed this is by design.
Kaspero Labs still flagged it as something users should know. Because max_extra is a single cap, wallets should set it tight. A high default would simply hand executors extra money. KOB changed its default in response. For a payment filled by one sell order, the default is now 0.14 KAS on top of the small amount of KAS that travels with the token, down from 1 KAS.
The other 15 are open only because the tool could not read the token programs involved. Nine come from eight refunds and one closed order, where the leftover is exactly 0.028 KAS, the same as the tip the order offered. The tool could not confirm it, because those orders use a slightly different build made for an older token program that exists only on testnet. Ross explained which build they use in his notes on the report. The last six involve tokens from KRON, which the tool does not yet understand. That is work on the tool's side, not a question for KOB.
What the test did not cover
The report has a whole section on its own limits, and it is worth reading.
Some paths were never built from the code alone. Paths that need several orders in one transaction, such as stop orders that trigger on another order's fill, were left unexplored in the code search, 48 of 178 paths in total. They were attacked only through the real transactions from KOB's test setup.
The token-specific attacks ran only on the standard KCC-20 token build. Other token programs, including KRON's, got only the general attacks.
On testnet, actions that need the owner's signature, such as cancels, were tested only as an outsider would see them. Without the key, the only thing to check is whether a change breaks the signature.
The judge was consensus only. Mempool relay policy, such as minimum fees, was not applied.
There is a deeper limit too. A tool like this throws known attack shapes at a contract. It can show that those attacks fail. It cannot promise that nobody will invent a new one.
Kaspero Labs was open about its own role. It said it is "not affiliated with KOB" and "only ran the red team tests and did a bit of volunteer QA" (post).
No outside audit, by choice
The red team run sits on top of KOB's own security work. On 12 October, Ross decided not to commission an external audit before the canary launch. He did his own internal review instead, which the project labels "Not an independent audit" (internal review).
That review is long, and it found real problems. One of them would have let anyone drain the funds of whoever runs a matcher. Under fee pressure, the matcher helps pay the network fee for sending back expired orders, up to 0.05 KAS per order, and nothing limited the total. Someone could place many tiny orders timed to expire when fees were high and make the matcher pay again and again. It is now capped, at most 24 KAS a day with the default settings.
Follow-up rounds at the end of October found two high-severity bugs in the off-chain payment service, the program that tells a merchant whether a customer has paid. In both cases a merchant could have been told a payment arrived when it hadn't. One of them was introduced by an earlier fix. Both are marked fixed, and the review says that in those rounds "nothing was found that moves funds without a signature."
Ross wrote in his notes on the report that the order, router and token contracts have not changed since the test. Before a mainnet release, KOB's own checklist asks for five things. Supported wallets must pass a signing test. The token code must match the KCC-20 specification. No serious finding can be left open. A long testnet run must include incident and recovery drills. And there must be a legal review (release gates).
What a clean run is worth
A test like this does something an audit report often doesn't. It publishes every attack, every accepted transaction and every gap, in files anyone can replay. Kaspero Labs has used the same tool on its own contracts, and other Kaspa builders have started publishing their own runs. A reader no longer has to take "we tested it" on trust.
It is also exactly what it says, and no more. It is a strong check against known ways of robbing a contract, run by an outside tester, on the contracts that are deployed. It is not an outside audit of KOB, which does not exist.
Ross has been designing for the case where things go wrong anyway. Replying to a user on X, he said that in case of a breach, even if every KOB service stops, users can still place orders directly from the source code (reply). The contracts, and whatever they let through, are the part that does not stop.
