# Risks
No yield-generating strategy is risk-free. Anyone who claims otherwise is either uninformed or dishonest. SHRED does not promise to eliminate risk. We promise to identify it, disclose it transparently, and reduce it through deliberate design choices. This page explains the risks you take when depositing into SHRED, what we do to mitigate them, and what residual exposure remains.
#### **Risk Summary**
| **Category** | **Mitigation** | **Residual Exposure** |
| ------------------------- | ------------------------------------------------------------------------- | ---------------------------------------- |
| Strategy & Yield | Buffer fund absorbs volatility; dynamic target rate adjusts to conditions | Yield depends on market conditions |
| Infrastructure & Protocol | Battle-tested venues; audited contracts; MPC custody | Third-party failures outside our control |
| Operational | Multi-party authorization; role separation; fail-safe defaults | Human error remains possible |
| Liquidity & Withdrawal | TVL caps; liquidity buffers; orderly withdrawal queues | Extreme conditions may delay withdrawals |
#### **Strategy & Yield Risk**
SHRED generates yield through funding rate arbitrage on perpetual futures, combined with returns from staking and money market lending. This is not a fixed-income product. Returns depend on market conditions.
| **Risk** | **Description** | **How It's Managed** |
| ----------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Negative funding rates | If funding rates go negative, the short side costs money instead of earning | Buffer fund absorbs short-term dips; target rate reduced if sustained |
| Liquidation | Extreme price moves could liquidate leveraged positions on either leg | Liquidation price movement (LPM) monitoring; automatic rebalancing at conservative thresholds |
| Execution slippage | Rebalancing during volatile conditions may incur unfavorable prices | Threshold-based rebalancing; capital-only adjustments where possible; slippage controls |
| Under-collateralization | Prolonged underperformance could leave protocol liabilities exceeding assets | Buffer fund reserves; dynamic target rate adjustment; withdrawal fees to prevent cost externalization |
**How the Buffer Fund Works**
The buffer fund is a protocol-level reserve that smooths returns for depositors. When strategy performance exceeds the target rate, excess yield flows into the buffer. When performance falls short, the buffer covers the gap. If market conditions deteriorate for a sustained period and the buffer is strained, we adjust the target rate downward to preserve fund health. If conditions improve, we adjust upward.
In extreme scenarios where adverse conditions persist and the buffer is depleted, the protocol may become undercollateralized relative to outstanding shUSD liabilities. This represents risk to both yield continuity and, in severe cases, depositor principal.
#### Infrastructure & Protocol Risk
SHRED depends on external infrastructure and deploys its own smart contracts. Any of these systems can fail.
| **Risk** | **Description** | **How It's Managed** |
| ------------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| Venue failure | Hyperliquid, Ethereum, or Aave could experience exploits, halts, or downtime | Only battle-tested protocols with significant TVL; real-time monitoring; ability to pause and unwind |
| Bridge risk | USDC transfers between Ethereum and HyperCore rely on bridging infrastructure | Circle CCTP only (burn-and-mint, not liquidity bridge); native USDC only; bridge status monitoring |
| Smart contract bugs | Vulnerabilities in SHRED vault or shUSD contracts could result in loss of funds | OpenZeppelin primitives; independent third-party audits; minimal contract surface area |
| USDC depeg | USDC could lose its $1 peg temporarily or permanently | No direct mitigation; risk disclosed transparently; users accept stablecoin counterparty risk |
| wstETH depeg | wstETH could trade at a discount to ETH, increasing liquidation risk on the long leg | High-quality collateral with deep liquidity; conservative leverage limits |
**Note on Bridging**
The strategy currently uses Circle's CCTP (Cross-Chain Transfer Protocol) to move USDC between Ethereum and HyperCore. CCTP is a burn-and-mint mechanism, meaning USDC is destroyed on the source chain and minted on the destination chain. This avoids the liquidity pool risks of traditional bridges. If the protocol later expands to use HyperCore for spot trading or leverage, reliance on bridging infrastructure would increase.
#### **Operational Risk**
Running a yield strategy requires custody infrastructure, execution systems, monitoring services, and administrative controls. Each introduces operational risk.
| **Risk** | **Description** | **How It's Managed** |
| ------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Key compromise | Unauthorized access to custody keys | Fireblocks MPC custody; no single-key control; allowlists restrict fund destinations |
| Upgrade errors | A bad contract upgrade breaks functionality or introduces vulnerabilities | Multi-party approval required; testing and review before execution |
| Governance failures | Administrative actions introduce errors or are exploited | Role separation (admin, operator, guardian); controlled upgrade paths |
| Service downtime | Off-chain monitoring or execution systems go offline | Redundant monitoring across independent services; fail-safe defaults pause rather than force execution; manual override capability |
Custodial infrastructure remains a centralized dependency. While MPC eliminates single points of failure for keys, the custody provider itself represents operational risk that cannot be fully decentralized.
#### **Liquidity & Withdrawal Risk**
SHRED aims to offer withdrawals without extended lockups. However, the strategy requires position management, and large or concurrent withdrawal requests may require unwinding positions.
| **Risk** | **Description** | **How It's Managed** |
| -------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Withdrawal delays | Large requests may take time to process if positions must be unwound | Liquidity buffers for routine withdrawals; orderly queues for large exits |
| Market impact | Unwinding positions during stress may move markets against remaining depositors | TVL caps relative to market depth; phased processing of large withdrawals |
| Cost externalization | Withdrawing users could leave execution costs for remaining depositors to absorb | Dynamic withdrawal fee covers slippage, market impact, and rebalancing costs |
**Why Withdrawal Fees Exist**
When a user withdraws, SHRED may need to unwind positions, incurring real costs: slippage, market impact, gas, and rebalancing. Without a fee, these costs would be absorbed by remaining depositors, effectively subsidizing exits. The withdrawal fee ensures that exiting users bear their own execution costs. The fee is dynamic and may change based on market conditions. Our long-term goal is to minimize this fee as liquidity, integrations, and strategy efficiency improve.
#### **Who Bears What Risk**
Clear accountability matters. Here is how risk is distributed:
| **Risk Type** | **Borne By** |
| ------------------------------------------------ | ------------------------------------------ |
| Strategy underperformance (lower yield) | Users |
| Strategy undercollateralization (principal loss) | Users |
| Smart contract vulnerabilities | Users (financial), Protocol (reputational) |
| Venue failures (Ethereum, Aave, Hyperliquid) | Users |
| Bridge failures (CCTP) | Users |
| USDC or wstETH depeg | Users |
| Withdrawal delays | Users (opportunity cost) |
| Operational errors | Users (financial), Protocol (reputational) |
#### **The Bottom Line**
Risk management is not a checkbox. It is an ongoing process that evolves as market conditions, infrastructure, and strategy design change.
This page represents our best-faith effort to describe the risks inherent in the system, the mechanisms we use to reduce them, and the trade-offs involved. There is always the possibility that certain risks are not fully identified, that mitigations prove insufficient under unforeseen conditions, or that residual risks are underestimated.
Evaluate SHRED not on the absence of risk, but on how risks are acknowledged, bounded, and actively managed. If you have questions about anything on this page, ask us. Transparency is not a marketing claim. It is how we operate.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.shred.fi/documentation/risks.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.