Exploration of FHE Laye
Exploration of FHE Layer
Partial Encryption of Funding and Vault Exposure
As the zero-knowledge tooling landscape matures, SnarkSide remains committed to pushing the frontier of encrypted financial primitives. One such frontier—currently in active research—is the integration of Fully Homomorphic Encryption (FHE) as a complementary privacy layer, enabling computation on encrypted data without decrypting it. This section outlines the motivations, technical feasibility, and early design pathways for partially integrating FHE within SnarkSide’s architecture, specifically targeting funding rate computation and vault exposure anonymization.
1. Motivation
SnarkSide's current ZK architecture provides selective privacy:
Trade intents are Poseidon-hashed and nullifier-bound
Vault state transitions are committed to Merkle trees
Liquidations are proven via non-interactive ZK proofs
However, certain global metrics—like funding rate skew and LP exposure—require some aggregate transparency. Currently, we rely on ZK-bound attestations and obfuscated event logs to minimize information leakage. But this approach still leaks:
Open interest imbalance (long vs short)
Temporal vault entry/exit patterns
Aggregate collateral movement visibility over time
These patterns can be extracted by sophisticated off-chain observers or relayers, even when individual user identities remain hidden.
FHE offers a path to close this privacy gap: allowing aggregate market metrics to be computed without ever revealing underlying user positions or trade flows.
2. Targeted FHE Use Cases
A. Funding Rate Skew
Problem: To compute funding payments fairly, the system must understand the imbalance between long and short open interest. Doing so today requires:
Aggregating position directionality
Trusting relayers to compute totals off-chain
Publishing decrypted metadata as ZK circuit inputs
FHE Solution:
Each vault encrypts its position size/direction using a homomorphic encryption key
Relayers homomorphically sum all encrypted vault directions
Resulting ciphertext is decrypted by a threshold MPC (or later, ZK-proven using FHE output range constraints)
ZK circuits receive the verified net skew value without exposing any individual vault direction
This removes directionality leakage without eliminating funding accuracy.
B. Vault Exposure Audits
Problem: LPs or auditors may want to verify total protocol collateral or leverage exposure without deanonymizing individual accounts.
FHE Solution:
Every deposit, withdrawal, and vault update emits an FHE-encrypted delta
These are streamed into a rolling accumulator ciphertext
Auditors or DAO governance modules may decrypt only the sum—not any component values
3. Technical Implementation Path
SnarkSide's FHE layer is experimental, and as of mid-2025 is undergoing design simulation using Zama and Concrete-ML. Early architecture includes:
A. Encryption Scheme
CKKS (for approximate arithmetic with funding rate floats)
TFHE (for binary/multiplicative vault flags)
B. Key Management
Homomorphic public key is hardcoded per epoch
Secret key is split across trusted relayers using Shamir secret sharing
Decryption only allowed under consensus from ≥t-of-n relayers (or governance quorum)
C. FHE Operations
Vault Entry Direction
✅
Long/Short bit masked via TFHE
Position Size
✅
CKKS approximate encrypted float
Net Skew Computation
✅
FHE-additive aggregation
Funding Rate Derivation
✅
Derived via FHE polynomial
Vault Merkle Inclusion
❌
Verified via ZK circuit (not FHE)
4. Constraints and Open Challenges
A. Performance
FHE is orders of magnitude slower than ZK circuits. On-chain FHE is infeasible, and even off-chain computation must be tightly bounded to prevent relayer lag.
B. Proof Integration
Unlike ZK proofs, FHE does not generate verifiable succinct witnesses. This limits trustless settlement unless wrapped in a hybrid ZK+FHE circuit (future research).
C. Ciphertext Size
Encrypted position fields can reach several kilobytes—much larger than Poseidon-committed state. Efficient compression or ephemeral aggregation models are needed.
D. Key Rotation and Epoch Finality
Public keys must rotate each epoch to prevent indefinite ciphertext reuse and allow for retroactive aggregate snapshotting without historical leakage.
5. Future Path: ZK-FHE Hybrid Circuits
SnarkSide is exploring the use of ZK-proven FHE computation outputs:
An MPC decrypts the FHE net skew
The result is passed into a ZK circuit that proves:
The ciphertext decrypts to a bounded integer
The corresponding funding rate falls within the pre-approved curve
Resulting proof can then be used on-chain without ever revealing vault directionality
This is a next-generation composability layer: ZK for structural constraints, FHE for latent privacy retention.
Conclusion
FHE will not replace ZK in SnarkSide’s core trade flows. But it offers something ZK cannot: computation over ciphertexts, useful for aggregate transparency without compromising individual privacy.
In time, we envision a protocol where:
Every trade is opaque
Every vault is silent
And yet the market still functions, prices funding accurately, and resists abuse—
Because privacy isn’t an obstacle to markets. It’s infrastructure for markets to remain trustless, even under total anonymity.
Last updated