Skip to main content
Voltaire takes a practical approach to external dependencies. We reject the “zero dependencies” dogma common in crypto projects—not because dependencies are always good, but because the right dependencies provide audited security and optimized performance. Every dependency in Voltaire earned its place through clear criteria: security audits, performance characteristics, specialization, or ecosystem benefits.

​
JavaScript Runtime Dependencies

​
Cryptography (@noble/@scure ecosystem)

Why: Paul Miller’s @noble ecosystem is the gold standard for JavaScript cryptography. These libraries are:
  • Audited by multiple security firms (Cure53, Trail of Bits)
  • Constant-time implementations that resist timing attacks
  • Actively maintained with rapid security response
  • Used by major wallets and infrastructure projects
Replicating this level of security and optimization would require significant cryptographic expertise and ongoing security investment.

​
ENS Support

Why: This is the authoritative implementation of ENSIP-15, the ENS name normalization standard. ENS normalization involves complex Unicode handling—script detection, confusable character prevention, and punycode encoding. The author (raffy.eth) wrote the specification itself.

​
ABI Types

Why: ABIType provides TypeScript type inference from ABI definitions. It includes extensive type-level optimizations that enable features like:
  • Inferring function argument/return types from ABI
  • Type-safe contract interactions without runtime overhead
  • Compatibility with the broader Ethereum TypeScript ecosystem
ABIType’s type-level optimizations are battle-tested across the Ethereum TypeScript ecosystem.

​
Ethereum Utilities

Why: ox provides well-tested implementations of Ethereum primitives. By sharing this dependency with other Ethereum libraries (like viem), we amortize bundle costs—users who already have ox in their bundle pay zero additional cost for Voltaire’s usage.

​
Chain Metadata

Why: Chain metadata (chain IDs, RPC endpoints, block explorers) changes frequently. Using a shared source keeps you in sync with the ecosystem.

​
ABI Detection

Why: WhatsABI infers contract ABIs from bytecode, even for unverified contracts. This enables interaction with any deployed contract without needing verified source code.

​
Optional Integration

Why: Effect.ts provides typed error handling and validation schemas. This is an optional peer dependency—only imported when users explicitly use the /effect subpath exports. Does not affect bundle size for users who don’t use Effect.

​
Hardware Wallets (lazy-loaded)

Why: These are the official SDKs from Ledger and Trezor. Hardware wallet integration requires device-specific protocols that only the manufacturers provide. These dependencies are dynamically imported—they’re only loaded when users explicitly use hardware wallet features.

​
Native Dependencies (Zig/WASM builds)

For native and WASM builds, Voltaire uses battle-tested C and Rust libraries compiled into static binaries.

​
Rust (compiled into libcrypto_wrappers.a)

Why: The arkworks ecosystem provides audited, production-proven implementations of pairing-friendly curves used in Ethereum (BN254 for EIP-196/197, BLS12-381 for EIP-2537). These curves require complex mathematical operations that are security-critical and performance-sensitive. The dual Keccak implementation uses assembly optimization for native builds (maximum performance) and pure Rust for WASM builds (portability).

​
C Libraries

Why: These are reference implementations used across the Ethereum ecosystem:
  • libwally-core is from Blockstream, used in production Bitcoin/Liquid wallets
  • c-kzg-4844 is the official Ethereum Foundation implementation for blob transactions

​
What Ships to End Users

​
Dependency Philosophy

We evaluate dependencies on these criteria:
  1. Security: Is it audited? Who uses it in production? How quickly are vulnerabilities addressed?
  2. Maintenance: Is it actively maintained? What’s the bus factor?
  3. Bundle impact: Is it tree-shakeable? Can we lazy-load it?
  4. Specialization: Does the author have domain expertise users benefit from?
  5. Ecosystem alignment: Does using it benefit users who also use related libraries?
The “zero dependencies” approach sounds good but often leads to:
  • Unaudited reimplementations of security-critical code
  • Slower security patches when vulnerabilities are discovered
  • Subtle bugs from underspecified edge cases
Voltaire provides both native Zig crypto implementations and bindings to audited libraries (noble, arkworks). By default, only audited options are exposed. Our Zig implementations are available for users who want maximum performance. For supply chain security, we recommend building from source—a more robust defense than zero dependencies, since you verify the exact code running in your application.