The due diligence library of SLVCE, a market-neutral crypto fund: NAV in dollars, red days and attestations, day by day.

Revenue comes from trade-flow structure and execution quality. Price-direction forecasting is not used. Liquidity management here is an engineering problem - financial results follow from correct operation, not from a strategy fitted to a target.

What problem SLVCE solves

Most LP solutions optimize the financial model: ranges, APR, fees. Execution is assumed to be a solved problem. In practice, it determines whether the model works at all.

SLVCE keeps liquidity working steadily across changing market regimes. The key system parameters are accuracy of liquidity placement in the active range, speed and predictability of response to trade flow, and maintaining operability under changing volatility and load.

Reduced activity or a full pause is normal behavior when capital preservation requires it.

The system makes its money at the infrastructure level - on execution, not on forecasts.

How income is generated

Under the SLVCE Core strategy, revenue comes from providing liquidity - an infrastructure function. Income sources are trader fees proportional to share in the active range, intraday trade-flow structure, and liquidity redistribution within DLMM mechanics. Revenue exists when there is trading activity, regardless of price direction.

Why the system is resilient

The architecture prioritizes survivability over yield maximization.

• No leverage in the strategies; margin exists only in the standing hedge.
• Holding zero market exposure is allowed: the system can stand fully flat.
• Risk is controlled at the infrastructure level, not after the fact.

Why access is limited

Throughput is physically limited - determined by execution speed and the characteristics of target pools. Capital growth beyond infrastructure capacity reduces execution accuracy, liquidity density in the range, and overall yield for all participants.

1. 01Intake within throughput - Capital intake is only possible within current throughput - exceeding it increases slippage and reduces yield for all participants.
2. 02Partial allocation - Partial allocation is allowed - volume is determined by the Capacity Controller in real time.
3. 03Delay or rejection - Delayed entry or rejection is possible when current AUM exceeds 90% of calculated capacity.

Capital interaction format

Interaction runs through SLVCE One, the investor app at one.slyce.xyz, and the investor portal at my.slyce.xyz. Capital is accounted in US dollars; deposits and withdrawals settle on-chain. Operational wallets are managed automatically: the investor controls deposits, profit withdrawals and redemption notices, nothing else. Reporting and metrics are available in real time. The app is described in the Interfaces chapter; withdrawal and redemption terms in Capital Terms.

LP is an infrastructure function.

How AMM / CLMM / DLMM markets work

AMM → DLMM: from passive economics to an environment where execution decides everything.

Where LP income comes from

• Fee flow - traders’ payment for trading volume. Income is proportional to the time capital spends in the active zone and the share within it.
• Trade-flow structure - intraday fluctuations and the frequency of price passing through the range can increase fee collection.
• Micro-spread and positioning - precise positioning within the active zone generates an additional slice of income.
• Incentives - external protocol incentives. Unstable and cannot be considered a structural source of income.

The "fees minus IL" formula is an oversimplification. In concentrated models, execution quality determines the result as much as pool economics.

Why IL is not the main risk

IL is asset redistribution when price changes - an economic risk of the model. It can be modeled and predicted. The main risk is inability to reposition the range in time. An LP with fast execution compensates IL with fees; an LP with delays is just a holder with growing losses. Volatility for an LP is a source of turnover - the problem is not volatility itself, but inability to react.

Execution risk as a systemic factor

Execution risk is the gap between the economic model and actual on-chain implementation. It manifests at several points:

• Latency risk - the delay between decision-making and transaction inclusion in a block. In an environment with fast block times, this is critical.
• Slippage risk - actual execution diverges from plan, and the gap widens as position size grows.
• Failed-transaction risk - failures due to congestion, pool-state changes, or insufficient compute budget.
• Stale-position risk - the position remains outside the optimal zone. Capital sits idle or accumulates IL without fee compensation.

In a calm market, execution differences are invisible. When the regime changes, they determine everything.

The systemic problem of the LP approach

The market treats LP as a financial model. In practice, it is an execution problem. In concentrated models: yield depends on time in the active zone, competition favors faster systems, and economics without infrastructure is impractical.

LP in DLMM is a continuous liquidity-management operation under competition and network constraints.

A human cannot maintain this level of monitoring and execution around the clock. This is where infrastructure becomes necessary. SLVCE is the autonomous execution layer that runs the SLVCE Core strategy and manages liquidity regardless of market regime.

Three principles

1. 01Execution > Strategy - Execution is the primary layer; strategy is a superstructure. Most LP models treat execution as a technical detail - in practice it determines whether the strategy is viable. Decisions account for actual network conditions; when execution degrades, activity is reduced or paused. Execution risk is built into the behavioral model.
2. 02Infrastructure > Capital - The driver is infrastructure, not capital. Capital growth without throughput growth leads to competition, slippage, execution degradation, and less time in range. Capital is capped by available throughput and accepted only when there is headroom. Scaling comes through infrastructure improvement.
3. 03Process > Forecast - The system operates without price-direction forecasting. Forecasting does not improve execution, reduce latency, or eliminate competition - it adds model risk. Instead of forecasting there is process: flow observation, reaction to pool state, liquidity repositioning, constraint compliance. Results follow from correct process, not forecast accuracy.

Not an algorithm trying to outsmart the market. Infrastructure that is faster and more precise than participants.

How principles solve systemic LP problems

The systemic LP problems are execution risk, degradation during regime changes, dependence on time in zone, and fragility under load.

SLVCE Core operates as part of an infrastructure system. Resilience and correctness are the priority.

How the SLVCE Core strategy makes money

PnL comes from several parallel mechanisms. Each works in its own market regime and has different sensitivity to execution quality. None is guaranteed.

1. 01Liquidity Fees (~46%) - The core of revenue and its most predictable component. Swap fees distributed proportionally to the liquidity share in the active DLMM range. Works when volume exists, the position is in the active zone, and competition is moderate; weakens when volume drops, price leaves the range, or active segments are overcrowded. Execution link: determines time share in the active zone - delays mean capital downtime, and inaccurate rebalance cuts fee collection.
2. 02Cross-venue Arbitrage (~11%) - Capturing price differences between pools and venues: prices for the same asset are aligned via simultaneous trades across venues. Not a directional bet. Works with fragmented liquidity, transient mispricings, and fast routing; weakens in tight efficient markets, crowded routes, or on latency loss. Execution link: latency- and routing-sensitive - first to lose the race when infrastructure degrades.
3. 03Basis & Carry (~7%) - Yield from durable bases - stablecoins, liquid-staking tokens, wrapped assets - and funding. Holding the spread between linked assets, with no directional bet. Works with stable basis spreads, positive funding, and intact asset linkages; weakens on basis compression, funding flips, or depeg stress. Execution link: low-frequency and cost-sensitive, tolerant of latency.
4. 04Structural / Event-driven (~7%) - Short-lived dislocations around large on-chain events. Opportunistic and race-gated - execution is contested, so the win rate is well below 100%. Works with episodic volatility, large flow events, and clean leader-slot access; weakens on a quiet tape, lost execution races, or congestion. Execution link: the most execution-bound source - leader-slot timing and priority decide the outcome.
5. 05Inventory & IL (−drag) - The structural cost of LP: inventory drift and impermanent loss / LVR as price moves through the range. Booked as a real negative, not hidden. Smallest under range-bound price, a tight active range, and timely rebalance; grows on one-sided trends, wide gaps, and delayed rebalance. Execution link: rebalance timing sets how much IL is realized; the Protection overlay trims the directional part.

Shares are of gross positive PnL; Inventory & IL is the offsetting drag (booked as a negative, shown separately), so the positive sources do not sum to 100%.

Source interaction

• Calm market - liquidity fees lead.
• Fragmentation and activity - arbitrage contribution grows.
• Trend - inventory and IL get costlier; the Protection overlay trims the directional part.
• Overall result comes from overlapping sources.

Why PnL is resilient

Resilience is not a constant income structure. It is independence from any single mechanism. Component shares shift across market regimes.

• Multiple parallel income sources.
• No directional forecasting.
• Capital bounded by the capacity model.
• Everything goes through the execution layer.

PnL follows from process. Strategy sets the framework, execution determines feasibility, architecture limits risk.

The idea

Price is singular. Markets are not.

A single asset does not have a single price. It has as many prices as the places that trade it - pools, exchanges, and networks, each quoting slightly differently at any instant. Those differences are small, temporary, and constant. They open when flow hits one venue before another, when a bridge is slow, when a stablecoin wobbles; they close when someone trades across them. Edge is the book that closes them, and is paid the gap for doing so.

This is not a bet on where a price is going. It is a bet that two prices for the same thing will converge - which they always, eventually, do. The only open questions are which disagreements are worth the cost of closing, and whether the book can execute before the gap closes on its own.

Every market eventually agrees. Before it does, someone is paid for the disagreement.

Why Edge runs in cycles

Core can stay deployed forever - liquidity is always needed, so its capital never has to leave the pool. Edge cannot. A dislocation is temporary by definition; there is no position to sit in and hold. Capital has to enter while gaps are open, harvest them, then be pulled back, reconciled, and reset before the next opportunity set. That rhythm is the cycle - not an operational detail, but a direct consequence of what the strategy is.

Core holds a position. Edge holds a schedule.

A cycle runs roughly 16 to 19 days and is not a fixed metronome: each phase floats within a set range, and each account runs its own cycle in parallel, so no two accounts are on the same clock.

1. 01Entry (~1.7 days) - Capital is deployed from base holdings into working positions across the sleeve assets and venues. Sizing respects current depth and route availability; nothing is forced in.
2. 02Work (10-12 days) - The bulk of the return is made here. Hundreds to thousands of small paired operations close dislocations as they appear. This is the phase the machine spends most of its life in.
3. 03Close (~1.3 days) - Positions are unwound back into base assets. Open exposure is retired deliberately, not dumped.
4. 04Consolidation (3-4.5 days) - Funds are gathered from every route and venue and finalized into one clean, reconciled payout. The cycle books its realized result; the next cycle re-seeds from it.

Because profit compounds cycle to cycle - each cycle re-seeds from the last - the book grows on its own realized result, not on fresh deposits.

The shape of a dislocation

Every capture Edge makes traces back to one kind of market inefficiency. So the book is organized around the disagreement it is exploiting, not around a catalog of tactics - the tactic is only the consequence. There are a handful of shapes a dislocation can take, and each pays under different conditions.

1. 01Price - the same value, quoted apart - The most common shape. A single asset, or a tight set of related assets, is quoted differently across places at the same instant - between two on-chain pools, between a centralized exchange and a pool, between two networks, or across three assets whose ratio has drifted. Closed by trading simultaneously across the venues that disagree; across chains it runs on inventory already positioned on both sides, and the bridge is used to rebalance the two, never to carry the trade. High-frequency, small-ticket, and the steady base of the book. (Methods: cross-venue, cross-asset, and cross-chain routing.)
2. 02Time - spot against the future - The spread between an asset's spot price and its perpetual future. Held market-neutral - long one side, short the other - so the position has no directional view; the return is the spread closing as the two converge into expiry. Low-frequency and cost-tolerant. (Methods: wrapper basis, futures basis.)
3. 03Settlement - what perps pay to stay open - The funding rate that perpetual-future holders pay each other to keep a position open. Collected market-neutral by holding the paid side against a spot hedge. Pays while funding is wide; weakens as it compresses or flips. (Methods: funding, DEX funding.)
4. 04Stable basis - and its rare tail - A small, steady spread between dollar tokens, taken continuously. A stablecoin or a staked asset trading away from its peg is the fat, rare tail of the same line: contested, the fattest single capture when it lands, with a win rate well below 100%, because everyone can see it and the race is crowded. (Method: stable basis.)
5. 05Lending - the rate gap between venues - The spread between borrow and supply rates across venues and protocols, taken only while it clears costs. Slow, small and steady. (Method: lending.)
6. 06Inventory - the cost side, booked honestly - Closing gaps leaves the book holding assets it must recycle back to base. When that recycling is slow or expensive, it is a real drag - carried in the open as a negative, never hidden inside a net number.

The steady base is high-frequency price dislocations; the rare, large captures (peg breaks, wide cross-chain gaps) are the tail, not the base. None is guaranteed - in any given cycle some shapes pay and some sit idle. Live contribution by type is shown on the Edge dashboard.

From observed to captured

The single most important fact about Edge: not every dislocation it sees becomes money. A gap on a screen is not a gap in the book. Between the two sits execution, and Edge measures the drop-off at every step rather than assuming it away.

1. 01Observed - A price disagreement is detected across venues, sized, and costed. Most observed gaps are never acted on - too small to clear fees, or already closing.
2. 02Attempted - The gaps worth closing are committed as paired trades - both legs sent to converge the price.
3. 03Captured - Both legs land at or better than target and the gap is banked. Only this last step is realized PnL.

Between attempted and captured, an operation resolves one of three ways, and each is booked as what it actually was:

A dislocation seen is not a dislocation captured. The difference is execution - measured, not assumed.

How Edge is accounted

Every sleeve is a double-entry book. This is the center of Edge, not a footnote - the accounting is the product, and the return is only its output. Every unit of value is traceable through one chain, and the chain is reconciled continuously, at every level.

1. 01Inventory - What each sleeve actually holds, in native units, at every moment - the ground truth everything else is derived from.
2. 02Trades - Every operation that moves inventory, booked individually with its own realized result. Nothing is netted before it is recorded.
3. 03PnL - The sum of those trade results, counted two independent ways - by trade and by tick - which must always agree. A standing invariant checks them against each other; if they drift, the book flags itself rather than papering over the gap.
4. 04Sleeve NAV - Inventory priced by Edge's own oracle, shown in native units first and dollars second, never blended into a single synthetic unit.
5. 05Fund NAV - Sleeves roll up into the book, and the book into the fund, with the same reconciliation applied at every level of the rollup.

Because the two counts must always reconcile, a silent error has nowhere to hide - the moment the trade view and the tick view disagree, the system says so. That is what makes the numbers on the dashboard trustworthy: they are not a report written after the fact, they are the ledger itself.

Why Edge is closed

Edge is deliberately capacity-bounded. This is not caution bolted on afterwards - it follows directly from what the strategy is. A book that lives on finite disagreements cannot simply absorb more capital and find more of them.

• Dislocations are finite. There is only so much disagreement in the market at any moment; a larger book does not create more of it.
• Execution degrades with size. Past a point, the book's own trades move the very prices it is trying to close - it starts competing with itself.
• Capacity is measured, not assumed. The size at which execution quality begins to fall is estimated continuously from live depth, spread, and fill data, and treated as a hard ceiling.
• Access is limited. New capital is accepted only while there is headroom under that ceiling, and each allocation is reviewed individually.

The Edge book, live

The same feed edge.slyce.xyz reads, shown here in the library: the book priced at Edge's own oracle, the cycle in progress for each sleeve in its own coin, and the mix of dislocation types the captures came from over the last thirty days.

Where Edge loses

Edge is not a machine that always wins, and it is worth naming the conditions under which it makes little or nothing.

• When markets synchronize faster than the book can execute - the gap closes before both legs land.
• When routing and gas costs exceed the spread - the dislocation is real, but not worth closing.
• When bridge latency expands - cross-chain captures carry more risk than they pay.
• When venues halt or pull liquidity - the other side of the trade simply is not there.
• When inventory cannot be recycled economically - capital sits in the wrong asset and waits.

In those periods the book stands flat. That is not a failure of the strategy - it is the strategy working correctly. Edge is built to do nothing when doing something would lose money; a cycle that closes near zero because conditions were poor is a cycle that protected capital.

The worst thing a dislocation book can do is force a trade when the market is already agreed.

What Edge is not

• Not forecasting - it holds no view on where any price is going, only on whether two prices for the same thing disagree.
• Not leverage - the return comes from closing gaps, not from borrowing to amplify a position.
• Not continuous - capital works in bounded cycles with a clean, reconciled close, not an open-ended tape.
• Not guaranteed - some cycles close flat or down; the drag and the misses are booked in full, in the open.
• Not blended with Core - a separate book, separate sleeves, separate accounting, separate risk.

Core monetizes liquidity. Edge monetizes disagreement. Both are execution businesses - and both disappear the moment execution stops being better than the market.

4.1 System Context & Dataflow

This reflects the full context of SLVCE - from external data sources to internal components that provide decision-making, risk management, and operation execution. Every element exists in the running system and performs a specific function.

External Environment:

• Solana Network - the blockchain on which the system operates. Source of data on pool states, balances, and transactions; the target environment for sending transactions.
• DEX / DLMM Pools - decentralized exchanges and liquidity pools in which the system places positions. The primary source of income (trading fees).
• Market Participants - traders, bots, arbitrageurs, other LPs. Their activity creates trading volume and, consequently, fees for LPs.

SLVCE Infrastructure Layer:

• RPC Cluster - multiple geo-distributed RPC nodes for receiving data and sending transactions. Provides fault tolerance and minimal latency.
• Shred Ingest - receiving and decoding shreds (minimal Solana data units) directly from validators. Lets the system see transactions before they are included in a block - the pre-mempool advantage.
• Priority Tx Gateway - sends transactions with adaptive priority fee. Automatically determines the optimal fee based on current network congestion.
• Stake & Infrastructure Ledger - internal accounting of staking and infrastructure costs. Provides accurate calculation of net performance.

Execution and Logic Layer:

• Market Data Bus - a single stream of normalized market data. Aggregates information from all sources (RPC, shreds, on-chain events) into a unified format.
• State Engine - forms a unified representation of the current state: prices, positions, balances, pool states, system mode. Updated every tick (5 seconds).
• Decision Engine - makes decisions based on the current state. Does not use predictive models - reacts to the actual market state.
• Risk Engine - filters Decision Engine decisions through a set of rules and limits. Can block, modify, or pass a decision.
• Execution Planner - plans and executes operations: position-size calculation, transaction building, retry-logic management.

Capital and Allocation Layer:

• Capacity Controller - determines the maximum volume of capital the system can effectively manage. Dynamically adapts to market conditions.
• AUM Intake Gate - controls the acceptance of new capital. Blocks acceptance if current AUM is close to the capacity limit.
• Position Sizing - calculates the optimal size of each position, taking current capacity, risk, and pool states into account.

Monitoring and Control: all components generate metrics and logs aggregated into centralized monitoring. The operator dashboard provides a complete picture of system state in real time; alerting flags anomalies and critical events.

4.2 Capacity Controller

The Capacity Controller determines the actual throughput capacity of the system under current market conditions. It ensures the volume of managed capital does not exceed the level at which execution quality begins to degrade. It does not manage capital directly - its task is to determine the boundary up to which the system can operate effectively. This boundary is not a static constant but a dynamic value that depends on current conditions.

Input data: liquidity depth in target pools, current volatility, average slippage over recent operations, Solana network congestion, current AUM and its distribution across positions. Capacity is calculated as the minimum of several independent constraints - each determines the maximum AUM at which a specific aspect of execution remains within acceptable limits, and the final capacity is the minimum of all constraints.

The AUM Intake Gate uses Capacity Controller data to decide on accepting new capital. If current AUM exceeds 90% of capacity, acceptance of new capital is blocked automatically - protecting existing investors from execution-quality degradation. When approaching capacity, the system also automatically reduces new position sizes, increases the minimum threshold for rebalancing, and tightens slippage tolerance.

4.3 Operating Loop

The Operating Loop is the formalized working circuit - the sequence of actions through which every decision passes, from observation to reconciliation of the execution result. It is a real circuit that executes continuously and synchronizes all modules. The loop is hybrid: the event-driven decision circuit is complemented by a periodic state-verification circuit. Decisions are initiated by market events and system state, while the periodic cycle handles reconciliation, invariant checking, and mode updates. In critical scenarios the system uses an interrupt path for immediate halt or protective actions.

1. 01Observe - The system receives data from multiple sources: RPC nodes (pool states, balances, prices), shred-ingest (pre-mempool data, before inclusion in a block), and on-chain events (transactions in target pools). All data is aggregated into the Market Data Bus - a single stream of normalized data from which the State Engine forms the current market picture.
2. 02Decide - The Decision Engine analyzes the current state and determines whether action is needed: open a new position, close an existing one, rebalance the range, change liquidity density. The decision is formed from the current state, not a forecast - the system reacts to what has already happened, not to where the price might go.
3. 03Risk - Every decision passes through the Risk Engine - a set of filters and limits. The Risk Engine can pass a decision unchanged, modify its parameters (reduce size, narrow range), or block it entirely. Filters include concentration limits, slippage checks, current-system-mode checks, and available-capacity checks.
4. 04Execute - The decision that passed the Risk Engine is forwarded to the Execution Planner, which calculates the optimal position size (Position Sizing), builds the transaction around current network state, sets the priority fee based on congestion, sends the transaction through the Priority Tx Gateway, and monitors confirmation while handling errors (retry logic).
5. 05Reconcile - After execution the system reconciles expected and actual results: whether the actual price matched the expected one, whether the transaction executed in full, and whether the position state updated correctly. The reconciliation result updates the State Engine and calibrates parameters for subsequent iterations.

Every step is critical: without correct synchronized data the market picture is distorted; decisions on stale state create false signals; lack of strict filtering breaches limits and accumulates unmanageable risk; suboptimal execution turns a correct model into slippage, delays, and failed transactions; and without reconciliation, drift emerges that gradually destroys the correctness of the whole system. The repeatability of structure with adaptability of content ensures predictable behavior across different modes.

4.4 System State Machine

The System State Machine describes what modes SLVCE can be in and how transitions occur. The mode affects all aspects of operation, from position sizes to capital acceptance.

Transitions occur automatically on a set of triggers. Moving from a softer mode to a stricter one happens instantly when any trigger fires; moving back happens only after sustained normalization of all parameters over a period (hysteresis). Hysteresis prevents "bouncing" between modes at borderline values. Hysteresis times differ by transition: LIMITED → NORMAL 15 minutes, CONSERVATIVE → LIMITED 30 minutes, PAUSED → CONSERVATIVE 60 minutes.

4.5 Deployment & Infrastructure Topology

Each component is placed considering requirements for latency, fault tolerance, and security.

• Regional distribution - infrastructure distributed across multiple regions to minimize latency to Solana validators and ensure fault tolerance. The main cluster sits in the region with minimal delay to majority-stake validators.
• RPC infrastructure - a cluster of dedicated (not shared) RPC nodes, geo-distributed for minimal latency, with automatic failover on any node failure and separation into read/write streams.
• Shred Ingest and pre-mempool processing - receives shreds directly from validators via the Turbine protocol, obtaining transaction information before block inclusion (pre-mempool advantage). Critical for low-latency decision-making.
• Central cluster - logical components (State Engine, Decision Engine, Risk Engine, Execution Planner) run on a dedicated cluster with guaranteed resources and no CPU/RAM competition, plus a hot-standby replica for instant failover.
• Transaction execution and control - the Priority Tx Gateway manages sending: adaptive priority fee, parallel sending through multiple RPCs, confirmation monitoring, automatic retry with updated blockhash.
• Monitoring, logging, and control - structured logs and metrics feed centralized monitoring: a real-time dashboard, alerting on deviations, a complete audit trail, and state history for post-mortem analysis.

The system is designed for graceful degradation - on failure of any component it does not stop completely but transitions to a more conservative mode. RPC node failure switches to backup; shred-ingest failure drops to RPC-only operation (losing the pre-mempool advantage); main-cluster failure switches instantly to hot-standby. The topology is optimized for two goals: minimal latency and maximum fault tolerance - every component has redundancy, every connection a fallback.

5.1 Data classes and information flow

The Execution Layer receives a structured decision from the Decision Engine that has passed Risk Engine filtering. The decision contains operation type (open, close, rebalance), target pool, position parameters (range and size), and constraints (max slippage, deadline).

Before execution, the decision is matched against data sources: confirmed network state via RPC, the pre-confirmation event stream, and internal system state (active ranges, inventory, history). Data is normalized by time and the decision is checked for relevance. At the output, the Execution Layer produces a confirmed transaction or a rejection report, actual execution parameters (slippage, latency, cost), and data for reconciliation (expected versus actual state).

5.2 Decision acceptance and rejection

Not every decision becomes a transaction. Before sending, the system checks pool-state relevance, balance sufficiency, RPC availability, current congestion level, and compliance with slippage limits. If conditions change between the decision and submission, the decision is rejected - stale actions are not executed, and rejection is correct behavior.

Three categories are recorded: Executed, Deferred, Rejected. The history of all decisions is preserved for analysis of execution quality and rejection reasons.

5.3 Execution infrastructure

Execution is a process with indeterminate confirmation time. The system works with facts, not assumptions.

5.4 Execution quality control

Each operation is evaluated against a set of metrics: actual slippage vs expected, latency from decision to confirmation, number of retries, execution cost, share of rejected decisions, and discrepancy between plan and actual. These metrics are used for calibrating subsequent operations, detecting infrastructure degradation, limiting activity, and switching system mode.

5.5 Execution and system-mode relationship

Execution degradation automatically downgrades the system mode: NORMAL → LIMITED → CONSERVATIVE → PAUSED.

5.5b Trading pairs and asset roles

The unit of account is the US dollar; the assets below are inventory the strategy holds and turns over. Active inventory is distributed across four trading pairs, with each asset playing a distinct role.

Not a directional crypto bet: no BTC / ETH position works as a "buy and hold for appreciation" play. The BTC class is controlled by the asset-class invariant - the structural delta-neutral WBTC/cbBTC spread is not false-flagged, while directional concentration (long or short above 70% of capital on a class) triggers an alert. ETH inventory is held only at the level required for MM operations.

5.6 Why execution cannot be replaced by strategy

Strategy defines what to do; execution defines whether it is possible to do it and with what quality. In a DLMM environment, dozens of LPs work with the same data - the difference in results arises at the level of reaction time, accuracy of liquidity movement, execution cost, and infrastructure stability. Execution does not scale linearly with capital; it is a limited resource. SLVCE manages execution as a separate risk layer, not as a technical appendage to strategy.

When everyone sees the same data, the one who executes faster and more precisely wins.

Mode model

Each mode constrains position size, operation frequency, allowable slippage, and overall activity level.

Closed-loop principle

• Every decision passes through a risk filter.
• Every allocation passes through a capacity gate.
• Every execution passes through mode constraints.

No layer can bypass another: the Decision Engine cannot bypass the Risk Engine, execution cannot bypass the mode model, and capital cannot bypass capacity constraints.

Autonomy

Normal operation requires no operator. The operator is limited to configuration changes, infrastructure updates, and post-factum incident analysis - making no decisions manually, only observing and stepping in when an invariant breaks.

A deterministic infrastructure system, not an operator strategy.

The five revenue sources of the SLVCE Core strategy - Liquidity Fees, Cross-venue Arbitrage, Basis & Carry, Structural / Event-driven, and Inventory & IL drag - are detailed in the strategy section. Below: how they combine, and how Protection trims the tail.

Inventory Hedge - the Protection layer

Protection is a first-class layer. The directional exposure built up in LP inventory is offset by the hedge the book holds itself. It does not trade on a schedule: it re-neutralizes only when net exposure leaves an allowed band, and only when the expected cost of drift exceeds the cost of executing the hedge. This trims inventory tail-risk without eating into fee income. The band, the venues and the guard thresholds are stated below; per-position sizing stays operational.

The standing hedge - a short against the inventory

Separate from the strategy, a standing hedge removes the linear price exposure of the book. It is a short perpetual future in the assets the inventory holds (SOL, bitcoin and ether; stablecoins are treated as dollar exposure), collateralised with the fund's own dollars and executed across Binance, Bybit, OKX, Coinbase, Gate and Kraken by depth, from one cross-margin wallet. Over it sits a small option tail: out-of-the-money puts on bitcoin and ether that pay in a violent, market-wide fall, bought within a fixed annual premium budget. Both carry a cost, funding, fees, slippage, basis and premium, and every cost is booked on its own line rather than folded into the result.

The cutover is marked at 10 September 2026 and Core 2.0 went live on 14 September at 20:00 UTC; the engine stood paused between the two dates. The hedge is held directly by the fund, not through a pool with units. It is a short perpetual against the inventory the book already owns, sized one for one in units of each asset rather than in dollars, so a price move alone never knocks it out of balance. Its daily result reaches each account in proportion to the exposure that account contributed, and is shown in SLVCE One under Core, Protection.

1. 01Daily settlement - Each day is sealed once, and the sealed day states four things apart: what the strategy earned, what the market did to the inventory, what the hedge returned, and what it all cost. The hedge settles every sealed day, not monthly. Each account receives its share of that day through the same dollar door as every other movement of money: it changes net asset value and never touches contributed capital.
2. 02The tail - Over the perpetual base sits a ladder of out-of-the-money puts on bitcoin and ether, struck 10, 20 and 30 per cent below spot and funded by a fixed budget of one per cent of net asset value per year. In a calm year that premium is simply a cost. In a crash it pays several times over.
3. 03Margin and guards - The short is collateralised at twice the minimum requirement. Three thresholds act on their own as the distance to liquidation narrows: at 30 per cent the margin is topped up, at 20 per cent inventory is sold and the short cut to match, at 12 per cent the position is flattened and the asset halted.
4. 04The pool is closed - The mutual pool that carried the hedge until September 2026, with senior units and an equity tranche, was closed at the Core 2.0 cutover. Investors no longer hold a stake in a pool; the hedge belongs to the book itself.

Source interaction

• Calm market - liquidity fees lead.
• Fragmentation and activity - arbitrage contribution grows.
• Trend - inventory and IL get costlier; the Protection overlay trims the directional part.
• Overall result comes from overlapping sources.

Why PnL is resilient

Resilience is not a constant income structure. It is independence from any single mechanism - component shares shift across market regimes. Resilience factors: multiple parallel income sources, no directional forecasting, capital bounded by the capacity model, and everything going through the execution layer.

Multi-asset accounting - live since 14 September 2026

The accounting core is being upgraded so that PnL is born natively in the asset of each trade leg - a WBTC/USDC fill earns its spread in USDC and carries its inventory leg in WBTC, rather than everything being booked through a single ledger unit. Per-account risk profiles then earn genuinely different mixes: a conservative account a more stable, fee-heavy stream; a growth account a more market-coupled one. Since 14 September 2026 this runs live. PnL is born in the asset of each trade leg; the ledger, capital, the daily close, the hedge and the reports all state US dollars, and each day is sealed once. Holdings, history and high water marks carried over from the previous engine unchanged.

PnL follows from process. Strategy sets the framework, execution determines feasibility, architecture limits risk.

8.1 No leverage

No leverage in the strategies. Every liquidity position is backed by own capital, so the strategies themselves cannot be liquidated or margin-called. The one place margin exists is the standing hedge: the short is collateralised at twice the minimum requirement, and three automatic guards act as the distance to liquidation narrows (see Protection). Rejecting leverage in the strategies reduces potential returns but removes nonlinear amplification of execution risks.

The hedge reduces price exposure, it does not remove it. It carries funding, trading fees, slippage, basis and option premium, and in a rising market it will show losses while the market line shows gains; see Limitations & Risks.

8.2 Concentration limits

The system limits capital concentration by pools, by tokens, by ranges, and by execution windows. Limits are dynamic and account for current liquidity, volatility, competition, and execution-layer capacity. Diversification is by liquidity-placement structure, not by asset classes.

8.3 Regime model and pause

PAUSED is not an emergency. It is an acceptable and normal state.

Automatic transition to restricted mode or pause on execution degradation, data anomalies, increasing failures, or infrastructure instability. Pause is used to prevent uncontrolled actions, not as a reaction to an already realized loss.

8.4 Stop conditions

Stop conditions are strict conditions for immediate halt. They can be triggered by critical drawdown, loss of infrastructure access, divergence between actual and expected state, anomalous pool behavior, or mass transaction failures. They are not optimized for profitability - they trigger before damage becomes significant.

8.5 Recovery logic

After restriction, the system does not return to NORMAL instantly. Recovery runs state-integrity verification, position and balance reconciliation, analysis of the restriction cause, and gradual activity restoration. Soft start uses minimal position sizes, limited operation frequency, and gradual parameter expansion - preventing re-triggering when conditions have not fully normalized.

8.5b Drawdown throttle and asset-class invariant

Two additional layers on top of limits and the regime model.

• Drawdown throttle - auto mode: after a short drawdown the system lowers the yield ceiling. Tier-based: severe / mild / neutral / hot / euphoric. Recovery is automatic without manual intervention. Logged daily, visible to operator in the audit log.
• Asset-class net invariant - BTC class merges the wrapped variants WBTC + cbBTC (same underlying); ETH class is WETH. Limit: |net class exposure| > max(70% of capital, a small fixed dollar floor ~$20k) is flagged. Direction-agnostic - long or short trigger equally - so the WBTC/cbBTC spread arb is not false-flagged.

8.5c Market Conditions Index

The system continuously distills the live market environment - the character of volatility, market depth, the fee environment, opportunity windows, the market’s direction and how much leverage OTHER participants have stacked around it (the book itself stays unlevered - this is a risk signal, not a tool we use), and the book’s own state - into a single internal market-conditions index with regimes running from clear to storm. The index reads only the real market and the system’s own measured state - never modeled results - so the signal can never be contaminated by the system’s own output.

• In deteriorating regimes the allocation layer gradually leans toward the stable reserve - within the same per-cycle limits that always apply.
• The market’s direction and outside participants’ leverage are read as a risk signal, not a tool we use (the book is unlevered): a persistent, confirmed downtrend and signs of forced selling as that outside leverage unwinds make the protective lean firmer and earlier, while a healthy uptrend eases it back - always defensively, never as a directional bet.
• The hedge band tightens: the short is re-matched to the inventory on smaller deviations.
• The option tail is kept, not monetized - in a storm, protection stays on.
• In normal conditions all of this stays dormant: base targets, the standard band.

Bounded by design: the index acquires no new powers - it only re-weights machinery that is limited independently of it; each coupling sits behind its own audited switch; a stale index is ignored entirely (everything reverts to neutral behavior), and its freshness is itself watched by the integrity layer.

The value of this discipline is measured, not asserted: the system keeps a running score, in dollars, against a do-nothing counterfactual at real market prices. Both sides are recorded - the protection the discipline buys in bad markets, and the cost it carries in good ones.

8.6 Deliberate trade-offs

• Rejection of leverage.
• Capital-volume limitation by the capacity model.
• Allowance for periods of reduced activity.
• Priority of resilience over short-term profitability.

These reduce aggressiveness and increase survivability during regime changes and infrastructure degradation. SLVCE does not eliminate risk - it makes it bounded and manageable.

Operations - current cycle

Engine metrics for the current cycle (since December 25, 2025). These describe execution quality - not fund value. Fund value is the USD record above. Figures are loaded live from the same feed as the header; a static baseline is shown until they arrive.

How to read these

• Win Rate - percentage of profitable trades. It is a per-trade figure, not a per-day NAV figure; in dollars some days still close red, which the record above shows honestly.
• Uptime - share of the cycle the system was operational.
• Volume - dollar turnover, a measure of activity and capacity use, not profit.
• Signals - total processed and the executed share. Most signals are filtered out; execution is selective by design.

Monthly PnL

Per-month figures are loaded live for the current cycle (since inception, 25 Dec). The first month and the in-progress current month are partial and marked as such in the live table. The engine books each day in US dollars and seals that day once at the daily close, with strategy, market, hedge and costs stated separately. Months before the priced dollar series began are shown as a dash rather than restated at a later price; the dollar record begins where the daily marks do.

PnL by source

Per-trade edge legs grouped into five public-facing sources, each shown with its dollar value (daily-marked, as above), share, and trade count:

• Liquidity Fees
• Cross-venue Arbitrage
• Basis & Carry
• Structural / Event-driven
• Inventory & IL

Execution quality

• Loss Days - across the entire cycle.
• Avg Daily PnL - total over days.
• Avg Trade PnL - across all types.
• Uptime - system availability.

A performance page is a claim. This is a commitment with a cost to breaking it: the record is fixed the day it is written, and the fixing is published where we cannot reach back and edit it.

How the chain works

For each finalized day, in order, we compute a per-day hash of the published row, then fold it into a running chain hash. The latest chain value - the head - commits the entire history at once.

A reader recomputes the leaf from the published numbers and re-walks the chain. It is pure sha256 arithmetic - nothing here asks you to trust us.

Nothing about the mechanism is private. The chain code, the append-only log, the Bitcoin timestamps and the verifier live in a public repository, github.com/zglide/slvce-attestation, and the current head is served live below and at deep.slyce.xyz/api/attestation. Anyone can clone the repository and recompute every hash.

# leaf = sha256 of the published row
import hashlib, json
rec = {"date":"…","nav":…,"capital":…,"strategy":…,"red":…}
hashlib.sha256(json.dumps(rec,separators=(",",":")).encode()).hexdigest()
# chain = sha256(prev_chain + leaf)

What it does, and does not, prove

• It proves no published day was rewritten after the fact - the head would break.
• It proves the log existed before a given Bitcoin block, via the OpenTimestamps anchor on the head.
• It does not retroactively timestamp days before genesis: those are committed in the genesis head so they cannot change afterward, but we do not claim they were stamped in the past.
• It commits the figures, not the trades behind them - no addresses, venues, or position sizes are revealed.

The point is not that the numbers are good. The point is that they cannot quietly become different numbers later.

SLVCE One - the investor app

SLVCE One is the investor app at one.slyce.xyz. It installs to the phone home screen as a web app and replaced the Telegram mini-app on 25 August 2026. One account, one way in: email and a passkey, with Face ID on the device. The SLVCE Telegram bot retires on 21 September 2026. Passwords are checked by the portal, never stored in the app.

Anything that moves money asks for a second confirmation: a passkey, or a six-digit authenticator code for investors who have enabled one in the portal. That covers profit withdrawals, redemption notices and card top-ups.

What an investor sees in One

The Journal and The Print are readable inside the app. A viewer role lets an investor add accounts of a family cluster to the same net worth; a watch role gives read-only sight of another account without summing it.

Investor portal

The web portal at my.slyce.xyz is the document and onboarding surface. It signs in with email and password (with an optional authenticator), or directly from One. It holds the signed documents, capital requests and their status, the mirror of redemption notices, and the security settings that One relies on.

Onboarding is a state machine with stages: invited, gate accepted, NDA signed, KYC in progress, KYC approved, documents pending, documents signed, subscription pending, active. Every onboarding, capital and signature event is written to an append-only audit log; rows cannot be updated or deleted.

• Entry Gate - four acknowledgements in a blocking modal: Disclaimer, Terms of Use, Privacy Notice, Risk Warning. KYC opens only after this step.
• NDA and fund documents - a mutual NDA with typed signature, then Risk Disclosure, Offering Memorandum and Subscription Agreement. Each acknowledgement stores the hash of the document as it was at signing. Edge investors sign a separate Edge package and re-acknowledge it when the terms change.
• Subscription lock - the terminal onboarding event. On acknowledging the Subscription Agreement the system snapshots accrued profit, capitalises it into base capital, stamps the lock-up window, and sends one aggregated receipt in US dollars to the investor and to the operator. Pure bookkeeping, no on-chain movement, reversible through the audit trail.

SLVCE Private - the card

SLVCE Private is a metal Visa Platinum card that carries no printed numbers, with Apple Pay and Google Pay. It is funded from the investor's SLVCE accounts: strategy earnings settle to the account, the account funds the card. The card is requested and managed in the Private tab of One: activation, delivery address, limits (set with the operator), freeze, and card details revealed on demand and concealed again after thirty seconds. The card terms are published at private.slyce.xyz. Further services on that page, including concierge, eSIM and spending directly from yield, are described there as planned.

Statements and reports

• Statements on demand - a weekly or monthly PDF statement generated in One under Account, per investor, from the same ledger the app reads.
• Daily digest - an email at 08:00 UTC with the day's result per account.
• Weekly and monthly reports - a weekly summary on Sunday and a long-form monthly report on the 1st of each month, delivered by email and mirrored in the app. The first monthly report of Core 2.0 goes out on 1 October 2026.
• Edge cycle reports - an automatic PDF at each closed cycle, to the investor and the operator, listing every execution record. One execution record is one terminal execution event; it may settle positive, negative or revert. The venue chart shows the share of records, not of money.
• Hedge settlement notices - a note each sealed day when the hedge result reaches your account, and when the hedge rules change.

Every delivery is logged. Investor-facing capital figures are always in US dollars; native units appear only where the asset itself is the point, as in Edge sleeves.

Operator interface

A separate internal interface displays execution metrics, RPC and infrastructure status, capacity and headroom, pool concentration, mode-transition history, stop conditions and active constraints, and the redemption and settlement queues. The operator does not intervene in individual decisions; the operator monitors invariants and executes the capital actions that require a human: pricing a redemption window, paying it out, releasing a holdback.

Notifications and control events

Notifications reach the investor as push messages in One and by email. Events include mode changes, capacity limits reached, large drawdowns, onboarding milestones, capital operations (deposit, withdrawal, subscription lock, redemption received, priced and paid), cycle closes, settlement notices and new publications. Cycle closes, settlement notices and the routine digests go out automatically. Anything else that concerns capital is drafted first and released by the operator.

Transparency

Transparency is implemented at the system-state level. The investor sees current results, historical dynamics, active constraints, the protection stake and operating mode. No trading signals are provided, and operational micro-logic is not disclosed.

Control without intervention

The investor has full access to data but does not control execution. This protects the system from emotional decisions, uncoordinated parameter changes, and risk-model violations. The system stays autonomous; the investor still sees everything that matters.

Profit withdrawals

Realized strategy profit in Core can be withdrawn from One on any day. Max $10,000 per withdrawal. The request settles after a short hold and needs a step-up confirmation. What the app shows as available is only realized profit; unrealized value and principal are never part of it. There is no fee on a deposit or a withdrawal.

In Edge, earned profit follows the same rail. Edge capital is separate: it can be redeemed only between cycles, in the window after a cycle closes and before the next one funds, and there is no early-exit penalty. Edge is accounted and redeemed in native units: an investor who deposited BTC and ETH is owed BTC and ETH, with dollars as the reference only.

Edge is in a service window until 17 September 2026, 20:00 UTC: cycles are extended and withdrawals are paused for its duration. The final Edge allocation round takes lots of 0.6 BTC, 37 ETH or 35,000 USDT on apply.slyce.xyz until 30 September 2026; after that no new Edge applications are accepted. Edge 2.0, with a daily close per sleeve and a coin-denominated capital door, is planned for October.

Redeeming capital

1. 01Notice - A redemption notice for Core capital can be filed on any day from One, under Assets, Capital & redemptions, as a percentage or a dollar amount. A notice filed in month M is priced at the Valuation Day at the end of month M+1, the last business day of that month. The first window is 30 September 2026. A notice can be cancelled while it is still in notice.
2. 02Price - The redeemed part is valued at the account NAV on the Valuation Day. The lock-up is respected: capital still inside its three months cannot be noticed out early.
3. 03Performance fee - Crystallized on the redeemed part only, against the high-water mark of that capital series: 25% of profit up to a 20% annual return, 50% of the part above it, pro-rated to the fraction of the year the capital was in. The high-water mark of what stays behind does not move.
4. 04Gate - Redemptions in any window are limited to 25% of fund NAV. If notices exceed it, every notice in that window is scaled down pro-rata and the remainder rolls to the next window.
5. 05Payout and holdback - 95% is paid in USDC within ten business days of the Valuation Day. The remaining 5% is fixed at pricing and released 90 calendar days after the Valuation Day.

The investor is notified when the notice is received, when it is priced, when it is paid and when the holdback is released. Redemption liabilities are carried in the fund NAV from the day the notice is received and appear in the attested daily record.

Fees

A 1% management fee per year, accrued and deducted from profit before the performance fee, and the two-tier performance fee above: 25% of profit up to 20% annualised over the mark, 50% above it. It crystallises on 31 December and on redemption, against a perpetual personal high water mark, and each contribution keeps its own dated series and its own mark. No entry, exit, deposit or withdrawal fees. The arithmetic is worked through in the Journal note "What we charge".

The protection stake

The hedge is part of the book, not a separate holding you buy into. Its daily result moves net asset value and never touches contributed capital. The mechanics are in PnL Formation & Protection.

11.1 Market risks

The system is subject to market conditions: extreme volatility, prolonged trend movements without reversals, declining trading volume, changes in liquidity structure, and flow migration to alternative venues. Under such conditions individual PnL sources may weaken, rebalance may lock in losses, and periods of zero returns are possible.

System behavior: activity reduction → LIMITED → CONSERVATIVE → PAUSED if necessary. Market risk cannot be eliminated by architecture.

11.2 Execution risks

Execution risk includes latency increase, slippage increase, increase in the failed-transaction share, priority-cost growth, confirmation-time unpredictability, and competition for active segments. Upon realization: automatic limit tightening, position-size reduction, operation-frequency restriction; under critical degradation the system goes to PAUSED. Execution risk is managed through infrastructure and the mode model.

11.3 Infrastructure limitations

The system depends on Solana network availability, RPC and communication-channel operation, data correctness, and internal-service operability. Redundancy exists, but partial and cascading failures remain possible. System behavior: graceful degradation → activity restriction → on loss of critical components, PAUSED. Infrastructure risks cannot be fully eliminated.

11.4 Human factor

The system is autonomous; configuration and updates are manual. Risks: configuration errors, incorrect updates, misinterpretation of anomalies. Impact limitation: strict Risk Engine limits, configuration validation, change logging, and role separation. The human factor cannot be fully excluded.

11.5 Regulatory uncertainty

Operating in DeFi involves uncertainty of legal status. Risks: legislative changes, protocol-access restrictions, operational-model requirements, and jurisdictional differences. SLVCE operates with decentralized protocols and no intermediaries; regulatory changes may require adaptation.

Summary

Participation implies acceptance that periods of zero returns are possible, losses are possible, technical limitations are possible, and pauses are possible. The system is built for loss limitation, reducing the probability of uncontrolled actions, and adapting to deteriorating conditions.