Security Best Practices
Guidelines for building secure applications on Specter.
Commitment secrets
- Never reuse secrets — each commitment must have unique
secret,nullifierSecret, andblindingvalues - Use cryptographically random values — generate secrets from
crypto.getRandomValues()orcrypto.randomBytes(), never from predictable sources - Store securely — commitment secrets are the only way to reveal committed tokens. If lost, tokens are permanently unrecoverable
- Never transmit in plaintext — if using the commitment relayer or proof relayer, understand that the operator can see your secrets. For maximum privacy, compute hashes and proofs client-side
Smart contract security
- Use ReentrancyGuard — all contracts interacting with the vault should be non-reentrant
- Check return values — verify that precompile calls return
true - Set gas limits — policy validation is capped at 100K gas, but your own contracts should use appropriate gas limits
- Follow CEI pattern — checks-effects-interactions to prevent reentrancy
Gas price
- Always set explicitly —
eth_gasPricemay return 0. Use 1 gwei minimum. - Don't rely on gas estimation — Cosmos EVM gas estimation may differ from Ethereum
Key management
- Separate testnet and mainnet keys — never use testnet keys for real funds
- Use hardware wallets for production deployments
- Rotate deployer keys after initial deployment
Privacy considerations
- Use fresh addresses for reveals — revealing to your commit address defeats the privacy purpose
- Wait before revealing — immediate reveals narrow the anonymity set
- Batch with other users — privacy improves with more commitments in the tree
- Don't link on-chain behavior — avoid patterns that correlate your commit and reveal addresses
Policy security
- Verify policy logic — policies are called via
staticcalland cannot modify state, but they can read any on-chain data - Test policy edge cases — expired timelocks, boundary conditions, zero values
- Keep gas usage low — policies exceeding 100K gas will fail silently