What is Shielder-SDK?

Simply speaking, Shielder-SDK is the developer-facing interface for Blanksquare's Shielder. It is currently provided as a TypeScript package and is meant to be integrated into EVM-compatible wallets or dApps to provide users with privacy based on shielding. If you want to jump straight into action and try creating an integration, head to Quickstart. Read on to learn what Shielder-SDK consists of.

There are two main features of Shielder-SDK that make integrating Shielder into a consumer app straightforward:

Downloading and Maintaining Shielded Account State

Similar to regular public blockchain accounts, access to an account in Shielder (called a shielded account) is represented by a keypair. The user holds a short secret in a specific format (roughly 256 bits of data) which allows them, at any time, to read their account details and download their history.

However, the way data is stored on-chain for shielded accounts is completely different from public accounts. No external observer can link any two actions of the same user. In particular, indexing the data should not be possible (and indeed, is not happening).

To retrieve account data, the user must run a data recovery algorithm, which—roughly—scans the chain to find all historical transactions created by that user, without leaking any information about them. By aggregating this transaction history, the user can reconstruct their account state. No external party, without access to the user's secret key, can learn anything about the account.

Shielder-SDK implements this data recovery algorithm, enabling account recovery from the seed (as the name suggests). This is also used during normal operation—for example, verifying that a previous transaction was confirmed on-chain.

Making Changes to the Account State

Obviously, a user who holds the keys to an account can spend assets from it (or deposit to it). In Shielder, each transaction must include a zero-knowledge proof—rather than a plaintext signature—proving that the user holds the appropriate key. This is the core idea behind shielding: performing actions without revealing who is performing them (see Protocol Details for more details).

Creating zk-proofs is known to be computationally intensive. Even though the zk-circuits used are relatively small and well-optimized, generating a proof still takes a nontrivial amount of time. This is where Shielder-SDK shines: it provides an extremely fast, wasm-based proving stack designed to run efficiently in the browser and on mobile. For most devices, the proofs finish computing within 1-2 seconds, even reaching subsecond times on certain hardware.

The main proving engine in Shielder-SDK is a multithreaded wasm prover that runs on the user's device. This is our recommended option for all integrations, especially in production, as it provides maximum security without compromise.

In addition to the client-side prover, Shielder-SDK also supports proving delegation via TEEs (Trusted Execution Environments). See TEE-based Proof Delegation for more details. The basic idea is as follows: instead of running the prover directly on the user’s device—which may be limited by performance or other constraints—the user can securely delegate proof computation to a remote server running inside a TEE. The TEE receives encrypted proof inputs, computes the proof, and returns the encrypted result. The plaintext values used in proof generation are never exposed outside the secure enclave and cannot be extracted by any external or internal adversary, even one with physical access to the TEE.