Glossary
Key terms and definitions across the Permissionless Technologies product suite.
Glossary
Products
UPD (Universal Private Dollar)
A non-freezable, decentralized stablecoin pegged 1:1 to USD. Backed by overcollateralized stETH. No admin keys, no blacklist. Part of the @permissionless-technologies/upd-sdk package.
UPP (Universal Private Pool)
A privacy layer enabling private transactions for any ERC20 token through a shared Merkle tree with ZK proofs. Part of the @permissionless-technologies/upp-sdk package.
UPC (Universal Private Compliance)
A standalone ZK compliance framework for ASPs (Association Set Providers). Provides pluggable identity verification without revealing user identity. Part of the @permissionless-technologies/upc-sdk package.
UPH (Universal Private Helpers)
A library of audited cryptographic primitives extracted from UPP and UPC. Planned for future release as @permissionless-technologies/uph.
sUPD (Staked UPD)
A yield-bearing share token representing staked UPD. Increases in exchange rate as yield accrues. Target ~8-10% APY.
Privacy System (UPP)
Shield
Deposit public ERC20 tokens into the UPP privacy pool. Creates an encrypted note. The amount is visible on-chain; subsequent transactions are private.
Unshield / Withdraw
Exit the UPP privacy pool back to a public address. Requires a compliance proof (or ragequit path). The recipient address and amount are revealed.
Note
A private unit of value in UPP. Similar to a Bitcoin UTXO. Each note represents a specific amount, token, and origin. Notes are consumed when spent and new notes are created.
Commitment
A cryptographic hash of a note's contents: Poseidon(amount, blinding, origin, token). Stored on-chain. Hides note details while enabling ZK membership proofs.
Nullifier
A unique identifier computed when a note is spent: Poseidon(commitment, spendingKey, leafIndex). Published on-chain to prevent double-spending.
Blinding Factor
A random value included in a note's commitment that ensures two notes with the same amount/origin/token have different commitments.
Transfer
A private payment within the UPP pool. Consumes one note and creates two new notes (recipient + change).
Merge
Combines two notes into one. The merger becomes the new origin. The only way to change origin.
Keys (UPP)
Spending Key
A private key that authorizes spending notes. Required to produce nullifiers.
Viewing Key
A private key that allows decrypting and reading notes without the ability to spend them. Share with auditors for selective disclosure.
Master Viewing Key (MVK)
The root viewing key from which all per-note viewing keys are derived. Can decrypt all notes for an account.
Decryption Viewing Key (DVK)
A per-note viewing key derived from the MVK using the note's ephemeral public key. Can decrypt only that specific note.
Stealth Address
A unique, unlinkable one-time address for receiving payments. Derived by the sender from the recipient's stealth meta-address.
Stealth Meta-Address
The public identifier shared by a recipient, containing their spending and viewing public keys. Encoded in bech32m format with 0zk prefix.
Compliance (UPC / ASP)
ASP (Association Set Provider)
An entity that maintains a Merkle tree of approved identities and publishes the root on-chain. Users prove membership via ZK proof without revealing their specific identity.
AttestationHub
The on-chain registry of all registered ASPs for a given chain. Protocols query this to verify compliance proofs.
IAttestationVerifier
The Solidity interface that any attestation backend implements. Allows plugging in Semaphore, WorldID, zkPass, or custom verifiers.
IASPProvider
The TypeScript interface for ASP storage backends. Implementations: MemoryProvider, LocalStorageProvider, RESTProvider.
Origin
The address that originally deposited funds into the UPP pool. Preserved through transfers. Only changed by merge. Used for compliance checking at withdrawal.
Ragequit
A special withdrawal path that bypasses ASP checks — allows the original depositor (origin == recipient) to always recover their own funds.
Root History
A rolling window of recent ASP Merkle roots stored on-chain. Allows users to prove against slightly-old roots within the TTL.
Root TTL (Time-to-Live)
The maximum age of an ASP root. Proofs generated against expired roots are rejected on-chain.
Cryptography
BabyJubJub
An elliptic curve optimized for ZK circuits (~1K constraints per multiplication, vs ~50K for secp256k1). Used in UPP for key operations in SNARK mode. Not post-quantum secure.
Poseidon
A ZK-friendly hash function. Used for note commitments, nullifiers, and Merkle trees. Designed for efficient circuit computation.
Groth16
A SNARK proof system using BN254 elliptic curve pairings. Compact proofs (~200B), fast verification (~230K gas). Requires trusted setup. Not post-quantum secure.
Circle STARK
A STARK proof system using the Mersenne-31 field and circle group (as implemented in Stwo). Post-quantum secure. Larger proofs (~5KB), higher verification cost (~20M gas). No trusted setup.
PLONK
A universal SNARK proof system. Supports universal trusted setup (no per-circuit ceremony). Used in UPC over BLS12-381 for 128-bit security.
LeanIMT
Lean Incremental Merkle Tree — the data structure used for note commitments and ASP membership trees. Optimized for incremental updates and ZK circuit compatibility.
ECDH (Elliptic Curve Diffie-Hellman)
A key agreement protocol used for note encryption. Sender and recipient derive a shared secret without communicating it directly.
AES-GCM
Symmetric encryption providing confidentiality and authentication. Used for encrypting note data on-chain. Post-quantum safe (Grover halves effective security to 128-bit).
BLS12-381
An elliptic curve providing ~128-bit security. Used in UPC for PLONK proofs. EIP-2537 precompiles available on Ethereum since Pectra (May 2025).
BN254
An elliptic curve providing ~100-bit security. Used in UPP Groth16 proofs. Native precompile on Ethereum.
M31 (Mersenne-31)
The base field where . Used in Circle STARKs for efficient shift-based modular reduction.
QM31 (SecureField)
The quartic extension over M31. Used as the challenge field in Circle STARKs — random challenges drawn from a space of elements.
FRI (Fast Reed-Solomon IOP)
The core mechanism in STARKs for proving polynomial degree bounds. Circle FRI adapts it to the circle-group domain.
DEEP (Domain Extension for Eliminating Pretenders)
A technique in STARKs that connects polynomial commitments at domain points with out-of-domain evaluations.
Infrastructure
EIP-2537
The Ethereum Improvement Proposal adding BLS12-381 precompiles to the EVM. Live since the Pectra hard fork (May 2025). Enables gas-efficient PLONK verification.
EIP-2612
The permit extension for ERC20 tokens. Allows gasless approvals via off-chain signatures. UPD supports EIP-2612.
LeanIMT (Lean Incremental Merkle Tree)
An optimized Merkle tree for incremental inserts. Used for both UPP note commitments and UPC identity trees.
Indexer
Software that scans the blockchain for encrypted notes and decrypts those belonging to a user. The UPP SDK includes makeRpcIndexer for this purpose.