Scope of work — Solana Mobile Security Grants application
Public Edition | September 2026
Seed Vault is the first item named in Solana Mobile's published bug bounty scope, and it is the component the entire Seeker security model rests on. It is also, as far as any public record shows, the least externally reviewed part of the stack.
I propose to audit it in three phases, beginning with the part nobody appears to have looked at: the compatibility test suite that certifies whether a Seed Vault implementation is correct.
I have already audited nine other Solana Mobile repositories and the full documentation corpus, unpaid, producing 232 findings. That work is the basis for this proposal and the evidence that it will produce results.
seed-vault-sdk does not contain Seed Vault. It contains the client SDK that wallets link against (~2,850 lines), a simulator (~7,465 lines), and a compatibility test suite (~8,169 lines). The privileged service that actually holds key material and enforces access lives in the Seeker system image and is not public.
That shape determines where the leverage is. The contract declares three permissions — a runtime permission for ordinary consumers, a signature permission automatically granted at install time to privileged apps, and an implementation permission — across nine distinct intent actions covering seed authorisation, transaction signing, message signing, public key retrieval, seed creation and seed import.
The certification suite is what decides whether an implementation honours those declarations. If the suite does not test a security property the contract requires, then any implementation can pass certification while violating it — including the one shipping on every Seeker today. A gap in the suite is therefore not one bug in one build; it is a permanently open door in the process that is supposed to close doors.
This is a systemic property, it is squarely inside the bug bounty scope's first-named component, and it is testable without privileged access. It is also the kind of finding I have a demonstrated record of producing: my strongest result to date came from asking whether a verification instrument's own inputs had ever been validated.
Build a matrix of every security property the contract declares — each permission against each action, each authorised and unauthorised caller state, each boundary condition on derivation paths and implementation limits — and check it against what the suite actually asserts. Every gap gets a controlled negative: the search that proves the property is untested, plus the positive control proving the search would have found it.
Deliverable: a per-property coverage matrix with a stated denominator, every gap evidenced at file and line, and for each gap an assessment of what a non-compliant implementation could do while still passing certification. Proposed test cases for each gap.
Full review of the ~2,850-line SDK that every Seed Vault-integrating wallet depends on: derivation path construction and validation, request and response marshalling, the public-key and signing response paths, and the permission assumptions the SDK makes on the caller's behalf.
Deliverable: findings at file and line with verbatim quotation, severity-rated, each absence claim carrying its control.
The suite can be run against the simulator. Any security-relevant behaviour where the real vault on Seeker hardware diverges from the simulator the suite validates against is, by definition, behaviour the certification process does not govern. I have Seeker hardware and can test both sides.
Deliverable: an enumerated divergence report, or a statement of no divergence found, stated against the same named denominator.
Every finding is verified by the auditor at the cited file and line before it is numbered — no finding is carried on a tool's or a reader's word. Every claim of absence ships with the control that proves the search could have found something, because a search that cannot find anything proves nothing. Counts are produced by script rather than by eye. False positives are discarded and the discard is disclosed.
That standard is not aspirational. In the most recent audit it caught one of my own candidate findings and killed it: an expression I had proposed as a fix turned out to predate my report by four months, so it proved nothing and was not cited.
Three prior audits of the Solana Mobile stack, June to September 2026, unpaid and unsolicited:
| Total findings | 232 |
|---|---|
| Repositories reviewed | 9, four of which had never had any external review |
| Documentation | full published corpus, 72 pages, plus 60 further source pages absent from the published index |
| Severity | 2 Critical, 60+ High |
The most recent pass covered the CLI, the templates repository, the agent-skills repository, the Kotlin RPC and Web3 libraries, the wallet registry and the new relay transport. It produced, among other things: a transaction builder that emits structurally wrong headers with a unit-test suite that encodes the wrong values as correct; a signing path that cannot serialise any multi-signature transaction; a newly shipped transport where the counterparty is unauthenticated on one side and any relay can terminate a session mid-signing; and two protocol error tables that disagree while each carries a comment instructing the reader to keep them synchronised.
Nine findings from the first report have been repaired in Solana Mobile's production documentation, including both items rated Critical. That is the practical measure of whether this work is useful.
Findings are held private. I can provide the full findings, in confidence, to anyone evaluating this application.
Requested: 1,000,000 SKR (approximately 20,000 USD at the time of application).
The figure is derived from the surface under review — roughly 18,500 lines across three modules, plus hardware testing — and from the depth of the deliverable, not from an hourly count. My method is heavily tooled and I work fast; that is a benefit to you rather than a discount, and it is why the delivery windows below are short.
| Phase | Scope | Delivery | Share |
|---|---|---|---|
| 1 — Certification-suite completeness | 3 permissions × 9 intent actions × caller states, plus derivation-path and implementation-limit boundaries, verified against 8,169 lines of test code | within 2 weeks of start | 400,000 SKR |
| 2 — Client SDK | Full review, 2,850 lines | within 2 weeks of Phase 1 | 250,000 SKR |
| 3 — Simulator vs device divergence | 7,465-line simulator against real Seeker hardware | within 3 weeks of Phase 2 | 350,000 SKR |
Phase 1 is self-contained and can be funded on its own at 400,000 SKR. If you would rather see output before committing to the rest, that is the natural unit — it is the highest-value phase and the one that determines whether the other two are worth doing at all. I would rather deliver a smaller piece well than negotiate the whole thing down.
Timeline: Phase 1 within two weeks of start, most likely inside one. All three phases within six weeks. Phases 2 and 3 can run in either order, and Phase 3 is the only one requiring hardware.
I would also be glad to continue on an ongoing basis. The three audits so far were one-off passes over a stack that changes weekly; the defect classes that recur do so precisely because nothing watches for them between releases.