Confidential positions, provable solvency

1Purpose and scope

The Private Trading Vault pools depositor capital under an autonomous trading agent. The product promise is that the agent’s positions, holdings, and strategy are not visible on-chain — not to competing desks, not to MEV bots, not to the depositors themselves — while the vault’s solvency and share price stay independently verifiable by anyone.

This document specifies the confidentiality boundary and the mechanism that bridges confidential off-chain state to the public vault contract. It is the answer to the hard question in private DeFi: how depositors know the vault is solvent without being shown what it holds.

What is confidential

• Portfolio composition — which tokens, in what size
• Entry and exit prices, trade timing, and venue routing
• Strategy code and parameters

What stays public

• Shares outstanding, deposits, and redemptions — ordinary ERC-4626 flows
• Attested NAV, share price, and the solvency-proof result
• Mandate parameters and drawdown-breaker state

Depositor-level privacy (who deposited, how much) is out of scope here; it is an additive shielded-deposit layer noted in §8.

2The trust boundary

Capital sits in one of two places. The settlement buffer holds the base asset on-chain in the clear. Deployed capital is held by execution accounts whose keys live inside a hardware enclave; only a single scalar — the aggregate mark-to-market value — ever crosses back to the contract.

3Components

3.1 Vault contract — public Built

An ERC-4626-style vault that custodies only the settlement buffer. It maintains share supply, the high-water mark, management and performance fees (minted as dilution shares), the redemption queue, the mandate parameters maxDeployedBps / maxTradeBps / maxDrawdownBps, and breaker state. It prices shares exclusively from verified NAV attestations and never holds or references an individual position. Today the prototype still exposes heldTokens and deployedValue directly — the surface that milestone M1 removes.

3.2 Execution enclave — TEE Planned

The agent runs inside a hardware enclave (AWS Nitro Enclaves or Intel TDX). It holds the execution-account keys, runs the sealed strategy, submits orders to the private venue, and each epoch emits a signed NAV attestation and — from M3 — a succinct solvency proof. The enclave image measurement is registered in the registry below; the buffer only funds execution accounts bound to an approved measurement.

3.3 AgentRegistry — public Partial

An allowlist of approved enclave measurements, timelocked key rotation, and attestationValidityPeriod / heartbeatTimeout liveness gates. If attestations lapse, the vault auto-enters unwind-only. The rotation and liveness scaffolding is built; the attestation is currently a hash placeholder, with full attestation-document verification scheduled for M2.

4The NAV attestation bridge

Every epoch — target cadence one hour — the enclave:

• Reads execution-account balances and a signed price vector from a committed oracle set
• Computes nav = Σ bal · price + settlementBuffer
• Signs { epoch, nav, oracleRoot, executionAccountsRoot, deployedValue, breakerState, measurement }
• Submits it to the vault, which checks the signature against an approved key, that epoch is monotonic, that the attestation is fresh within attestationValidityPeriod, and that deployedValue ≤ maxDeployedBps · nav

The contract then sets pricePerShare = nav / totalSupply. No position data crosses the boundary — only the scalar nav and two Merkle roots. Between epochs the price is stale-but-bounded, which is exactly why maxDeployedBps caps how far NAV can drift before the next attestation lands.

5Verifiable solvency Planned · M3

A signed nav still asks depositors to trust the enclave’s arithmetic. So the enclave also produces a zero-knowledge proof that, against the committed executionAccountsRoot and oracleRoot:

• it knows balances bᵢ and prices pᵢ with Merkle membership in those roots such that Σ bᵢ pᵢ + buffer ≥ navClaimed
• Σ bᵢ pᵢ ≤ maxDeployedBps · navClaimed — the agent cannot over-deploy
• no single epoch trade exceeded maxTradeBps · nav, against a committed trade log

A verifier contract checks the proof; the dashboard shows “solvency verified at epoch N / block B.” Individual balances, tokens, and prices stay hidden. The interim form shipped alongside M1–M2 is per-epoch Pedersen balance commitments plus a summed-value attestation, with full disclosure only under dispute.

6Redemptions and the breaker, against a hidden NAV

Instant Built

Paid from the settlement buffer at the last attested price, capped by buffer size.

Queued Built · skeleton

The enclave watches the on-chain queue, unwinds enough positions into base asset, bridges to the buffer, and the contract settles the queue at the NAV attested after the unwind — a redeemer cannot exit on a stale favourable mark.

Liveness failure Built guardian: M4

If attestations lapse past attestationValidityPeriod, the vault enters unwind-only: no new deployment, redemptions prioritised pro-rata against the buffer, and emergencyRedeem opens. A timelocked guardian path (M4) lets a final signed balance disclosure be posted so residual positions can be recovered and distributed.

Drawdown breaker Built

Each attestation carries nav; the contract tracks the attested series against the high-water mark and trips to unwind-only when drawdown exceeds maxDrawdownBps. The breaker runs entirely on the public scalar — no position visibility required.

7Threat model

8Status and roadmap

Built live on testnet Partial scaffolding in place Planned ahead

Today — on Horizen Testnet: an ERC-4626 vault with high-water-mark fee dilution, the redemption queue, the drawdown breaker, AgentRegistry with timelocked rotation and liveness gates, on-chain mandate parameters, a fixed-rate mock venue, and a full operator UI. The app already commits the held-token set rather than listing it; the vault contract still exposes those reads — the surface M1 closes.

1. M1 Confidentiality boundary Move deployed capital into enclave-controlled execution accounts. Replace heldTokens / deployedValue reads with an executionAccountsRoot commitment plus a signed NAV attestation. The contract prices shares only from verified attestations.
2. M2 Real TEE Agent running in Nitro or TDX. On-chain verification of the full attestation document, not a hash. Sealed strategy. Order routing to the Horizen private DEX.
3. M3 Verifiable solvency Zero-knowledge proof of reserves and mandate compliance. Public verifier contract. Solvency status surfaced on the dashboard.
4. M4 Mainnet and resilience Mainnet deployment. Timelocked guardian disclosure path. Optional shielded-deposit layer for depositor-level privacy.

9Why this fits Horizen

• Uses a TEE and zero-knowledge proofs together — the stack Horizen is already built on
• Composes with the private DEX (the agent trades there) and with private yield products
• Answers “positions confidential, solvency verifiable” with a concrete mechanism, not an aspiration