A service credential can prove that a request came from an allowed caller. It does not prove that this caller may move this amount, from this account, to this destination, right now. That distinction matters when a business service is compromised, whether its caller is an agent, a person or another service.
Public disclosures about the Binance incident prompted us to test that boundary. The result was not a victory lap. We found gaps in our own earlier composition, then changed where authorization and execution meet.
The incident inspired a question, not a reconstruction
In its initial October 29 disclosure, Binance described an investigation suggesting a path from a compromised DevOps engineer's laptop to a service container and unauthorized withdrawal transactions. It reported no evidence of a wallet private key leak. That initial account did not establish the complete attack chain.
We tested a narrower hypothesis: if an attacker holds a business-service credential, what still prevents an unauthorized payment? We also added concurrency, revocation races, direct write paths, lost responses and crashes. These are stress conditions, not confirmed causes of the incident. This is not a reconstruction of Binance's systems or a comparison with exchange infrastructure.
A gateway check was not enough
Our earlier composition checked requests upstream and committed ledger effects later. Concurrent requests could pass before the first payment was recorded. Revocation between check and commit did not reliably stop execution. A direct write path could skip the gateway altogether.
In the same comparison, a conventional, independent resource-side authorization check also worked. The lesson is not that only OSuite can enforce authorization. It is that an earlier approval cannot substitute for a check at the resource that commits the effect.
One transaction at the protected resource
The implemented Matoi controlled-ledger profile binds the payment reference, source account, destination, asset, network and exact amount. SDK and MCP paths connect the request to Studio review and the resource owner.
Required review happens before commitment. Inside the resource transaction, the profile rechecks current authority and approval, enforces business-payment uniqueness, consumes the permitted budget and records the ledger effect with a signed receipt. The full evidence view updates afterward. Refreshing that view does not send another payment.
This connects preparation, review, current authority and execution history without treating them as interchangeable. A receipt records a commit. It is not permission to execute again.
What happened under test
In the implemented profile, 100 concurrent requests for the same business payment produced exactly one commit. When a response was lost after a possible commit, recovery queried the original operation. The crash-recovery tests followed the same rule. An uncertain payment was not automatically resent.
Two finite load runs retained every scheduled request in the denominator:
| Measure | Earlier run | Final run |
|---|---|---|
| Eventually known committed | 1,800 / 1,800 | 1,800 / 1,800 |
| Known committed within 2 seconds | 1,760 / 1,800 | 1,711 / 1,800 |
| Within-2-second completion rate | 97.7778% | 95.0556% |
Both used 10 requests per second over 180 seconds, with 10 clients and batches. Timing includes preparation, queueing and two automated reviewer requests per batch, not human think time. These are synthetic ledger effects, not real bank or blockchain settlement. Completion of legitimate work is not an attack-detection rate.
Neither met the original 99.5% target. After reviewing the results, the owner accepted a 5-percentage-point tolerance, lowering the finite acceptance threshold to 94.5%. The final run meets that adjusted criterion, not the original one. This is not a statistical confidence interval, production qualification or an SLA.
Released code, deliberate adoption
The SDK 2.12.0 release is published. The controlled-ledger profile remains disabled pending deployment qualification. Existing customers are not automatically opted in.
All writes must pass through the protected resource boundary for its controls to apply. This does not protect an unrelated raw write path or put a remote bank inside the same transaction. It is a candidate for operators who control the ledger or payment service, can enforce mediation and can reconcile unresolved outcomes.
The nine-page technical case contains the diagrams, recovery states, both performance runs and sources. These October 31-November 5 engineering results are separate from the October 15 Matoi preprint. Raw experiment archives are not publicly released; this is an engineering report, not independent certification or customer-production telemetry.
If your agents or services can request consequential payments, discuss the execution boundary with us. Start with one question: what remains between a compromised service credential and a committed payment?
