Deep security review for protocols that move real value.

1. 01 / Design review

   Resolve architectural risk before code hardens.

   Keel Formal reviews the protocol design, roles, upgrade paths, threat model, and economic assumptions before implementation details lock in the highest-cost risks.

   • Architecture and trust boundaries
   • Governance, roles, and upgrade paths
   • Economic risk and failure modes

2. 02 / Invariant suite

   Reusable fuzzing around core safety properties.

   Keel Formal builds invariant harnesses around solvency, accounting, rounding, edge states, and other core guarantees so fixes and future changes can be pressure-tested repeatedly.

   • Accounting and solvency invariants
   • Rounding and math edge cases
   • Reusable regression harnesses

3. 03 / Manual audit

   Senior researchers battle-test the system.

   Formal-methods researchers attack protocol logic, integrations, privileged flows, and economic assumptions with exploit-driven review and proof-of-concept depth.

   • Protocol logic and integrations
   • Privilege, oracle, and upgrade risk
   • Exploit narratives and reproduction paths

• Cloud posture IAM roles and trust policies, over-broad permissions, exposed storage, network reachability, and what a single stolen access key unlocks.
• Data at rest Database exposure, encryption and key custody, backup access, and whether a provider compromise reads your data in the clear.
• Secrets handling Where keys and tokens live, who and what can read them, rotation in practice, and what stays valid after an employee leaves.
• Build and deploy CI/CD runner permissions, dependency and artifact integrity, and whether a compromised pipeline can ship or sign on your behalf.
• Containers and clusters What is baked into your images, how workloads are isolated from each other, and whether a foothold in one pod reaches the rest of the cluster.
• Vendor consoles The SaaS accounts that can change production — source control, CDN, hosting, identity — who holds admin, and what a single one of those logins is worth.

Covers AWS, GCP, and Azure alongside the platforms built on top of them — GitHub, GitLab, Bitbucket, CI pipelines, Docker, Kubernetes, Terraform and other infrastructure-as-code, Cloudflare, Vercel, Okta, and other third-party services. Scope an entire account, or narrow it to the services that matter most, such as IAM and key management.

The breach was at a cloud database provider. Nothing onchain had to fail for the funds to move. Mixin · $200M↗ (read the incident write-up)

• Authentication Login and recovery flows, session lifetime and invalidation, token handling, and whether 2FA is enforced server-side on the actions that matter.
• Authorization Horizontal and vertical access control, object-level checks, and whether a request forged by one user reaches another user's resources.
• Value-moving flows Withdrawal, transfer, and settings changes — step ordering, replay, race conditions, and the confirmations guarding each.
• Client-side surface XSS and injection paths, CSRF protections, supply-chain exposure in the bundle, and what the frontend trusts from the API.
• Business logic Steps that can be skipped or reordered, workflows that can be run twice, and limits enforced in the interface but not behind it.
• Input handling Every parameter the application accepts, manipulated by hand and fuzzed at scale, to find injection, unsafe parsing, and what breaks on malformed input.

Keel Formal maps the application function by function — every form, background request, socket, and wallet interaction a user can reach, at every privilege level — and tests each one. Working from the source repository is strongly recommended: it is the only way to be certain nothing user-reachable was missed. Frontend-only and backend-only scopes are available.

Withdrawals were approved while two-factor authentication was bypassed — the control existed and did not hold. Crypto.com · $34M↗ (read the incident write-up)

• Key scoping Permission granularity, whether read-only is genuinely read-only, IP allowlisting, expiry, and revocation that takes effect immediately.
• Endpoint authorization Per-object checks, tenant isolation, mass-assignment, and endpoints that trust a parameter the client controls.
• Abuse resistance Rate limiting, quota enforcement, replay protection, and whether limits are applied per key or trivially evaded.
• Surface discovery Undocumented, deprecated, and staging endpoints still reachable in production, plus schema drift between them.
• Authentication JWT signing and validation, OAuth flows, session and refresh tokens, 2FA and email steps, and the account-recovery paths that bypass all of them.
• Automation triggers Endpoints that fire relayers, bots, or onchain transactions, and multi-step flows that can be interrupted, replayed, or driven out of order.

Covers REST, GraphQL, gRPC, and custom protocols. Every endpoint is treated as its own piece of functionality and tested at each privilege level, so the review scales with what the API actually does rather than how large it is. Existing documentation — a Swagger file or Postman collection — and credentials for each role make that faster and more complete.

Exchange API keys were stolen and traded. The keys stayed valid, and the trades they placed were authorized. 3Commas · $22M↗ (read the incident write-up)

• Permissions and manifest What the extension is allowed to reach, whether it needs all of it, and how far a malicious version could go using only the access users already granted.
• Content scripts What gets injected into every page, what a hostile site can reach through it, and how the extension stays separated from the page's own code.
• Internal messaging The routes between content script, background worker, and popup, and whether an untrusted page can send a message that lands on a privileged handler.
• Key and session storage Where keys, seeds, and tokens live, how they are encrypted at rest, and what stays readable while the wallet is unlocked.
• Signing flows What the user is actually shown before approving, and whether the payload that gets signed matches what was on screen.
• Supply chain Dependencies bundled into the shipped package, integrity of the build, and who is able to publish an update to the store.

A large part of an extension review is shared across every extension — manifest, permissions, storage, messaging — which makes the engagement predictable to plan. Source code is effectively required: a store download alone cannot confirm that every code path was reviewed.

One phished developer account was enough to publish a malicious update. It reached roughly 400,000 users before anyone noticed. Cyberhaven · 400k users↗ (read the incident write-up)

• Transaction construction What the SDK encodes and hands to the wallet, whether the payload matches the call the integrator asked for, and what an unexpected argument turns it into.
• Key and credential handling Signers, seeds, session tokens, and API keys the library touches — how long they stay in memory, what ends up in logs and telemetry, and what leaves the process at all.
• Response trust Data coming back from RPC nodes, relayers, price sources, and your own backend, and whether the SDK validates it before acting on it or passing it upward as fact.
• Published artifact What actually ships to the registry versus what is in the repository: build reproducibility, install and postinstall scripts, bundled and transitive dependencies, and what a consumer gets on a fresh install.
• Release control Who is able to publish a version, whether 2FA and provenance are enforced on the account and in CI, and how a malicious version gets pulled once it is out.
• Integration surface Unsafe defaults, footguns in the public API, and documented patterns that lead a correct-looking integration into an insecure one.

Covers TypeScript, JavaScript, Python, Rust, Go, and JVM client libraries — wallet and connect kits, transaction builders, bridge and swap routers, indexer clients, and API wrappers. EVM and Solana SDKs alike: on the Solana side that means @solana/web3.js and Anchor-generated clients, Rust and solana-py wrappers, and the instruction assembly, account resolution, and versioned-transaction paths where a client can quietly sign for the wrong account. Both the source repository and the published package are reviewed: the gap between the two is where supply-chain risk lives. Scope an entire SDK, or narrow it to the modules that build, sign, or hold anything.

The wallet was never broken. Three malicious versions of the library it publishes reached every dApp that had installed it. Ledger Connect Kit · $600K↗ (read the incident write-up)

• Threshold signing Share generation and storage, participant authentication, what a subset below threshold can force, and recovery after one node is compromised.
• Bot and keeper privileges What each automated key can call, whether the contract constrains it beyond trusting the caller, and the ceiling on a single run.
• Input integrity Oracle and price-feed handling, staleness and deviation limits, and what the automation does with an input it cannot validate.
• Failure behavior Whether a stuck, spammed, or partially failing job halts safely or keeps acting, and how an operator intervenes mid-incident.
• Schedulers and jobs Cron jobs, sequencers, risk engines, and oracle update scripts: what causes each run to fire, and what a mistimed, skipped, or duplicated run does onchain.
• Data pipelines Where the numbers come from before they are signed, how they are validated in transit, and whether a manipulated upstream source reaches the chain unchallenged.

These systems are custom by nature, so the review starts by establishing what the automation is supposed to guarantee and then works through the paths that break that guarantee: triggers, state transitions, key handling, retry logic, and the threat model of the automation-to-chain boundary. Source code access is required.

Offchain threshold signing was broken. The signing set produced valid signatures for transactions it should have refused. THORChain · $10M↗ (read the incident write-up)