Sealed copy trading on Solana perps

#1. Introduction

Unseen is a copy-trading protocol for perpetual futures on Solana. A trader, the leader, runs a strategy; followers deposit USDC into it and receive shares in the strategy's ledger. Every signal the leader sends becomes one pooled order for the whole strategy, so the leader and every follower receive the same fill and pay the same costs per share. Each new position opens from a fresh execution account that carries a 32-byte commitment instead of a strategy identifier. An observer sees that a trade happened, with its market, side and size, but cannot tell which strategy made it until the strategy's reveal delay has passed and the execution is published.

This chapter states the problem Unseen addresses, what the protocol treats as its product, why it is built on oracle-priced perpetuals, and the design goals the remaining chapters specify.

#1.1 What copy trading sells

Copy trading on Solana is a large paid market whose revenue goes to the tools rather than to the traders being copied. On DefiLlama (fetched 2026-10-15), all-time revenue was $466.5M for Axiom, $442.0M for Photon, $288.2M for GMGN and $203.0M for BullX; the Axiom and GMGN figures also count other chains. GMGN charges 1% per trade and Axiom 0.75–0.95% net. The trader whose wallet sits on a PnL leaderboard is the input to these products and earns nothing from them.

What a copier pays for is attribution: a wallet address together with its public history. A single trade is cheap to reproduce once visible on-chain; the information with value is which trades come from a source worth following, and on a public chain anyone who watches has it. Real-time monitoring over WebSockets and Yellowstone gRPC is sold as a standard RPC product, so any profitable address is found and followed.

#1.2 The parties and what they bear

Table 1.1 — Parties to copy trading today.

Hyperliquid's vaults show that the payment side works when built into a venue: vault leaders take a 10% profit share and must keep at least 5% of the vault. Every vault position is public, and Hyperliquid is not on Solana. Profit shares paid to leaders and private execution for traders exist today in separate products. Unseen combines them.

#1.3 Attribution as the product

Unseen sells attribution as the product. The trade is executed in public, on a public venue, at the venue's oracle price. What the protocol withholds, for a bounded and declared time, is the link between the trade and the strategy that made it. Four mechanisms produce this separation.

1. Pooled execution. A strategy's equity is the leader's stake plus follower deposits, tracked as shares. A signal produces one order for the whole strategy. There is no separate leader order, so there is no ordering between leader and followers, and every share carries the same fill and fees (§3 Strategies, shares and the pool).
2. Unlinkable execution accounts. Each new position opens from a fresh program-derived account with a random 64-bit index, funded from one pool vault shared by every strategy. The account stores its market, side, notional, collateral and a 32-byte commitment, never a strategy identifier or signal sequence. Each execution extends an on-chain hash chain of commitments (§6 Exec accounts and commitments).
3. Sealed signals. The leader's client checks the executor's Intel TDX attestation, signs the signal with a registered key and encrypts it to a key held only by the attested confidential VM. The signal does not appear in public before the trade lands (§4 Signals, §5 The Sealed Executor).
4. Delayed, collective reveal. Each strategy declares an immutable reveal delay D between 24 hours and 30 days, 7 days by default. The opening of an execution, the data that hashes to its commitment, is posted on-chain once the execution is closed, D has passed since closure, and every strategy active in that UTC day has passed its own delay. Anyone can then rebuild every strategy's trade log and NAV from chain data (§10 Reveal).

While the record is withheld, two mechanisms keep it checked. An independent verifier recomputes each daily epoch's NAV from on-chain fills and the confidential openings and co-signs it before any deposit or withdrawal settles (§8 Epochs and settlement). Hourly statistics of return, drawdown and exposure band are quantized, delayed and jointly signed by the executor and the verifier (§11 Attested statistics).

A paying follower receives the leader's exact fill and a record verified at every epoch, while the leader keeps the strategy's positions private for D. An observer sees aggregate flow without attribution until publication.

#1.4 Why oracle-priced perpetuals

A capable trader usually refuses followers because followers move the price on entry and exit and, in thin markets, take the leader's liquidity. On liquid oracle-priced perpetuals this cost is small and computable. Jupiter Perps fills requests at the oracle price, so follower flow does not move the price the leader trades at, and its price-impact fee is deterministic, about 1 bp per started ~$375k of SOL notional. Its other fees, 0.06% to open and to close plus an additive fee on large net flow per minute, follow published formulas and are capped at 0.50% of trade size.

Followers therefore impose little cost on the leader, which removes the usual objection to follower capital. Free copying is equally cheap, so on these markets attribution is what separates a trader from a follower business. Unseen targets Jupiter Perps' SOL, ETH and wBTC markets, long and short, at up to 3× leverage. Memecoins are not served: capacity in seconds-old tokens is tiny and speed decides the edge. Oracle pricing and published fees also make capacity computable in advance: §3.7 derives a strategy's capacity from the per-minute flow slice, and §7 Venue: Jupiter Perps gives the fee arithmetic.

#1.5 Design goals

Unseen is specified against nine goals, each enforced by a named mechanism (§13 Security design collects them).

Table 1.2 — Design goals and the mechanism that enforces each.

G4 shapes the architecture most. An order is in plaintext when it reaches a public venue, so the hot path runs in a trusted execution environment, which builds a transaction in milliseconds. Accounting correctness does not rest on that environment: settlement waits for an independent recomputation, and every risk-increasing transaction carries a second signature from a party outside the enclave.

#1.6 Version 0

Version 0 covers Jupiter Perps SOL, ETH and wBTC, long and short, up to 3×; up to 10 invited strategies run by human leaders or AI agents through the same interface; USDC deposits; caps of $250,000 per strategy and $2,000,000 for the platform; allowlisted, screened followers outside the US and the EU; daily epochs, delayed reveal, attested hourly statistics and an open-source verifier; a leader console, a signal API and SDK, a page per strategy and a revealed-trade explorer.

#1.7 Conventions

• Amounts. USDC amounts are integers in base units with six decimals (1,000,000 base units = 1 USDC). Shares are integers with nine decimals ($10^9$ share units = one whole share). NAV per share is in USDC base units per whole share.
• Basis points. 10,000 bps = 100%. A target weight of 15,000 bps is a position of 150% of strategy equity; leverage is already included in the weight.
• Integers. Money, shares, sequences, slots and indices are canonical decimal strings in JSON and fixed-width little-endian integers in byte encodings. Arithmetic is exact, with explicit floor or ceiling; no floating-point value enters a money path.
• Notation. $H$ is SHA-256, $\Vert$ is byte concatenation and $u64le(x)$ is the 8-byte little-endian encoding of $x$. Public keys are 32 bytes, base58 in JSON; strategy identifiers, salts and commitments are 32 bytes, 64 lowercase hex characters.
• Time. Protocol time is the program's Unix clock. UTC day $k$ is the interval $[86400k,86400(k+1))$. Chain events also carry slots.
• Parameters. Values fixed by the protocol are stated as numbers. Values left to deployment configuration, such as the challenge window or the slice retry window, are described as configured parameters; a local development value is quoted only when labelled as one. §16 Parameters and encodings collects them all.

#1.8 Organization of this paper

§2 gives the system overview and the lifecycle of one trade. §3 to §4 specify strategies, shares and signals; §5 to §7 the Sealed Executor, execution accounts and commitments, and the venue; §8 to §11 epochs and settlement, fees, reveal and attested statistics. §12 documents the on-chain programs, §13 the security design, §14 infrastructure, §15 interfaces, and §16 every parameter and byte encoding with a glossary.

#2. System overview

This chapter describes Unseen as a whole: the parties and what each can do, the components, how funds move, the path of one trade from signal to reveal, and what an observer can see at each stage. Later chapters specify each part in detail.

#2.1 Actors

Table 2.1 lists what each party holds and what it can and cannot do. Each refusal in the last column is enforced by a program check, a required second signature or the absence of the necessary key.

Table 2.1 — Actors, what they hold, and what they can and cannot do.

Leaders and agents use one interface. The protocol records the kind (human or agent) on the strategy and applies identical rules to both. A follower's eligibility is a program account written by the admin after screening; a leader's admission is a single-use invitation account (§3.10 Application and admission).

#2.2 Components

Figure 2.1 shows the components and the channels between them.

The unseen program is an Anchor program on Solana. It holds the protocol configuration with the complete registry of strategies, the shared pool and its USDC vault, one account per strategy, per share holder, per epoch and per execution, the commitment receipts and the daily reveal-period certificates. It moves funds only along the paths described in §2.3 and checks every transaction against the limits in §3 Strategies, shares and the pool and §12 On-chain programs.

The Sealed Executor is a Rust service running inside an Intel TDX confidential virtual machine. It generates its Ed25519 signing key inside the VM and binds that key and a derived P-256 encryption key into a TDX quote obtained through configfs-tsm and verified by Intel Trust Authority; the attestation is published for clients. The executor accepts sealed signals, signs receipts, sizes, slices and schedules orders, sends transactions through a configured sender (RPC, Jito bundles or Helius Sender), proposes epoch NAVs, posts statistics with the verifier and publishes reveals. Its state is an authenticated-encrypted journal whose every save is anchored to an independent monotonic counter service, so an older copy of the journal cannot be restored silently (§5 The Sealed Executor).

The Verifier is an independent Rust service run by a separate operator with its own RPC endpoint and its own signing key. It admits each executor receipt into its own journal in strict sequence, independently checks and co-signs every execution, fill record, reduction, close and statistics post, recomputes each epoch's NAV and liquid cash from chain data and the authorized openings, and co-signs the proposal on-chain. It also answers public replay of revealed history without any private input (§8 Epochs and settlement).

Public services run as separate Railway services: the API (wallet sign-in, transaction plans, public reads, the server-sent event stream and the sealed-signal relay), the indexer and jobs worker, which reconciles chain accounts into PostgreSQL and writes an unattributed event outbox, and the database. The web app serves strategy pages, the leader console and the revealed-trade explorer. None of these services holds an enclave, verifier or user key, and the public database contains no table that links an execution to a strategy before reveal (§14 Infrastructure).

External services are Jupiter Perps for execution, Intel Trust Authority for attestation tokens, Range for deposit screening when its key is configured, and Squads for the admin multisig.

#2.3 Custody: the pool loop

All strategies share one pool account and one USDC vault, a token account whose authority is the pool PDA. Funds enter and leave it only along fixed paths.

• In. A leader's initial stake at strategy creation; follower deposits, held in escrow in the vault but outside the pool's executable cash until settled at an epoch; challenge bonds.
• Trading loop. execute moves a position's collateral from the pool vault to a fresh execution vault and from there into the venue request. Partial and full closes return collateral and realized PnL from the venue to the execution vault and on to the pool vault; a never-filled request is refunded the same way. Execution fees go from the pool vault to the protocol fee account, a token account of a program address no key signs for, which only buyback_and_burn spends; venue fees are paid out of collateral.
• Out. Withdrawal payouts, refunds, leader performance fees, the protocol share and returned bonds are credited as claims in program accounts and pulled by their owners into token accounts of the configured USDC mint that belong to them.

The enclave key has no instruction that moves funds to an arbitrary destination. Its transfers are pool → exec → approved venue and fixed-destination returns to the pool. Guardian rescue after enclave expiry or revocation also returns funds only to the pool. Because payouts are pull claims, a frozen or missing recipient token account cannot block another owner's settlement.

#2.4 Lifecycle of a trade

Figure 2.2 follows one trade from signal to reveal. The numbered steps below match the arrows.

Signal and admission (steps 1–4). The leader's client verifies the executor's TDX attestation, signs a deployment-bound signal of target weights with the registered signal key and encrypts it to the attested key; the ciphertext goes to the executor directly or through the API relay. The executor decrypts and checks it, assigns the next global receipt sequence and a strictly increasing microsecond timestamp, signs a receipt and persists the record. The verifier admits the record only if its receipt sequence is exactly one greater than the last it admitted. The client checks the returned receipt against the signal it sent (§4 Signals).

Sizing and ordering (step 5). The executor recomputes the strategy's equity and turns each target weight into a signed notional difference from the current position: reductions first, then new exposure, split into slices no larger than the configured slice size. A later receipt cannot overtake an unfinished action in the same market from an earlier receipt (§5 The Sealed Executor).

Execution (steps 6–9). For each slice that opens exposure, the executor draws a random 64-bit index and a 32-byte salt, computes the policy evidence hash and the commitment, and asks the verifier to authorize the action; the verifier checks the signed target, sizing, the strategy's own liquid cash and the slice policy, and adds its signature. The execute transaction checks the enclave key, the verifier signature, the market, the common collateral ratio, the anonymous pool envelope over the complete strategy registry, the pool-wide flow limit per market and minute, and the signal's validity slot. It then extends the commitment hash chain, moves collateral pool → exec vault → venue and creates the position request with a retry deadline of the current slot plus the configured retry window (§6 Exec accounts and commitments, §7 Venue: Jupiter Perps).

Fill (steps 10–11). A Jupiter keeper fills the request at the oracle price in its own transaction. The executor and the verifier then record the fill on-chain, which charges the 2 bps execution fee on the filled notional. An unfilled request is retried until its deadline and then dropped with its collateral refunded to the pool.

Adjustments and closure (step 12). A later signal that reduces exposure in the same direction partially closes the same execution account, keeping its entry price and charging fees on the reduced notional only. A signal that flips direction closes the old account and opens a fresh one. When a position is flat, all balances return to the pool vault.

As an example with the protocol's parameters: a strategy with 30,000 USDC of equity and a signal of SOL long at 15,000 bps targets 45,000 USDC of SOL notional. At a common collateral ratio of 3,334 bps (the local development value; the permitted range is 3,334–10,000 bps) the request carries $\lceil 45,000\times 3334/10000\rceil =15,003$ USDC of collateral. The fill is charged 9 USDC of execution fee (2 bps) and Jupiter's 0.06% opening fee of 27 USDC plus its impact fee (§7), all borne by the strategy as a whole.

Epoch (steps 13–15). Once a day per strategy, the executor proposes the strategy's NAV and liquid cash; the verifier recomputes both at the proposal slot and prices and co-signs them with an evidence hash; after the configured challenge window, anyone can finalize the epoch, which charges the performance fee on high-water-mark gains, protects 20% of net NAV as the next withdrawal reserve, and lets pending deposits and withdrawals settle at the final NAV (§2.5).

Reveal (step 16). After the execution is closed, its strategy's delay has passed and the reveal-period certificates for the days it was opened and closed have matured, the executor posts the opening on-chain together with the signed signal, receipt and policy evidence. The program checks that the opening hashes to the stored commitment. Rent is then reclaimed, leaving a permanent archive of the execution's public fields and a tombstone that prevents reuse of its index (§10 Reveal).

#2.5 The daily cycle

Deposits and withdrawals never settle at an unverified price. Each strategy has its own schedule: a next boundary timestamp one day (86,400 seconds) after its last finalization, and a next boundary slot at the configured number of slots per epoch. The executor may propose once the timestamp is due and no later than the boundary slot plus a configured proposal deadline. A proposal whose NAV per share differs from the last final value by more than 15% requires guardian review. The verifier's co-signature must match the immutable proposal exactly and arrive within the deadline; it opens the challenge window, during which anyone can post a bond to freeze finalization until the guardian resolves the challenge. Finalization is permissionless once the window has passed with no open challenge and any required guardian review resolved. Settlement of individual share accounts is also permissionless and follows a FIFO queue for withdrawals within the epoch's 20% budget. If a proposal cannot finalize, it is voided after a configured timeout, and owners keep the ability to exit at the last final NAV throughout (§8 Epochs and settlement).

#2.6 What is public when

Table 2.2 lists each class of information and who can read it at each stage.

Table 2.2 — Visibility of information by stage.

Before reveal, three parties can read private state, each through a distinct channel. The executor holds everything in its sealed journal. The verifier receives openings through an endpoint that requires a fresh Ed25519 proof from the registered verifier key, valid for 60 seconds, with a nonce that cannot be replayed. A leader reads only its own strategy through a one-use proof signed by the leader wallet, also valid for at most 60 seconds. The public API, the indexer and the database never receive the mapping.

The time at which an execution becomes public is the latest of three clocks. Let $t_c$ be the execution's closing time, $D_s$ its strategy's delay, $d_o$ and $d_c$ the UTC days of its opening and closing, $f_d$ the first time at or after the end of day $d$ at which the whole pool held no open notional (pending requests count as open), and $D_{\max }$ the longest delay of any strategy ever registered:

The second and third terms are the maturity times of the immutable reveal-period certificates the program issues for those days. They implement the rule that no opening of a day is published until every strategy active in that day has passed its own delay, without publishing which strategies were active (§10 Reveal).

#2.7 Clusters and deployment

The same program and services run on two clusters. On mainnet, the venue is Jupiter Perps and the mint is USDC. Devnet has no Jupiter Perps, so the devnet profile deploys the program with the fake venue adapter and a devnet test USDC mint, which exercises the whole flow end to end. Production configuration refuses fixture mode, development routes, the local fake attestation, the in-process test chain and the accelerated clock: the program accepts a clock scale other than 1 only in its separate local-testing build. Deployment consists of deploying the program, initializing Config, Pool and their accounts, starting the executor in its TDX VM so it can produce its attestation, registering the enclave key through the admin, and starting the Railway services (§14 Infrastructure).

#3. Strategies, shares and the pool

A strategy is a pooled account of equity owned by its leader and its followers in proportion to their shares. This chapter specifies the strategy and share accounts, how equity and NAV per share are computed, how shares are minted and burned, how the performance fee and leader compensation change the share supply at finalization, the caps and the leader stake, the strategy's states including the shadow period, how leaders and followers are admitted, and the shared pool that holds every strategy's cash.

#3.1 The strategy account

Each strategy is a program account at the PDA with seeds ["strategy", id], where id is a 32-byte identifier. The API's plan builder derives it as $H(\text{wallet}\Vert \text{":"}\Vert \text{idempotency key})$ over the leader's base58 wallet address, so a retried creation plan produces the same account. Table 3.1 lists the fields that matter for accounting and admission; §12 On-chain programs gives the complete layout.

Table 3.1 — Strategy account fields used by the share arithmetic.

The strategy account holds no position mapping: nothing in it identifies the execution accounts the strategy owns. Its parameters, AUM, flows and latest attested statistics are public from creation.

#3.2 The share account

Each owner's holding is a program account at ["share", strategy, owner]. Shares are a u128 balance in a ledger; there is no token mint and no transfer instruction.

Table 3.2 — Share account fields.

An account carries at most one pending request: a deposit requires no pending deposit or withdrawal, and so does a withdrawal. A request made while a proposal is active targets the epoch after it; otherwise it targets the next epoch.

#3.3 Equity

The equity of strategy $s$ at a valuation point is computed from its cash flows and its execution accounts. Let $D_s$, $W_s$ and $P_s$ be cumulative deposits (including the leader's stake), cumulative withdrawals paid and cumulative performance fees, and let $X_s$ be the set of execution accounts whose openings belong to $s$. For each execution $x$, $R_x$ is its realized PnL and $f_x^{\mathrm{exec}}$, $f_x^{\mathrm{venue}}$ the execution and venue fees charged to it. Then

where the unrealized PnL of a filled position with remaining notional $n_x$, entry price $p_x$ and oracle price $p_m$ is

Prices are in USD micros, amounts in USDC base units, and division truncates toward zero. A pending request contributes neither PnL nor fees; its collateral is still the strategy's equity at face value. For an epoch, the valuation point is the proposal slot and the oracle prices the program captured with the proposal. A venue fill that has landed but is not yet recorded on-chain blocks a proposal until it is recorded.

The same equity decomposes by asset as cash plus venue collateral plus unrealized PnL. Revealed history is checked against both identities (§10 Reveal). The verifier computes $E_s$ independently from its own RPC and the authenticated openings; the executor's proposal must equal it exactly (§8 Epochs and settlement).

#3.4 NAV per share

NAV per share $\pi$ is expressed in USDC base units per whole share, a whole share being $10^9$ share units:

where $S$ is the total share supply. The value of $s$ share units at NAV per share $\pi$ is $\lfloor s\pi /10^9\rfloor$. A strategy starts at the genesis NAV ${\pi }_0$, a deployment parameter that must be at least 1,000,000 (one USDC per share) and has no default; the local development profile uses 1,000,000. The program stores the last finalized value as last_nav and the running maximum as high_water_mark.

#3.5 Minting and burning

Shares change only at strategy creation, at settlement after a finalized epoch, through leader fee compensation (§3.6) and through owner-signed emergency withdrawal at the last final NAV.

At creation the leader's stake $k$ is transferred to the pool vault and minted at the genesis NAV:

A deposit $a$ is escrowed in the pool vault at request time and minted at the final NAV per share ${\pi }_f$ of the epoch it settles in:

Settlement adds $a$ to the owner's cost basis, to the strategy's AUM and liquid cash, and to the pool's executable cash.

A withdrawal of $s$ shares is paid from the epoch's withdrawal budget $B$ (§3.6). With $B_{\text{used}}$ already paid in that epoch, the amount available to the request at the head of the FIFO queue is

and the shares burned and the payout are

The payout is credited to claimable_withdraw and the cost basis falls by $\lfloor c\cdot s^{\ast }/s_{\text{held}}\rfloor$. A remainder stays queued in the same position and carries to the next epoch. A request worth zero base units at the last final NAV is refused when made; if a later NAV makes a queued remainder worth zero, settlement releases only that reservation, keeps the owner's shares and cost basis, and advances the queue.

Every conversion rounds down. Rounding residue therefore stays in the strategy's equity and accrues to the remaining holders.

#3.6 Finalization: performance fee, leader compensation and the high-water mark

Finalization applies the performance fee to followers only, and compensates the leader with shares so that the leader's own equity is unaffected by a fee the leader does not pay. Let $E$ be the proposed NAV, $S$ the share supply, $S_L$ the leader's shares, $\phi$ the fee rate in bps and ${\pi }_g=\lfloor E\cdot 10^9/S\rfloor$ the proposed NAV per share. The follower gain above the high-water mark and the fee are

The protocol share is $F_p=\lfloor F/5\rfloor$ (20%), or zero while a founding waiver is active, and the leader receives $F_L=F-F_p$ as a pull claim. To keep the leader's pre-fee equity $L$, the program mints compensation shares to the leader:

The rounding up assigns at most one share base unit to the leader. The finalized values are then

$B$, 20% of net NAV, is protected as the strategy's withdrawal reserve for the epoch. Finalization requires the verified liquid cash to cover the fee plus that reserve.

Table 3.3 works one finalization through with a genesis NAV of 1,000,000 (the local development value), a leader holding 10,000 shares, followers holding 20,000 shares, a proposed NAV of 33,000 USDC, the default fee of 1,500 bps and no waiver.

Table 3.3 — Worked finalization with real protocol rates.

The leader keeps exactly its pre-fee 11,000 USDC, and followers bear the full 300 USDC fee. Valued through the floored ${\pi }_f$, the leader's shares are worth 10,999.989861 USDC and the followers' 21,699.980000 USDC; the 0.030139 USDC difference is per-share rounding retained in equity. A deposit of 1,000 USDC settled in this epoch mints $\lfloor 10^9\times 10^9/1,084,999\rfloor =921,659,835,631$ units, 921.659835631 shares. §9 Fees specifies the fee rules, including the founding waiver, in full.

#3.7 Caps and capacity

Table 3.4 lists the bounds that apply to strategies and their flows, with the instruction that enforces each. $A$ is a strategy's AUM at the last final NAV and $Q$ its pending deposits; platform totals are kept in Config.

Table 3.4 — Caps and bounds.

The executor additionally limits each strategy's flow per market to a slice, 250,000 USDC per minute in the protocol defaults, and splits larger orders into slices (§5 The Sealed Executor). Because target weights are fractions of equity, the slice bounds how much equity a strategy can rebalance in a given time. For a change of direction $\Delta w$ (2 for a full long-to-short flip) at leverage $\lambda$, a per-minute slice $q$ and $T$ minutes allowed per rebalance, the capacity estimate is

A full flip at 3× rebalanced over 10 minutes gives $250,000\times 10/6\approx$ 417,000 USDC. This is an estimate, not a protocol constant; v0 caps each strategy at 250,000 USDC and the platform at 2,000,000 USDC.

#3.8 Leader stake

A leader must hold at least 5% of the strategy's equity, valued at the last final NAV per share $\pi$, counting every pending request against it. With $w_L$ the leader's shares pending withdrawal, a deposit $a$ is admitted only if

A leader's withdrawal request for $s$ shares requires

and settlement of $s^{\ast }$ leader shares requires $10^4(S_L-s^{\ast })\ge 500(S-s^{\ast })$. Leader emergency exits apply the same check, including pending leader withdrawals and follower deposits. The strategy's reserved equity can therefore never exceed 20 times the leader's equity. A stake worth 10,000 USDC supports at most 200,000 USDC of reserved equity; reaching the 250,000 USDC cap requires 12,500 USDC of leader equity. The leader holds its stake on the same terms as followers: it shares every fill and pays the same execution and venue costs per share, and the compensation in §3.6 only offsets a performance fee that followers alone owe.

#3.9 Strategy states and the shadow period

The public status of a strategy is derived from its account and Config, in this order:

1. Paused if the protocol is paused, if its latest attested drawdown has reached its declared kill level, or if it has been deactivated.
2. Shadow period if the current time is before shadow_ends_at.
3. Capped if $A+Q\ge$ 250,000 USDC.
4. Open otherwise. Deposits are accepted only in this state.

The shadow period lasts 30 days (2,592,000 seconds) from creation. During it the strategy trades the leader's stake under the same rules as any other strategy: epochs are proposed, verified and finalized, hourly statistics are attested, and executions follow the reveal rule. Deposits are refused until shadow_ends_at, so when a strategy opens to followers it already has a month of verified epochs and attested statistics.

A drawdown kill is the declared drawdown_kill_bps, bounded at creation by the configured protocol maximum. The published maximum drawdown is monotonic; once it reaches the declared level, deposits are refused, the strategy shows as paused, and the executor admits no new risk for it. A deactivated strategy is one that a permissionless deactivate_zero_strategy has retired: it requires zero AUM, no active epoch or pending cash flow and a flat pool, and it freezes the commitment count after which no execution can be attributed to that strategy. Its registry slot remains.

#3.10 Application and admission

Leaders. A prospective leader submits a public application with a name of at most 80 characters, the leader kind (human or agent), one or more distinct markets, the size of its own book (under_50k, 50k_250k, 250k_2m or over_2m), an optional wallet and a contact of at most 120 characters. The route requires an idempotency key, accepts ten writes per IP per minute and returns only an identifier, a status and a timestamp. An accepted applicant receives an invitation: the admin's invite_leader writes a LeaderInvitation account at ["leader_invitation", leader] with an expiry and a founding flag. create_strategy requires an unused, unexpired invitation for the signing wallet and marks it used; it grants the 90-day protocol-share waiver only if the invitation is marked founding. Creation also checks every parameter bound in Table 3.1, the strategy count, the caps, transfers the stake, mints the leader's shares, registers the signal key, appends the strategy to the registry in Config and raises the registry's longest-ever reveal delay if D exceeds it.

Followers. A follower submits an access request with its wallet, an optional contact and the literal attestations notUSPerson: true and notInEU: true. The request alone grants nothing. Screening runs through the Range risk API when its key is configured, and otherwise through an allowlist the operator manages; the admin then writes an Eligibility account at ["eligibility", owner] holding an allowed flag and an expiry. request_deposit requires that account to be allowed and unexpired. Eligibility gates deposits only: withdrawal requests, cancellations, claims and emergency withdrawals need nothing but the owner's signature.

#3.11 The shared pool

All strategies share one Pool account at ["pool", venue_program] and its USDC vault. The pool separates three kinds of balance. Executable cash is the cash available to trading, from which collateral is drawn. Protected withdrawal reserves are the sum of every strategy's 20% reserve; no execution and no ordinary execution fee can spend them. Escrowed deposits sit in the vault but are outside executable cash until they settle, so pending funds cannot finance trades.

Each strategy's own share of the cash is its liquid_cash, checked at every finalization. Before an order is authorized, the verifier checks that the selected strategy's own liquid cash covers its withdrawal reserve, prospective fees, the new margin and every earlier authorization still able to land; another strategy's idle cash cannot satisfy that check. Independently, the program admits new pool risk only if it fits a conservative envelope computed over the complete strategy registry at the smallest active strategy's capacity, without knowing which strategy the order belongs to (§5 The Sealed Executor, §12 On-chain programs). The pool also stores the head and length of the commitment hash chain that every execution extends (§6 Exec accounts and commitments).

#4. Signals

A signal is the only instruction a leader gives the protocol: the portfolio the strategy should hold, as target weights of equity, and the conditions under which the request may be carried out. This chapter specifies target weights, the signed fields and their canonical encoding, deployment binding, sealing, admission and receipts, sequence and validity, sizing into slices, lifecycle states and retries.

#4.1 Target weights

A target weight names a market, a side and a weight in basis points of strategy equity. SOL long 15000 means a long SOL position with notional equal to 150% of equity. Leverage is already contained in the weight and is not applied again. A signal carries one to three targets, each market at most once, and the sum of the weights must not exceed the strategy's declared maximum leverage, itself at most 30,000 bps (3×).

A signal describes the strategy's whole book, not an order. The executor trades only the difference between target and current position; a weight of 0 closes its market, and a market in the signal's scope that the targets omit is driven to zero (§4.8). Because weights are fractions of equity, signals scale with AUM, and resending one cannot double a position (§4.10).

For market $m$, let $w_m$ be the signed weight (positive for long, negative for short, zero when omitted), $E$ the strategy's equity at sizing and $c_m$ its current signed filled notional. The target notional and the difference to trade are

With 30,000 USDC of equity and an existing SOL long of 15,000 USDC, the signal SOL long 15000, ETH short 5000 gives $n_{\mathrm{SOL}}^{\ast }=45,000$ and ${\delta }_{\mathrm{SOL}}=+30,000$ USDC, and $n_{\mathrm{ETH}}^{\ast }={\delta }_{\mathrm{ETH}}=-15,000$ USDC. The weights sum to 20,000 bps, so the strategy must have declared a maximum leverage of at least 2×.

#4.2 Signal fields

Live signals use version 2. Table 4.1 lists the fields of a signed signal as it is sealed and submitted.

Table 4.1 — Fields of a signed signal (version 2).

#4.3 Canonical signing encoding

The signal key signs a fixed UTF-8 JSON serialization of every field except version and signature, preceded by a domain string. The keys appear in exactly this order, with no whitespace and no trailing newline:

{"domain":"unseen-signal-v2","genesisHash":"<base58>","programId":"<base58>","executorPublicKey":"<base58>","strategyId":"<64 hex>","sequence":"7","targets":[{"market":"SOL","side":"long","weightBps":"15000"},{"market":"ETH","side":"short","weightBps":"5000"}],"validUntilSlot":"<decimal slot>","maxOracleDeviationBps":"30","signalKey":"<base58>"}

Target objects have the keys market, side, weightBps in that order, and targets keep the order the leader listed them in. Integers are canonical decimal strings: digits only, no sign, no leading zero except 0. Every value is base58, lowercase hex, decimal digits or a fixed market or side name, so no JSON escaping applies, and JSON.stringify in a browser and serde_json in the Rust executor and verifier produce identical bytes.

The signal key signs these bytes with Ed25519, and the executor verifies with strict Ed25519 verification. The signed-signal hash, referenced by the receipt, the policy evidence and the commitment, covers the bytes and the raw 64-byte signature:

Version 1 used the domain unseen-signal-v1 and omitted the three deployment fields. Its encoder is kept so that historical V1 proofs remain verifiable; the executor refuses version 1 for any live signal.

#4.4 Deployment binding

The deployment fields bind a signal to one cluster (genesisHash), one deployment of the program on it (programId) and one attested executor identity (executorPublicKey). A devnet signal fails on mainnet, a second deployment refuses the first one's signals, and signals made for an enclave key are refused once that key is rotated. The executor compares all three with its chain snapshot: the genesis hash, which must also equal Config.deployment_genesis, the program ID and Config.enclave. The verifier repeats the comparison from its own RPC at admission. The same three values are bound into the sealed envelope's authenticated data (§4.5), the receipt (§4.6), the V2 commitment preimage (§6 Exec accounts and commitments) and the leader-view proof (§4.11). A client reads them from GET /v1/deployment and checks them against independently pinned values before signing.

#4.5 Sealing and transport

A signal is never sent in clear. The client seals the signed signal to an encryption key that only the attested executor holds.

1. Attestation. The client verifies the executor's Intel Trust Authority token against a pinned trust policy (issuer, signing keys, TDX measurement and workload policy identifiers). Its report data must equal the SHA-512 hash of this runtime binding, which ties the executor's Ed25519 key and P-256 encryption key to the deployment (§5 The Sealed Executor):

   unseen-tdx-runtime-v1\n<genesisHash>\n<programId>\n<executorPublicKey>\n<encryptionPublicKey>
   

2. Key agreement. An ephemeral P-256 key pair and the executor's encryption key give an ECDH shared secret; HKDF-SHA256 with salt $H(\text{aad})$ and info unseen-sealed-signal-v1 derives a 256-bit key.

3. Encryption. AES-256-GCM encrypts the JSON of the signed signal under a random 12-byte nonce with a 128-bit tag and the authenticated data unseen-sealed-signal-v1\n<genesisHash>\n<programId>\n<executorPublicKey>.

4. Envelope. {version: "unseen-sealed-signal-v1", ephemeralPublicKey, nonce, ciphertext}, holding the 65-byte uncompressed key, the nonce and the ciphertext with its tag, each in standard base64.

The envelope goes to the executor's POST /v1/signals/sealed, or through the API relay at the same path for a browser that cannot reach the VM. The relay requires a leader session, accepts 60 envelopes per wallet per minute, checks only the envelope's shape (canonical base64, a 65-byte key beginning with 0x04, a 12-byte nonce, 17 to 16,384 ciphertext bytes) and forwards it with a 15-second timeout; it has no key that could decrypt it. The executor refuses envelopes while its attestation is expired, decryption under another deployment's authenticated data fails, and a production executor refuses unsealed signals.

#4.6 Admission and the receipt

Inside the VM, the executor decrypts the envelope and applies the following checks in order. The first failure ends admission.

1. The signature verifies under signalKey; version is 2 and sequence is positive.
2. If the strategy already has a signal with this sequence, identical canonical bytes are an exact replay and return the original acknowledgment (§4.10), and different bytes are refused as REPLAY_DETECTED. Otherwise the sequence must exceed every earlier sequence of the strategy.
3. The strategy exists, signalKey is its registered key, and the deployment fields match (§4.4).
4. validUntilSlot is above the current slot and maxOracleDeviationBps is at most 10,000.
5. The strategy is not paused, and the targets satisfy Table 4.1 with their sum within $\min (\text{max\_leverage\_bps},30,000)$.
6. The strategy's drawdown, recomputed from current equity, is below its declared kill level.
7. The signal key is within its admission rate, a configured number per minute charged only after the signature and key checks (60 in the local development profile).

The executor then assigns a receipt. Its sequence $r$ is one more than the largest it has issued across all strategies, and its time is

so receipt times strictly increase with receipt sequence. The enclave key signs the receipt bytes, the newline-joined lines:

unseen-receipt-v2
<genesisHash>
<programId>
<executorPublicKey>
<receiptSequence>
<receivedAtUnixMicros>
<signedSignalHash>

The executor persists the record in its sealed journal and submits it to the verifier, authenticated with the enclave key. The verifier admits it only if the receipt sequence is exactly one more than the last it admitted and the receipt time is strictly later; it then rechecks the signal against its own RPC (registered key, deployment, signature, signed-signal hash, receipt signature, markets and leverage), freezes the receipt's market scope (§4.8) and persists the record in its own journal. Only after this does the executor acknowledge the signal.

The acknowledgment (RealSignalReceipt, acceptedForExecution: true) returns the signal as admitted, always in state received, with the receipt: deployment fields, receiptSequence, receivedAtUnixMicros, signedSignalHash and receiptSignature. The SDK accepts it only if the deployment fields match, signedSignalHash equals its own computation and the receipt signature verifies under the executor key.

A receipt proves admission and a place in the global order, not sizing or fills, and a replay returns the same document. Its sequence, time and signed-signal hash enter the V2 commitment of every execution the signal opens, so after reveal anyone can check which signal caused an execution and in what order competing signals arrived (§6, §10).

#4.7 Sequence, validity and deviation

Sequence. Each strategy's sequences start at 1 and strictly increase; gaps are allowed. The pair (strategy, sequence) is the signal's identity for idempotency, and the sequence appears in every commitment and opening the signal produces.

Validity. validUntilSlot is checked at admission, before sizing (an expired signal is dropped), before each action is submitted, and on-chain: execute, partial_close and close_exec each require the current slot not to exceed the validity slot they carry, which for ordinary actions is the signal's and is bound into the policy evidence. A request already funded at the venue stays reserved after expiry until it fills or is refunded at its retry deadline (§4.10).

Oracle deviation. Every venue request carries one common, configured wire slippage bound, so the public request reveals nothing about the leader's tolerance. The leader's maxOracleDeviationBps is enforced privately: while a request is pending, the executor compares the oracle price $p$ with the request's reference price $p_{\text{ref}}$ and cancels when

The cancellation is a dual-signed refund-only close returning all collateral to the pool; the signal's remaining actions in that market end with oracle_deviation. The verifier checks the bound independently.

#4.8 From signal to slices

The verifier freezes each receipt's market scope at admission: the markets in its targets, every market where the strategy has a pending or filled position, and every market still held by an unfinished earlier receipt of the strategy. A market in scope with zero gap and no pending work completes at once as a no-op and never reopens for that receipt. The executor sizes each remaining market with the formula of §4.1:

• Same direction, larger: open ${\delta }_m$ of new exposure on fresh execution accounts.
• Same direction, smaller: reduce existing execution accounts by $|{\delta }_m|$, closing each account entirely when the reduction covers it; a partial reduction keeps the account and its entry price.
• Direction flip: close the existing exposure, then open $n_m^{\ast }$ on a fresh execution account.

Reductions precede openings, so collateral is released and gross exposure falls first. Openings are split into slices of at most the configured slice size (250,000 USDC in the protocol defaults), each with collateral $\lceil n\rho /10^4\rceil$ at the common collateral ratio $\rho$. Just before it is sent, a slice is resized to $\min (n_{\text{slice}},|{\delta }_m|)$; if ${\delta }_m$ has reached zero or reversed, it completes unsent.

Continuing the example of §4.1, ${\delta }_{\mathrm{SOL}}=+30,000$ USDC is one opening slice, carrying 10,002 USDC of collateral at the local development ratio of 3,334 bps. Had the signal been SOL short 10000, the executor would close the 15,000 USDC long and then open a 30,000 USDC short on a fresh execution account.

A later receipt's action never overtakes an unfinished action in the same market from an earlier admissible receipt (§5 The Sealed Executor).

#4.9 Lifecycle states and reasons

A signal moves through five states and each of its slices through four (Figure 4.2): received (admitted, not yet sized), sized (actions computed from current equity and positions), sliced (actions being dispatched), and the terminal filled or dropped.

Table 4.2 — Reasons reported in the leader console.

The executor's journal records three finer causes: drawdown_limit when the strategy has reached its declared drawdown kill level and its unfinished actions are stopped, target_reached when an opening slice becomes unnecessary and completes as filled, and request_refunded when an unfilled request is cancelled with its principal returned to the pool.

#4.10 Retries

Submission. Without an acknowledgment, the client resends the identical signed signal, with the same sequence, targets, validUntilSlot and deviation bound, and therefore the same bytes. The executor recognizes the (strategy, sequence) pair and returns the original acknowledgment. The replay is not charged against the key's rate, and it completes the verifier's admission of the stored record if that had not finished; no intent ever receives a second receipt. A client must not turn an uncertain response into a new signal with a higher sequence, which would be a second order. The CLI prints the validUntilSlot it signed so that a retry reproduces the bytes.

Table 4.3 — Admission responses and the client action for each.

Venue. An unfilled funded request is retried until the execution's authenticated creation slot plus the retry window $N$, a configured parameter stored as Config.retry_slots (300 slots in the local development profile). It is then dropped, its collateral returns to the pool and the slice ends with retry_window_exhausted. A keeper fill that lands before the cancellation is recorded instead, through a dual-signed reconciliation that requires the original admission, commitment, policy hash and venue fill.

Capacity. A slice that does not fit the pool's common envelope stays queued with pool_capacity at its exact signed size, keeps its place in the market's receipt order, and is dropped as expired if its signal's validity ends first.

Key rotation. After a wallet-signed rotate_signal_key, signals must use the new key. Old-key work that has not landed is retired, and a never-filled request is refunded through the principal-only cancellation path even after its signal expired. Filled openings keep their original signature, receipt and commitment and stay valid for NAV and public replay.

#4.11 Reading the lifecycle

A leader reads current signals, slices, reasons, positions, fills and fees only through a leader-view proof: canonical JSON with the domain unseen-leader-view-v2 binding the deployment fields, the strategy, the leader wallet, a random 32-byte nonce, issuedAt and an expiresAt at most 60 seconds later. The leader wallet signs it, not the signal key. The leader posts the proof to the API's POST /v1/leader/strategies/:strategyId/console, which forwards it unchanged to the executor, and the executor verifies the signature, the deployment, on-chain leadership of the strategy and the single use of the nonce. A revealed signed signal therefore grants no access to the strategy's later activity (§15 Interfaces).

#5. The Sealed Executor

The Sealed Executor is the component that decrypts signals and keeps the strategy-to-account mapping. Before reveal, plaintext signals and the mapping exist only inside it and, for verification, at the independent verifier. It is a Rust service running inside an Intel TDX confidential VM. It decrypts sealed signals, signs receipts, sizes one pooled order per signal, slices it, orders it against every other strategy's work and submits the transactions that move collateral from the pool into fresh exec accounts. It also proposes each strategy's daily NAV (§8 Epochs and settlement) and posts openings once their reveal conditions hold (§10 Reveal).

Its authority is narrow by construction. The program moves funds for it only along pool → exec → approved venue and back to the fixed pool vault (§12 On-chain programs). Every execute, fill record, reduction, close and stats transaction also carries the independent verifier's signature, and the verifier signs only after replaying the policy from the leader's signed signal (§5.5). The executor holds no follower key and no admin key, and no instruction lets it withdraw.

#5.1 The confidential VM

The production executor runs as a container image on a cloud confidential VM with Intel TDX, such as a GCP C3 confidential VM or an Azure DCesv5 instance. TDX measures the VM's initial image into MRTD, a 48-byte register, and later boot and runtime components into the RTMRs. Unseen pins MRTD directly and pins the measured OS and executor workload, RTMRs included, through Intel Trust Authority (ITA) policies.

The executor generates its Ed25519 enclave signing key inside the trust domain on first start and keeps it on the VM's encrypted volume; the secret never leaves the VM. This key, registered on-chain as the EnclaveKey, signs receipts, transactions, proposals, stats and reveals. The P-256 key that opens sealed signals is derived from it under the domain unseen-sealed-signal-key-v1, so no second secret exists. A symmetric key sealed to the VM encrypts the private store state.enc (signals, receipts, openings, policy histories, flow reservations, job state) with XChaCha20-Poly1305. Each save is anchored to a monotonic counter kept by the verifier, whose signed replies bind the ciphertext hash, so an older ciphertext cannot be restored. The public database never receives the strategy-to-account mapping.

#5.2 Quote and key binding

The attestation has to prove that the keys a client is about to use belong to the measured executor of this deployment. The executor writes a binding string, lines separated by LF:

unseen-tdx-runtime-v1
<genesis hash>
<unseen program ID>
<executor Ed25519 public key, base58>
<P-256 encryption public key, base64 SEC1 uncompressed>

Its SHA-512 digest, exactly 64 bytes, becomes the TDX report data. The executor obtains a quote through the Linux configfs-tsm interface under /sys/kernel/config/tsm/report: it requires the provider tdx_guest, writes the report data to inblob and reads the quote from outblob, accepting it only if the entry's generation advanced by exactly one. The quote carries MRTD, the RTMRs and the report data under the platform's signature. A relay that substitutes its own encryption key changes the digest and no longer matches the quote.

The executor posts the quote and the binding string as runtime data to ITA with its API key, naming the configured policy IDs, requiring every policy to match and asking for a PS384-signed token. Before publishing the token it verifies it itself, with the same pins a client uses (§5.3) plus a freshness bound. It then publishes the token, both public keys, the MRTD, the report data and the token's issue and expiry times as Deployment.executor.attestation on the public route GET /v1/deployment, next to the cluster, program IDs and USDC mint, and refreshes the short-lived token as it ages.

On chain the enclave key enters the registry only through the admin. The Squads multisig calls schedule_enclave(key, expiry, measurement_hash, report_hash); the program requires a key different from the current one, nonzero 32-byte hashes, and an expiry more than 172,800 seconds ahead. After the 48-hour timelock anyone may call activate_enclave, which creates EnclaveKey at ["enclave", key] and replaces Config.enclave. The guardian revokes instantly with set_pause(paused, revoke_enclave = true). Every enclave-signed instruction checks that the signer equals both EnclaveKey.public_key and Config.enclave, that neither record is revoked, and that the logical clock is before both expiries. The key lifetime is a configured deployment parameter.

#5.3 How clients check the attestation

The signal SDK runs on Web Crypto alone, in browsers and in the CLI. Its trust policy is configured independently of the executor: the deployment pins (genesis hash, program ID, executor public key), the ITA issuer and JWKS URL, the expected MRTD and the expected ITA policy IDs. A key URL carried inside the token is never followed. Before the signal key signs anything, the SDK applies every check in Table 5.1 and stops on the first failure.

Table 5.1 — Attestation checks run by the signal SDK before every signature.

Once the attestation passes, the SDK signs the canonical V2 signal bytes (§4 Signals), verifies the signature, and seals the signed signal: an ephemeral P-256 key agrees a secret with encryptionPublicKey by ECDH, HKDF-SHA256 (salt = SHA-256 of the associated data, info unseen-sealed-signal-v1) derives an AES-256-GCM key, and the JSON signal is encrypted under a random 12-byte nonce with the associated data unseen-sealed-signal-v1, genesis hash, program ID and executor key, joined by LF.

The envelope {version, ephemeralPublicKey, nonce, ciphertext} names no wallet, strategy, market, target or sequence. The SDK posts it to the executor's HTTPS endpoint at /v1/signals/sealed, or, when a browser cannot reach the VM, to the API at the same path, which relays it unchanged. Whichever TLS connection carries the envelope, only the VM that produced the quote holds the key that opens it; this is the attested channel. The SDK accepts the response only if its receipt repeats the signal's deployment fields, its signedSignalHash equals SHA-256 of the signing bytes followed by the 64-byte signature, and the receipt signature verifies under the pinned executor key. Attestation is re-checked before every signature, so an expired token stops signing.

#5.4 Admission and receipts

After decryption the executor applies the admission checks of Table 5.2, then assigns a receipt. The receipt sequence is one more than the highest sequence it has ever issued, across all strategies. The receipt time is in Unix microseconds and is forced to be strictly increasing: $t_n=\max (\text{clock},t_{n-1}+1)$. The enclave key signs

unseen-receipt-v2
<genesis hash>
<program ID>
<executor public key>
<receipt sequence>
<received at, Unix microseconds>
<signed signal hash>

with LF separators and no trailing newline. The record is saved to the sealed store and sent to the verifier, which checks both signatures and the registered signal key, requires the receipt sequence to be exactly one more than the last it admitted with a strictly later time, and freezes the markets the receipt affects. Only then does the executor acknowledge, with an immutable received acknowledgement carrying the receipt (§4 Signals). Receipt sequence and time are inside every V2 commitment (§6 Exec accounts and commitments), so once openings are public anyone can check that executions followed receipt order.

#5.5 The risk engine

The risk engine is the set of rules that every signal and every slice must pass. The executor applies them first. The verifier applies them again, independently, from the signed signal, the authenticated openings and its own RPC reads before it co-signs a transaction. The program enforces the parts that need no attribution. Table 5.2 lists where each rule runs.

Table 5.2 — Risk rules and where they are enforced.

Drawdown. With $E$ the recomputed NAV and $S$ the share supply, the NAV per share is $p=\lfloor E\cdot 10^9/S\rfloor$. The reference peak $P$ is the largest of the genesis NAV, the high-water mark, the last final NAV per share and the highest value the executor has observed. Drawdown never decreases:

When $\mathrm{dd}$ reaches the strategy's declared drawdown_kill_bps, new signals are refused, queued work is dropped with reason drawdown_limit, unfilled requests are cancelled and filled positions are closed. The declared level is bounded on-chain by Config.max_drawdown_bps (configured; local development value 2,000 bps).

Own cash. Pooled idle cash from another strategy never funds an order. The verifier recomputes the strategy's liquid cash $L$, which is its NAV less the collateral of its pending and filled positions and less their unrealized PnL, and requires

where $\lfloor E/5\rfloor$ is the next epoch's 20% withdrawal reserve, $F_{\text{perf}}$ the prospective performance fee, $A$ the candidate plus every authorization that can still land without an existing exec (deduplicated by exec PDA, across all markets and sides), $P$ the strategy's funded pending requests whose principal is already deducted from $L$, and $\varphi$ the venue opening-fee bound of the production adapter (the development venue uses $\lfloor 6n/10^4\rfloor$).

Forced reductions. Three conditions authorize a reduction without a new leader signal: drawdown at the kill level, cash below the settlement reserve (withdrawal_liquidity) and leverage above the declared maximum after pending withdrawals (withdrawal_leverage). The verifier then signs an unseen-risk-reduction-v2 certificate binding the original signal hash and receipt, the exec and its next operation sequence, the reduced notional, the reason, an expiry within the retry window and the recomputed NAV, cash and drawdown. Its hash becomes the reduction's policy hash (§6). A certificate can only reduce or close an existing filled position.

#5.6 Sizing

A signal states target weights in basis points of strategy equity; a weight already includes leverage, so 15,000 bps means a position worth 1.5 times equity. For market $m$ the executor computes, with $E$ the strategy NAV recomputed from chain data and openings, $w_m$ signed (shorts negative), and $n_x$ the remaining notional of each filled exec $x$ of the strategy in that market:

where ${\sigma }_x=+1$ for a long and $-1$ for a short. Three cases follow.

1. Increase in the same direction ($C_m=0$, or $T_m$ and $C_m$ share a sign with $|T_m|>|C_m|$): open $|{\Delta }_m|$ on the side of ${\Delta }_m$.
2. Reduction in the same direction ($|T_m|<|C_m|$, same sign): reduce $|C_m|-|T_m|$, walking the existing execs, with a partial close where the reduction is smaller than an exec's remaining notional and a full close otherwise.
3. Sign flip: close all of $|C_m|$, then open $|T_m|$ on the new side from fresh exec accounts.

All reductions and closes of a signal are ordered before its openings, so collateral is released before new margin is posted. Each opening is cut into slices of at most 250,000 USDC (§5.7), each with collateral $c=\lceil n\cdot r/10^4\rceil$, where $r$ is the common collateral ratio (configured within 3,334–10,000 bps; local development value 3,334 bps). Immediately before a slice is submitted, the executor repeats the computation at the current NAV and position and trims the slice to $\min (n,|{\Delta }_m|)$; if the target has been reached or the sign has turned, the slice is marked done with reason target_reached.

Table 5.3 — Sizing one signal, with the local development collateral ratio and venue fee bound and no performance fee due.

#5.7 Slicing and the per-minute flow limit

Slicing bounds how fast the pool trades a market. Three limits apply.

• Per action. No exec opens with more than 250,000 USDC notional; the program rejects larger execute calls.
• Per strategy and market. Before a slice, partial close or close is submitted, the executor reserves its notional in a flow window keyed by strategy and market. Openings and reductions consume the same absolute budget of 250,000 USDC per window. The production window is 60 seconds (local development: 5 seconds). A slice that does not fit waits for the next window.
• Per pool and market. The program keeps flow_minute[m] and flow_notional[m] and charges every execute, every partial_close and every full close_exec (a refund-only cancellation is not charged); gross notional per market per logical minute may not exceed 250,000 USDC. Because the pool counter covers every strategy, each strategy's flow is bounded as well.

A rebalance that moves gross notional $G$ in one market therefore takes at least $\lceil G/250,000\rceil$ minutes, which is what bounds a strategy's capacity (§7.5).

A slice that has landed as a venue request waits for the keeper. Its on-chain expiry is the creation slot plus Config.retry_slots, a configured parameter (local development value 300 slots). If it is still unfilled when the window ends, or when the signal expires, or when the oracle has moved further from the request's reference price than the leader's bound, the executor cancels it through the principal-only refund path, all collateral returns to the pool, and the slice is reported as dropped with its reason.

#5.8 Pool capacity before dispatch

The program cannot know which strategy owns a new exec, so it checks each risk increase against every possible owner. Every execute passes the complete strategy registry, in registry order. For each active strategy $s$ the program computes a conservative equity

where $V_s^{\text{wd}}$ is the value of its pending withdrawals at the last final NAV, $R-R_s$ the pool's realized losses and execution fees since the strategy's last final checkpoint, $\Lambda$ an upper bound on the sum of all unrealized losses in the pool, and $\Phi =\lceil 16\cdot N/10^4\rceil$ a fee bound on aggregate notional $N$ including the candidate. $\Lambda$ uses per-market long and short notional and the worst entry extremes, widened by the common wire slippage at entry, and never nets one position's profit against another's loss. The candidate passes only if

with $K_{\text{locked}}$ the original collateral of all pending and filled requests and ${\mathrm{reserve}}_s$ the strategy's protected withdrawal reserve. The market must be allowed by every active strategy, and pool cash net of protected reserves must cover $c$.

The executor evaluates the same envelope before dispatching an opening, adding the pending requests' fee reservations, the remaining minute flow and the remaining daily fee budget. An opening that does not fit is not clipped: it keeps its size with reason pool_capacity and resumes when capacity returns, or is dropped when its signal expires. Reductions and funded requests never wait.

Table 5.4 — The shared envelope for an empty pool, with the local development SOL price of 100 USD, wire slippage of 100 bps and collateral ratio of 3,334 bps. $\Lambda$ = 2,475.25 and $\Phi$ = 400 USDC in both rows.

Capacity is deliberately shared at the bound of the smallest active strategy. A strategy with zero equity would block all new risk, so deactivate_zero_strategy lets anyone retire one that has zero AUM, no active epoch, no pending cash flows and a flat pool; it freezes active_until_sequence at the current commitment count.

#5.9 FIFO ordering and batching

Priority is the global receipt sequence. A receipt's next action may be dispatched only if no earlier receipt still has an unfinished action in the same market. An earlier receipt with several markets reserves all of them, including markets behind its current head, and an earlier receipt that has not been sized yet reserves every market in its targets. Receipts of a paused strategy, or of a strategy whose proposal is awaiting finalization, reserve nothing, so one strategy's frozen state does not block another strategy that shares its market.

Order within FIFO is relaxed in one case. When two or three fresh opening heads in distinct markets are ready together, the executor computes the pool resources at the final state of the whole batch: cash after collateral and nominal fees, open-interest ceiling, minute flow per market and daily execution-fee budget. Every reservation is non-negative, so if the final state fits, every prefix of every permutation fits too, and the executor shuffles the batch with a random permutation before dispatch. If any input is scarce, missing or malformed, or if a reduction is involved, receipt order is kept. Reductions get no credit for cash they will release until they have landed.

A batch, for fee purposes, is the set of actions from receipts received in the same chain slot. Its identifier is SHA-256 of unseen-batch-v2, genesis hash, executor key and receipt slot, joined by LF. A batch price-impact fee $I$ over total notional $N$ is split by notional with a prefix-floor rule that conserves the exact total and gives the remainder to members in receipt order:

where $N_{<i}$ is the notional of the members before $i$. A fee of 100 over members of 2, 3 and 5 gives 20, 30 and 50; a fee of 2 over three equal members gives 0, 1 and 1. Each member's policy evidence records the batch and its own allocation (§6).

#5.10 Signing and sending

An unsigned-transaction bridge outside the VM assembles transactions and holds no role key. The executor and the verifier each decode the prepared bytes and rebuild the expected instruction data, PDAs, signers and deployment from their own RPC reads; the verifier also re-runs the policy, records the authorization in its encrypted journal and returns a partial signature, and the enclave key adds its own. Priority settings are in the message before either role signs: a compute-unit limit (at most 1,400,000), a compute-unit price and, for Jito or Helius, a tip transfer to a published tip account. Sending never changes bytes. The sender first simulates with signature verification on its own HTTPS RPC, because the bundle path skips preflight.

Table 5.5 — Sender modes. Compute-unit limit, price and tip are configured values.

Each request times out after 15 seconds, and a retry resends the identical signed bytes, so an ambiguous outcome never becomes a second economic action. The opening execute and the keeper's fill are separate transactions: execute creates the venue request, the keeper fills it at the oracle price, and the executor and verifier then record the fill with record_fill, which charges the 2 bps execution fee (§7 Venue: Jupiter Perps). No NAV can be proposed for a strategy while one of its landed fills is unrecorded.

#6. Exec accounts and commitments

Every position Unseen opens lives in its own program-derived account, funded from the shared pool vault and addressed by a random 64-bit index. The account shows the trade, which is public by necessity, and a 32-byte commitment to its owner, which stays sealed until reveal. Commitments are appended to a single pool-wide hash chain, so the order and number of executions are fixed on-chain at the moment they happen. This chapter specifies the accounts, the two commitment encodings, the chain, how a position is reduced without changing account, and how accounts are closed and their rent recovered. The reveal conditions themselves are in §10 Reveal.

#6.1 Accounts created per position

One execute instruction creates the accounts of Table 6.1. Every address is derived from fixed seeds; the only free input is the index.

Table 6.1 — Accounts created by one execute.

The pool itself is the PDA ["pool", venue_program], and its USDC vault is ["pool_vault"] with the pool as token authority. The exec PDA signs for the venue request and for its own vault with the seeds ["exec", pool, index_u64_le, bump]; no key exists for it. The enclave key pays the rent of the accounts created in execute. Rent recovered at cleanup goes to the pool PDA (§6.8).

#6.2 The random 64-bit index

The index is the only variable seed of an exec address. For each new position the executor draws a 64-bit integer from the operating system's random source and rejects it if an execution with that index already appears in its chain snapshot or in its private positions, drawing up to 32 times. The program provides the hard guarantee: Exec is created with Anchor init, which fails if the address already holds an account, and a reclaimed exec is never deleted but shrunk to a tombstone (§6.8), so an index can never be used twice, even after cleanup.

A random index carries no information. There is no per-strategy counter, so the address of an exec reveals neither which strategy opened it, nor how many positions that strategy has opened, nor in what order. The exec account stores no strategy ID and no signal sequence; the index space has $2^{64}$ values, shared by every strategy in the pool.

#6.3 What an exec account shows

Exec is a fixed-size Anchor account of 341 bytes: an 8-byte discriminator and 333 bytes of fields.

Table 6.2 — Fields of Exec.

Every public value is a function of the pooled order and of deployment-wide parameters, never of a strategy's own parameters. Collateral is $\lceil n\cdot r/10^4\rceil$ with one common ratio $r$ for the whole pool, and the venue request carries one common wire slippage bound. A leader's declared leverage and private oracle-deviation limit are enforced off-chain by the executor and the verifier (§5.5) and never select an on-chain field. The policy hashes are 32-byte digests whose preimages are sealed with the opening.

#6.4 Commitment V1

The original encoding, unseen-sha256-v1, commits to the four values named in the product brief. Its preimage is exactly 80 bytes; integers are little-endian.

Table 6.3 — V1 opening, 80 bytes; commitment = SHA-256(preimage).

The salt is 32 bytes from the operating system's random source, fresh for every exec. It is what makes the commitment hiding: strategy IDs are public, the exec index is visible in the account, and signal sequences are small integers, so without 256 bits of salt an observer could test every strategy against every commitment. V1 remains supported for legacy contract fixtures and is opened by the reveal instruction, which recomputes the hash on-chain. New live executions use V2.

#6.5 Commitment V2

V2 commits to the deployment, the executor, the leader's signed signal, the executor's signed receipt and the policy evidence that sized the trade. Its preimage is 273 bytes.

Table 6.4 — V2 opening, 273 bytes; commitment = SHA-256(preimage).

The two nested hashes extend the commitment to the full evidence without enlarging it.

• Signed signal hash: SHA-256 of the canonical V2 signal signing bytes (§4 Signals) followed by the raw 64-byte Ed25519 signature. It binds the targets, validity slot, oracle-deviation bound and signal key, and the signature itself.
• Policy evidence hash: SHA-256 of a fixed 392-byte binary record, "unseen-policy-v2" (16 bytes) followed by: genesis, program, executor, strategy and signed signal hash (32 bytes each); receipt sequence (u64); batch ID (32); batch index and batch size (u32 each); ten u64 amounts and slots, namely batch total notional, batch impact fee, member notional, original notional, allowed reduction notional, allocated impact, venue and execution fees, sizing slot and sizing equity; prior signed notional (i128); target weight in bps (i64); declared maximum leverage, declared drawdown kill level and reveal delay (u64 each); prior policy hash (32); and the validity slot (u64). The commitment and the policy record are fixed binary layouts; only the signal's signing bytes are canonical JSON.

The receipt fields sit in the preimage, and the published evidence also carries the enclave's signature over them: unseen-receipt-v2, genesis, program, executor, receipt sequence, receipt time and signed signal hash (§5.4). A revealed V2 opening is therefore checkable without trusting the executor's word on any field: the commitment recomputes from the preimage, the signal signature verifies under the registered signal key, the receipt signature under the enclave key, and the policy record reproduces the sizing. The shared Rust and TypeScript implementations are pinned to the same vector:

genesis = 01×32, program = 02×32, executor = 03×32, strategy = 04×32
exec_index = 18446744073709551615, signal_sequence = 7
receipt_sequence = 42, received_at_unix_micros = 1700000000123456
signed_signal_hash = 6b8c341de4a2a743241b35fe48799a0345f74a223a2b54d55430e78d3c6eb9fd
salt = 05×32
policy_evidence_hash = 91629885f9214898bc0358e8df5fc646fbd5a579fd915f42e4c2ed2e42eafbdc
commitment = 878235a4eb7fff0c354d75ca8ad2bb337682acabe93a7367a9474a9f7cd798ed

On-chain, reveal_v2 takes the opening fields as instruction data, recomputes the commitment with the stored Config.deployment_genesis, the program's own ID and the executor recorded in the exec at creation, and requires equality with the CommitmentReceipt. It also requires the supplied policy hash to equal Exec.policy_evidence_hash. Binding the genesis hash, program and executor means an opening from one deployment or executor key cannot be presented as an opening in another.

#6.6 The on-chain hash chain

The pool keeps a running head and count. Both start at zero, and every successful execute updates them in the same instruction that creates the exec:

where $c_k$ is the commitment of the $k$-th execution. The exec stores previous_head $=h_{k-1}$, resulting_head $=h_k$ and chain_sequence $=k$, and the ExecutionCommitted event carries the exec address, index, commitment, both heads, notional, market, side, slot and timestamp. Only execute extends the chain; reductions and closes change positions, not commitments.

The chain fixes a total order over all executions of all strategies at the time they land. Any observer can recompute it from the ExecutionCommitted events, or from the archives after cleanup, and compare the result with Pool.head and Pool.count; an omitted, inserted or reordered commitment changes every later head. The public API reports the head and count alongside platform AUM. Two later checks use the sequence number. A dormant strategy's active_until_sequence is frozen at the pool count when it is deactivated, and both reveal instructions require chain_sequence ≤ active_until_sequence and a strategy created no later than the commitment, so no later execution can be attributed to a dormant strategy and no strategy can claim an execution from before it existed.

#6.7 Partial reductions on the same account

A reduction that keeps the position's direction stays on the same exec. The executor and verifier sign partial_close(reduce_notional, operation_sequence, policy_evidence_hash, valid_until_slot), and the program requires a filled exec, $0<r<n$ for reduced notional $r$ and current notional $n$, operation_sequence equal to the stored value plus one, a nonzero policy hash and the slot no later than valid_until_slot. The reduction counts against the pool's per-market minute flow. The venue reduces the position at the oracle price and returns margin plus realized PnL less its closing fee to the exec vault, and the whole amount moves on to the pool vault. With current collateral $c$:

The released margin $m$ leaves Pool.locked_collateral; if the returned amount is below $m$, the shortfall is added to the pool's realized losses; the 2 bps execution fee on the reduced notional goes to the protocol's pull claim. The exec keeps its entry price, and last_policy_hash and operation_sequence advance. An ExecutionAdjusted event records the policy hash, operation sequence, reduced notional, collateral released, amount returned, realized PnL, venue fee, execution fee, oracle price, slot and time.

Keeping the account means fees are charged only on the change. Closing a 100,000 USDC position and reopening 90,000 USDC would pay venue fees on 190,000 USDC and the execution fee again on 90,000 USDC; a partial close pays them on 10,000 USDC. Each reduction's own signed signal, receipt and policy record become an entry of the opening's policyHistory. Entries must have kind reduce or close, strictly increasing operation sequences, non-decreasing receipt and signal sequences, and a notional equal to their policy record's member notional, and each verifies as its own opening against the same commitment fields. Forced reductions carry a verifier-signed risk certificate in riskHistory instead (§5.5). A position whose target changes sign is not reduced through zero: the old exec is closed and the new direction opens from a fresh random index.

#6.8 Closure, cancellation and rent

An exec ends in one of two terminal states.

• Closed (2) through close_exec with cancel = false, signed by the enclave and the verifier. The exec must be filled; the full notional counts against the minute flow; everything the venue returns moves to the pool vault; the loss against collateral, if any, enters realized losses; the 2 bps fee on the closed notional goes to the protocol claim; notional and collateral are set to zero and closed_at is stamped.
• Dropped (3) through close_exec with cancel = true, the refund-only path for a request that never filled. The venue request must be unfilled with zero fees and zero PnL, the amount returned must be at least the original collateral, no fee is charged, no flow is consumed, and the zero policy hash is allowed because no new leader intent is involved.

After enclave expiry or revocation only the guardian can unwind, with guardian_close. Funds still return only to the pool vault, and guardian closes are exempt from execution fees and flow admission so that an exhausted budget cannot hold collateral. Whenever the last open notional in every market reaches zero, the program stamps Pool.last_flat_at, which the reveal certificates use (§10).

An opening is revealed only once its exec is closed or dropped and the reveal conditions of §10 hold. After the reveal, anyone may call reclaim_exec(index). It requires a terminal exec, a revealed CommitmentReceipt and an empty exec vault, and then:

1. writes an ExecutionArchive of 363 bytes into the CommitmentReceipt: executor, pool, index, commitment, both heads, chain sequence, market, side, original notional and collateral, execution fees, timestamps and slots, state, both policy hashes, operation sequence, entry price, venue fee, realized PnL and amount returned;
2. closes the flat venue request and the exec vault, sending their rent to the pool PDA;
3. shrinks Exec from 341 to 40 bytes and rewrites it as an ExecutionTombstone, a distinct 8-byte discriminator followed by the 32-byte commitment, and moves every lamport above the 40-byte rent-exempt minimum to the pool PDA.

The CommitmentReceipt is created at its full 454 bytes in execute, archive space included, so archiving needs no reallocation, and it is never closed. The tombstone keeps the exec address occupied, so the index cannot be reused, and the receipt keeps the commitment occupied, so it cannot be committed again. Historical NAV reconstruction reads the archives together with the ExecutionAdjusted events (§10).

#7. Venue: Jupiter Perps

Unseen v0 trades one venue: the SOL, ETH and wBTC perpetual markets of Jupiter Perps, long and short, up to 3×. The choice follows from the product. Jupiter Perps is priced by oracles: Jupiter-run keepers execute position requests at the oracle price, and follower flow does not move that price. A pooled order of a strategy and its followers therefore fills where the leader's own order would have filled, and front-running one's own followers earns nothing. Jupiter publishes its fee and price-impact formulas, which makes the cost and the capacity of a strategy computable in advance.

This chapter describes how an exec account holds a Jupiter position, how fills happen, how collateral is posted on each side, and what the venue charges. Devnet has no Jupiter Perps; the devnet profile deploys the unseen program with the development venue program and a test USDC mint, and runs the same flow end to end. Mainnet uses Jupiter Perps and real USDC.

#7.1 Venue binding

The venue is fixed when the protocol is initialized. initialize records the venue program in Config.venue and creates the pool at ["pool", venue_program], so one pool serves one venue. Every instruction that moves a position's funds, namely execute, partial_close, close_exec, guardian_close and reclaim_exec, requires the venue program account to equal Config.venue, and every transfer it performs ends in the pool vault, an exec vault or that venue. The mainnet deployment is configured with the Jupiter Perps program ID, its pool account, the custody accounts of the SOL, ETH and wBTC markets, and a validated per-market oracle configuration. The program's market index maps 0 to SOL, 1 to ETH and 2 to wBTC.

An execute that performs the Jupiter CPI needs an address lookup table to fit Solana's 1,232-byte transaction limit; protocol initialization creates the lookup tables for the static accounts. Each execute handles one market, which keeps it within the 64-account limit. The compute budget per execute is estimated at 400,000 units, against Solana's per-transaction maximum of 1,400,000.

#7.2 The request path from an exec PDA

Jupiter Perps changes positions through requests. The position owner creates a request account that states the change, and a keeper executes it in a later transaction. In Unseen the owner of every position is an exec PDA. The PDA has no private key; the unseen program signs for it with the seeds ["exec", pool, index_u64_le, bump] inside its own instructions, so only those instructions can act on the position.

1. Request. The executor and verifier sign execute (§5). After its risk checks, the program transfers the collateral from the pool vault to the exec vault and, signing as the exec PDA, creates the venue request: market, side, notional, collateral, an expiry of the current slot plus Config.retry_slots, and the common wire slippage bound.
2. Fill. A keeper executes the request at the oracle price, provided the price is within the request's slippage bound of its reference price and the expiry has not passed. The venue's opening fee is taken from collateral.
3. Record. The executor and verifier sign record_fill. The program requires the exec to be pending and the request filled, charges the 2 bps execution fee on the notional from pool cash into the protocol fee vault, and marks the exec filled.
4. Adjust. partial_close and close_exec decrease the position through the venue. What the venue returns, margin plus realized PnL less its closing fee, lands in the exec vault and moves on to the pool vault; no other destination is accepted.
5. Cancel. A request that has not been filled when its retry window ends, when its signal expires or when the oracle has moved beyond the leader's bound is cancelled through the refund-only path; the venue returns all collateral and the exec becomes dropped (§6.8).

Until the keeper fills it, the request is a public account. It shows what the exec account shows: a market, a side, a size and the common pool parameters, with the exec PDA as owner. Every request in the pool has the same kind of owner and the same collateral ratio and slippage bound, so nothing in it identifies a strategy.

Jupiter Perps allows six positions per owner, one per market and side, and a minimum collateral of 10 USD. Because every position has its own exec PDA as owner, the per-owner limit never applies to the pool, and the program's floor of 10 USDC of collateral per exec equals the venue minimum. The executor never submits an opening below that floor; a residual target smaller than it is left unexecuted and can be certified complete only by the verifier.

#7.3 Keepers and the oracle price

Fills come from Jupiter-run keepers at the oracle price, with Edge, Chainlink and Pyth as price sources. The pooled order does not move that price, so the cost of size is the deterministic impact fee of §7.5, not slippage against a book. Two bounds limit how far the price may move between request and fill.

• Common wire slippage. Every request carries Config.common_wire_slippage_bps (configured; local development value 100 bps). It is identical for every strategy, so the public request reveals nothing about the leader's preferences.
• Leader bound. Each signal carries a signed maxOracleDeviationBps, at most 10,000. Before each fill attempt the executor compares the current oracle price with the request's reference price; if the deviation exceeds the leader's bound, it cancels the unfilled request. The verifier checks the same bound independently.

A keeper fill lands on its own, independently of the executor. The executor reconciles it with record_fill, or with a dual-signed reconcile_fill when the fill raced a cancellation; in both cases the program requires the request to be filled on the venue, and the strategy cannot propose an epoch while a landed fill is unrecorded. NAV valuation uses the oracle prices captured in the epoch proposal (§8 Epochs and settlement).

#7.4 Collateral for longs and shorts

All collateral leaves the pool as USDC and is sized by one ratio:

The ratio $r$ is set at initialization (COMMON_COLLATERAL_RATIO_BPS; local development value 3,334 bps, a margin fraction just above one third). At 3,334 bps a position's notional is at most $10,000/3,334\approx 2.9994$ times its collateral, under the 3× protocol maximum. Since $r$ is the same for every strategy and both sides, no public collateral amount encodes a strategy's declared leverage. Leverage is expressed by the leader's target weights and bounded by the risk engine (§5.5). The program also requires pool cash, after protected withdrawal reserves, to cover the collateral, so withdrawal money is never posted as margin.

Jupiter Perps collateralizes a long position in the market's underlying asset. The pool holds only USDC, so the production adapter's long path converts the exec vault's USDC collateral into the custody asset within the position request, and the decrease path returns USDC to the exec vault. A short posts USDC collateral directly. Either way the pool's accounting stays in USDC: the program records collateral, returned amounts and realized PnL in USDC base units, and every return lands in the pool vault.

#7.5 Venue fees and price impact

Venue fees go to Jupiter and its liquidity providers. Followers pay them in proportion to their shares, as the leader does, because the order is pooled.

Table 7.1 — Charges on a Jupiter Perps trade, from Jupiter's published fee schedule and the protocol's execution fee.

For a SOL trade of size $n$ USD, with Jupiter's step of approximately $375k, the linear impact charge is

so a slice up to about $375k pays 1 bp, and a larger one 2 bps or more on its whole size. Unseen's per-action limit of 250,000 USDC (§5.7) keeps every slice inside the first step.

Table 7.2 — Opening one 250,000 USDC SOL slice, with the local development collateral ratio. Closing the slice pays the 0.06% close fee and the execution fee again, with impact according to Jupiter's schedule.

When several strategies' actions land in one batch, the batch's impact fee is split by notional with the prefix-floor rule of §5.9, so each strategy pays for its own share of the size and the total is conserved to the base unit. The verifier's cash check reserves each pending opening's future venue fee, bounded at 6 bps in the development venue and by the production adapter's bound on Jupiter, so a strategy cannot commit more margin than it can pay fees on.

Capacity. Fees and flow limits together bound how much strategy money the venue can carry. Unseen limits each strategy to 250,000 USDC of flow per market per minute and the whole pool to 250,000 USDC of gross flow per market per logical minute, below every one of the venue's additive-fee thresholds. A strategy that rebalances over $M$ minutes supports roughly $250,000\times M/(|\Delta w|\times \text{leverage})$ of AUM; a full long-to-short flip at 3× over ten minutes gives about $417k (an estimate). v0 caps each strategy at $250,000 and the platform at $2,000,000. Across the three JLP markets, where the additive thresholds are shared with every other trader and correlated rebalancing bursts are what bind, Unseen estimates a ceiling of roughly $30–60M of strategy AUM at its assumed turnover; Jupiter's per-custody position limits also apply. Growth beyond that requires further venues.

#8. Epochs and settlement

Deposits and withdrawals never execute at a price the executor chooses on its own. They settle only at the close of a strategy's daily epoch, at a NAV that the executor proposed, the independent verifier recomputed and co-signed, and no one successfully challenged within the challenge window. Each strategy runs its own sequence of epochs, so a stalled proposal affects only that strategy. This chapter specifies the schedule, the proposal, the verifier's recomputation and co-signature, challenges, finalization, the mint and burn of shares, the 20%-per-epoch withdrawal budget and its queue, pull-based claims, and the paths that retire a proposal that cannot finalize. Figure 8.1 shows the states an epoch passes through.

#8.1 Units and rounding

All amounts are integers. USDC has 6 decimals, so one USDC is 1,000,000 base units. Shares have 9 decimals; one whole share is $10^9$ share units. NAV per share $\pi$ is in USDC base units per whole share, and the genesis value ${\pi }_0$ is a deployment parameter of at least 1,000,000, one USDC per share. With equity $E$ and supply $S$, the three conversions are

Every conversion rounds down, intermediate products are checked 128-bit integers, and rounding residue stays in the strategy's equity for the remaining holders. Among share and NAV computations, the only rounding up is the leader's fee compensation, by at most one share unit (§3.6).

#8.2 The daily schedule

Each Strategy carries a timestamp next_epoch_at and a slot next_epoch_slot. At creation they are the creation time plus 86,400 seconds and the current slot plus Config.epoch_duration_slots; after every finalization or void they are reset the same way from the current clock and slot. A proposal for epoch $n$ is accepted only when

so the executor cannot postpone the valuation moment indefinitely. If a window is missed, anyone can call reset_epoch_schedule once there is no active proposal and either the slot deadline has passed or $t\ge \text{next\_epoch\_at}+\text{epoch\_timeout\_seconds}$; it schedules the next boundary one day ahead and changes no NAV. The slot cadence, proposal deadline and epoch timeout are configured parameters (local development values: 75 slots, 1,000 slots and 172,800 logical seconds).

Accounting epochs are anchored to each strategy's own finalizations. They are distinct from the UTC days used for reveal periods (§10 Reveal). Epochs run from creation onward, including the 30-day shadow period, during which only the leader's own capital is in the strategy.

Deposit and withdrawal requests target the next epoch that has not yet been proposed: a request made while a proposal is open waits for the following one. A deposit is escrowed in the pool vault at request time but does not enter the pool's executable cash until it settles, so pending money never finances a trade. Each Share holds at most one pending request, sequenced by an owner nonce.

#8.3 The proposal

The executor values each strategy at its boundary and signs propose_epoch(number, nav, liquid_cash). Before proposing, it deleverages the strategy if pending withdrawals require cash or would push leverage above the declared maximum (§5.5). The program checks:

• the protocol is not paused and the enclave key is valid;
• number is the strategy's last epoch number plus one and no proposal is active;
• the time and slot window of §8.2 holds;
• every request captured by the previous epoch has been settled, carried or cancelled (unsettled_requests = 0);
• $\text{liquid\_cash}\le \text{nav}$.

It then creates Epoch at ["epoch", strategy, number_u64_le] and freezes the checkpoint the proposal will be judged by: scheduled boundary time and slot, actual proposal time and slot, proposed NAV and liquid cash, the venue's oracle prices for all three markets, the strategy's cumulative deposits, withdrawals and performance fees, the pre-fee share supply, and the withdrawal shares captured. It computes the proposed NAV per share ${\pi }_g=\pi (\text{nav},S)$ and sets the guardian review flag when the move from the last final value ${\pi }_{\text{last}}$ exceeds 15%:

Settlement of earlier epochs is forbidden while the proposal is active, and the next proposal is forbidden until this one's captured requests are processed. A late burn therefore cannot change the supply under a proposed NAV. While the proposal is open, the verifier refuses new risk for that strategy only.

#8.4 Verifier recomputation and co-signature

The verifier is an independent operator with its own key, its own RPC endpoint and its own state. It obtains the private openings from the executor at POST /internal/verifier/openings with a proof signed by the registered verifier key over unseen-verifier-openings-v1, a fresh nonce and the issue time; proofs expire after 60 seconds and nonces cannot be replayed. It authenticates every opening against its on-chain exec and commitment: a missing, duplicated or relabelled opening of a real execution fails the audit, and an opening reserved for an exec that never landed is ignored.

It then rebuilds the chain state as of the proposal slot. Executions created after the slot are excluded. A request filled after the slot is valued as pending: its original collateral at face value, with no fees and no PnL. A request cancelled at or before the slot counts as closed with zero amounts. Reductions after the slot are ignored. Prices are the oracle prices frozen in the Epoch, and capital flows are its cumulative checkpoints. On that state it computes the strategy's equity exactly as defined in §3.3:

and its liquid cash, which is equity less the remaining collateral of pending and filled positions and less the unrealized PnL of filled positions. The audit passes only if all of the following hold:

1. $E$ equals the proposed NAV exactly.
2. Liquid cash covers the next withdrawal reserve and the prospective performance fee: $L\ge \lfloor E/5\rfloor +F$.
3. After the captured withdrawals, the strategy is within its declared leverage $\mathrm{lev}$, as defined below.

With $E^{-}=E-F$ and captured withdrawal shares $S_w$, the withdrawal the next budget can pay and the leverage condition are

The verifier then hashes its evidence: SHA-256 of a JSON object with the domain unseen-epoch-evidence-v2, the genesis hash, the program ID, the epoch, the NAV and the account and transaction evidence it read. It signs cosign_epoch(expected_nav, liquid_cash, evidence_hash). The program requires the signer to be Config.verifier, expected_nav and liquid_cash to equal the proposal exactly, a nonzero evidence hash, the epoch to be in state Proposed, and the slot to be no later than the proposal slot plus proposal_deadline_slots. It stores the evidence hash, moves the epoch to Challengeable and opens the window: challenge_ends_at = cosigned_at + Config.challenge_seconds.

A verifier that disagrees does not sign; the epoch stays Proposed until it is voided (§8.9), and other strategies continue. Historical epochs keep the verifier key and signature of their co-sign transaction after the verifier key is rotated, so past epochs remain checkable.

#8.5 Challenge window and bonds

While an epoch is Challengeable and $t<\text{challenge\_ends\_at}$, any wallet may call challenge. It transfers Config.challenge_bond in the protocol's USDC mint from the challenger into the pool vault, creates a ChallengeReceipt at ["challenge", epoch, challenger], and marks the epoch challenged, which blocks finalization. The receipt allows one challenge per wallet per epoch, including after a dismissal; while one challenge is unresolved no second one can be filed. The window length and the bond amount are configured parameters with no production default (local development bond: 1 USDC).

The guardian resolves with resolve_challenge(approve). Approving the epoch dismisses the challenge: the bond is forfeited to the protocol's pull claim, the challenge flag clears and the epoch may finalize. Upholding the challenge credits the bond back to the challenger's pull claim, claim_bond, and leaves the epoch blocked, so its only exit is a void. The same instruction clears a guardian review flag raised by a move of more than 15%; a review-only resolution involves no challenger and no token account.

#8.6 Finalization

finalize_epoch is permissionless. It requires the protocol not to be paused; the epoch to be co-signed and Challengeable with its window elapsed, not challenged and, if flagged for review, resolved; and the epoch to be the strategy's active epoch and its next number. The fee and share computations are those of §3.6, with $E$ the proposed NAV, $S$ the pre-fee supply, $S_L$ the leader's shares and $\phi$ the fee rate:

with $F_p=0$ during a founding waiver. Then $E^{\prime }=E-F$, the leader receives compensation shares $\Delta S_L$ that preserve its pre-fee equity, $S^{\prime }=S+\Delta S_L$, ${\pi }_f=\pi (E^{\prime },S^{\prime })$, ${\mathrm{HWM}}^{\prime }=\max (\mathrm{HWM},{\pi }_f)$, and the epoch's withdrawal budget is

Finalization checks liquidity before it commits: pool cash, proposed liquid cash and proposed NAV each at least $F$; proposed liquid cash at least $F+B$; and pool cash net of all strategies' protected reserves at least $F$ plus any increase of this strategy's reserve. It credits $F_L$ to the leader's fee claim and $F_p$ to the protocol claim, sets the strategy's liquid cash to $L-F$, its AUM to $E^{\prime }$, last_nav to ${\pi }_f$ and its loss checkpoint to the pool's current realized losses, and replaces its protected withdrawal reserve with $B$ in both the strategy and the pool totals. The epoch becomes Final with final_nav $=E^{\prime }$, nav_per_share $={\pi }_f$, its performance fee and its budget, and the next boundary is scheduled one day ahead.

The reserve is physical: execution collateral and ordinary execution fees can be paid only from pool cash above the sum of protected reserves, so the 20% set aside at finalization cannot be spent on trades before the strategy's withdrawals are paid.

#8.7 Settlement: mint, burn and the withdrawal queue

Settlement runs per share account with the permissionless settle_share, after finalization and while no new proposal is active. It processes a request captured by the final epoch that has not yet been settled for it.

Deposit. The deposit $a$ mints $\mathrm{shares}(a,{\pi }_f)$, which must be positive. The amount is added to the owner's cost basis, the strategy's AUM and liquid cash, the platform AUM and the pool's executable cash.

Withdrawal. Withdrawals form a FIFO queue per strategy. Each request receives a sequence number and a WithdrawalTicket at ["withdrawal", strategy, sequence_u64_le], and only the request at next_withdraw_sequence can settle. With $B_{\text{used}}$ already paid from this epoch's budget, the head request of $s$ shares receives

The program burns $s^{\ast }$, lowers the owner's cost basis by $\lfloor \text{basis}\cdot s^{\ast }/s_{\text{held}}\rfloor$, reduces the strategy's AUM, liquid cash and reserve and the pool's reserves and cash by the payout, and credits the payout to the owner's claimable_withdraw. If $s^{\ast }<s$, the remainder stays at the head of the queue and carries to the next epoch; if the budget is exhausted the request is carried whole. A leader's withdrawal must leave at least 5% of the supply with the leader. A request that is worth zero base units at the last final NAV is refused when made; if a later NAV makes a queued remainder worth zero, settlement releases only that reservation, keeps the owner's shares and cost basis, and advances the queue. A cancelled request leaves its ticket marked cancelled, and anyone can skip it with advance_withdrawal_queue, so a cancelled head never blocks the owners behind it.

The 20% budget bounds how much equity any single epoch can release. The executor prepares for it by deleveraging, the verifier refuses to co-sign a proposal whose liquid cash or post-withdrawal leverage cannot support it, and the program enforces it through the reserve.

#8.8 Pull-based claims

No settlement step pushes tokens to a user. Payouts accumulate as claims and leave the pool vault only when their owner pulls them:

Table 8.1 — Pull claims. Each instruction zeroes the claim before the pool PDA signs the transfer.

A frozen or missing token account delays only its own owner's claim; it cannot block finalization, the queue or another follower's payout.

#8.9 Voids, timeouts and emergency exits

A proposal that cannot finalize is retired by void_epoch. The guardian may void any non-final epoch; anyone may void it when the protocol is paused, the enclave key is revoked or expired, or $t\ge \text{proposed\_at}+\text{epoch\_timeout\_seconds}$. A void sets the epoch to state Voided, moves any unresolved bond to the challenger's claim without adjudicating it, clears the active proposal and its request counters, consumes the epoch number and schedules the next boundary one day ahead. The last final NAV is unchanged. Requests captured by the voided proposal are captured again by the next one. The executor's epoch job finalizes a finalizable proposal first; otherwise it voids at the on-chain timeout, refreshes state, deleverages and proposes again.

Two owner-signed paths keep exits open whatever the state of a proposal.

• emergency_withdraw(shares, nonce) pays at the last final NAV from the remainder of that epoch's budget, at any time, including while a proposal is open or the protocol is paused. It must be the queue head; the payout must be positive and within the remaining budget, the strategy's liquid cash and reserve, and pool cash; a leader must keep 5% of equity, counting pending requests. A pending deposit of the same owner is refunded to its claim without counting against the budget. If a proposal is open, the same transaction voids it, and only if the positive burn and payout succeed. Once the reserve is spent, further withdrawals wait for another verified epoch; neither a void nor a pause creates a second budget.
• cancel_request(nonce) withdraws a pending request. A deposit becomes a refundable claim; a withdrawal's ticket is marked cancelled. If the request was captured by an open proposal, only the proposal's request counters change; its NAV and share supply stay as proposed.

Guardian pause stops execution, proposals and finalization. Settlement of an epoch that is already final, claims and emergency withdrawals remain available.

#8.10 Worked example

This example continues the finalization of Table 3.3 (§3 Strategies, shares and the pool): a genesis NAV of 1,000,000, a leader with 10,000 shares and followers with 20,000 shares, of which follower A holds 12,000 and follower B 8,000, a 1,500 bps fee, no waiver and a declared maximum leverage of 3×. Before the proposal, A requests a withdrawal of 8,000 shares and a new follower C requests a deposit of 5,000 USDC; both are captured by epoch $n$. The strategy holds one filled SOL long of 30,000 USDC notional with 10,002 USDC of collateral and 998 USDC of unrealized gain.

Table 8.2 — One epoch from proposal to settlement. Amounts in USDC unless stated; the execution and venue fees of the open position are already included in the NAV.

A then pulls 6,539.999999 USDC with claim_withdrawal, the leader pulls 240 USDC with claim_leader_fee, and anyone can move the protocol's 60 USDC to its fee vault. The one base unit of USDC by which the payout falls short of the budget, and the one by which the NAV per share rises after settlement, are rounding residue retained in equity. In epoch $n+1$ A's remaining 1,972.344674973 shares, worth about 2,140 USDC, are first in the queue; at an unchanged NAV the new budget is about $\lfloor 31,160/5\rfloor =6,232$ USDC, so they settle in full. Had the verifier refused to co-sign or the proposal been challenged and upheld, the epoch would have been voided at its timeout, both requests would have rolled into the next proposal at the unchanged last final NAV, and A could still have exited up to the last epoch's remaining budget with emergency_withdraw.

#9. Fees

A strategy carries three kinds of cost, all in USDC: a performance fee on follower gains above the high-water mark, a protocol execution fee on every change in position notional, and the venue's own trading fees. v0 has no management fee. Every amount is an unsigned integer in USDC base units (six decimals), shares carry nine decimals, and every intermediate product is checked u128 arithmetic in the shared unseen_domain crate. The program, the Sealed Executor and the verifier all link that crate, so the three compute the same integers.

Table 9.1 — Fee schedule.

#9.1 Performance fee and the high-water mark

Each Strategy account stores performance_fee_bps and high_water_mark. create_strategy rejects a fee above 2,500 bps, and no instruction changes it afterwards. The high-water mark is a NAV per whole share in USDC base units. It starts at the deployment's genesis NAV (Config.genesis_nav, which initialize requires to be at least 1,000,000, that is 1 USDC per share) and never falls.

The fee is computed once per epoch, in finalize_epoch, from values frozen when the epoch was proposed (see §8 Epochs and settlement). Let $N$ be the proposed NAV, $T$ the total shares, $L$ the leader's shares, $F=T-L$ the follower shares, $H$ the high-water mark and $f$ the fee in basis points. The proposal records the pre-fee NAV per share

and finalization computes the follower gain and the fee:

Only follower shares enter $G$. The leader's stake pays no performance fee to itself. Because $\Phi$ leaves equity that the leader shares with followers, the program also mints compensation shares to the leader, so that the leader's equity after the fee equals its equity before it:

Rounding up gives the leader at most one share base unit of dust, and no USDC is created. Finalization then sets the strategy's AUM to $N-\Phi$, adds $c$ to both $L$ and $T$, computes the final NAV per share $p^{\prime }=\lfloor (N-\Phi )\cdot 10^9/T\rfloor$ and raises the mark to $H\leftarrow \max (H,p^{\prime })$.

The mark is a single per-share value for the whole strategy, so every follower share is measured against it. A gain is charged once, in the epoch that first carries NAV per share above the mark. Deposits always mint at the final NAV per share, which never exceeds the mark, so a share minted below the mark pays nothing while NAV climbs back to it.

Finalization charges the fee only if the strategy can pay it in cash. It requires Pool.cash, the proposal's verified liquid cash and the proposed NAV each to be at least $\Phi$. It also requires liquid cash to cover $\Phi$ plus the new 20% withdrawal reserve, and the pool's unprotected cash to cover $\Phi$ plus any increase in that reserve. The fee is then booked as two pull claims, Strategy.leader_fee_claim and Pool.protocol_claim, and Pool.cash falls by $\Phi$. Both Epoch.performance_fee and Strategy.cumulative_performance_fees record it. The cumulative figure is part of every later epoch's capital checkpoint, and both the verifier and the public NAV reconstruction subtract it (see §10.10). Because payouts are claims, a missing or frozen leader token account cannot hold up an epoch.

#9.2 The 80/20 split and the founding waiver

The split is fixed in code: the protocol share is $\lfloor \Phi /5\rfloor$ and the leader receives $\Phi -\lfloor \Phi /5\rfloor$, so rounding never favours the protocol. At the v0 strategy cap, take a leader with 100,000 USDC of their own and 150,000 USDC from followers, a 30% gross annual return, a 15% fee and the 20% protocol share (the brief's assumptions). Followers gain 45,000 USDC and owe 6,750 USDC, of which the leader keeps 5,400 USDC on top of the 30,000 USDC earned on their own capital.

Founding leaders pay no protocol share for 90 days, and that waiver can only be granted on-chain. The admin issues a LeaderInvitation (invite_leader(expires_at, founding)), and create_strategy accepts founding = true only when that invitation carries the founding flag. The strategy then stores waiver_ends_at = created_at + 7,776,000 seconds (90 days); non-founding strategies store zero. While the finalization timestamp is below waiver_ends_at, the protocol share is zero and the leader receives the whole fee. The 30-day shadow period starts at the same moment, and request_deposit refuses deposits until it ends, so a founding waiver covers the follower-funded epochs from day 30 to day 90. The waiver leaves the execution fee unchanged. The public Strategy record exposes protocolPerformanceShareBps and foundingFeeWaiverEndsAt.

#9.3 Execution fee

The protocol charges 2 bps on notional that actually changes:

where $\Delta N$ is one of three amounts:

• the exec account's opened notional, charged in record_fill once the keeper has filled the request;
• the reduced notional in partial_close, which keeps the same exec account and entry price;
• the remaining notional in close_exec.

A request that never filled and is cancelled through close_exec(cancel = true) pays nothing, and neither does a guardian rescue through guardian_close. A same-side reduction pays only on the delta. A sign flip closes the old exposure and opens a fresh exec account, so it pays on both legs, which together equal the full change from $+x$ to $-x$.

Every charge passes charge_execution_fee. That function keeps a per-UTC-day counter (Pool.fee_day, Pool.execution_fees) and rejects the transaction if the day's total would exceed $\lfloor \text{platform AUM}\cdot \text{execution\_fee\_epoch\_cap\_bps}/10000\rfloor$. The cap rate is a configured parameter. Its local development value, 100 bps, allows 20,000 USDC per day at the 2,000,000 USDC platform cap. The function also adds the fee to Pool.total_realized_losses, which the anonymous risk envelope deducts from every active strategy's conservative equity until that strategy's next final checkpoint (see §12.3). Each charge also requires unprotected pool cash, Pool.cash − Pool.withdrawal_reserves, to cover the fee.

The fee comes out of pooled strategy cash, so it reduces NAV and every share bears it in proportion, the leader's included. The signed policy evidence of each execution carries allocatedExecutionFeeUsdc as an authorized ceiling. The indexer requires every revealed adjustment's actual fee to be at or below that ceiling. Execution-fee revenue pays for the enclave, keepers, RPC and Jito tips.

#9.4 Venue fees

Jupiter Perps charges 0.06% to open and 0.06% to close. It adds a linear price-impact fee of about 1 bp per started ~375,000 USDC of SOL notional, and an additive fee once net opened-minus-closed size on an asset over roughly a minute passes 1.5 million USDC (SOL, ETH) or 750,000 USDC (wBTC). All fees together are capped at 0.50% of trade size. These fees are taken from the position's collateral inside the exec account and go to Jupiter and its liquidity providers. Followers pay them with or without Unseen; §7 Venue: Jupiter Perps gives the request path. The local fake venue models the same structure: at fill it takes 6 bps of notional from the request's collateral, and at a reduction or close it takes $\min (\lfloor 6\cdot \Delta N/10000\rfloor ,\text{gross returned})$.

When several strategies' orders in one market land in the same batch, the batch's price-impact fee $I$ is split pro rata by notional. Members are taken in signed receipt order, and $P_i$ is the notional of the members before member $i$:

The sum telescopes to exactly $I$, and the remainder falls by receipt order. The domain tests pin $I=100$ over notionals 2, 3 and 5 to 20, 30 and 50, and $I=2$ over 1, 1 and 1 to 0, 1 and 1. Each member's share is written into its policy evidence (allocatedImpactFeeUsdc, allocatedVenueFeeUsdc, allocatedExecutionFeeUsdc) and published with its opening.

Fees are reserved before an order is sent. The verifier requires the strategy's own cash to cover future opening fees, $\lfloor 2N/10000\rfloor$ for the protocol plus the venue's opening fee (the fake venue's $\lfloor 6N/10000\rfloor$ locally). The program's envelope subtracts a 16 bps ceiling-rounded bound on outstanding venue and execution fees over the pool's aggregate notional, the candidate order included.

#9.5 Worked example: performance fee over three epochs

The parameters are a genesis NAV of 1 USDC per share, a leader stake of 10,000 USDC and follower deposits of 20,000 USDC (the local development profile's stake and deposit), the default 1,500 bps fee and no waiver. The opening state is $T=30,000$ shares, $L=10,000$ and $H=1,000,000$.

Table 9.2 — Three consecutive finalizations.

NAV and fees are in USDC, $p$ and the mark in base units per whole share, and $c$ in shares. In epoch 1 the strategy is up 10% gross. Followers own 20,000 shares that each gained 0.1 USDC, so $G=2,000$ and $\Phi =300$. The leader receives 138.248847927 new shares, and the 32,700 USDC of equity divides as exactly 11,000 USDC to the leader (its pre-fee equity) and 21,700 USDC to followers: a net 8.5% on 20,000 USDC. In epoch 2 NAV per share is below the mark and no fee accrues. In epoch 3 the fee applies only to the climb from 1,084,999 to 1,128,134, that is 43,135 base units on each of the 20,000 follower shares.

#9.6 Worked example: fees over a position's life

Take a strategy at the v0 cap of 250,000 USDC trading SOL at unchanged oracle prices, with sizing equity held at 250,000 USDC for simplicity. A 15,000 bps long target is 150% of equity, that is 375,000 USDC of notional. execute accepts at most 250,000 USDC per call, and pool flow is capped at 250,000 USDC per market per logical minute, so the opening goes out as two fresh exec accounts in two minutes.

Table 9.3 — Execution and venue fees for one sequence of targets.

Each of the six trades is below 375,000 USDC, so each pays about 1 bp of price impact, roughly 125 USDC in all. None comes near Jupiter's 1.5 million USDC per-minute additive threshold. A leader holding the 5% minimum bears 12.50 USDC of the execution fees and 37.50 USDC of the open and close fees.

#9.7 Where each fee is charged on-chain

Table 9.4 — Instructions, ledgers and destinations.

#9.8 The protocol's share: buyback and burn of $UNSEEN

Every fee the protocol earns ends in one account, the protocol fee account (Config.protocol_fee_vault, the USDC token account of the keyless protocol PDA). Opening execution fees are transferred there by record_fill at once; execution fees on reductions and closes, the protocol's 20% of each performance fee and forfeited challenge bonds accrue in Pool.protocol_claim. No key can sign for the protocol PDA, and no instruction pays its USDC to a wallet: the only way out is buyback_and_burn.

All of it buys $UNSEEN and burns it. buyback_and_burn(min_out, route_data) is permissionless and atomic. It moves the whole Pool.protocol_claim into the protocol fee account; invokes the configured swap program — Jupiter v6 on mainnet — with an exact-in USDC → $UNSEEN route whose authority, source and destination it checks against the protocol PDA's own token accounts, signing only as that PDA; requires at least min_out newly received $UNSEEN; and burns the PDA's entire $UNSEEN balance. Claim, swap and burn succeed or roll back together, so the account never keeps the token and the supply only falls. Config keeps the cumulative USDC spent and $UNSEEN burned, and GET /v1/protocol publishes them with the last buyback's signature.

The protocol's worker cranks it every hour once at least 1 USDC has accrued: it quotes the route from Jupiter's swap API (at most 48 accounts, 1% slippage by default), sets min_out to the quote's minimum output, and sends claim, swap and burn as one versioned transaction. The $UNSEEN mint and the swap program are set through the admin path with the 48-hour timelock (schedule_buyback, then activate_buyback). $UNSEEN has a fixed supply of 1,000,000,000 and was launched 100% fair: the whole supply went to the public launch on equal terms, with no presale, no team or investor allocation, no airdrop, no reserved pools and no vesting.

Table 9.5 — What each fee contributes to the buyback.

Users never hold or spend the token to use Unseen: deposits, NAV, every fee as charged and every payout are USDC, and strategy shares are a ledger in the Share account, separate from $UNSEEN.

#10. Reveal

Every Unseen execution is public from the moment it lands: its exec account, market, side, notional, collateral, fills and fees are ordinary Solana state. Only its owner is hidden, behind the 32-byte commitment the account carries, until the strategy's reveal delay $D$ has passed (24 hours to 30 days, default 7 days). A reveal publishes the commitment's opening: the preimage that names the strategy, plus the signed evidence that ties the trade to the leader's signal. This chapter specifies when an opening may be published, how the program enforces that without knowing who owns which account, what an opening contains, how it is posted, and how anyone checks it and rebuilds a strategy's NAV from it.

#10.1 Why reveals are grouped by period

If each opening were published at its own strategy's $D$, revealing would leak attribution. Every exec account of a day is visible and unattributed. As the openings of short-delay strategies come out, the day's still-hidden accounts can only belong to strategies with longer delays. Once a single long-delay strategy is left, its trades are identified before its own delay ends. This reveal-by-elimination property was found in review and settled by a product decision on 2026-10-15: publish a period only once every strategy active in it has passed its delay, even if short-delay strategies then reveal later than their own delay. No opening is ever published before its own strategy's delay.

#10.2 Periods

A reveal period is a UTC day on the program's clock:

The program uses Euclidean division, so days before 1970 are well defined. Its clock is logical_genesis + (unix_timestamp − real_genesis) · clock_scale + clock_offset. initialize accepts a clock_scale other than 1 only in a local-testing build, so in production the period boundary is the Solana clock's UTC midnight. Reveal periods are independent of each strategy's accounting epochs (see §8 Epochs and settlement). A strategy is active in a period if it traded in it or held an open position at any time during it.

#10.3 The rule

The openings of period $d$ may be published once every strategy active in $d$ is past its own delay. On top of that, each revealed execution must be terminal: closed, or a cancelled request that never filled. An open position is never revealed. A position that spans several days is active in each of them, so its opening waits for every day it was held, from the day of its first fill to the day it closed. Each of those days matures at its end plus a delay at least its own strategy's, so no opening is ever published before its own strategy's delay.

#10.4 How the program enforces it

The set of strategies active in a day is the mapping Unseen keeps secret: no account links a strategy to an exec account. The program never learns the set. It learns one number about it, certified by the two parties who can compute it: $D_P$, the longest reveal delay among the strategies active in day $d$.

After the day ends, the executor computes $D_P$ from its sealed openings — every execution filled in the day or held through it, and the delays of the strategies they belong to — and proposes it. The independent verifier reads the complete execution history from its own RPC, checks that authenticated sealed openings account for every execution, recomputes which strategies were active and their longest delay from the on-chain strategy accounts, and signs only a matching value. seal_reveal_period_certified(day, D_P, evidence_hash) requires both registered signatures and creates the day's RevealPeriod account (seeds "reveal_period", the pool, $d$ as i64 little-endian):

It accepts $24\text{ h}\le D_P\le 30\text{ d}$, no more than the longest delay ever registered, and a non-zero evidence hash. The hash commits to the private openings, salts included, so observers can't enumerate the short public strategy list to recover membership. A certified day can't be rewritten. The certificate publishes the day, $D_P$, the opaque hash and its status — never the active set.

Neither an unrelated open position nor a registered strategy that didn't trade that day moves the certificate: a day on which only a 24-hour strategy was active matures 24 hours after it ends, even while a 30-day strategy is registered.

An understated $D_P$ publishes nothing early. Every reveal checks that its own strategy's delay is at most each certificate's $D_P$ (§10.5), so a strategy whose delay exceeds the certified value can't be revealed against it.

The permissionless seal_reveal_period(day) remains as a fallback for a day that never gets a certificate. It waits for the first moment the whole pool is flat after the day ends, $F$, and sets mature_at = $F$ plus the longest delay ever registered. A certificate can replace a fallback record; a fallback can never replace or change a certificate.

#10.5 Reveal checks

reveal_v2 publishes a V2 opening and reveal publishes a legacy V1 opening. Both are signed by the registered, unexpired, unrevoked enclave key. The two period accounts are not caller-chosen: the instruction's account constraints derive them from the exec account's own timestamps: the day of its first fill for the opening period, day(closed_at) for the closing period.

Table 10.1 — Checks in reveal_v2.

The period accounts are not caller-chosen: the first-fill and closing days come from the exec account's own timestamps, and each intermediate account is derived from its day. A held day that ended more than 30 days ago — the protocol's longest delay — is mature under any certificate, so it needs no account, and a reveal never presents more than 30 of them.

#10.6 One period, three delays

Figure 10.1 extends the reveal job's own test case. On 2026-10-01, strategy A ($D=24$ h) trades from 01:00 to 02:00, B ($D=7$ d) from 06:00 to 14:00 and C ($D=30$ d) from 18:00 to 22:00. Measured from each close, their own delays would end on Oct 2 at 02:00, Oct 8 at 14:00 and Oct 31 at 22:00. The executor and the verifier certify the day with $D_P$ = 30 days, the longest delay among A, B and C, so mature_at = Oct 2 00:00 + 30 d = Nov 1 00:00. On Oct 9 none of the three openings may be published. From Nov 1 00:00 all three may. Had A's and B's openings appeared on Oct 2 and Oct 8, the one unrevealed exec account of Oct 1 would have pointed to the only registered strategy with a longer delay, more than three weeks before C's own delay ended. Had only A traded on Oct 1, the day would have been certified with $D_P$ = 24 hours and matured on Oct 3 at 00:00, though C stays registered. The program's tests reject the 24-hour reveal until the 30-day certificate matures, publish a 24-hour-only day after 24 hours, and never publish an open position.

#10.7 The opening

A V2 commitment is the SHA-256 of a fixed 273-byte preimage. Integers are little-endian, and keys and hashes are raw 32 bytes.

Table 10.2 — V2 opening preimage (unseen-sha256-v2).

The legacy V1 commitment (unseen-sha256-v1) is the SHA-256 of 80 bytes: strategy_id ‖ exec_index ‖ signal_seq ‖ salt. V1 remains verifiable for legacy fixtures, and all new live executions use V2.

The published evidence envelope, OpeningV2, carries the preimage fields and everything needed to check them:

• signedSignal, the complete deployment-bound signal: strategy, sequence, target weights in submitted order, validUntilSlot, maxOracleDeviationBps, signal key and Ed25519 signature (see §4 Signals);
• receiptSignature, the enclave's Ed25519 signature over the unseen-receipt-v2 lines: genesis, program, executor, receipt sequence, receipt time and signed-signal hash;
• policyEvidence, 26 fields: batch identity, index and size, member and original notional, allowed reduction, allocated impact, venue and execution fees, sizing slot and equity, prior signed notional, target weight, declared leverage, drawdown kill level and reveal delay, prior policy hash and validity slot;
• policyHistory, one witness for each later leader-signed reduction or close, each with its own signal, receipt and policy evidence and its per-exec operation sequence;
• riskHistory, any unseen-risk-reduction-v2 certificates by which the verifier forced a reduction for withdrawal liquidity, post-withdrawal leverage or drawdown;
• openingPeriodDay and closingPeriodDay, which are derived metadata outside the preimage.

#10.8 Publication

The executor's background job publishes in four steps, after trading and keeper reconciliation in each tick. Per tick it attempts at most one period seal, at most two evidence pages and at most three background chain operations, and its round-robin cursors advance on failure as well as success, so one stuck item cannot starve the rest.

1. Seal. seal_reveal_period for the creation day and the closure day, once each is eligible.
2. Header. reveal_v2 passes the fixed fields as instruction data and emits OpeningRevealedV2: strategy ID, index, signal sequence, salt, receipt sequence and time, signed-signal and policy hashes, executor, genesis, commitment, exec, timestamp and slot. It sets revealed on the Exec account and the CommitmentReceipt and stores nothing else.
3. Evidence pages. reveal_evidence(page, pages, data) splits the UTF-8 JSON envelope into pages of at most 400 bytes, each emitted as a RevealEvidence event. The program accepts pages only after the header and while the exec account is terminal. The job's progress record is bound to the SHA-256 of the exact evidence bytes, so a lost acknowledgement retries the identical page.
4. Cleanup. reclaim_exec, which anyone may call once the opening is revealed and the exec vault is empty, archives the exact public execution fields in CommitmentReceipt.archive. It closes the venue request and the SPL exec vault to the pool, and shrinks the Exec account to a 40-byte tombstone that keeps its random index irreusable.

Public reads expose a reveal only once it is complete and mature. GET /v1/strategies/:strategyId/revealed-trades and GET /v1/revealed-executions/:executionId return the RevealedExecution record: the unattributed execution, the opening, reveal time, slot and transaction, exact execution and venue fees, and a revealBarrier holding both period certificates under the policy name daily_closed_cohort. An unrevealed execution ID returns the same NOT_FOUND as an unknown one. revealSchedule.nextBoundaryAt is the same fixed daily boundary for every strategy and is never derived from a hidden execution.

#10.9 Verification in the browser

The browser check needs only the public record and Web Crypto. The strategy page fetches each revealed execution and calls verifyOpening(opening, commitment) from the contract package. It shows Opening matches its commitment when every step passes:

1. Encode the preimage (Table 10.2), hash it, and compare the result with the commitment.
2. Check cross-field bindings: genesis, program, executor and strategy are identical in the opening, the signed signal and the policy evidence; the signal's sequence equals signalSeq; the receipt sequence and signed-signal hash agree with the policy evidence; and the policy's validUntilSlot equals the signal's.
3. Recompute signedSignalHash from the canonical signing bytes and the 64-byte signature, and policyEvidenceHash from the 392-byte encoding.
4. Verify the executor's receipt signature with the executor key.
5. Walk policyHistory in order, requiring strictly increasing operation sequences, non-decreasing receipt and signal sequences and each witness's notional equal to its policy's member notional, and verify each witness the same way.
6. Verify each riskHistory certificate's Ed25519 signature against its verifier key, with operation sequences unique and increasing.
7. Verify the leader's Ed25519 signature over the signal with the signal key.

A second, chain-side layer runs before the indexer projects any reveal. It reads the actual accounts and transactions from its RPC and checks the following:

• the full commitment chain: sequence numbers 1 to n with no gap, each resulting_head equal to SHA-256 of previous_head ‖ commitment, and the last head equal to Pool.head;
• each certificate: matured at the reveal's time, with a maximum delay no shorter than the revealed strategy's, for the first-fill day, the closing day and every held day in between that ended less than 30 days before;
• each reveal: the envelope equals the on-chain header, the policy hash equals the exec account's, and every leader-authorized adjustment has exactly one matching witness or risk certificate whose notional, fees and validity agree with the landed transaction;
• terminal state: zero remaining notional and verifyOpening passing.

Checking the signal key's historical registration and replaying the sizing policy need chain history, and the independent verifier performs them.

#10.10 NAV reconstruction from revealed data

GET /v1/revealed-strategies/:strategyId/nav, served from the same public replay as the verifier's public-nav --strategy <id> command, rebuilds a strategy's NAV at each finalized epoch. It uses only public accounts, signed transactions and complete revealed evidence. It never reads the executor's store and needs no signing key. An epoch is included only when it is final, its boundary plus the strategy's $D$ has passed, and every pool execution created at or before the epoch's valuation slot has a public opening. Until the whole pool's openings for that window are out, nobody can prove that some hidden execution does not belong to this strategy, so the epoch is left out rather than estimated.

For an included epoch, the replay reconstructs every execution's state at the valuation slot, the actual proposal slot recorded in Epoch.proposal_slot. A request that had not filled by then counts as refundable collateral at face value, with no fees or PnL. Adjustments count only up to that slot, from the original archived notional and collateral. Prices are the epoch's captured Epoch.prices. It authenticates the complete opening set: one opening per execution, each commitment checked, and market and side equal to the chain's. Then, over the strategy's openings, with $S_k$ the epoch's cumulative capital checkpoints:

Here $R_e$ is realized PnL, the two $\varphi$ terms are the actual execution and venue fees, $U_e$ is the unrealized PnL of a still-filled position at the epoch price, and ${\Phi }_{\text{epoch}}$ is the epoch's own performance fee. The replay then checks a second, independent composition:

$C$ is the collateral still at the venue, and $S_{\text{perf}}^{\prime }$ includes ${\Phi }_{\text{epoch}}$. Each point carries navUsdc, totalShares, boundarySlot, valuationSlot, the itemized reconstruction, the transaction signature and slot of every source (execution, keeper fill, reveal, adjustment), and commitmentSetHash, the SHA-256 of the strategy's commitments sorted and concatenated. The API accepts a point only if its NAV equals the epoch's on-chain final NAV and its share count matches. Each point therefore checks the verifier's co-signed number against data anyone can fetch.

#11. Attested statistics

Before any of its trades is revealed, a strategy's public page shows three numbers: return, maximum drawdown and an exposure band. They are published hourly into the strategy's own on-chain account and computed only from finalized epochs. They are quantized to 100 bps, delayed at least one hour, and written only by a transaction that both the registered enclave key and the registered independent verifier key sign. This chapter defines each number, the observation that produces it, the joint signing path, the checks the program applies, and what the label attested asserts.

#11.1 What is published

Table 11.1 — The attested statistics and where they are stored.

The statistics are computed from NAV per share, not from NAV, so deposits and withdrawals change a strategy's size but not these figures.

#11.2 The observation

Let $t$ be the chain clock and $\delta$ the publication delay. The delay is a configured parameter (STATS_PUBLICATION_DELAY_SECONDS, local development value 3,600 seconds) and is at least one hour. The observation hour is

The input set is the strategy's Final epochs whose finalized_at is at or before $h$, ordered by number. Let $p_0$ be the genesis NAV per share, $p_1\dots p_n$ the final NAV per share of those epochs, and $q$ the quantum (STATS_QUANTIZATION_BPS, a configured parameter that the program requires to be a multiple of 100 bps, local development value 100).

Return is truncated toward zero, so a fall of 150 bps publishes −100. Drawdown is floored.

For exposure, let $g$ be the summed remaining notional of the strategy's exec accounts that were filled at the valuation slot of the last included epoch, and $N_n$ that epoch's final NAV. Then $x=\lfloor g\cdot 10000/N_n\rfloor$ and the band is:

• flat if $g=0$;
• low if $x\le X_{\text{low}}$;
• moderate if $x\le X_{\text{mod}}$;
• high otherwise.

The high band reaches up to the strategy's declared maximum leverage, at most 30,000 bps. Both thresholds are configured parameters (EXPOSURE_LOW_UPPER_BPS, EXPOSURE_MODERATE_UPPER_BPS), common to all strategies, with local development values of 5,000 and 15,000 bps. Exposure is the one statistic that depends on the private mapping: computing $g$ requires knowing which filled exec accounts belong to the strategy.

The evidence hash binds the values to the deployment and the enclave key. It is the SHA-256 of UTF-8 JSON with its keys in alphabetical order:

{"domain":"unseen-stats-v2","executorPublicKey":"…","exposureBand":"low","genesisHash":"…",
 "maxDrawdownBps":"200","observationHour":"…","programId":"…","returnBps":"700","strategyId":"…"}

All quantities are decimal integer strings. The example values are illustrative.

#11.3 Why quantized and delayed

Exact statistics would leak attribution. A strategy's NAV moves by exactly its fees at each of its fills. If a return figure updated with every fill, an observer could match a 1 bp step in a strategy's return to a public, unattributed fill in the same minute, and with it the exec account to the strategy. Three rules close this.

1. Finalized state only. The input set contains only finalized epochs, so intra-epoch execution fees never produce a per-fill update. A strategy's statistics change at most once per daily epoch, and only after the verifier has recomputed and co-signed that epoch's NAV.
2. Quantization. Return and drawdown are published in steps of the quantum, which the program fixes at a minimum of 100 bps. A strategy's fees or small price moves within an epoch fall below the step.
3. Delay. An observation is posted at least an hour after its hour begins, and observation hours strictly increase. The public series is therefore coarse in time as well as in value.

The exposure band is coarse by construction: four common bands, with thresholds shared by every strategy, so a band does not identify a strategy's declared leverage. The posting cadence beyond the hourly series is a configured parameter (STATS_ATTESTATION_CADENCE_SECONDS). The local development executor polls every five seconds and posts each new hour once.

#11.4 The joint signing path

The executor and the verifier each compute the statistics, and both must sign the same transaction.

1. Executor proposal. When its cadence elapses, the Sealed Executor computes each strategy's payload (hour, return, drawdown, band and evidence hash) from its chain snapshot and the strategy's openings. It builds the unsigned post_stats transaction. It sends the verifier an authorization request carrying the operation, payload, openings context and exact transaction bytes, and signs the request with the enclave key.
2. Independent recomputation. The verifier reads its own snapshot through the RPC it chose and checks the request's signature against the enclave key registered on-chain. It rejects an hour that is negative, not aligned to 3,600 seconds, younger than $\delta$, or not later than the strategy's last published hour. It then recomputes the payload for that hour from its own snapshot and requires return, drawdown, band, hour and evidence hash all to match exactly.
3. Transaction check. The verifier decodes the prepared transaction. It confirms the compute-budget instruction, this operation with exactly these arguments, the expected program-derived accounts and the signer set. It then records the authorization in its journal and returns the transaction with its signature added.
4. Submission. The executor adds the enclave signature and sends the transaction.