/ READ THIS BEFORE PARTICIPATING /

Understanding the risks

Every design decision in this protocol is a trade-off. Below, we explain what each choice means for you - what you're trusting, why we built it that way, and what happens if the risk materializes. This isn't a generic disclaimer. It's an honest map of the trust boundaries in the system.

Inverse Exposure Can Lose - Fast

What you're trusting

You are trusting your own understanding of what a short position means. Inverse-silver settlement assets gain value when silver falls and lose value when silver rises. Silver can rise sharply and stay elevated. A community holding a short thesis is still a community exposed to being wrong.

Why this design

The inverse position is the point of the movement - it is disclosed, deliberate, and held in the open. The protocol does not use leverage on deposits and does not margin-call participants; exposure is limited to the settlement assets acquired with real revenue.

What happens if it occurs

If silver rallies, the value of the short book and of inverse-settled rewards declines - potentially severely. Your staked $BULLION is not itself the short, but rewards settled in inverse assets can lose most or all of their value. The stablecoin settlement option exists precisely so participants can opt out of directional exposure.

The Settlement Asset Is an Issued Instrument

What you're trusting

Inverse-silver exposure on-chain requires a wrapped, issued instrument. You are trusting the issuer of that instrument to honor its obligations. You hold a token whose value depends on the issuer, not a direct market position.

Why this design

There is no way to hold real-world inverse exposure on a blockchain without an issuer or protocol standing behind the instrument. A regulated wrapper is the vehicle that bridges traditional markets and DeFi.

What happens if it occurs

If the issuer defaults, becomes insolvent, or ceases operations, settlement tokens would lose their backing. They would still exist on-chain but would no longer represent a redeemable claim. This is standard counterparty risk - here it is transparent and disclosed upfront.

Issuer Has Administrative Controls

What you're trusting

The settlement-asset issuer retains on-chain administrative capabilities: freezing addresses, pausing transfers, halting oracles, adjusting parameters. You are trusting these controls are used only for compliance, security incidents, and operational necessity.

Why this design

A regulated financial product operating across jurisdictions cannot be fully permissionless. These controls exist because regulators require them, and because responding to exploits protects the broader ecosystem.

What happens if it occurs

A frozen address cannot transfer or interact with its settlement tokens. The protocol's stablecoin fallback ensures pending rewards can still be claimed in stablecoin, but frozen settlement tokens remain locked. Admin controls are the trade-off for access to regulated instruments.

Geographic Restrictions

What you're trusting

Tokenized settlement instruments may not be available to persons in certain jurisdictions, including US persons, under the issuer's terms. The protocol does not perform KYC. You are responsible for understanding whether you can legally receive these tokens where you live.

Why this design

Rather than a gated, KYC-heavy experience, the protocol is permissionless by design and relies on self-attestation - preserving open access while placing the compliance burden where it legally belongs: on the recipient.

What happens if it occurs

If a restricted person holds settlement tokens and regulatory action follows, the issuer could freeze those addresses or restrict transfers. The protocol designs around this with the stablecoin fallback and clear disclosures.

Returns Depend on Trading Activity

What you're trusting

Rewards are funded entirely by creator fees from trading activity. You are trusting that there will be sustained volume. There is no treasury, no emissions schedule, and no external source of yield.

Why this design

Rewards tied to actual economic activity are sustainable - they scale with usage and require no inflationary emissions. When fees are high, rewards are high. When fees are low, rewards are low.

What happens if it occurs

In quiet periods, rewards may be minimal or zero. Deposits remain withdrawable (subject to cooldown). This isn't a failure - it's the mechanism working as designed. You earn a share of real fees, not a guaranteed rate.

Smart Contract Risk

What you're trusting

All deposits are held in smart contracts on Robinhood Chain. You are trusting that the code is free of critical bugs, that the EVM behaves correctly, and that the deployment is secure.

Why this design

Smart contracts are the only way to build trust-minimized DeFi. The contracts are intentionally simple: deposit, earn fees, withdraw. No lending markets, no leverage, no reusable collateral. Simplicity is the primary security measure.

What happens if it occurs

A critical bug could result in loss of deposited tokens. Small batch sizes and caps limit exposure; the withdrawal cooldown creates a response window; comprehensive on-chain events make unusual activity observable. These are mitigations, not guarantees.

Protocol Governance and Upgradability

What you're trusting

The protocol administrator can pause deposits, claims, and withdrawals, and can modify parameters including cooldowns, reward splits, and fee structures. You are trusting the administrator to act in the protocol's interest.

Why this design

Immutable protocols can't fix bugs or respond to attacks. Pause-and-adjust is a safety mechanism. All administrative actions are emitted as on-chain events, making them publicly auditable - transparency is the check on admin power.

What happens if it occurs

During a pause you cannot deposit, claim, or withdraw; your tokens remain in the contract. Parameter changes could shift protocol economics and are observable before they take effect.

Oracle Dependency

What you're trusting

Settlement pricing is supplied by Chainlink oracles. You are trusting that these oracles report accurate, timely prices and that the oracle infrastructure remains operational.

Why this design

On-chain applications cannot query off-chain prices directly. Chainlink is the most battle-tested oracle network in DeFi. No decentralized alternative eliminates oracle dependency entirely.

What happens if it occurs

On stale or incorrect prices, the protocol pauses conversions rather than executing against unreliable data. During market closures the oracle is expected to be stale - the protocol handles this by pausing rather than guessing.

DEX Liquidity

What you're trusting

Settlement conversions execute on decentralized exchanges. You are trusting that there is sufficient on-chain liquidity to fill orders at reasonable prices.

Why this design

On-chain execution is the only trust-minimized way to acquire settlement assets. A centralized exchange integration would introduce custody risk. The trade-off is exposure to DEX liquidity conditions.

What happens if it occurs

Thin liquidity means higher slippage and a lower effective reward rate. In extreme conditions, swaps may fail and rewards accumulate as stablecoin value until liquidity returns. Small batch sizes minimize price impact.

Early Withdrawal Penalty

What you're trusting

Deposits withdrawn within 24 hours incur a 5% fee that is permanently burned. You are trusting yourself to plan deposit timing appropriately.

Why this design

Without a cooldown, the reward mechanism could be gamed - deposit before a distribution, claim, exit. The burn makes this unprofitable. The fee is not captured by the protocol; it is removed from supply, benefiting remaining depositors.

What happens if it occurs

Withdrawing within 24 hours costs 5% of the withdrawn amount. A known, fixed cost - a deterrent, not a revenue stream.

Regulatory Evolution

What you're trusting

You are trusting that the regulatory environment for tokenized instruments, inverse products, and DeFi reward protocols remains broadly permissive - or that the protocol can adapt to changes.

Why this design

This technology exists at the frontier of financial regulation. Transparent on-chain operations and clear disclosures are designed to comply with existing frameworks. But regulations evolve, and novel structures get scrutinized - inverse exposure especially so.

What happens if it occurs

Adverse developments could require restricting access in certain jurisdictions, modifying mechanics, or in an extreme case, winding down. The stablecoin fallback, admin controls, and transparent events make adaptation possible without catastrophic disruption.

Protocol Maturity

What you're trusting

You are trusting software that is early in its lifecycle. The protocol has not undergone a third-party audit by a major firm.

Why this design

The choice to ship and iterate - with clear disclosures, conservative limits, and observable on-chain behavior - reflects a philosophy that real-world usage is the most honest form of testing. The protocol is designed to earn trust through transparency, not claim it through a badge.

What happens if it occurs

Without a formal audit, the probability of undiscovered vulnerabilities is higher. Mitigations: simplicity, exposure caps, and a cooldown response window. The honest answer is that early-stage software carries elevated risk - and the protocol doesn't pretend otherwise.

I understand the trust boundaries in this system and accept that every design choice involves trade-offs. I am responsible for my own decisions.

I UNDERSTAND THESE RISKS