Nexus: The Untraceable Stablecoin Bank

We present Nexus, a non-custodial stablecoin banking protocol that provides active returns on deposited USDC while maintaining full financial privacy through confidential computing. The system employs per-user PDA-derived vaults on Solana, quant-managed strategy execution, and encrypted state to ensure that account balances, transaction amounts, and counterparty relationships are computationally infeasible to reconstruct by any external observer, including the protocol operators.

The core contribution is a practical construction that eliminates the historically forced tradeoff between DeFi composability and financial privacy, while delivering institutional-grade risk-adjusted returns to permissionless participants.

Stablecoin holders face a dual-exposure problem. In traditional finance, deposit institutions earn 4-8% on customer assets through lending, treasury operations, and capital markets while distributing <0.5% to depositors. The information asymmetry is structural: institutions monetize deposits while externalizing opportunity cost to holders.

In decentralized finance, the opportunity cost problem is solved (DeFi yields are accessible to all participants), but a new vulnerability is introduced: total financial transparency. Every on-chain balance, transfer, and counterparty relationship is publicly observable. This creates measurable attack vectors including front-running, targeted social engineering, transaction graph deanonymization, and regulatory exposure.

We define the private returns problem as follows: construct a system where (1) stablecoin deposits generate risk-adjusted returns comparable to institutional strategies, (2) account state is encrypted at rest and in transit, and (3) the system remains permissionless and non-custodial.

Nexus operates as a three-layer architecture with strict separation of concerns. Each layer enforces independent privacy and security invariants.

Layer 1: Client (Expo/React Native). The mobile application manages local key material, UI rendering, and encrypted session state. It issues authenticated API calls to Layer 2 but never constructs or signs Solana transactions directly. This constraint eliminates an entire class of client-side key extraction vulnerabilities.

Layer 2: Backend (Supabase Edge Functions). Stateless compute functions that handle authentication (JWT-based), transaction construction, and Solana program interaction. The backend processes encrypted payloads and constructs transactions on behalf of users. It has access to the operator keypair but never to user balances in plaintext. Row-level security policies at the database layer ensure cross-user isolation.

Layer 3: On-Chain (Solana + Confidential Computing). An Anchor program managing per-user PDA vaults. Each user account maps to a unique vault authority derived as PDA(["vault", username_hash]). The associated token account holds USDC. Confidential computing integration provides encrypted state: balances are stored as ciphertexts that can be operated on (addition, comparison) without decryption.

The critical property is that no single layer has complete information. Layer 1 knows the user's intent but not the operator key. Layer 2 knows the operator key but not the plaintext balance. Layer 3 stores the balance but only in encrypted form. Compromise of any single layer is insufficient to violate user privacy.

The privacy guarantees of Nexus are cryptographic, not policy-based. We distinguish four properties and specify how each is achieved.

P1: Balance confidentiality. Account balances are encrypted using additively homomorphic encryption. The ciphertext is stored on-chain. Only the account holder possesses the decryption key. The protocol can compute on encrypted balances (e.g., verify sufficient funds for a withdrawal) without learning the plaintext value. External observers, including block explorers, see only ciphertext.

P2: Transaction privacy. Transfers between Nexus accounts are shielded. The sender, receiver, and amount are encrypted. The on-chain transaction contains only proof that the sender has sufficient funds, the receiver's account exists, and the amounts balance. This is implemented as a zero-knowledge proof of correct state transition.

P3: Selective disclosure. Users can generate zero-knowledge proofs attesting to properties of their account without revealing the underlying data. Example: proving balance ≥ $X without disclosing the exact balance. This enables compliance, creditworthiness verification, and counterparty due diligence on the user's terms.

P4: Metadata resistance. Transaction timing and frequency patterns are obscured through batched settlement windows. Counterparty graph analysis is defeated by the encryption of sender/receiver pairs. Network-level traffic analysis is mitigated by constant-rate encrypted communication between client and backend.

Threat model. We assume a computationally bounded adversary with full read access to the blockchain, the ability to observe network traffic, and potential compromise of the backend infrastructure. Under this model, the adversary learns nothing beyond the total number of active accounts and aggregate transaction volume (both of which are publicly visible by design for protocol health monitoring).

Returns are generated through algorithmic strategy execution on deposited stablecoins. The strategy layer operates within the confidential computing environment, ensuring that allocation decisions, rebalancing events, and return distributions are invisible to external observers.

Risk tranches. Users select from discrete risk profiles at account creation. Each profile maps to a strategy set with defined parameters:

• Conservative (Low Risk). Target: risk-free rate + 200bps. Instruments: lending protocols, over-collateralized positions, and principal-protected structures. Maximum drawdown constraint: 2%. Volatility target: <5% annualized.
• Aggressive (High Risk). Target: risk-free rate + 800bps. Instruments: leveraged lending, basis trades, and cross-protocol arbitrage. Maximum drawdown constraint: 15%. Volatility target: <25% annualized.

Return calculation. Net returns are computed as:

R = B_current - (B_initial + Σ deposits + Σ swaps - Σ withdrawals)

where:
  B_current   = current USDC balance (from on-chain state)
  B_initial   = balance at account creation (signup snapshot)
  Σ deposits  = sum of all deposit-type transactions
  Σ swaps     = sum of all swap-type transactions (SOL→USDC)
  Σ withdrawals = sum of all withdrawal-type transactions

This formula is implemented as a single atomic SQL function (get_net_deposits) to prevent TOCTOU race conditions in the return calculation. Swap transactions are explicitly counted as inflows to prevent misattribution of converted volatile assets as organic returns.

Nexus supports four payment modalities, all operating within the privacy layer:

5.1 Username-based P2P. Users send funds by @username. The backend resolves usernames to vault addresses server-side, constructs a shielded transfer, and creates dual transaction records (sender and recipient). The on-chain transaction reveals no counterparty information. Push notifications to the receiver are delivered through encrypted channels.

5.2 Card payments (Visa). A Nexus-branded Visa card draws from the user's stablecoin balance. The card network sees a standard card transaction. No link exists between the card transaction and the on-chain account. Spend activity is isolated from blockchain identity.

5.3 Fiat bridge. On-ramp and off-ramp to traditional banking. The bridge operates as a one-way mirror: fiat institutions observe a standard payment. The stablecoin side is encrypted. No transaction graph connects fiat identity to on-chain activity.

5.4 Agentic commerce (Payproof/x402). Autonomous agents deposit, earn returns, and pay using atomic payment proofs. The x402 protocol enables machine-to-machine commerce where payment verification is cryptographic rather than identity-based. Agents operate with full financial privacy.

6.1 Non-custodial guarantee. User funds reside in individual PDA-derived vaults. The vault authority is a program-derived address: PDA(["vault", H(username)]). Withdrawals require the operator to sign, but the operator cannot initiate withdrawals unilaterally. The program enforces that only the vault owner (identified by username hash) can authorize fund movement.

6.2 Timelock governance. All configuration changes to the on-chain program (operator rotation, fee adjustments, strategy parameters) are subject to a 48-hour timelock. Proposed changes are visible on-chain, giving users a guaranteed exit window before any parameter modification takes effect.

6.3 Zero-knowledge solvency. The protocol periodically publishes a zero-knowledge proof of solvency: proof that the sum of all encrypted user balances equals the total USDC held across all vaults. This enables public verification of full backing without revealing any individual balance.

6.4 Operator risk. The operator keypair is a single point of trust for transaction submission. This is mitigated by: (a) the operator cannot move funds to arbitrary addresses (program constraints), (b) timelock governance prevents unilateral parameter changes, (c) all operator actions are logged on-chain and publicly auditable. Future work includes distributed operator sets and threshold signing.

Nexus is built by FCA-licensed quantitative analysts and engineers with backgrounds in institutional finance, cryptography, and distributed systems. The team holds regulatory authorization from the UK Financial Conduct Authority, bringing compliance expertise and institutional credibility to permissionless infrastructure.

Nexus demonstrates that privacy and performance are not competing objectives in stablecoin infrastructure. By combining non-custodial vault architecture, confidential computing, and quantitative strategy management, we construct a system that delivers institutional-grade returns to permissionless participants while maintaining cryptographic privacy guarantees against computationally bounded adversaries with full blockchain read access.

Financial privacy is not a feature. It is a precondition for financial sovereignty. Nexus provides both.