Current state
Status
Basis has completed an internal security review covering the cryptographic core, the announcement service, and the deployment tooling. An external audit has not yet been performed, and no funds should be committed that you cannot afford to lose until one is complete.
- Source reviewed
- ~2,400lines across 3 packages
- Automated tests passing
- 86
- Live chain integrations passing
- 3
- Issues found and resolved
- 6
- Issues with permanent regression coverage
- 6
- External audits completed
- 0
Evidence over assumption
How the review was conducted
Reading code finds fewer faults than attacking it. Every suspected issue was turned into a hypothesis and reproduced against running code before it was treated as real, and every fix shipped with a test that fails against the previous version. That last part is what makes a fix permanent rather than temporary.
Differential testing against the reference implementation.
The cryptographic core was run against the ecosystem's reference ERC-5564 implementation in both directions across 50 randomised trials. Payments the reference generated were derived and spent by Basis; payments Basis generated had their keys recovered by the reference. Divergence in either direction would mean Basis is not the standard it claims to be.
Differential testing between internal code paths.
Basis has two scanning implementations, one optimised for throughput. Both were run over identical corpora and checked for exact agreement with each other and with known ground truth. This class of test catches the failure where a faster path silently produces different answers.
Contract binding verified against deployed bytecode.
Rather than trusting internal hash computations, every function selector and event signature Basis relies on was confirmed present in the canonical deployed contract bytecode. All nine matched.
Signature payloads verified against an independent implementation.
Every message Basis asks a wallet to sign was checked against a separate typed-data implementation across sixteen chain and sequence combinations. A single character of divergence in a type definition would cause on-chain rejection.
Adversarial cryptographic testing.
Ten thousand randomised sender and recipient pairs confirmed that a recipient always derives the controlling key. A further thousand confirmed that an unrelated party never does. Forged tags, malformed curve points, and a stranger scanning an identical corpus were all tested; the stranger recovered nothing.
Hostile input testing.
Both the client and the service were tested against malformed, truncated, mislabelled, and empty responses, along with malformed requests of various shapes. Every case was rejected with a specific error rather than silently accepted, which matters because silent acceptance of incomplete data would present to a user as an empty balance.
Chain reorganisation simulation.
A reorganisation was forced on a live node. The service detected it, discarded exactly the affected records, matched chain state precisely, and a client holding a payment inside the affected range saw it correctly removed.
Resource and scaling measurement.
Pagination and scan throughput were measured under load to establish real performance characteristics rather than assumed ones.
Findings and fixes
What the review produced
Six issues were identified and resolved. Two were significant.
A data-availability fault in the announcement service.
A boundary condition existed under which some records could not be retrieved by any client. In reproduction this affected a substantial portion of a test dataset. The user-facing consequence would have been a received payment that never appeared, with no error displayed — a failure indistinguishable from having received nothing, and therefore among the most dangerous shapes a wallet fault can take. Resolved, verified at full retrievability, and covered by a regression test that fails against the previous implementation.
An unbounded workload in the client.
The synchronisation routine trusted a value supplied by the service without limit, allowing a misconfigured or hostile service to cause a client to attempt an unbounded download. On mobile this represents a data and battery cost imposed without consent. Resolved with a limit enforced before any download begins, verified by a test asserting that no requests are issued when the advertised workload is implausible.
MINOR / 04
The remaining four were minor: unused code in tooling, an obscured comparison routine rewritten for legibility after being verified correct, request rate limiting formally assigned to the reverse proxy layer, and a data-access pattern measured as adequate at current scale with a documented replacement threshold.
Full technical detail for all six will be published alongside the source code, where the findings can be independently checked rather than taken on faith.
Accountable claims
Properties verified
These are the claims Basis holds itself accountable for, with what was done to confirm each.
The service cannot identify which announcements belong to you.
No endpoint accepts a key, an address, or any user identifier. This is enforced by the shape of the interface rather than by policy, and is asserted by a test requiring that identifier-shaped routes be rejected.
Scanning code cannot spend.
Identifying your payments requires your viewing key and the public half of your spending key only. This was verified three ways, including confirmation that a scanning context structurally rejects a private key supplied where a public one belongs. Compromise of any scanning component cannot move funds.
Funds are never pooled.
Every address derives from your own keys and is controlled only by you. There is no commingling and no dependence on other users' behaviour.
No lock-in.
Bidirectional compatibility with the reference implementation is verified. Funds remain recoverable with independent tooling regardless of what happens to Basis.
Account derivation is permanently stable.
Keys derive from a fixed signed message. Altering that message by a single character would re-derive every user's keys and permanently sever access to their funds. The resulting value is pinned to fixed constants in the test suite, so any such change fails automated testing rather than reaching production.