The problem Obscura solves

Perpetual DEX users must fund their trading wallets directly from their main EOA. This creates a permanent, publicly visible link between an identity-bearing wallet and the wallet used for trading. As a result, anyone can trace deposits, infer balances, monitor positions, and correlate liquidation events. Existing DEX flows provide no practical way to break this link without relying on mixers, custodial services, or complex privacy tooling.

What People Can Use It For

• Funding a perp trading wallet without revealing which EOA supplied the funds
• Separating trading activity from personal or identity-linked wallets
• Preventing on-chain observers from correlating deposits with trading accounts
• Preserving privacy without introducing custodial risk or depending on mixers
• Integrating a privacy layer without changing how existing DEXs operate

How It Makes Existing Tasks Safer

• Escrow-based deposits and jittered withdrawals break deterministic tracing
• Trading wallets receive funds from a shared pool, improving unlinkability
• Private keys are generated inside a TEE-like environment and never exposed to the backend
• Operator actions are auditable and restricted through smart contract controls
• Users maintain full self-custody while gaining practical on-chain privacy

In short, it enables private, trust-minimized funding of trading accounts while remaining fully compatible with any perp DEX.

Challenges we ran into

Challenges I Ran Into

Matching Deposits to User Sessions

A core challenge was reliably matching on-chain Deposited events to the correct user session without exposing user data or relying on strict timing. Early versions matched only by amount and address, which failed when multiple users deposited identical amounts.
Fix: Added session metadata, tolerances, and a short-lived session window, allowing deterministic pairing without leaking identifiers.

Avoiding Direct Timing Correlation

Straight-through withdrawals made deposits and withdrawals trivially linkable. Adding randomness had to be done without creating indefinite delays or breaking expected UX.
Fix: Implemented a jittered withdrawal engine with bounded randomness and a queue-backed job system.

Secure Wallet Generation

Generating private keys on the backend introduced security concerns and possible key exposure through logs or memory.
Fix: Built a small TEE server that generates keys in a sealed module, returns only encrypted blobs, and logs only opaque references.

Preventing Operator Misuse

Early contract designs allowed the operator to withdraw to any address, which introduced custodial-like risk.
Fix: Restricted operatorWithdraw to verified job IDs and wallet addresses created via the TEE simulator, ensuring funds can only move to user-owned unlinker wallets.