# Technology #### **Summary** SHRED’s backend combines audited smart contracts with automated monitoring systems. Strategies are continuously managed by scripts that monitor position health, balance long/short exposures, and execute rebalancing when required. Alerts are sent if transactions fail or infrastructure components (such as bridges) experience downtime. Ethereum and Hyperliquid were chosen as the initial execution layers due to their deep perp liquidity, fast infrastructure, and ability to support funding rate arbitrage at scale. Over time, SHRED will extend across Solana and other ecosystems, all unified by a single frontend and cross-chain bridging layer. The development team previously built the leading money market and perp DEX on Cosmos with a track record of managing over $300m TVL at its peak - having worked together for over 4 years across multiple chains. The same practices in risk management and capital efficiency underpin SHRED. **Key Terms:** | **Term** | **Definition** | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | shUSD | A token users receive when they deposit. It represents their share of the pool and grows in value as yield accrues. | | Delta-Neutral | A strategy where long and short positions offset each other, so the protocol doesn't profit or lose from price movements—only from yield sources like funding rates. | |

LPM (Liquidation

Price Movement)

| How far the price would need to move before a position gets liquidated. Higher is safer. | | Price Impact | A small variable fee deducted from withdrawals to cover the cost of unwinding positions. | | Funding Rate | Periodic payments between traders holding long vs short positions in perpetual futures markets. | #### **System Architecture** Deployed Contracts (Ethereum Mainnet) The protocol's smart contracts are deployed on Ethereum (Chain ID: 1): | **Contract** | **Address** | **Purpose** | | ------------ | ------------- | ------------------------------------------ | | ShredVault | TBC at launch | Holds user deposits and manages accounting | | shUSD Token | TBC at launch | The yield-bearing token users receive | **How the System Fits Together** The diagram below shows how funds flow through the system:
**Component Overview:** | **Component** | **What It Does** | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ShredVault Contract | The on-chain smart contract that holds user USDC deposits. It tracks balances, mints/burns shUSD tokens, and manages the withdrawal queue. | | shUSD Token | A standard token that users can hold, transfer, or use in other protocols. Only the vault can create or destroy these tokens. | | Fireblocks | An institutional custody service that securely holds the keys for the strategy wallets. Uses MPC (multi-party computation) so no single person controls the keys. | | Aave on Ethereum | A lending protocol where we hold the "long" side of our strategy using wstETH (wrapped staked ETH). | | HyperCore | A perpetual futures exchange where we hold the "short" side of our strategy. | #### **How Deposits and Withdrawals Work** **Depositing** When a user deposits USDC:
The deposit happens instantly in one transaction. The amount of shUSD received depends on the current exchange rate. As yield accrues, each shUSD becomes worth more USDC over time. **Withdrawing** Withdrawals work in one of two ways, depending on how much USDC is available in the vault:
**Key points** The user's shUSD is burned immediately when they request a withdrawal, so they stop earning yield at that moment. A small variable "price impact" fee is deducted to cover the cost of unwinding positions. Most withdrawals complete instantly if the vault has enough USDC on hand. Larger withdrawals may take up to 48 hours while positions are unwound. **How Yield Works** The vault tracks a "liquidity index" that increases over time based on the interest rate set by the admin. This is similar to how Aave's aTokens work—the shUSD token doesn't change in quantity, but each token becomes worth more USDC. Important: The yield rate is variable and not guaranteed. It's set based on actual strategy performance and may be adjusted if market conditions change. #### **Roles & Permissions** **Smart Contract Roles** The smart contract uses role-based access control. Each role has specific powers: | **Role** | **Who Holds It** | **What They Can Do** | | ------------- | ------------------------------------------ | ------------------------------------------------------------------------------------- | | Default Admin |

Fireblocks (quorum

required)

| Upgrade the contract code; grant or revoke other roles | | Admin |

Fireblocks (quorum

required)

| Change interest rate, deposit limits, price impact; pause the protocol in emergencies | | Operator |

Fireblocks (quorum

required)

| Fulfill pending withdrawals; move USDC to the approved strategy address | | Users | Anyone | Deposit, withdraw, claim, and transfer shUSD tokens | **Off-Chain Strategy Roles** The off-chain strategy that manages positions on Ethereum and Hyperliquid has its own permission structure: | **Role** | **What They Can Do** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | Strategy Executor Wallet | Proposes transactions to the Fireblocks vault (e.g., rebalancing, position adjustments) | | Fireblocks Policy Engine | Enforces rules about what transactions are allowed (spending limits, approved addresses, etc.) | | Guardian Network | A Guardian Network built on top of Fireblocks that verifies strategy logic and nyst approve before any strategy transactions execute. | This multi-layer approval process means no single person or system can unilaterally move funds. **Security Measures:** | **Measure** | **Status** | | ---------------------- | ------------------------------------------------------------------------------------------------ | | OpenZeppelin contracts | Using industry-standard, audited libraries for access control, pause-ability, and safe transfers | | Reentrancy protection | All functions that move funds are protected against reentrancy attacks | | Fireblocks MPC custody | Keys are distributed across multiple parties; no single point of compromise | | Guardian approval | Multiple independent signers must approve strategy transactions | | Deposit insurance | None — users bear full risk of any losses | **Protocol Limits:** | **Parameter** | **Value** | **Can Be Changed?** | | ---------------------- | ------------------------------------------------------ | --------------------- | | Maximum APY | 100% | No (hard-coded limit) | | Current target APY | \~10-15% | Yes (by Admin role) | | Maximum total deposits | 10M initial cap (increases systematically - 20M, etc.) | Yes (by Admin role) | | Minimum deposit | 10 USDC | Yes (by Admin role) | --- # 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/technology.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.