Vault Structure
A community vault is a smart contract that pools capital from multiple contributors and routes it through a trading strategy. Either an Indicator Marketplace bot or a human signal caller. Every contributor's stake is UTT-private. Revenue distributes in real time as profitable trades close.
The vault is a transparent onchain structure: the strategy is defined in the Move module, the execution is fully automated via AIP-125, and the profit distribution is determined by the contract rules, not by a fund manager's discretion.
Vault Types
Indicator-attached Vault
The strategy is an Indicator Marketplace Move module. When the onchain indicator fires a signal, AIP-125 auto-executes the corresponding Decibel perps order sized to the vault's capital allocation.
The execution is trustless: the vault manager who attached the strategy cannot selectively execute signals. The AIP-125 keeper fires every signal that meets the indicator's conditions, without human intervention or discretion. Either every signal executes or the bot is offline.
Use case: Systematic strategies. RSI crossovers, momentum breakouts, volatility regime detection. Any strategy that can be encoded as a PineScript-derived Move module and certified through the backtest pipeline.
Signal-attached Vault
The strategy is a human signal caller operating through Whop. When the caller publishes a call (with UTT-proven prior entry), the vault auto-executes the same direction, sized to the vault's capital and leverage parameters.
The execution has one human in the loop: the caller decides when to trade. But the trade flow into the vault is automatic. The caller's published call triggers the vault's execution, not a separate vault manager decision.
Use case: Discretionary strategies where human judgment is essential. Macro calls, event-driven trades, news-reaction strategies. Any situation where a human reading the market has alpha that a systematic indicator cannot encode.
Capital Structure
Contribution Mechanics
Contributors send capital to the vault address as UTT coins (Zone 2) or CA-confidential transfers (Zone 1).
Zone 2 (UTT) contributions: Each contribution is a Pedersen commitment in the global Merkle tree. No observer. Including other vault contributors. Can determine how much any individual contributed. The vault contract tracks the sum of all commitments (verifiable onchain) without revealing the individual split.
Distribution: proportional to contribution using ZK-proven range proofs. When the vault closes a profitable trade and distributes $10,000, each contributor receives their proportional share as new UTT output coins. Without the vault contract (or anyone else) ever revealing the individual amounts.
Zone 1 (CA) contributions: Addresses visible, amounts hidden via Twisted ElGamal. Simpler than UTT for moderate-scale vaults where address privacy is acceptable but amount privacy is needed.
Minimum Stake
Set by the vault manager at creation. Typical range: 0.5-5 APT. Prevents dust contributions that create accounting overhead without meaningful capital participation.
Maximum Capacity
Many trading strategies have an optimal AUM range. An indicator that generates 0.3% edge on a $100K position may have zero edge at $10M (market impact exceeds the alpha). Vault managers can set a maximum capacity.
When the vault reaches capacity, new contributions are rejected until existing capital is withdrawn. This protects the strategy's alpha from dilution. A good vault with a capacity limit is itself a signal of quality.
Revenue Distribution
The Distribution Event
Every time a Decibel perps position opens and closes profitably through the vault, a distribution event fires:
public fun on_position_close(
vault_id: u64,
gross_pnl: u64, // in base currency
gas_cost: u64,
) acquires VaultState {
let vault = borrow_global_mut<VaultState>(vault_address(vault_id));
let net_pnl = gross_pnl - gas_cost;
if net_pnl <= 0 { return; } // no distribution on losses
// Manager fee (typically 2-5% of profits)
let manager_fee = net_pnl * vault.manager_fee_bps / 10000;
ca::transfer(manager_fee, vault.manager_address);
// Attribution: signal caller or indicator creator (if applicable)
let attribution_fee = net_pnl * vault.attribution_bps / 10000;
contentrewards::record_and_distribute(attribution_fee, vault.strategy_id);
// Remaining distributes to contributors pro-rata
let distributable = net_pnl - manager_fee - attribution_fee;
// ZK-proven proportional distribution
// Each contributor proves their commitment's proportion
// and receives their corresponding output coin
distribute_to_contributors(vault, distributable);
}
Key property: Distribution is event-triggered by trade closure, not periodic. A contributor who funded the vault for a single profitable trade receives their share immediately when that trade closes, even if they withdraw the same day.
The Manager Fee
Vault managers earn a percentage of profits only, not AUM, not time-based. The standard range is 2-5% of net profitable trades.
This alignment is intentional: managers earn when contributors earn. A vault that loses money generates no manager fee. There is no incentive to churn trades to generate fees. The manager earns only from net profitable outcomes.
The manager fee is specified at vault creation and immutable. Contributors can verify the fee structure before depositing.
The Attribution Fee
If the vault is attached to an indicator strategy, the indicator creator earns an attribution fee on each profitable trade. This is the indicator's per-signal earnings, calculated as a percentage of the vault's profit from that signal rather than a flat APT fee.
This connects the indicator creator's earnings to vault performance: an indicator that generates large profitable signals for large vaults earns more than one that generates small signals for small vaults. The attribution mechanism scales with actual value delivered.
Strategy Configuration Privacy
The vault's trading parameters. Leverage cap, position sizing rules, maximum concentration, entry/exit conditions for human-attached strategies. Are ACE-encrypted and stored in the vault's Move struct or on Shelby CDN.
struct VaultConfig has key {
// Public: visible to all potential contributors
strategy_type: u8, // indicator vs signal
strategy_id: u64,
manager_fee_bps: u16,
attribution_bps: u16,
max_capacity: u64,
min_stake: u64,
// ACE-encrypted: visible only to contributors
leverage_cap: vector<u8>, // encrypted
max_position_pct: vector<u8>, // encrypted
stop_loss_params: vector<u8>, // encrypted
indicator_params_hash: vector<u8>, // encrypted (pointer to Shelby)
}
The ContractID for the ACE-encrypted fields: is_active_contributor(requester, vault_id). As long as you have an active stake in the vault, you can decrypt the configuration. If you withdraw, your stake drops to zero and the ContractID returns false. You lose access to the configuration updates.
What competitors see: The vault exists, has some AUM, is attached to strategy X, and has a manager fee of Y%. They cannot see the specific parameters that make the strategy work.
What contributors see: Everything. Full configuration, full strategy parameters, full historical execution log.
Strategy Versioning
When a vault manager updates the strategy. Changes the leverage parameters, switches to a new indicator version, adjusts the stop-loss logic. The change is recorded onchain as a versioned update.
struct StrategyVersion has store {
version: u64,
timestamp: u64, // block height of the update
change_hash: vector<u8>, // hash of what changed (not the params themselves)
deployer: address,
// Performance from this version forward
version_start_block: u64,
}
Explorer shows all strategy version changes with timestamps. A contributor can see:
- ›When the strategy changed
- ›Whether performance improved or degraded after the change
- ›How many times the strategy has been updated
- ›The cumulative track record across all versions
A vault that has been updated 15 times in 6 months is a red flag. A vault that deployed v1 and has not changed it in 18 months is a stability signal.
Governance and Contributor Protections
Strategy Change Voting
When a vault manager proposes a significant strategy change (defined as any change that affects more than X% of the configuration parameters), contributors can vote. If a quorum of contributors (by contribution weight) reject the change within 48 hours, the change is blocked.
This is the protection against a manager who builds a profitable track record, attracts large capital, then changes the strategy to one they benefit from at contributors' expense.
Emergency Exit
Any contributor can withdraw their stake at any time, subject to a cooldown period. The cooldown (typically 24-72 hours) exists to prevent coordinated withdrawal attacks during volatile markets, not to trap capital.
The cooldown is specified at vault creation and immutable. Contributors know before depositing exactly how quickly they can exit.
Vault Sunset
If a vault has been inactive (no trades) for more than 60 days and the manager has not responded to a governance ping, contributors can collectively trigger a sunset. The sunset returns all capital pro-rata to contributors.
The $199 Course Conversion Mechanic
The mechanic: $199 course fee converts to $199 vault stake.
A Whop course creator who sells a $199 trading course can offer students the option to convert their course purchase into an equivalent vault stake.
The flow:
- 02Student purchases the $199 course
- 04Course includes a call-to-action: "Put your fee to work. Convert to vault stake"
- 06Student's $199 converts to an equivalent APT-denominated vault stake at the creator's vault
- 08The student is now a vault contributor earning from the same strategy the course teaches
Why this works for both parties:
- ›Creator: retains the economic relationship with the student beyond the course. A student who is also a vault contributor has an ongoing stake in the creator's continued performance. They're motivated to remain engaged.
- ›Student: the course fee becomes capital that earns rather than a sunk cost. Even if the course content is mediocre, their vault stake might outperform.
- ›Content Rewards: the vault stake conversion counts as a 10× conversion event for Content Rewards. The creator earns significantly more from a course → vault conversion than from a course → completion.
This mechanic is unique to the Whop ecosystem. No other platform has the infrastructure to convert an educational purchase into a live trading stake in the same transaction.
Vault Performance Metrics on Explorer
Explorer tracks and displays all vault performance data publicly:
Core metrics:
- ›Total PnL (UTT-timestamped, all trades included)
- ›Sharpe ratio (calculated from daily returns over the full history)
- ›Maximum drawdown (worst peak-to-trough, ever)
- ›Win rate (profitable trades / total trades)
- ›Average hold duration (short-term vs long-term strategy characterization)
- ›Largest single trade (as percentage of AUM. Risk concentration indicator)
Comparative metrics:
- ›Backtest Sharpe vs live Sharpe gap (for indicator-attached vaults)
- ›Version performance (how did each strategy version perform vs prior versions)
- ›Peer comparison (how does this vault's Sharpe rank against comparable vaults by strategy type and duration)
Red flags automatically surfaced:
- ›Live Sharpe < 50% of backtest Sharpe: potential overfitting, flagged prominently
- ›Strategy version count > 5 in 6 months: frequent changes may indicate instability
- ›Drawdown > 30%: displayed with a warning
- ›No trades in 30 days: staleness flag (is the strategy still running?)
These flags are objective and automatically computed. The vault manager cannot suppress them. Contributors making decisions based on Explorer data see the complete picture.