How Papillae Works
Privacy-first stablecoin transfer system using zero-knowledge proofs, encrypted commitments, and selective transparency
User Deposits Stablecoins
Connect web3 wallet and deposit supported stablecoins (USDC, USDT, etc.)
- Standard on-chain transaction
- Funds enter Papillae's privacy context
- Deposit accepted and verified
Create Private Transfer Intent
User enters recipient (username.papillae or wallet address) and amount
- Recipient resolved privately
- Amount and metadata encrypted
- Transfer intent created
Privacy Layer Shields Data
Transaction data is encrypted and shielded from public view
- Sender identity hidden
- Receiver identity hidden
- Amount encrypted
- ZK proof generated
Stablecoin Routing Executes
Papillae routes value using chain-native execution
- Optimal route selected
- Fees calculated automatically
- Privacy preserved throughout
Recipient Receives Funds Privately
Funds arrive instantly with full privacy protection
- Instant delivery
- Only recipient can decrypt
- Optional compliance disclosure
Core Principles
Papillae uses zero-knowledge proofs and encrypted computation to process transactions without exposing sensitive data. The system performs all necessary validations cryptographically while keeping amounts, identities, and metadata private.
Key Features:
- Zero-knowledge proof generation for transaction validity
- Encrypted computation on transaction data
- Privacy-preserving smart contract execution
Through stealth account technology, Papillae completely separates user identity from transaction execution. Each transaction uses a unique stealth address, making it impossible to link transactions to a specific user identity on-chain.
How It Works:
- Stealth addresses generated per transaction
- Identity mapping stored off-chain
- No on-chain identity linkage
All transaction amounts are represented as encrypted commitments using Pedersen commitments or similar cryptographic primitives. The system can verify transaction validity and balance without ever decrypting the actual amounts.
Technical Details:
- Pedersen commitments for amount hiding
- Homomorphic operations on commitments
- Range proofs for validity verification
While transactions are private by default, users can selectively disclose transaction details to authorized parties (regulators, auditors) when needed for compliance. This is done through view keys and selective disclosure mechanisms.
Use Cases:
- Regulatory compliance reporting
- Audit trail generation
- User-controlled disclosure
Architecture
Shield Key
Used to create encrypted commitments and shield transaction amounts. Derived from user's master key using hierarchical deterministic (HD) key derivation.
- • Generates stealth addresses
- • Creates encrypted value commitments
- • Never exposed on-chain
View Key
Allows authorized parties to decrypt transaction details for compliance. Can be shared selectively with regulators or auditors.
- • Decrypts encrypted commitments
- • Reveals transaction details
- • User-controlled sharing
Derivation Process:
1. Deposit & Shield
- User deposits token
- Token locked in contract
- Encrypted commitment created
2. Create Intent
- Enter recipient
- Encrypt amount
- Generate stealth address
3. Generate Proof
- Off-chain computation
- ZK proof generation
- Proof validation
4. Execute
- On-chain verification
- Commitment transfer
- Route execution
5. Deliver
- Funds arrive
- Recipient decrypts
- Transaction complete
Public Chain Sees
- A valid transaction request
- Encrypted commitments (cannot decrypt)
- ZK proof verification result
Public Chain Does NOT See
- Transaction amount
- Sender identity
- Recipient identity
- Transaction metadata