Design Philosophy
Why we build SDKs not monoliths, and why privacy and compliance are not opposites.
Design Philosophy
The SDK Approach
Every product we build is an SDK — independently installable, tree-shakeable, version-controlled.
Why Not a Monolith?
A monolithic privacy protocol forces everyone into one UX, one compliance model, one frontend, one chain. Three problems emerge:
1. Adoption ceiling. A monolith forces everyone into your UI. An SDK integrates into any wallet, any DEX, any chain. Wallets add a "Shield" button next to "Send." DEXes offer private swaps. Bridges shield on source, unshield on destination.
2. Audit scope. A monolith means auditing everything even if you only use 10%. SDKs let auditors focus on the specific modules a protocol uses. The audit result is portable across every integrator.
3. Composability. A privacy pool that only works with one stablecoin isn't infrastructure — it's a product. A privacy SDK that any stablecoin can integrate is infrastructure.
What an SDK Enables
| Integrator | What They Build |
|---|---|
| Wallets | Privacy as a feature (shield button next to send) |
| DEXes | Private swaps using the same shared pool |
| Bridges | Shield on source chain, unshield on destination |
| Stablecoin issuers | Add privacy without modifying token contracts |
| Compliance providers | ASP-as-a-service to multiple protocols |
| Protocol developers | Drop-in compliance via IAttestationVerifier |
Privacy and Compliance Are Not Opposites
The dominant narrative in crypto treats privacy and compliance as a zero-sum tradeoff. We reject this framing.
The Banking Analogy
Your bank verifies your identity once. Not every merchant you transact with. The bank is a trusted intermediary that provides compliance guarantees to the financial system.
The UPC model replaces trust with cryptography:
- For regulators: Every withdrawal goes through an ASP. The ASP operator performs the compliance check. The proof is on-chain and verifiable.
- For users: Identity is never revealed on-chain. The ZK proof says "someone in the approved set did this" — never who.
- For institutions: Operate your own ASP with your own compliance rules. No permission required.
The Composable Compliance Stack
The ASP model scales because compliance providers can specialize:
| ASP Type | Operated By | Criteria |
|---|---|---|
| OFAC sanctions screen | Chainalysis, TRM Labs | Not on OFAC list |
| KYC verification | Exchanges, compliance firms | Passed identity verification |
| Accredited investor | Broker-dealers | Meets SEC definition |
| Institutional | Prime brokers | Verified institutional entity |
| Sanctions (government) | FinCEN, OFAC | National sanctions list |
Users choose which ASPs they interact with. Recipients choose which ASPs they accept. No central authority controls the list.
Post-Quantum by Design
The UPP STARK vault is not a future upgrade — it is a present feature.
SNARKs and STARKs run side-by-side. They are not competing alternatives or a migration path. They serve different threat models:
- SNARKs (Groth16/BN254): Everyday transfers. ~200K gas, ~200B proofs. Post-quantum decryption risk is acceptable for routine transfers where later exposure doesn't matter.
- STARKs (Circle STARK/M31): Post-quantum secure vault. ~20M gas, ~5KB proofs. High-value, long-term storage where future decryption must never happen.
Harvest Now, Decrypt Later
State-level adversaries are already storing on-chain data for future decryption. Every elliptic-curve public key published today is a permanent record. The STARK vault provides protection against this threat — today.
Why Native Solidity STARK Verification?
Rather than waiting for EVM precompiles, we built a native Circle STARK verifier in Solidity — the first of its kind on Ethereum L1. Built on Stwo with a custom Keccak-256 channel (replacing Blake2s for a ~100x gas reduction in hash operations).
Standards First
We prefer existing standards over custom implementations where possible:
- Stealth addresses: Build on ERC-6538 patterns (stealth meta-address registry)
- Token interface: Standard ERC20 + EIP-2612 permit — no custom token standards
- Proof systems: PLONK with Perpetual Powers of Tau (no per-circuit ceremony)
- On-chain proofs: EIP-2537 BLS12-381 precompiles (live since Pectra, May 2025)
- Ethereum clients: viem/wagmi, not ethers.js
When we deviate from a standard, we document why — typically different cryptographic requirements (different hash functions, different security levels, post-quantum considerations).
Reusability as First Principle
Every primitive we build is designed to be extracted. The UPH (Universal Private Helpers) package is the formalization of this principle: every cryptographic primitive that has been battle-tested across UPP and UPC gets audited once and published for anyone to use.
- One audit, many users. M31 field arithmetic audited once, reused in every STARK project.
- Consistent quality. Same Merkle tree implementation across every protocol.
- Faster development.
npm install @permissionless-technologies/uphinstead of writing 3,000 lines of Solidity.
This is what OpenZeppelin did for contract patterns. We do it for cryptographic primitives.
Composing the Stack
How UPD, UPP, UPC, UPH, and UPR fit together — and how to assemble them into a complete privacy-first financial application.
Universal Private Dollar
Self-sovereign, non-freezable stablecoin pegged 1:1 to USD. No issuer, no custodian, no blacklist — you mint directly against the protocol using stETH collateral.