Open source security-critical components of Holder self-custody wallet.
This repository contains the cryptographic, signing, and policy enforcement code that protects user funds. It is published so that anyone can audit the logic that handles keys, signs transactions, and enforces spending limits.
| Directory | Language | Purpose |
|---|---|---|
near/ |
Rust | NEAR smart contract: subkey registration, policy enforcement, MPC signing orchestration |
rust-wasm/ |
Rust → WASM | Client-side cryptography: key derivation, AES-256-GCM encryption, transaction building |
rust-signer-external/ |
Rust | External signer daemon: HSM integration, gRPC job polling, E2EE key delivery |
rust-signer/ |
Rust | Signing library: key unwrapping (RSA-OAEP + AES-GCM), ed25519 signing |
frontend-lib/ |
TypeScript | API key creation, subkey derivation, MPC address resolution, policy sync |
policy/ |
Rust + TypeScript | Spending limit enforcement, transaction templates, auto-approval rules |
This code has not been formally audited. Use at your own risk.
We welcome security review from the community. If you find a vulnerability, please report it responsibly to info@holder.bot
This code is verified in CI to match what runs in the production Holder deployment. To verify independently:
./verify.sh https://holder.botThe script hashes all files in this repo and compares the digest against what the live application reports at /api/verify/oss.
For a full architecture overview, please contact info@holder.bot
Key design principles:
- Keys never leave the browser (mnemonic held in WASM memory, encrypted at rest)
- All MPC-signed transactions flow through the NEAR subkey contract (policy enforcement at the contract level)
- Spending limits are enforced both server-side and on-chain (dual enforcement)
- External signer uses E2EE (ECDH-P256 + AES-256-GCM) between server and daemon
- Template-based EVM signing: the contract builds the transaction internally, the server cannot influence what gets signed
MIT