Provable SDK: SnarkVM in the browser through WebAssembly

Low level protocol objects, deliberately

The Provable SDK provides low level tools for building zero-knowledge applications on the Aleo blockchain. The mechanism it uses is the interesting part. It re-exports core protocol objects from SnarkVM via wasm with TypeScript and JavaScript bindings, so developers who need low level control can build wallets, servers and CLI tools entirely in JS/TS.

The phrase re-exports matters. This is not a reimplementation of the protocol in JavaScript, which would be a large and risky undertaking, nor is it a thin HTTP wrapper over a node. The actual protocol objects come from SnarkVM, the Rust implementation, and reach JavaScript across a WebAssembly boundary. That gives you the type shapes and the primitives of the real implementation rather than an approximation, at the cost of working with a wasm module and its memory model.

The consequence for a project is architectural. If you are writing a wallet, you need the account objects and the key derivation chain to be exactly right, and a JavaScript reimplementation would be a liability. If you are writing a script that submits a transaction, you need the program execution and the proof-related types to match what the network expects. Both are cases where the wasm route is the right one.

The project positions itself accordingly. The readme says the SDK is divided into three TypeScript and JavaScript packages, and that the official SDK package provides low-level Aleo protocol utilities and JavaScript and TypeScript helpers. The usage documentation for it is in the SDK package's own readme rather than in the top-level file.

The licence is GPL-3.0, with a LICENSE.md at the repository root, which is worth noting early for a JavaScript package, since a copyleft licence in a client library is a different situation from one in an application.

Veil is the layer most people should start with

The readme is unusually direct about which layer you want, and it is not the one the repository is named after.

Builders looking for more developer friendly interfaces should choose Veil, a Viem like toolkit for building browser and mobile dapps or server-side applications, scripts and AI agents. The explanation of what Veil provides is spelled out in terms of a library many JavaScript developers already know: Veil provides a Viem like interface that has familiar concepts from Viem such as wallet and public clients, actions, transport configurations, and client and action composability.

That is a well-chosen analogy. A Viem user already knows the shape of a typed client with actions, transports and a public client, so the mental transfer is small, and the analogy makes it possible to describe a zero-knowledge toolkit in terms a JavaScript developer can reason about without knowing anything about SnarkVM.

The package table lists six of the Veil packages. There is veil-core for Viem-like clients, actions, transports and types, veil-aleo-sdk as an adapter for the Provable SDK for building server side apps, scripts, wallets and AI agents, and veil-aleo-wallet-adapter to build browser and mobile dapps with the same interface. There is aleo-bridge-sdk to bridge assets into and out of Aleo, veil-leo to build and deploy Leo programs from JavaScript or TypeScript, and veil-aleo-devnode for local nodes, block mining and snapshots for Foundry-like test harnesses.

The devnode package is the one that tells you the most about how the team expects people to work. A local node with block mining and snapshots, in a Foundry-like shape, means you can develop and test against a chain you control rather than against a live network, which for a zero-knowledge system is the difference between a fast loop and a slow one.

So the practical guidance is straightforward. Start with Veil, and drop down to the Provable SDK when you need something Veil does not expose.

Three packages, one workspace, Rust and TypeScript in the same build

The repository layout explains the engineering, and it is a mixed language workspace rather than a JavaScript package with a Rust subdirectory.

The three published packages are the SDK itself, published as @provablehq/sdk, which is the official Provable SDK providing low-level Aleo protocol utilities and JavaScript and TypeScript helpers. The second is create-leo-app, published as create-leo-app, which provides runnable SDK examples for Node.js and frameworks such as React. The third is Aleo Wasm, published as @provablehq/wasm, and it is the piece that makes the other two possible.

Aleo Wasm is a Rust crate that compiles the Aleo source code responsible for creating and executing zero-knowledge programs into WebAssembly. When compiled with wasm-pack, JavaScript bindings are generated for the WebAssembly, allowing Aleo zero-knowledge programs to be used in the browser and in Node.js. The package readme has instructions for compiling that crate and using it in JavaScript projects for anyone who wants to build from source.

The root package.json is a Yarn workspace named sdk-root, marked private, with the workspaces list covering sdk, wasm, website, create-leo-app and the e2e directory, and the package manager pinned to yarn 4.14.1. The build scripts make the dependency order explicit:

    "build:wasm": "rustup show active-toolchain && cd wasm && yarn build",
    "build:sdk": "cd sdk && yarn build",
    "build:all": "yarn build:wasm && yarn build:sdk && yarn build:create-leo-app",

The wasm build comes first, because the SDK bindings are generated from it, and the debug variants set BUILD_DEBUG=1. There is a separate script for the SDK documentation, a sh script under scripts/, and a change-version script written in JavaScript that runs a script from the same directory.

The deployment scripts publish each package to npm in turn, and the wasm one runs from the wasm directory, the sdk from the sdk directory, and create-leo-app from its own directory, which keeps each package's own manifest in charge of what it ships.

The repository also has a rust-toolchain.toml, which pins the Rust side, a .rusty-hook.toml, a .prettierrc.json for formatting, an .agents/ and .claude/ directory, an AGENTS.md, a llms.txt, a website/ directory for the docs site, and an e2e/ directory.

What the feature list says about the protocol coverage

The core features section in the readme is a table, and the first two rows are the most informative about what the SDK actually does.

Account management covers creating, importing and encrypting and decrypting Aleo accounts, with the full key derivation chain named: PrivateKey, ViewKey, ComputeKey, Address and GraphKey. It also describes password-based private key encryption with key bytes zeroized for secure memory handling. Zeroization is the detail that matters to a careful reader. It means the key bytes are overwritten rather than left for the garbage collector, which is the right thing to do with private keys, and the fact that it is called out in the feature list rather than buried in the source is a sign of how the project positions itself.

Program execution is the second row, and the text is cut off in the available excerpt at the point where it describes executing arbitrary Aleo programs locally or on-chain. The heading of the section itself is enough to establish the shape of the surface area: the SDK is not only a signing library, it also runs programs.

The features section is organised under headings that also tell you what the SDK covers beyond the protocol core. There is an Aleo RPC section, an AI agent support section, a networks section listing the networks supported, and a runtimes section covering the JavaScript runtimes and frameworks the SDK works with. The roadmap section points at the repository milestones, which is where the project tracks what is planned rather than what is shipped.

The one thing the readme does not spell out in the visible text is the exact runtime and network matrix, so anyone with a specific target environment should check those two sections before committing. The contributors badge says 23, and the links at the top point to the Leo language developer documentation and the Aleo Discord server, so both the language reference and the community are the places to look for detail the readme leaves out.

Editorial conclusion

The Provable SDK suits a JavaScript or TypeScript developer who needs the Aleo protocol objects themselves rather than a friendly wrapper, particularly for a wallet, a server or a CLI tool, and who is prepared to work with a WebAssembly boundary. It does not suit a developer who wants a pleasant API, because the readme itself points you to Veil for that. Before adopting it, read the SDK README for the package you need, check that the Rust toolchain and wasm-pack are available if you intend to build the wasm crate yourself, and note the licensing, which is GPL-3.0 rather than the permissive licences most JavaScript packages carry.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. ProvableHQ/sdk on GitHub
4. README
5. Releases