What an engagement is
You rely on a feed, an index, or an attestation that somebody else produces. We measure it from primary sources instead of trusting it, and tell you where it disagrees with reality.
Your numbers are correct until the day they quietly are not. We look for the blind spots a system cannot see in itself: silent upstream failure, integrity gaps at boundaries, and evidence that rots before anyone needs it.
Enumeration from primary sources, integrity checks at every boundary, alerting on the producers you depend on, and evidence preserved so a finding outlives the log that backed it.
What you receive is a written record in which every finding is bound to a check you can run again yourself, plus the code where building it was the scope. Scope, timing and terms are agreed before anything starts, in conversation rather than from a page.
Case study · Stellar
A read-only measurement system over Soroban contract verification on Stellar mainnet. It enumerates the deployed contract population directly from the network's own history archive, attributes verification state across the independent verifiers, and has published a cross-verifier coverage snapshot with the method attached. It has surfaced two failures in the Stellar Development Foundation's own public pipelines, one of which was fixed the day after it was reported.
Found a 44-day silent failure in the Stellar Development Foundation’s contract-population workflow and reported it. SDF merged a fix the following day.
The scheduled job had failed on every run since 2026-07-08, 186 consecutive runs by the time it was reported on 2026-08-21, while everything downstream inherited a frozen view of the contract population.
contract-wasms issue 26 →Diagnosed a second pipeline failure to a specific dependency regression, with the failing build identified and remediation routes laid out.
Traced the compiler error in the public build log to a pinned lockfile, identified the dependency release that compiles cleanly, and set out three routes for the maintainers. Still open at the time of writing.
contract-verifications issue 1 →Published a cross-verifier coverage snapshot of the ecosystem, aggregates only, with the full method attached so anyone can recompute it.
The method matters more than the numbers. A coverage figure nobody can reproduce is an opinion.
coverage snapshot →Contributed a measured data point to the Stellar Development Foundation’s verification-registry API design discussion.
The measurement was offered while the design decision was still open.
stellar discussion 1945 →The capability behind the receipts
The contract population is read directly from the network’s own history archive, decoding ledger entries and applying bucket-list precedence, rather than depending on a single upstream feed that can fail silently.
Every downloaded bucket is checked against its own content hash, and the live bucket list is cross-checked against sibling archives at the same ledger before a run is trusted. A partial or disagreeing run is recorded and never published.
Published numbers carry the method that produced them, at the ledger they were taken at, so a coverage claim can be recomputed later instead of resting on a log that has aged out.
The upstream producers are measured, not assumed healthy. Both failures above were found that way: a population count that had stopped moving, then the size of the gap measured directly from the archive rather than from the feed that had frozen.
Protocol change is treated as a maintenance obligation rather than a surprise: the decoding path is kept current with mainnet, because a decoder that silently misreads a new ledger entry type produces numbers that look fine and are wrong.
Verification infrastructure is only as trustworthy as its ability to notice its own blind spots. Enumerate from primary sources, check integrity at every boundary, measure the producers you depend on, and publish numbers with the method that produced them. That pattern is portable to any ecosystem where being right is the product.
What gets published, and what does not
The receipts above are public for a specific reason. They describe shared infrastructure that nobody owns privately, and reporting a fault upstream is how that kind of infrastructure gets fixed. Every one of those reports went to the maintainers first.
Client work is a different thing entirely. Findings from a paid engagement belong to the client. Nothing from one is published, named, or referenced without written consent, and if a case study is ever wanted afterwards it is written together or not at all. If discretion is the requirement, say so at the start and it goes into the terms.
An indexer, an explorer, a verification pipeline, an attestation service, or any system whose output other people rely on: the failure above is the class we test for. Write and say what you run, and you will get back what we would check first and why. You get a real answer whether or not it goes any further.