Obscura V2 - The Problem It Solves

What is Obscura V2?

Obscura V2 is a privacy-preserving copy trading platform that enables users to follow and automatically replicate the trades of successful cryptocurrency traders without exposing sensitive trading data, wallet balances, or transaction histories.

Problems It Solves

1. Privacy in Copy Trading

Traditional copy trading platforms expose your trading activity, portfolio size, and strategies to centralized operators. Obscura uses:

• Zero-Knowledge Proofs (ZK) via Cairo/Ztarknet to verify trader performance without revealing actual trades
• Trusted Execution Environments (TEE) through the Citadel module to process sensitive data in secure enclaves
• Shielded Zcash payments for private subscription transactions

2. Trustless Trader Verification

Users can verify that a trader’s claimed performance is legitimate without the trader revealing their full trading history or wallet addresses. The platform generates cryptographic proofs of:

• Trade execution authenticity
• Portfolio performance metrics
• Historical ROI/win rates

3. Private Subscription Payments

Using Zcash shielded transactions, subscribers pay for premium trader signals without leaving a public payment trail. This protects:

• Subscriber identity
• Which traders they follow
• Subscription amounts

4. Cross-Exchange Trading

The platform supports copying trades across multiple exchanges (Binance, Bybit, OKX, Kraken, etc.) through a unified API gateway, with:

• Encrypted API key storage
• Multi-wallet management (EVM, Solana, Starknet)
• Real-time trade mirroring

How It Makes Tasks Easier/Safer

Task	Traditional Approach	Obscura V2 Approach
Following traders	Publicly visible subscriptions, leaked strategies	Private subscriptions via Zcash, ZK-verified performance
Verifying performance	Trust screenshots/claims	Cryptographic proofs on-chain
Storing API keys	Plain text or weak encryption	TEE-protected Citadel vault
Paying for signals	Credit cards, public crypto txs	Shielded Zcash transactions
Executing copy trades	Manual or centralized bots	Decentralized workers with privacy

Key Use Cases

1. Retail traders can safely follow expert traders without exposing their capital or trading activity
2. Professional traders can monetize their strategies while keeping alpha confidential
3. Institutions can offer copy trading services with regulatory-compliant privacy guarantees
4. Privacy-conscious users can participate in DeFi copy trading without on-chain footprint

---

Architecture Highlights

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   Frontend      │────▶│   API Gateway    │────▶│   Citadel TEE   │
│  (Next.js 15)   │     │   (FastAPI)      │     │   (Encrypted)   │
└─────────────────┘     └──────────────────┘     └─────────────────┘
                               │
        ┌──────────────────────┼──────────────────────┐
        ▼                      ▼                      ▼
┌───────────────┐    ┌─────────────────┐    ┌─────────────────┐
│  Verification │    │    Payments     │    │   Copy Trading  │
│  (Cairo/ZK)   │    │    (Zcash)      │    │   (Workers)     │
└───────────────┘    └─────────────────┘    └─────────────────┘

Summary

Obscura V2 solves the fundamental tension between transparency (needed for trust in copy trading) and privacy (needed for competitive advantage and security). It enables a marketplace where traders can prove their skill and subscribers can verify performance all without exposing the underlying data that makes those strategies valuable.

Challenges I Ran Into Building Obscura V2

1. Docker Build Dependency Hell

The Problem

Building the E2E Docker stack revealed cascading dependency conflicts across multiple services:

React 18/19 Peer Dependency Conflict

npm error ERESOLVE could not resolve
npm error peer react@"^18" from @starknet-react/[email protected]
npm error   react@"19.0.0" from the root project

The Starknet React SDK required React 18, but Next.js 15 shipped with React 19.

Solution: Added --legacy-peer-deps to the npm install command in frontend/Dockerfile.dev.

Python Version Mismatch

ERROR: Package 'secretvaults' requires a different Python: 3.11.14 not in '>=3.12'

The secretvaults package (Nillion’s privacy SDK) required Python 3.12+, but the Docker image used Python 3.11.

Solution: Upgraded the base image from python:3.11-slim to python:3.12-slim in the API Gateway Dockerfile.

Missing System Dependencies

error: command '/usr/bin/gcc' failed with exit code 1
secp256k1.h: No such file or directory

The secp256k1 cryptographic library needed pkg-config and libsecp256k1-dev to compile.

Solution: Added system dependencies to the Dockerfile:

RUN apt-get install -y pkg-config libsecp256k1-dev git

2. Binary Distribution Issues

Zcash Wallet CLI Not Available

E: Unable to locate package zecwallet-light-cli

The zecwallet-light-cli wasn’t available in Debian repos, and the GitHub release didn’t have the expected version tag.

Solution: Downloaded the pre-built binary directly from GitHub releases with architecture detection:

RUN ARCH=$(uname -m) && \
    if [ "$ARCH" = "x86_64" ]; then ARCH_NAME="linux-x86_64"; \
    elif [ "$ARCH" = "aarch64" ]; then ARCH_NAME="linux-aarch64"; fi && \
    curl -L "https://github.com/AlenMalik/zecwallet-cli/releases/download/v1.0.0/..." \
    -o /usr/local/bin/zecwallet-cli

grpcurl Not in Debian Repos

E: Unable to locate package grpcurl

Needed for Zcash lightwalletd health checks, but not available via apt.

Solution: Downloaded directly from GitHub with architecture detection for ARM64/AMD64 compatibility.

3. Bun Lockfile Version Incompatibility

The Problem

error: Outdated lockfile. bun.lock (v1) is out of date
The lockfile was generated with bun 1.2.14

The verification service used Bun, but the lockfile version didn’t match the Docker image’s Bun version.

Solution: Removed --frozen-lockfile flag from bun install to allow lockfile regeneration:

RUN bun install  # instead of: bun install --frozen-lockfile

4. 600MB Build Context Transfers

The Problem

Docker was transferring the entire node_modules folder (600MB+) to the build daemon on every build, making iterations painfully slow.

Solution: Created .dockerignore files for frontend and verification services:

node_modules
.next
.git
*.log

5. Zero-Knowledge Proof Integration

The Problem

Integrating Cairo ZK proofs with the TypeScript verification service required:

• Compiling Cairo contracts to Sierra/CASM
• Deploying to Starknet testnet
• Calling verification from Node.js

Solution

Created a multi-stage build with:

1. Cairo compilation in a Scarb container
2. Bun service with starknet.js for proof verification
3. gRPC endpoints for the backend to request verifications

6. TEE Key Management

The Problem

The Citadel module needed to store encrypted API keys for multiple exchanges, but key derivation had to happen inside the Trusted Execution Environment—not in application code.

Solution

• Used envelope encryption with TEE-derived master keys
• Implemented key rotation without re-encrypting all stored keys
• Added attestation verification before any key operations

Key Takeaways

Challenge	Root Cause	Fix Time
React version conflict	Breaking changes in React 19	10 min
Python version mismatch	Upstream dependency update	5 min
Missing binaries	Assuming apt availability	30 min
Slow Docker builds	No .dockerignore	5 min
Bun lockfile	Version drift	5 min

Lesson learned: Always check dependency requirements before assuming base images will work, and create .dockerignore files from the start.