SDK security audits

• 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, including 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)