Protected Basket of Tokenised Stocks¶

Issuer: MoonUp · Document version: 1.1 · Date: July 2026 · Classification: Public

Abstract¶

Constant Proportion Portfolio Insurance (CPPI, Black & Jones 1987) dynamically allocates between a risky asset and a protective reserve in proportion to the distance between portfolio value and a declared floor. MoonUp implements CPPI as a continuously running strategy engine over self-custodied on-chain portfolios: allocations, rebalances, and fees are settled and recorded on-chain, and yield earned in the protective leg accrues directly to the position.

The system is a three-agent architecture:

1. A rules-based strategy engine computes targets and detects drift on a ~10-minute cycle.
2. An agentic AI Guardian adjusts the strategy's multiplier in real time from macro, sectorial, single-name, and price-action signals.
3. A supervisory Risk Sentinel independently authorizes every proposed trade before execution and can freeze a position in degraded or emergency conditions.

This document specifies the mathematical framework, basket design, agent responsibilities and boundaries, position lifecycle, and risk profile.

1. Background¶

1.1 Motivation¶

Growth assets carry the largest expected long-run returns and the deepest short-term drawdowns. Common retail mitigations are blunt: calendar-rebalanced fixed weights, binary stop-losses, or costly option overlays. CPPI instead makes allocation a continuous function of the distance to a declared floor: heavily invested in growth when the cushion is wide, systematically rotated into the protective leg as the cushion compresses.

1.2 On-Chain Execution¶

Traditional CPPI is delivered through fund wrappers, with daily-or-slower rebalancing, management fees, and no allocation-level transparency. On-chain execution changes the operating properties:

• Continuous settlement: swaps confirm in seconds rather than at end-of-day NAV.
• Public state: every allocation, rebalance, and fee is independently verifiable on-chain.
• Self-custody: the user's wallet holds the underlying tokens at all times; capital is never transferred to a counterparty.
• Direct yield: the protective leg earns from on-chain instruments (lending, tokenised treasuries, reinsurance tranches) with no fund layer extracting a margin.

The product is a strategy engine operating on a self-custodied wallet, not a pooled fund.

2. Strategy Mechanics¶

2.1 Core Variables¶

Floor \(F\) is the minimum portfolio value to protect:

where \(f \in [50\%, 95\%]\) is user-selected and \(V\) is total portfolio value at the time of instruction. The floor is not fixed in dollar terms: changing \(f\) recomputes \(F\) against the current \(V\), so a rising portfolio compounds the floor.

Cushion \(C\) is the live risk budget:

Rising markets widen \(C\) and increase equity capacity; falling markets compress it and shift capital to the yield leg. \(C \leq 0\) constitutes a floor breach and pauses the position.

Equity allocation \(E\) is the target exposure to the equity basket:

where \(m\) is the multiplier and \(Y\) the residual allocated to the yield-generating basket. The multiplier is not user-configurable; it is managed dynamically by the AI Guardian (Section 3).

2.2 Rebalancing Logic¶

Every active position is evaluated on a ~10-minute cycle: \(V\), \(F\), \(C\), and \(E\) are recomputed, and if actual equity allocation has drifted from \(E\) beyond a configured threshold, two simultaneous on-chain swaps restore both legs to target. The drift threshold suppresses economically immaterial trades; independently, every proposed rebalance requires Risk Sentinel authorization before submission (Section 7.3).

Rebalances also fire on basket recomposition, scheduled re-anchoring, volatility regime changes, and Guardian multiplier adjustments. A floor breach freezes the position rather than trading it (Section 7.2).

2.3 Parameter Summary¶

3. The AI Guardian¶

3.1 Function¶

The AI Guardian is an autonomous agent, architecturally distinct from the rules-based polling engine: the engine reacts to quantitative drift; the Guardian acts on qualitative and contextual signals. Its primary function is multiplier management: lowering \(m\) ahead of deteriorating conditions so equity exposure is reduced before drift accumulates, and raising it when conditions normalise. Guardian actions take effect immediately, outside the polling cycle, and are recorded with rationale in the position's event history.

3.2 Signal Taxonomy¶

Signals are not thresholded mechanically; the Guardian interprets them against the active position's basket composition, cushion level, and multiplier history.

3.3 Actions¶

1. Multiplier adjustment (autonomous). The implied trades are subject to Risk Sentinel authorization like any other rebalance; the user is notified with the reasoning in plain language.
2. News and event alerts (informational). Material macro, sectorial, or single-name events relevant to the active basket are surfaced in-app with a summary and impact assessment.
3. Sector rotation recommendations (advisory). Sustained structural rotation away from the held basket produces a basket-switch prompt with reasoning and estimated impact. Basket changes always require explicit user confirmation.

3.4 Boundaries¶

The Guardian cannot:

• switch equity baskets without explicit user confirmation;
• modify the user-defined floor \(f\);
• close or pause a position outside standard floor-breach logic;
• access funds outside the CPPI position it monitors.

It does not guarantee protection against flash crashes or liquidity gaps between execution cycles. All capital-allocation authority above intra-strategy multiplier management remains with the user.

4. Equity Baskets¶

Each position is anchored to one of four equity baskets. Token selection and weighting within a basket are managed by MoonUp's investment engine; the user invests in the basket as a unit.

4.1 Weight Architecture¶

All baskets share a three-layer weight representation:

UI basket weights refresh at ~15-minute intervals.

5. The Yield-Generating Basket¶

The protective leg of every position is a single system-defined basket, fixed in structure per version and shared across all equity basket variants. Capital in it earns yield while standing ready for redeployment, partially offsetting the opportunity cost of protection.

MoonUp reviews the category blend periodically against the yield environment, correlation with the equity baskets, and on-chain liquidity. Composition changes do not interrupt live positions; they apply at the next rebalance. The basket uses the same three-layer weight architecture as the equity baskets.

6. Position Lifecycle¶

6.1 Opening¶

The user specifies: equity basket, floor percentage (\(f \in [50\%, 95\%]\)), and capital amount. On confirmation the system synchronously computes the allocation split from \(V\), \(f\), and current \(m\); executes two on-chain swaps (one per leg); and begins monitoring. The position becomes active on swap confirmation. One active CPPI per equity basket per wallet is permitted.

6.2 Managing an Active Position¶

• Floor adjustment: takes effect immediately via a synchronous rebalance. Raising \(f\) reduces \(C\) and moves capital to the yield leg (de-risking); lowering \(f\) does the reverse.
• Upsize: deposits are re-allocated against the new \(V\) using existing \(f\) and \(m\); both legs topped up.
• Downsize: partial withdrawals unwind both legs proportionally. Rejected if the result would make \(C \leq 0\); the user must lower \(f\) first. Funds settle within on-chain confirmation time.
• Close: both legs are fully unwound; proceeds return to the wallet. Irreversible; a new position is created on the latest algorithm version.

Every allocation change, rebalance, and floor adjustment is recorded and remains visible in the position's history for the life of the position.

6.3 Floor Breach Recovery¶

On breach detection the Risk Sentinel freezes the position: holdings lock in place, no trades are emitted, and the position is paused pending user action. The system deliberately does not trade into a breached market (Section 7.3). From this paused state, the user may:

• Resume: set a new floor creating positive cushion against the current \(V\) and reactivate monitoring; or
• Close: fully unwind.

Resumption is never automatic; re-entry timing and floor level remain the user's decision.

7. Rebalancing Engine¶

7.1 Monitoring¶

The engine runs server-side on a continuous ~10-minute cycle, evaluating all active positions independently of app sessions. Each cycle recomputes \(V\), \(F\), \(C\), \(E = m \times C\) and tests every trigger condition.

7.2 Trigger Taxonomy¶

7.3 The Risk Sentinel¶

Target computation and trade authorization are separated across two agents. The strategy engine and Guardian produce the raw target (the economically ideal allocation); the Sentinel produces the authorized target (what is actually sent to execution). Both are preserved on every decision record, making the gap auditable.

For every candidate rebalance the Sentinel evaluates:

• Persistence: transient deviations within market noise are not acted on; conditions must be sustained.
• Materiality: economically insignificant rebalances are withheld.
• Cost-effectiveness: where execution-cost intelligence is available, expected benefit is weighed against estimated cost; uneconomic trades are declined.
• Data quality: incomplete, stale, or degraded market data blocks all trading on the position. This gate fails closed and cannot be bypassed by any other agent.
• Turnover: cumulative trading activity per position is capped, regardless of how many triggers fire.

The Sentinel's posture is asymmetric: urgent de-risking is accelerated, while risk-increasing trades face a stricter evidentiary standard.

Emergency protocol. On floor breach the Sentinel freezes the position rather than attempting a rescue trade, because swaps into a breached, fast-moving market can compound losses. Acting from a breached state is always the investor's decision (Section 6.3).

Every Sentinel evaluation, including decisions not to trade and the reasoning behind them, is written to the append-only event history. Thresholds, observation windows, budgets, and policies are proprietary, version-controlled, and stamped onto each decision record, so any historical decision can be replayed against the exact policy that produced it.

7.4 Execution Flow¶

On an authorized rebalance:

1. The investment engine returns exact lot quantities for both baskets.
2. Two sets of on-chain swaps execute simultaneously, one per leg.
3. Failed swaps are retried at the next polling cycle; partial execution is recorded in the event history.
4. The allocation snapshot and rebalance timestamp are updated.

User-initiated changes (floor adjustments, upsizes, downsizes) bypass the polling cycle and rebalance synchronously, settling within block confirmation time.

7.5 Transaction Costs¶

Rebalancing incurs network gas and, where DEX routing is used, trading fees. Estimated costs are shown before any user-initiated action is confirmed. Automated rebalances are not individually confirmed; their costs are reflected in net performance.

8. Governance and Versioning¶

8.1 Algorithm Versioning¶

Each position is stamped with the investment-algorithm version at open and runs on that version for its entire life. Improvements ship as new versions; existing positions are never migrated automatically. Adopting a new version requires closing the position and opening a new one; users are notified when a materially improved version is available. Rationale: a position opened under a specific risk profile should behave consistently throughout its life.

8.2 Non-User-Configurable Parameters¶

Managed exclusively by MoonUp:

9. Risk Considerations¶

CPPI manages downside risk structurally; it does not eliminate it.

10. Reference Parameters¶

Disclaimer¶

MoonUp — Institutional on-chain wealth infrastructure.