Resources
Security Model
Security assumptions, audit status, known limitations, and responsible disclosure for Permissionless Technologies SDKs.
Tech Preview
All Permissionless Technologies SDKs are currently in tech preview on testnets. None have been security audited. Do not use with real funds or in production.
Security Model
Current Status
| Component | Network | Audit | Status |
|---|---|---|---|
| UPP Contracts | Sepolia | None | Tech Preview |
| UPP SDK | npm (private) | None | Alpha |
| UPC Contracts | Sepolia | None | Tech Preview |
| UPC SDK | npm | None | Alpha |
| UPD Contracts | Sepolia | None | Tech Preview |
| UPD SDK | npm (private) | None | Alpha |
Cryptographic Assumptions
UPP (SNARK mode)
| Assumption | Primitive | Impact if Broken |
|---|---|---|
| Discrete log hard | BabyJubJub | Spending keys compromised |
| Collision resistance | Poseidon | Note forgery |
| Proof soundness | Groth16/BN254 | Invalid transactions accepted |
| Encryption security | AES-256-GCM | Note contents exposed |
| Trusted setup integrity | Powers of Tau | Proof forgery (undetectable) |
UPP (STARK mode)
| Assumption | Primitive | Impact if Broken |
|---|---|---|
| Collision resistance | Keccak-256 | Proof forgery |
| Hash preimage resistance | Keccak-256 | Key extraction |
The STARK mode has no trusted setup requirement and is secure against quantum computers (see Post-Quantum Analysis).
UPC
| Assumption | Primitive | Impact if Broken |
|---|---|---|
| Discrete log hard | BLS12-381 | Proof forgery |
| Collision resistance | Poseidon-BLS12-381 | Tree manipulation |
| Universal setup integrity | Powers of Tau | Proof forgery |
UPD
| Assumption | Primitive | Impact if Broken |
|---|---|---|
| Oracle accuracy | Chainlink + Uniswap V3 | Incorrect mint/burn price |
| stETH peg | Lido | Collateral devaluation |
| Contract correctness | Solidity 0.8.29 | Fund loss |
Trust Assumptions
| Component | Trust Required | What Happens Without It |
|---|---|---|
| Smart contracts | Code correctness | Fund safety |
| ASP operators | Honest list maintenance | Compliance accuracy |
| Price oracle | Accurate price feed | Incorrect UPD valuation |
| Frontend | No key logging | Key exposure |
What We Don't Trust
- Observers: Cannot see transaction details (ZK proofs hide contents)
- Miners/validators: Cannot censor specific users by identity
- Other pool users: Cannot steal or forge notes
Known Limitations
UPP Privacy Limitations
- Metadata leakage: Transaction timing, gas costs, and shield/unshield amounts are visible
- Anonymity set: Privacy improves with more users — small pools offer less privacy
- Timing analysis: Quick shield→unshield cycles may be linkable
UPP Functional Limitations
- Proof generation time: 10-30 seconds per SNARK proof (browser WASM)
- Scanning time: Must scan the entire event history to find your notes
- No ETH support: ETH needs ERC20 wrapping first
UPC Limitations
- Root TTL: Proofs against expired roots are rejected — ASPs must publish regularly
- No revocation within TTL: Once a root is published, it's valid for its entire TTL
- ASP quality: UPC verifies proof validity, not the quality of an ASP's compliance checks
UPD Limitations
- Oracle dependency: Incorrect price feed leads to incorrect mint/burn ratios
- stETH depeg risk: Severe stETH devaluation could undercollateralize the system
- sUPD liquidity risk: Unstaking may be blocked at 100% collateral utilization
Audit Plan
Planned Audits (Before Mainnet)
| Scope | Target Auditors | Timeline |
|---|---|---|
| UPP smart contracts | TBD | Before mainnet |
| UPP ZK circuits | TBD | Before mainnet |
| UPC smart contracts | TBD | Before mainnet |
| UPD smart contracts | TBD | Before mainnet |
| Cryptographic review | TBD | Before mainnet |
Previous Reviews
None — tech preview stage.
Responsible Disclosure
If you discover a security vulnerability:
- Do not publicly disclose until a fix is available
- Do not exploit the vulnerability
- Contact us via Telegram or email
- Include detailed reproduction steps and impact assessment
- Allow reasonable time for investigation and fix
We will acknowledge valid reports and credit researchers in our security advisories.
Operational Security for Integrators
When integrating UPP:
- Always use the latest SDK version
- Validate all user inputs before passing to SDK
- Handle proof generation failures gracefully
- Never log or persist viewing keys or spending keys
- Test on testnet before mainnet deployment
- Monitor for unusual withdrawal patterns
When operating a UPC ASP:
- Use a production-grade database (not in-memory storage)
- Monitor for unexpected membership changes
- Set alerts for root publish failures
- Backup your operator key
- Rate-limit the proof generation API
When integrating UPD:
- Verify the oracle address is the canonical deployment
- Check collateralization ratio before large mints
- Implement slippage protection (minUpdOut, minStEthOut)
- Monitor the system health endpoint
Disclaimer
UPP, UPC, and UPD are experimental software. The developers make no warranty of any kind. Users and integrators are responsible for assessing risks appropriate to their use case. Nothing in this documentation constitutes financial, legal, or regulatory advice.