# Introducing SIR A New DeFi Protocol for Safer Leverage SIR is a DeFi protocol designed to address the key challenges of leveraged trading, such as volatility decay and liquidation risks, making it safer for long-term investing. SIR is live on **Ethereum**, **HyperEVM**, and **MegaETH**. Here's how SIR stands out: * **No Liquidation Risk:** SIR's leveraged tokens (APE) can lose value but never get liquidated. Unlike margin trading or perps where a sudden price move can wipe your entire position, SIR's convex payoff structure means your downside is bounded — you keep your position through any market conditions. * **No Funding Fees for Holding Positions:** SIR differentiates itself by not charging any funding fees while you hold a leveraged position. Fees are only applied when minting or burning leveraged tokens, reducing the cost of maintaining long-term positions. * **Volatility Decay Elimination:** Unlike traditional leveraged ETFs, or other leveraged tokens like Squeeth, that lose value in stagnant markets due to [volatility decay](https://www.afrugaldoctor.com/home/volatility-decay-dont-hold-leveraged-etfs-long-term), SIR ensures that its leveraged tokens maintain their value over time on a best-effort basis. This is achieved by tracking the value of the leveraged token according to its theoretical power-law formula which eliminates the need for external transactions for rebalancing.

On May 2022 the price of ETH was the same than in the beginning of the chart, but Squeeth had already lost a fair chunk of value.

* **Trustless Leveraged Trading:** SIR prioritizes being maximally trustless, a cornerstone for becoming a fundamental DeFi building block. It achieves this by utilizing on-chain price oracles (Uniswap V3 on Ethereum, HyperSwap on HyperEVM, Kumbaya on MegaETH) and thanks to its non-upgradable contracts and immutable parameters. * **Permissionless Vault Creation:** Echoing the ethos of platforms like Uniswap, which democratize the creation and trading of tokens, SIR brings this philosophy into the leveraged trading space. It allows users to create vaults without needing permission, with each vault defined by its collateral token (COL), debt token (DBT), and leverage $$l$$. This setup enables the leveraged token to accurately track the price of COL/DBT with the chosen leverage $$l$$, providing unparalleled flexibility. SIR is designed for investors looking for small, long-term compounding leverage, in a maximally trustless setting. By only charging fees on token minting and burning, and addressing the issue of volatility decay internally, SIR offers a more efficient and safer way to engage in leveraged trading in the crypto space. To understand why this matters and how SIR compares to every other form of leverage, see [Why SIR Matters](/protocol-overview/readme/why-sir-matters). {% hint style="success" %} Following the [March 2025 exploit](/protocol-overview/user-risks/exploit-and-relaunch), SIR was rebuilt and relaunched after completing [four independent security audits](/protocol-overview/user-risks/audits). {% endhint %} # Why SIR Matters Leverage You Can Sleep On ## A New Primitive DeFi has produced a handful of genuine financial primitives — mechanisms so fundamental they become building blocks for everything else. AMMs let anyone provide liquidity. Flash loans enabled atomic arbitrage. Perpetuals brought leveraged exposure on-chain. Each was dismissed early and recognized late. Big jumps happen when the primitive changes, not when you sand down the old one. Bitcoin did not come from polishing payment rails, and AMMs did not come from tweaking TradFi order books. SIR is the same pattern: a new primitive that unlocks payoff shapes you simply cannot get by patching perps, leverage tokens, or options. SIR is not "slightly better perps" or "less bad leverage tokens". It is a different primitive for holding leverage. ## Holding Leverage Is Practically Impossible The trader and the investor are often described as disjoint types of participants: traders use leverage for short-term bets, investors hold spot for the long run. Can leverage be holdable for months, or even years? To see why that has basically not been possible, look at the main leverage tools we have today: **1. Margin trading** — You borrow funds to increase your position size. You pay a borrow rate, so the longer you hold, the more you bleed. You can get liquidated if price moves against you. Holding a margin position is paying rent over time.

Total margin fees after one year, as a percentage of initial equity. Even moderate leverage at moderate rates eats a significant share of your position.

**2. Leveraged tokens/ETFs** — Lever up by taking on more debt as price goes up, deleverage by selling as price goes down. This keeps leverage quasi-constant and avoids liquidation. What breaks: volatility decay. In choppy markets you repeatedly buy high and sell low. Range-bound price action turns the rebalancing mechanic into a slow bleed.

Leverage rebalancing in choppy markets. The mechanism buys at local highs and sells at local lows — a systematic bleed even when price ends flat.

**3. Perps** — Cash-settled synthetic exposure with no borrowing of the underlying. This is what made x100 leverage possible. What breaks: liquidations become the norm. At x100, a -1% move wipes out the entire position. **4. Call options** — Amplified exposure without liquidation risk. What breaks: the price depends not only on the underlying but also on volatility and time to expiration. As expiration approaches, the option decays in value. | Approach | Volatility Decay | Ongoing Fees | Liquidation | Practical Hold Duration | | --------------------- | :----------------: | :-------------------: | :---------: | :---------------------: | | Margin Trading | — | Funding rates | Yes | Days to weeks | | Leveraged ETFs/Tokens | Severe | Hidden (rebalancing) | No | Degrades over time | | Perpetuals | — | Funding rates | Yes | Days to weeks | | Options | Time decay | Premium | Expiration | Fixed term | | **SIR** | **Best-effort no** | **One-time mint fee** | **No** | **Unlimited** | ## An Original Approach to Holdable Leverage In an ideal world, a holdable leverage product would: 1. Charge only a one-time fee, and 2. Maintain the leverage perfectly constant at every price tick A one-time fee eliminates the recurrent bleed from funding and borrowing. Perfectly constant leverage removes liquidation risk and produces the payoff curve people intuitively expect from leverage: compounding gains as price moves up.

Spot vs 2x perp (linear) vs perfect constant 2x leverage. The convex green curve is what constant leverage actually looks like — superlinear gains on the upside, bounded losses on the downside. The skull marks the liquidation point for a 2x perp.

The problem is that promising superlinear gains forever at a finite one-time fee is unfeasible. Something has to give. ### Best-Effort Convexity SIR solves this by promising convex returns only up to a certain price threshold. Beyond that threshold, returns become linear — basically like a perp. The key is that this threshold is not fixed. It is dynamic, and depends on the ratio between trader notional and LP inventory: * **More LP inventory** → higher threshold (bigger convex zone) * **Less LP inventory** → lower threshold (smaller convex zone) SIR provides **unconditionally**: 1. Zero risk of liquidation 2. No recurrent fees — just a one-time fee SIR provides **on a best-effort basis**: 3. Convex returns 4. No volatility decay With the right one-time fee, we can incentivize the right ratio between traders and LPs, so the system operates in the convex zone most of the time. For the full math behind the payoff formula, see [Take on Leverage and Forget](/protocol-overview/readme/take-on-leverage-and-forget).

Best-effort ^2 leverage. In the convex zone (blue), returns compound superlinearly. Beyond the saturation threshold, returns become linear (dashed) — like a perp, but still without liquidation.

### Self-Balancing Convexity The convex and linear zones are not static. They adjust based on the ratio between traders' notional and LP inventory, creating a natural feedback loop: **The main loop:** 1. Traders open positions → they pay a one-time fee to LPs 2. LP yield increases → more LPs deposit liquidity 3. More LP inventory → the convex zone widens 4. Wider convex zone → opening positions becomes more attractive 5. Return to step 1 **When the system drifts out of balance:** * If LPs exit, inventory drops and the convex zone shrinks. Some traders then close, sending more fees to LPs and pushing LP yield back up. * If traders don't close, they end up operating in the linear zone. There leverage is no longer perfectly constant, volatility decay slowly eats the position, and over time the system naturally migrates back toward a wider convex zone. The threshold is not a fixed parameter — it is an organic variable, steered by fees and liquidity, with the system constantly nudging itself back toward the convex zone.

The self-balancing convexity loop. The top cycle (black arrows) is the main growth flywheel. The bottom paths show how the system self-corrects when liquidity drops.

## Real Utility This isn't just a trading toy. Holdable leveraged tokens unlock use cases that were previously impractical: * **Long-term directional bets** — Bullish on ETH over the next year? Take 1.5x exposure and forget about it. No maintenance, no margin calls, no daily check-ins. * **Capital-efficient hedging** — Hedge a portfolio position with less capital at risk than a full short would require. * **Leverage you can sleep on** — No liquidation means no 3 AM margin calls. Your worst case is the minting fee, not your entire position. * **Composability** — APE tokens are standard ERC-20s. They can be held, transferred, or integrated into other protocols like any other token. ## Multi-Chain SIR is live on **Ethereum**, **HyperEVM**, and **MegaETH**, with the same core mechanics on each chain. See [Deployments](/protocol-overview/deployments) for contract addresses across all chains. # Take on Leverage and Forget APE: The Math Behind Holdable Leverage APE is SIR's leveraged token designed to magnify returns through directional price exposure. Unlike conventional leveraged products that erode returns with time-based fees (e.g., daily funding costs or volatility decay), APE decouples profitability from holding duration. Gains and losses are determined exclusively by two factors: the ratio between entry and exit prices, and a single upfront fee. ### **The Formula** Within the [convex zone](/protocol-overview/liquidity-and-leverage#the-limits-of-constant-leverage), APE's returns follow: $$ \textrm{Exit value} = x(1-f)\left(\frac{p'}{p}\right)^l $$ where * $$x$$ is the initial investment * $$f$$ is the initial fee (e.g., \~9% for ^1.5, \~17% for ^2 — higher leverage means higher fee) * $$p$$ is the entry price * $$p'$$ is the exit price #### Key Implications * **Fixed Initial Fee**: A fixed fee is deducted upfront, meaning the traders experience an immediate loss on opening their position. * **Convex Returns**: The exponent amplifies gains and losses non-linearly: * **Upside**: Profits accelerate faster than linear growth as prices rise. * **Downside**: Losses are mitigated compared to normal leverage, and the trader is never liquidated. * **No Time Penalty**: Returns depend purely on price movement, not holding duration. ### Example Scenario Assume an initial investment $$x=$1000$$ in the pair `(ETH/USD)^1.5`, and the fee is $$f=9%$$. | Price Change | Calculation | Gain Multiple | Exit Value | Net Return | | ------------ | ----------------------- | ------------- | ---------- | ---------- | | -50% | $$0.91\cdot0.5^{1.5}$$ | 0.32x | $322 | -68% | | -25% | $$0.91\cdot0.75^{1.5}$$ | 0.59x | $591 | -41% | | 0% | $$0.91\cdot1^{1.5}$$ | 0.91x | $910 | -9% | | +50% | $$0.91\cdot1.5^{1.5}$$ | 1.67x | $1,672 | +67% | | +100% | $$0.91\cdot2^{1.5}$$ | 2.57x | $2,574 | +157% | | +150% | $$0.91\cdot2.5^{1.5}$$ | 3.60x | $3,597 | +260% | #### **Critical Considerations** 1. **Liquidity Limits**: The power-law formula holds within the [convex zone](/protocol-overview/liquidity-and-leverage#the-limits-of-constant-leverage). Beyond the saturation price, where demand for leverage exceeds available LP liquidity, gains become path dependent and volatility decay can occur — similar to traditional leveraged tokens. The size of the convex zone depends on the ratio of LP inventory to trader notional. See [Liquidity and Leverage](/protocol-overview/liquidity-and-leverage) for details. 2. **Fee Structure**: The initial fee necessitates a minimum price recovery to breakeven. For example, to offset a 9% fee at ^1.5, the price must rise by \~7%. ### **Conclusion** APE offers a unique balance of amplified upside and defined risk, making it a powerful tool for investors confident in directional price movements. By decoupling returns from time and focusing purely on price action, SIR ensures transparency and simplicity in profit generation — provided the vault operates within the convex zone. # Liquidity and Leverage The Mechanics of Constant Leverage Vault creation in SIR is open to anyone and is defined by three key parameters: the collateral token (COL), the debt token (DBT), and the leverage ratio ($$l$$). There are two types of users: gentlemen (liquidity providers or LPers) and the apes (traders). Gentlemen mint TEA tokens by depositing collateral, earning fees generated from the trading activities of the apes. Similarly, apes mint APE tokens, a leveraged COL/DBT token, by also depositing collateral. TEA tokens are ERC-1155, and APE tokens are ERC-20. The reserve of collateral in the vault, $$R$$, is always split between the gentlemen and the apes $$ R=G+A. $$ At any time a gentleman can claim their part of $$G$$ proportionally to their TEA balance, and similarly the apes can claim their part of $$A$$. ### Fees **From Apes:** Vaults charge a one-time fee when minting and burning APE tokens. The fee scales with leverage — for example, \~9% for $$l=1.5$$ and \~17% for $$l=2$$. These fees are substantial upfront but allow apes to hold APE tokens without incurring any maintenance fees, regardless of the holding period. The fee is roughly equivalent to one year of funding on a perps position, striking a balance between potential returns and upfront costs. **From LPers:** LPers are charged a 4.9% fee when minting TEA. Without this fee, an actor could mint TEA, collect a share of protocol fees, and then immediately burn the TEA, extracting value without taking on meaningful risk. The minting fee aligns LP incentives with the long-term health of the protocol. This fee is allocated to [Protocol-Owned Liquidity (POL)](/protocol-overview/liquidity-and-leverage/protocol-owned-liquidity), which participates in the vault as a permanent LPer. POL continues to accumulate rewards and deepens liquidity over time, contributing to the overall resilience of the system. ## The Limits of Constant Leverage Let's define $$p$$ as the current price of the collateral (COL) in terms of the debt token (DBT). For instance, if COL = ETH and DBT = USDC, then $$p$$ is the ETH/USDC price. Ideally, the apes' claim on the reserve, $$A$$, adapts based on the power-law function of constant-leverage: $$ A'=\left(\frac{p'}{p}\right)^{l−1}A, $$ where $$A'$$ is the new value of the apes' reserve, $$p'$$ is the new price, $$p$$ is the original price, and $$l$$ is the leverage. This constant leverage regime is the preferred regime but it cannot, logically, be sustained for any price $$p'$$ since $$A'$$ can escalate indefinitely. To maintain the leverage ratio $$l$$, an additional $$l-1$$ units of liquidity are required for every $$1$$ unit held by the apes. The saturation price, $$p\_\textrm{sat}$$, signifies the threshold at which liquidity is fully utilized, i.e., when $$G=(l-1)A$$. Therefore, the vault can accommodate any price movement within the $$\[0,p\_\textrm{sat}]$$ range without disrupting the constant leverage — this is the **convex zone**. Importantly, $$p\_\textrm{sat}$$ is not static; it adjusts based on the $$G/A$$ ratio, reflecting changes in the gentlemen's liquidity versus the apes' positions. Specifically, $$p\_\textrm{sat}$$ increases when gentlemen add liquidity or apes reduce their leveraged positions, and it decreases otherwise.

Best-effort ^2 leverage across different liquidity levels. More LP inventory (higher G/A ratio) pushes the saturation threshold further out, giving traders a wider convex zone.

## The Saturation Zone The saturation zone is initiated when the market price surpasses $$p\_\textrm{sat}$$, shifting away from the ideal constant leverage scenario to a liquidity-constrained state, where $$G<(l-1)A$$. Beyond $$p\_\textrm{sat}$$, the amount owed to the gentlemen denominated in debt token (DBT) becomes fixed: $$D=G\_\textrm{sat}p\_\textrm{sat}$$, thereby fixing their reserve portion to $$ G'=\frac{D}{p'}=\frac{p}{p'}G. $$ In practical terms, if COL = ETH and DBT = USDC, in this regime the gentlemen's reserve value is calculated in USDC, while the apes benefit from the appreciation of ETH versus USDC. This mirrors a conventional margin long position with the initial leverage $$l$$. Similar to traditional margin trading, as the price continues to climb, the effective leverage ratio experienced by the apes diminishes.

LP (gentleman) profit profile. In the convex zone (blue), LPs gain quote-asset exposure as price rises and base-asset exposure as price falls. Beyond saturation (orange), LP value in quote terms is fixed.

{% hint style="warning" %} **Volatility decay in saturation:** When a vault operates in the saturation zone, leverage is no longer perfectly constant. Price oscillations in this zone cause the same buy-high-sell-low dynamic seen in traditional leveraged tokens, gradually eroding the position's value. The deeper into saturation, the more pronounced the decay. This is why deep LP liquidity matters — it keeps $$p\_\textrm{sat}$$ high and the convex zone wide. {% endhint %} # Protocol Owned Liquidity Permanent Liquidity That Compounds Over Time ## How It Works When liquidity providers (gentlemen) deposit assets to mint TEA tokens, a 4.9% fee is charged. This fee is permanently allocated to Protocol-Owned Liquidity (POL), which participates in the vault as a permanent LPer. Both the depositor's 95.1% and the POL's 4.9% earn trading fees from APE leverage positions. POL never withdraws. It earns and compounds fees alongside other LPers, creating a growing liquidity floor that benefits everyone: * **For traders:** Reliable liquidity depth that keeps the [convex zone](/protocol-overview/liquidity-and-leverage#the-limits-of-constant-leverage) wide * **For LPers:** A stable base that dampens liquidity shocks * **For the protocol:** Reduced reliance on inflationary incentives over time ## The Growth Cycle 1. Users deposit liquidity → 4.9% goes to POL 2. POL earns fees → its share grows 3. Deeper liquidity → better trading experience (wider convex zone) 4. More traders → higher fee generation 5. Higher yields → attracts more liquidity As POL compounds over time, it becomes the bedrock of the protocol — a permanent, growing foundation that ensures perpetual operation regardless of market conditions. ## Comparison to Traditional Models Traditional liquidity mining pays protocols to rent temporary liquidity — high ongoing costs, mercenary capital that leaves when rewards decrease, and unsustainable token inflation. SIR's POL model flips this: a one-time contribution creates permanent value with zero ongoing costs. {% hint style="info" %} **MegaETH:** On MegaETH, Protocol-Owned Liquidity is optional. LPs can opt out of the POL fee by locking their deposit for a period of time instead. This gives LPs flexibility — pay the fee for immediate withdrawability, or lock up and keep 100% of their deposit. {% endhint %} # Price Oracle Maximally Trustless Prices According to [Chainlink](https://chain.link/education/blockchain-oracles), > Blockchain oracles are entities that connect blockchains to external systems, thereby enabling smart contracts to execute based upon inputs and outputs from the real world. As evident in [Liquidity and Leverage](/protocol-overview/liquidity-and-leverage), for every vault, SIR requires accurate price data between the collateral and the debt token. SIR integrates the Uniswap v3 Oracle to ensure its price data is as trustless as possible. A wrapper contract around the Uniswap v3 oracle extends its functionality, enabling SIR to: 1. Selecting the most liquid fee tier: When SIR retrieves the price for a particular token pair from Uniswap v3, it can fetch it from different [fee tiers](https://docs.uniswap.org/concepts/protocol/fees#pool-fees-tiers). These are Uniswap v3 pools with the same pair of tokens but different fee structure. SIR selects the fee tier with the highest liquidity—a figure directly provided by Uniswap v3. The premise here is that pools with more liquidity are less likely to be manipulated. 2. Autonomous TWAP management: SIR autonomously handles adjustments to the Time-Weighted Average Price (TWAP), ensuring it selects the most liquid fee tier for accurate pricing. Although SIR typically employs a 15-minute TWAP, it recognizes that not all Uniswap v3 pairs have their price buffers fully initialized. To address this, the system incrementally extends the TWAP duration each time a mint/burn transaction occurs. This gradual extension distributes the initialization cost of the price buffer among many users. 3. Defense against multi-block price manipulation: The shift from Proof of Work (PoW) to Proof of Stake (PoS) in Ethereum introduced [new attack surfaces for oracles](https://blog.uniswap.org/uniswap-v3-oracles). SIR addresses this risk by coupling its 15-minute TWAP with a price truncation mechanism. This strategy sets a cap on the maximum allowable price change per block, effectively neutralizing the impact of such attacks. ### The Uniswap V3 Oracle SIR's hypothesis is that **any protocol can only be as trustless as its underlying layers of technology**. For this reason SIR uses the Uniswap v3 oracle which is, in our opinion, the most trustless on-chain price oracle for the following reasons: * [x] Purely on-chain. Being on-chain implies that it is ran by smart contracts, and therefore it is fully auditable. * [x] Immutable smart contracts. Contrary to many other money legos, all versions of Uniswap were launched with non-upgradable immutable contracts. * [x] Protected by economic incentives. Any divergence between the price of Uniswap v3 and any other exchange will be arbitraged for a profit, eliminating the price difference. The cost to manipulate the price is proportional to the liquidity of the traded pair. * [x] Permissionless. Similar to a blockchain, a key part is that anyone can arbitrage the price between Uniswap v3 and any exchange. * [x] Largest liquidity. Uniswap v3 is [the most liquid DEX](https://www.coingecko.com/en/dex) and among the top most liquid exchanges. ### Oracle on Other Chains SIR applies the same oracle principles on every chain it deploys to. The Oracle contract is configured per-chain with the appropriate DEX factory: * **HyperEVM** — uses **HyperSwap** pools for TWAP price data. HyperSwap follows the Uniswap V3 design, so the same fee-tier selection, TWAP management, and multi-block manipulation defenses apply. * **MegaETH** — uses **Kumbaya** pools for TWAP price data, again following the same Uniswap V3 oracle interface. The core mechanism is identical: SIR selects the most liquid fee tier, autonomously manages the TWAP window, and applies price truncation to defend against manipulation. Only the DEX factory address differs between chains. See [Deployments](/protocol-overview/deployments) for the specific factory addresses. # Tokenomics The Core Value-Capturing Token of the SIR Protocol SIR holders can stake their tokens to earn a share of protocol fees. All fees are converted to the chain's native wrapped token (WETH on Ethereum, WHYPE on HyperEVM, WETH on MegaETH) through an [auction system](/protocol-overview/token-auctions) and distributed to stakers, providing a direct claim on the protocol's revenue. The SIR protocol features a carefully designed token economy that aligns incentives across all participants while ensuring long-term sustainability. This section explores how the three-token system works together to create a self-reinforcing ecosystem. ## Overview At its core, SIR solves a fundamental DeFi challenge: how to sustainably incentivize liquidity while capturing value for token holders. The protocol achieves this through: * **Three specialized tokens** (SIR, TEA, APE) each serving distinct roles * **Permanent liquidity accumulation** through protocol-owned liquidity * **Constant token emission** ensuring fair opportunity for all participants * **Mathematical optimization** for efficient capital allocation ## Section Contents ### [🎩 SIR Token Mechanics](/protocol-overview/sir-a-dividend-paying-token/sir-token-mechanics) * **Flexible Operations:** Stake, unstake, and claim dividends at any time * **Dividends:** All protocol fees are converted to the chain's native wrapped token via [auctions](/protocol-overview/token-auctions) for consistent payouts * **Pro-rata Distribution:** Rewards proportional to your staked share ### [💰 Economic Model](/protocol-overview/sir-a-dividend-paying-token/economic-model) Explore the three-token ecosystem from a business perspective. Understand how APE traders, TEA providers, and SIR holders interact to create value, and why constant issuance beats traditional capped supply models. ### [🍰 Token Distribution](/protocol-overview/sir-a-dividend-paying-token/token-distribution) Detailed breakdown of how SIR tokens are allocated during the bootstrap phase (years 1-3) across Ethereum, HyperEVM, and MegaETH, and the transition to 100% liquidity provider rewards thereafter. ## Getting Started New to SIR? Start with the [Economic Model](/protocol-overview/sir-a-dividend-paying-token/economic-model) to understand the big picture, then explore [SIR Token Mechanics](/protocol-overview/sir-a-dividend-paying-token/sir-token-mechanics) for technical details on staking and rewards. # SIR Token Mechanics How the SIR Token Works - Staking, Dividends, and Governance The SIR token serves as the protocol's value-capture mechanism and governance backbone, designed with sustainable economics and aligned incentives at its core. {% hint style="info" %} SIR is deployed on three chains, each with its own token: **SIR** on Ethereum, **HyperSIR** on HyperEVM, and **MegaSIR** on MegaETH. Each chain has independent staking and emission — tokens are not bridged between chains. {% endhint %} ## Core Functions **1. Dividend Distribution** SIR holders can stake their tokens to earn a share of protocol fees. Fees are converted through an [auction system](/protocol-overview/token-auctions) and distributed to stakers, providing a direct claim on the protocol's revenue. On Ethereum dividends are paid in WETH, on HyperEVM in WHYPE, and on MegaETH in WETH. **2. Perpetual Liquidity Incentives** Unlike temporary liquidity mining programs, SIR embeds token distribution directly into the protocol's immutable contracts. This ensures continuous, predictable rewards for liquidity providers without arbitrary end dates or governance votes. **3. Future Governance** Once the SIR DAO is established, token holders will govern: * Vault selection and reward allocation for SIR emissions * Treasury management This creates a direct alignment: vaults generating the highest fees receive optimal reward allocation, maximizing value for all stakeholders. ## Staking Mechanics **How Staking Works** To earn protocol dividends, SIR holders must stake their tokens, temporarily removing them from circulation. Key features: * **Flexible Operations:** Stake, unstake, and claim dividends at any time * **Dividend Payouts:** WETH on Ethereum, WHYPE on HyperEVM, WETH on MegaETH — all converted via [auctions](/protocol-overview/token-auctions) * **Pro-rata Distribution:** Rewards proportional to your staked share **Anti-Exploitation Locking** Staked SIR follows a progressive unlocking mechanism to prevent flash loan attacks: * **Initial Lock:** 100% locked upon staking * **Exponential Decay:** 30-day half-life unlocking schedule * Day 30: 50% unlocked * Day 60: 75% unlocked * Day 90: 87.5% unlocked * **Continuous Process:** Unlocking occurs every second, not in discrete steps This design prevents short-term manipulation while maintaining long-term flexibility for genuine stakers. ## Token Issuance Model **Constant Emission Rate** SIR tokens are emitted at a fixed rate of **2.015 billion per year**, starting from zero supply at launch. This predictable, linear issuance continues indefinitely. Each chain emits independently at this rate. **Why Not Capped Supply?** Many protocols follow Bitcoin's model with limited supply and decreasing emissions. However, as Fiskantes explains, front-loaded emissions create unsustainable dynamics: {% embed url="" %} Our constant issuance model ensures: * **Early Participants:** Benefit from easier accumulation when liquidity is low * **Future Participants:** Still receive meaningful rewards when TVL is higher * **Sustainable Growth:** Avoid the "death spiral" of diminishing rewards * **Mitigation Strategy:** LPers can retain positions to offset dilution through rewards ## Liquidity Mining Framework **Permanent Integration** Unlike temporary "liquidity mining" campaigns from DeFi Summer 2020, SIR embeds rewards directly into immutable smart contracts. This creates: * **Predictable Incentives:** No arbitrary end dates or governance votes * **Long-term Commitment:** Permanent support for protocol liquidity * **Fair Distribution:** Rewards proportional to economic contribution **Vault Reward Mechanism** Selected vaults receive SIR emissions in exchange for sharing fees with stakers: * **Fee Sharing Cap:** Maximum 50% of vault fees to SIR stakers * **Proportional Rewards:** Higher fee share earns proportionally more SIR * **Aligned Incentives:** Most productive vaults receive optimal rewards ## Governance & Vault Selection **The Human Element** While most protocol functions are automated, vault selection requires human judgment due to: * **Token Diversity:** Various collateral types across vaults * **Oracle Limitations:** Not all token pairs have suitable DEX pools * **Economic Complexity:** Difficulty measuring true vault productivity on-chain **DAO-Driven Optimization** The SIR DAO will manage vault rewards through mathematical optimization: **Reward Formula:** $$r\_i = \alpha f\_i$$ Where: * $$r\_i$$ = Vault reward rate \[SIR/s] * $$f\_i$$ = Fee contribution \[%] * $$\alpha$$ = Proportionality constant **Optimization Constraint:** $$\sqrt{\sum f\_i^2} \leq 50%$$ This ensures rewards match economic contribution while maintaining system sustainability. **Example Allocation** Two-vault scenario: * Vault 1: $1M fees → 403M SIR/year (20%) * Vault 2: $4M fees → 1,612M SIR/year (80%) The mathematical framework guarantees fair, efficient capital allocation across all protocol vaults. # Economic Model The Three-Token Economy and Business Model ## The Three-Token Ecosystem The SIR protocol operates through a synergistic three-token model, each serving distinct but interconnected roles: **SIR Token: Value Capture & Governance** * **Dividend Distribution:** Stake SIR to earn a share of protocol fees (WETH on Ethereum, WHYPE on HyperEVM, WETH on MegaETH) * **Continuous Issuance:** 2.015 billion SIR per year, creating sustainable liquidity incentives * **Future Governance:** Control treasury and direct reward allocations across vaults **TEA Token: Liquidity Provision** * **Liquidity Representation:** Mint TEA by depositing assets; burn to withdraw * **Fee Structure:** 4.9% upfront deposit fee (retained as protocol-owned liquidity) * **Revenue Streams:** * Primary: Trading fees from APE leverage positions * Secondary: SIR token rewards for selected vaults **APE Token: Leverage Positions** * **Position Management:** Minted when opening leverage, burned when closing * **Fee Structure:** One-time minting fee paid to LPers, scaling with leverage ratio (\~9% for ^1.5, \~17% for ^2) * **Revenue Generation:** Trading activity drives protocol fees distributed to stakeholders ## Business Model Architecture The protocol's economic model can be understood through traditional business roles: **Customers:** APE holders (leverage traders) who pay fees for leveraged positions. They are the primary revenue generators for the ecosystem. **Service Providers:** TEA holders (liquidity providers) act as intermediaries, enabling leverage capacity. Greater TEA liquidity allows higher leverage potential, attracting more APE users. **Stakeholders:** SIR holders capture value through dividends and governance rights, aligning their interests with protocol growth. **Revenue Flow** 1. APE holders generate fees through leverage trading 2. Fees flow to TEA holders and SIR stakers (up to 50% can be directed to stakers) 3. SIR emissions incentivize TEA liquidity provision 4. Increased liquidity attracts more APE users, creating a growth flywheel ## Sustainable Tokenomics Design **Why Constant Issuance?** Unlike projects with capped supplies that front-load emissions, SIR maintains constant issuance for several strategic reasons: **Long-term Viability:** High initial emissions followed by reduction creates unsustainable dynamics. As emissions decrease, new participants have less incentive to join, potentially leading to protocol forks or competitive disadvantages. **Fair Opportunity:** Constant issuance ensures future liquidity providers (when TVL is higher) can still earn meaningful rewards, while early participants benefit from easier accumulation when liquidity is lower. **Transparent Predictability:** Instead of teams selling tokens unpredictably to fund operations, SIR embeds liquidity incentives directly into the protocol in a transparent, permanent manner. **The Best of Both Worlds** For participants seeking to optimize their position: * **Stake SIR:** Earn dividends from protocol fees * **Provide Liquidity:** Earn SIR rewards to offset dilution * **Do Both:** LP and stake earned SIR for maximum benefit (no dilution + dividends) ## Protocol-Owned Liquidity On Ethereum and HyperEVM, 4.9% of every TEA deposit becomes permanent protocol-owned liquidity (POL). This POL never withdraws and continuously earns fees, creating a growing foundation that reduces reliance on temporary incentives over time. On MegaETH, POL is optional — LPs can opt out of the fee by locking their deposit for a period of time instead. For detailed mechanics, see [Protocol Owned Liquidity](/protocol-overview/liquidity-and-leverage/protocol-owned-liquidity). ## Economic Alignment **Incentive Structure** The protocol aligns all participant incentives toward sustainable growth: 1. **APE Users:** Access leverage with predictable fees and deep liquidity 2. **TEA Holders:** Earn stable income from fees plus SIR rewards 3. **SIR Holders:** Capture protocol value through dividends and price appreciation 4. **Protocol Treasury:** Accumulates permanent liquidity for long-term resilience **Mathematical Optimization** Reward distribution follows economic contribution: * Vaults receive SIR proportional to fees generated * Maximum 50% fee redistribution to SIR stakers * Quadratic constraint ($$\sqrt{\sum f\_i^2} \leq 50%$$) optimizes allocation efficiency This creates a self-balancing system where the most productive vaults naturally attract appropriate incentives, maximizing capital efficiency across the protocol. # Token Distribution Emission Schedule and Allocation Strategy ## Emission Schedule **Constant Rate Model** * **Annual Emission:** 2.015 billion SIR per year (per chain) * **Starting Supply:** Zero at launch * **Distribution Frequency:** Continuous (every second) * **Duration:** Perpetual (no end date) **Phased Allocation Strategy** Years 1-3: Bootstrap Phase During the initial three years, emissions support both protocol development and liquidity growth through diversified allocation. Year 4+: Full Liquidity Focus After year three, **100% of emissions flow to liquidity providers**, ensuring sustainable long-term incentives. ## Ethereum Allocation (Years 1-3) Following the protocol redesign after the March 2025 exploit, the emission breakdown for Ethereum is: | Recipient | Allocation | Purpose | | --------------------------------------------------------------------- | ---------- | ----------------------------------------------------------------------------- | | **Liquidity Providers** | 56.13% | Protocol liquidity incentives | | **Team & Contributors** | 13.65% | Development and operations | | **Hack Victims Fund** | 12.00% | [Compensation for losses](/protocol-overview/user-risks/exploit-and-relaunch) | | **Protocol Treasury** | 10.00% | Strategic reserves & development | | **Presale Investors** | 8.22% | Early funding supporters | ## HyperEVM Allocation (Years 1-3) | Recipient | Allocation | | -------------------------------------------------------------------------------------------- | ---------- | | **Liquidity Providers** | 70% | | **Previous SIR Holders, Users & Contributors** | 30% | ## MegaETH Allocation (Years 1-3) | Recipient | Allocation | | -------------------------------------------------------------------------------------------- | ---------- | | **Liquidity Providers** | 69% | | **Previous SIR Holders, Users & Contributors** | 31% | ## Original Ethereum Allocation (Pre-Exploit) The initial protocol design allocated first three years' emissions as: | Recipient | Allocation | | --------------------------------------------------------------------- | ---------- | | **Liquidity Providers** | 68.13% | | **Team & Contributors** | 13.65% | | **Protocol Treasury** | 10.00% | | **Investors** | 8.22% | ## Strategic Rationale **Liquidity First:** On every chain, the majority of emissions flows to LPers, ensuring deep liquidity from day one. **Aligned Incentives:** Team and contributor allocations ensure long-term commitment while treasury reserves enable strategic flexibility. **Fair Compensation:** On Ethereum, hack victims receive meaningful restitution without compromising protocol viability. **Sustainable Transition:** After year three, all chains transition to 100% LP rewards, creating predictable long-term incentives. Protocol fees fund operations via SIR staking dividends. # Token Auctions Streamlining Conversion: From Diverse Tokens to Dividends SIR accrues fees in various tokens, making direct distributions to [stakers](/protocol-overview/sir-a-dividend-paying-token#staking) both gas-intensive and administratively complex. To streamline this, SIR utilizes an efficient auction system for converting all tokens into the chain's native wrapped token seamlessly. ### Auction Mechanics Each week, an auction is open for every unique ERC-20 token (uniqueness determined by contract address). This auction, lasting one day, allows participants to place bids for the tokens. The process ensures that the highest bidder wins the tokens at the end of the auction, with immediate refunds issued to outbid participants. The process for claiming the auctioned tokens is open to anyone, facilitating the withdrawal to the auction winner. ### Chain-Specific Details The auction mechanics are the same on every chain, with minor differences in bid currency and minimum bid increase: | Chain | Bid Currency | Dividend Token | Min Bid Increase | | -------- | ------------ | -------------- | :--------------: | | Ethereum | ETH | WETH | 1% | | HyperEVM | HYPE | WHYPE | 5% | | MegaETH | ETH | WETH | 5% | ### Incentives for Participants This system presents opportunities for those interested in Maximal Extractable Value (MEV), often viewed negatively, and repurposes it into a positive mechanism for SIR. It facilitates the trustless conversion of any token into the dividend token, leveraging MEV for the protocol's advantage. While bids are placed in the chain's native token for simplicity, stakers receive their dividends in the wrapped version, marrying efficiency with ease of implementation. # Deployments SIR is deployed on three chains. The core protocol contracts are identical across all deployments — the same Vault, Oracle, and token mechanics — configured for each chain's native price oracle and tokens. *** ## Ethereum | | | | ---------------- | ---------- | | **Chain ID** | 1 | | **Native Token** | ETH | | **SIR Token** | SIR | | **Price Oracle** | Uniswap V3 | | Contract | Address | | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | [Vault.sol](https://github.com/SIR-trading/Core/blob/master/src/Vault.sol) | [`0x7Dad75dD36dE234C937C105e652B6E50d68b0309`](https://etherscan.io/address/0x7Dad75dD36dE234C937C105e652B6E50d68b0309) | | [SIR.sol](https://github.com/SIR-trading/Core/blob/master/src/SIR.sol) | [`0x4Da4fb565Dcd5D5C5dB495205c109bA983A8ABa2`](https://etherscan.io/address/0x4Da4fb565Dcd5D5C5dB495205c109bA983A8ABa2) | | [Oracle.sol](https://github.com/SIR-trading/Core/blob/master/src/Oracle.sol) | [`0xeD89aF5E62965C45956A0125a5d078218228497A`](https://etherscan.io/address/0xeD89aF5E62965C45956A0125a5d078218228497A) | | [SystemControl.sol](https://github.com/SIR-trading/Core/blob/master/src/SystemControl.sol) | [`0xbbb9BafB8E41f081fFa064b697bBeffd1a5B52F4`](https://etherscan.io/address/0xbbb9BafB8E41f081fFa064b697bBeffd1a5B52F4) | | [Contributors.sol](https://github.com/SIR-trading/Core/blob/master/src/Contributors.sol) | [`0xca5d6c55e249a9add07a2440eccfe16f56572cb5`](https://etherscan.io/address/0xca5d6c55e249a9add07a2440eccfe16f56572cb5) | | [Assistant.sol](https://github.com/SIR-trading/Periphery/blob/main/src/Assistant.sol) | [`0xff14f91285580AEd3733c0B1F3C8b6d04804c5ec`](https://etherscan.io/address/0xff14f91285580AEd3733c0B1F3C8b6d04804c5ec) | **Uniswap V3 Factory:** [`0x1F98431c8aD98523631AE4a59f267346ea31F984`](https://etherscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984) *** ## HyperEVM | | | | ---------------- | --------- | | **Chain ID** | 999 | | **Native Token** | HYPE | | **SIR Token** | HyperSIR | | **Price Oracle** | HyperSwap | | Contract | Address | | ------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | [Vault.sol](https://github.com/SIR-trading/Core/blob/master/src/Vault.sol) | [`0x4a35e7448Dad9cAc6B3e529050B5a6Ee56A0eDF0`](https://hyperevmscan.io/address/0x4a35e7448Dad9cAc6B3e529050B5a6Ee56A0eDF0) | | [SIR.sol](https://github.com/SIR-trading/Core/blob/master/src/SIR.sol) (HyperSIR) | [`0xA06D0c5a8ADb7134903CA13D1FC0641731E2B766`](https://hyperevmscan.io/address/0xA06D0c5a8ADb7134903CA13D1FC0641731E2B766) | | [Oracle.sol](https://github.com/SIR-trading/Core/blob/master/src/Oracle.sol) | [`0x2Ab530127a40a832B3e9AD2F0eC6Cdfee17542E0`](https://hyperevmscan.io/address/0x2Ab530127a40a832B3e9AD2F0eC6Cdfee17542E0) | | [SystemControl.sol](https://github.com/SIR-trading/Core/blob/master/src/SystemControl.sol) | [`0xaAD7A78da51Fa53b50d17f4dA47ae0A042301C93`](https://hyperevmscan.io/address/0xaAD7A78da51Fa53b50d17f4dA47ae0A042301C93) | | [Contributors.sol](https://github.com/SIR-trading/Core/blob/master/src/Contributors.sol) | [`0xDCd0d8bb7F54010b745Aee52eFf95eA246078A94`](https://hyperevmscan.io/address/0xDCd0d8bb7F54010b745Aee52eFf95eA246078A94) | | [Assistant.sol](https://github.com/SIR-trading/Periphery/blob/main/src/Assistant.sol) | [`0x7d987b986FbA5e0A4247649A2334Bb2D4029656c`](https://hyperevmscan.io/address/0x7d987b986FbA5e0A4247649A2334Bb2D4029656c) | **HyperSwap Factory:** [`0xB1c0fa0B789320044A6F623cFe5eBda9562602E3`](https://hyperevmscan.io/address/0xB1c0fa0B789320044A6F623cFe5eBda9562602E3) *** ## MegaETH | | | | ---------------- | ------- | | **Chain ID** | 4326 | | **Native Token** | ETH | | **SIR Token** | MegaSIR | | **Price Oracle** | Kumbaya | | Contract | Address | | ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | [Vault.sol](https://github.com/SIR-trading/Core/blob/master/src/Vault.sol) | [`0x8d694D1b369BdE5B274Ad643fEdD74f836E88543`](https://megaeth.blockscout.com/address/0x8d694D1b369BdE5B274Ad643fEdD74f836E88543) | | [SIR.sol](https://github.com/SIR-trading/Core/blob/master/src/SIR.sol) (MegaSIR) | [`0x9367A0c482703d8d9bda995B03f8E71056a72500`](https://megaeth.blockscout.com/address/0x9367A0c482703d8d9bda995B03f8E71056a72500) | | [Oracle.sol](https://github.com/SIR-trading/Core/blob/master/src/Oracle.sol) | [`0x4edF071a7dEe52fBE663DF7873994725ba91Cdc7`](https://megaeth.blockscout.com/address/0x4edF071a7dEe52fBE663DF7873994725ba91Cdc7) | | [SystemControl.sol](https://github.com/SIR-trading/Core/blob/master/src/SystemControl.sol) | [`0x549618c8E4b74f9eB519e459698b2CaF53dA0453`](https://megaeth.blockscout.com/address/0x549618c8E4b74f9eB519e459698b2CaF53dA0453) | | [Contributors.sol](https://github.com/SIR-trading/Core/blob/master/src/Contributors.sol) | [`0x686748764c5C7Aa06FEc784E60D14b650bF79129`](https://megaeth.blockscout.com/address/0x686748764c5C7Aa06FEc784E60D14b650bF79129) | | [Assistant.sol](https://github.com/SIR-trading/Periphery/blob/main/src/Assistant.sol) | [`0xB91AE2c8365FD45030abA84a4666C4dB074E53E7`](https://megaeth.blockscout.com/address/0xB91AE2c8365FD45030abA84a4666C4dB074E53E7) | **Kumbaya Factory:** [`0x68b34591f662508076927803c567Cc8006988a09`](https://megaeth.blockscout.com/address/0x68b34591f662508076927803c567Cc8006988a09) {% hint style="info" %} LP positions on MegaETH have a lock period. Plan your liquidity provision accordingly. {% endhint %} # Contract Interfaces Function-level reference for integrating with SIR Protocol contracts. This section documents the public and external functions of SIR Protocol's core contracts. It is intended for developers building on top of the protocol — bots, aggregators, frontends, and other integrations. For deployed contract addresses, see [Deployments](/protocol-overview/deployments). {% hint style="info" %} The core contracts are deployed on **Ethereum**, **HyperEVM**, and **MegaETH**. Function signatures are nearly identical across chains, but there are meaningful differences noted on each page. Always verify against the deployment you are targeting. {% endhint %} ## Contract Pages | Contract | Description | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------- | | [Vault](/protocol-overview/smart-contract-interfaces/vault) | Main entry point for minting and burning APE/TEA tokens | | [SIR & Staking](/protocol-overview/smart-contract-interfaces/sir-and-staking) | SIR token, staking for dividends, reward claiming, and fee auctions | | [Price Oracle](/protocol-overview/smart-contract-interfaces/oracle) | TWAP price feed interface | | [TEA & APE Tokens](/protocol-overview/smart-contract-interfaces/tea-and-ape) | LP token (ERC1155) and leveraged token (ERC20) interfaces | ## Key Structs These structs appear throughout the contract interfaces. ### `VaultParameters` Identifies a specific vault. Used as input to most Vault functions. ```solidity struct VaultParameters { address debtToken; address collateralToken; int8 leverageTier; // Range: -2 to +2 } ``` ### `Reserves` Collateral reserves held by a vault, returned by `getReserves()`. ```solidity struct Reserves { uint144 reserveApes; // Collateral belonging to APE holders uint144 reserveLPers; // Collateral belonging to TEA holders (LPs) int64 tickPriceX42; // Current price in Q21.42 fixed point } ``` ### `VaultState` On-chain storage representation of a vault's state. ```solidity struct VaultState { uint144 reserve; // Total reserve (reserveApes + reserveLPers) int64 tickPriceSatX42; // Saturation price in Q21.42 fixed point uint48 vaultId; // Unique vault identifier } ``` ### `Fees` Fee breakdown returned during mint/burn operations. ```solidity struct Fees { uint144 collateralInOrWithdrawn; // Net collateral deposited or withdrawn uint144 collateralFeeToStakers; // Fee portion sent to SIR stakers uint144 collateralFeeToLPers; // Fee portion sent to LPers / POL } ``` ### `Auction` State of a fee auction. ```solidity struct Auction { address bidder; // Current highest bidder uint96 bid; // Current highest bid amount uint40 startTime; // Auction start timestamp } ``` # Vault Main entry point for minting and burning the protocol's synthetic tokens. The Vault is the core contract of SIR Protocol. It uses a singleton architecture — all vaults live in a single contract. Users interact with the Vault to create new vaults, mint/burn APE and TEA tokens, and query vault state. The Vault inherits from TEA (the ERC1155 LP token contract) and deploys APE contracts (ERC20 clones) for each vault. {% hint style="warning" %} **Chain differences:** * **`mint()` lock parameter:** On MegaETH, `mint()` includes a `portionLockTime` parameter that lets LPers reduce their minting fee by locking TEA. On Ethereum and HyperEVM this parameter does not exist. * **Native token:** Send ETH with `mint()` on Ethereum/MegaETH (WETH vaults), or HYPE on HyperEVM (WHYPE vaults). The contract auto-wraps the native token. * **Swap callback:** Named `uniswapV3SwapCallback` on Ethereum/MegaETH, `hyperswapV3SwapCallback` on HyperEVM. {% endhint %} *** ## `initialize` Creates a new vault. Permissionless — anyone can call it. Deploys a new APE (ERC20) contract for the vault and initializes the Oracle for the token pair if needed. Reverts if the vault already exists. ```solidity function initialize(VaultParameters memory vaultParams) external ``` | Parameter | Type | Description | | ------------- | ----------------- | ----------------------------------------------------------------------------- | | `vaultParams` | `VaultParameters` | The debt token, collateral token, and leverage tier identifying the new vault | > Each unique combination of `(debtToken, collateralToken, leverageTier)` creates a distinct vault with its own APE token. *** ## `mint` Mints APE or TEA tokens by depositing collateral. Supports three deposit methods: 1. **Collateral token** — set `collateralToDepositMin = 0` 2. **Debt token** (auto-swapped via Uniswap/HyperSwap/Kumbaya) — set `collateralToDepositMin > 0` as slippage protection 3. **Native ETH/HYPE** — send value with the call (only for WETH/WHYPE vaults) {% tabs %} {% tab title="Ethereum / HyperEVM" %} ```solidity function mint( bool isAPE, VaultParameters memory vaultParams, uint256 amountToDeposit, uint144 collateralToDepositMin, uint40 deadline ) external payable returns (uint256 amount) ``` {% endtab %} {% tab title="MegaETH" %} ```solidity function mint( bool isAPE, VaultParameters memory vaultParams, uint256 amountToDeposit, uint144 collateralToDepositMin, uint40 deadline, uint8 portionLockTime ) external payable returns (uint256 amount) ``` {% endtab %} {% endtabs %} | Parameter | Type | Description | | ------------------------ | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | `isAPE` | `bool` | `true` to mint APE, `false` to mint TEA | | `vaultParams` | `VaultParameters` | The vault to mint into | | `amountToDeposit` | `uint256` | Amount of collateral (or debt token if `collateralToDepositMin > 0`) to deposit. Ignored when sending native ETH/HYPE. | | `collateralToDepositMin` | `uint144` | Set to `0` when depositing collateral directly. When depositing debt token, this is the minimum collateral to receive from the swap (slippage protection). | | `deadline` | `uint40` | Transaction deadline timestamp. Set to `0` to disable. | | `portionLockTime` | `uint8` | **MegaETH only.** `0` = full fee (no lock), `255` = no fee (full lock period). Ignored for APE mints. | **Returns:** `uint256` — amount of APE or TEA tokens minted. > When minting with native ETH/HYPE, `msg.value` overrides `amountToDeposit`. The contract wraps it to WETH/WHYPE automatically. *** ## `burn` Burns APE or TEA tokens and returns collateral to the caller. ```solidity function burn( bool isAPE, VaultParameters calldata vaultParams, uint256 amount, uint40 deadline ) external returns (uint144) ``` | Parameter | Type | Description | | ------------- | ----------------- | ------------------------------------------------------ | | `isAPE` | `bool` | `true` to burn APE, `false` to burn TEA | | `vaultParams` | `VaultParameters` | The vault to burn from | | `amount` | `uint256` | Amount of APE or TEA tokens to burn | | `deadline` | `uint40` | Transaction deadline timestamp. Set to `0` to disable. | **Returns:** `uint144` — amount of collateral received. > On MegaETH, burning TEA will revert with `TEALocked` if the caller's TEA position is still within its lock period. *** ## `getReserves` Returns the current reserves of a vault — how much collateral belongs to APE holders vs TEA holders (LPs), and the current price. ```solidity function getReserves( VaultParameters calldata vaultParams ) external view returns (Reserves memory) ``` | Parameter | Type | Description | | ------------- | ----------------- | ------------------ | | `vaultParams` | `VaultParameters` | The vault to query | **Returns:** `Reserves` — `(reserveApes, reserveLPers, tickPriceX42)` *** ## `vaultStates` Returns the raw on-chain state of a vault. ```solidity function vaultStates( VaultParameters calldata vaultParams ) external view returns (VaultState memory) ``` | Parameter | Type | Description | | ------------- | ----------------- | ------------------ | | `vaultParams` | `VaultParameters` | The vault to query | **Returns:** `VaultState` — `(reserve, tickPriceSatX42, vaultId)` > Use `getReserves()` for the decomposed view (separate APE and LP reserves). Use `vaultStates()` to get the vault ID or raw storage values. *** ## `ORACLE` Returns the current Oracle contract address. On MegaETH, this accounts for pending oracle changes with a time delay. ```solidity function ORACLE() public view returns (Oracle) ``` **Returns:** The active `Oracle` contract address. *** ## `totalReserves` Returns the total collateral balance across all vaults for a given token (excluding fees reserved for stakers). ```solidity function totalReserves(address collateral) external view returns (uint256) ``` | Parameter | Type | Description | | ------------ | --------- | ---------------------------- | | `collateral` | `address` | The collateral token address | **Returns:** `uint256` — total collateral held. *** ## `APE_IMPLEMENTATION` Returns the address of the APE implementation contract used for deploying clones. ```solidity function APE_IMPLEMENTATION() external view returns (address) ``` **Returns:** The APE implementation address. # SIR & Staking SIR token, staking for dividends, reward minting, and fee auctions. The SIR contract is the protocol's ERC-20 governance and reward token. It inherits from Staker, which handles staking, dividend distribution, and fee auctions. SIR stakers receive dividends from protocol trading fees. {% hint style="warning" %} **Chain differences:** * **Token name:** SIR (Ethereum) / HyperSIR (HyperEVM) / MegaSIR (MegaETH) * **Dividends paid in:** WETH (Ethereum/MegaETH) or WHYPE (HyperEVM), distributed as native ETH/HYPE * **`bid()` payability:** `payable` on HyperEVM and MegaETH (supports native token bidding); not payable on Ethereum * **Bid threshold:** Must be >1% higher on Ethereum, >5% higher on HyperEVM/MegaETH {% endhint %} *** ## Staking & Dividends ### `stake` Stakes SIR tokens to earn dividends from protocol fees. Newly staked SIR is locked and unlocks gradually — after 30 days, half of the staked amount is unlocked. ```solidity function stake(uint80 amount) public ``` | Parameter | Type | Description | | --------- | -------- | ---------------------- | | `amount` | `uint80` | Amount of SIR to stake | *** ### `unstake` Unstakes SIR tokens. Only unlocked stake can be unstaked. Reverts with `InsufficientUnlockedStake` if `amount` exceeds unlocked balance. ```solidity function unstake(uint80 amount) public ``` | Parameter | Type | Description | | --------- | -------- | ------------------------ | | `amount` | `uint80` | Amount of SIR to unstake | *** ### `claim` Claims accumulated dividends (ETH on Ethereum/MegaETH, HYPE on HyperEVM). Reverts with `NoDividends` if there is nothing to claim. ```solidity function claim() public returns (uint96 dividends) ``` **Returns:** `uint96` — amount of native token dividends received. *** ### `unstakeAndClaim` Convenience function that unstakes SIR and claims dividends in a single transaction. ```solidity function unstakeAndClaim(uint80 amount) external returns (uint96 dividends) ``` | Parameter | Type | Description | | --------- | -------- | ------------------------ | | `amount` | `uint80` | Amount of SIR to unstake | **Returns:** `uint96` — amount of dividends received. *** ### `stakeOf` Returns the unlocked and locked stake breakdown for a staker. Locked stake unlocks gradually with a 30-day half-life. ```solidity function stakeOf(address staker) external view returns (uint80 unlockedStake, uint80 lockedStake) ``` | Parameter | Type | Description | | --------- | --------- | ---------------- | | `staker` | `address` | Address to query | **Returns:** `(unlockedStake, lockedStake)` — breakdown of the staker's position. *** ### `unclaimedDividends` Returns the amount of unclaimed dividends for a staker. ```solidity function unclaimedDividends(address staker) external view returns (uint96) ``` | Parameter | Type | Description | | --------- | --------- | ---------------- | | `staker` | `address` | Address to query | **Returns:** `uint96` — unclaimed dividend amount (in WETH/WHYPE). *** ## SIR Reward Minting ### `lperMint` Claims SIR rewards earned by providing liquidity (TEA) in a specific vault. ```solidity function lperMint(uint256 vaultId) public returns (uint80 rewards) ``` | Parameter | Type | Description | | --------- | --------- | ---------------------------------- | | `vaultId` | `uint256` | The vault ID to claim rewards from | **Returns:** `uint80` — amount of SIR minted. *** ### `lperMintAndStake` Claims SIR rewards from a vault and immediately stakes them in a single transaction. ```solidity function lperMintAndStake(uint256 vaultId) external returns (uint80 rewards) ``` | Parameter | Type | Description | | --------- | --------- | ---------------------------------- | | `vaultId` | `uint256` | The vault ID to claim rewards from | **Returns:** `uint80` — amount of SIR minted and staked. *** ### `contributorMint` Claims SIR rewards for pre-mainnet contributors based on their allocation. Only available during the first 3 years. ```solidity function contributorMint() public returns (uint80 rewards) ``` **Returns:** `uint80` — amount of SIR minted. *** ### `contributorMintAndStake` Claims contributor SIR rewards and immediately stakes them. ```solidity function contributorMintAndStake() external returns (uint80 rewards) ``` **Returns:** `uint80` — amount of SIR minted and staked. *** ### `contributorUnclaimedSIR` Returns the amount of unclaimed SIR for a contributor. ```solidity function contributorUnclaimedSIR(address contributor) public view returns (uint80) ``` | Parameter | Type | Description | | ------------- | --------- | ---------------- | | `contributor` | `address` | Address to query | **Returns:** `uint80` — unclaimed SIR amount. *** ## Fee Auctions Protocol fees collected in various tokens are auctioned off for WETH/WHYPE, which is then distributed as dividends to stakers. ### `collectFeesAndStartAuction` Collects accumulated fees from the Vault for a given token and starts a new auction. If the token is WETH/WHYPE, fees are distributed directly as dividends without an auction. ```solidity function collectFeesAndStartAuction(address token) external returns (uint256 totalFees) ``` | Parameter | Type | Description | | --------- | --------- | ------------------------------------ | | `token` | `address` | The fee token to collect and auction | **Returns:** `uint256` — total fees collected. > Reverts with `NewAuctionCannotStartYet` if the cooldown from the previous auction hasn't elapsed. Reverts with `NoFeesCollected` if there are no fees to collect. *** ### `bid` Places a bid on an active fee auction. The bid must exceed the current highest bid by a minimum threshold. {% tabs %} {% tab title="Ethereum" %} ```solidity function bid(address token, uint96 amount) external ``` Bid must be >1% higher than the current winning bid. Bidders must approve WETH spending beforehand. {% endtab %} {% tab title="HyperEVM / MegaETH" %} ```solidity function bid(address token, uint96 amount) external payable ``` Bid must be >5% higher than the current winning bid. Send native ETH/HYPE with the call (auto-wraps), or approve WETH/WHYPE and pass `amount`. {% endtab %} {% endtabs %} | Parameter | Type | Description | | --------- | --------- | ------------------------------------------------------------------------- | | `token` | `address` | The token being auctioned | | `amount` | `uint96` | Bid amount in WETH/WHYPE (ignored if `msg.value > 0` on HyperEVM/MegaETH) | > The same bidder can increase their bid by calling `bid()` again — amounts are additive. Previous bidders are automatically refunded. *** ### `getAuctionLot` Called by the auction winner after the auction ends to claim the auctioned tokens. ```solidity function getAuctionLot(address token, address beneficiary) external ``` | Parameter | Type | Description | | ------------- | --------- | --------------------------------------------------------------------------------------- | | `token` | `address` | The token that was auctioned | | `beneficiary` | `address` | Address to receive the tokens. Set to `address(0)` to send to the bidder's own address. | > Reverts with `AuctionIsNotOver` if called before the auction ends, or `NotTheAuctionWinner` if the caller is not the winning bidder. *** ### `auctions` Returns the current auction state for a token. ```solidity function auctions(address token) external view returns (Auction memory) ``` | Parameter | Type | Description | | --------- | --------- | ------------------ | | `token` | `address` | The token to query | **Returns:** `Auction` — `(bidder, bid, startTime)`. *** ## View / Constants ### `ISSUANCE_RATE` Returns the global SIR issuance rate (tokens minted per second across all recipients). ```solidity function ISSUANCE_RATE() external pure returns (uint72) ``` *** ### `LP_ISSUANCE_FIRST_3_YEARS` Returns the SIR issuance rate allocated to LPers during the first 3 years. ```solidity function LP_ISSUANCE_FIRST_3_YEARS() external pure returns (uint72) ``` *** ### `supply` Returns the current supply of transferable (unstaked) SIR. ```solidity function supply() external view returns (uint256) ``` *** ### `totalSupply` Returns the total supply of SIR (staked + unstaked, but excluding unclaimed). ```solidity function totalSupply() external view returns (uint256) ``` *** ### `maxTotalSupply` Returns the maximum total supply as if all SIR tokens had been claimed (staked + unstaked + unclaimed from LPers and contributors). ```solidity function maxTotalSupply() external view returns (uint256) ``` *** ### `DOMAIN_SEPARATOR` Returns the EIP-712 domain separator for permit signatures. ```solidity function DOMAIN_SEPARATOR() public view returns (bytes32) ``` *** ### `nonces` Returns the current permit nonce for an address (EIP-2612). ```solidity function nonces(address owner) external view returns (uint256) ``` *** ## Standard ERC-20 The SIR token implements standard ERC-20 functions: | Function | Signature | | -------------- | -------------------------------------------------------------------------------------------------------- | | `balanceOf` | `balanceOf(address account) returns (uint256)` | | `transfer` | `transfer(address to, uint256 amount) returns (bool)` | | `transferFrom` | `transferFrom(address from, address to, uint256 amount) returns (bool)` | | `approve` | `approve(address spender, uint256 amount) returns (bool)` | | `allowance` | `allowance(address owner, address spender) returns (uint256)` | | `permit` | `permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)` | > SIR uses 12 decimals (`SystemConstants.SIR_DECIMALS`). Transfers to `address(0)` or to the staking vault address are not permitted. # Price Oracle TWAP price oracle interface backed by Uniswap V3 / HyperSwap / Kumbaya. The Oracle contract provides time-weighted average price (TWAP) feeds for all token pairs used by SIR Protocol. It interfaces with the chain's native Uniswap V3-style DEX and automatically selects the most liquid fee tier for each pair. The Oracle is fully permissionless — anyone can initialize new token pairs or register new fee tiers. {% hint style="warning" %} **Chain differences:** * **DEX backend:** Uniswap V3 (Ethereum) / HyperSwap (HyperEVM) / Kumbaya (MegaETH) * **TWAP delta:** 5 minutes on Ethereum vs 1 minute on HyperEVM/MegaETH * **Fee tier update cadence:** 23 hours on Ethereum vs 1 hour on HyperEVM/MegaETH * **TWAP duration:** 30 minutes (same on all chains) {% endhint %} *** ## `getPrice` Returns the TWAP price for a collateral-debt token pair as a Q21.42 fixed-point tick value. This is a view function that does not modify state. ```solidity function getPrice( address collateralToken, address debtToken ) external view returns (int64) ``` | Parameter | Type | Description | | ----------------- | --------- | ---------------------------- | | `collateralToken` | `address` | The collateral token address | | `debtToken` | `address` | The debt token address | **Returns:** `int64` — TWAP price as a Q21.42 fixed-point tick. The sign convention ensures the price represents collateral/debt. > Reverts with `OracleNotInitialized` if the token pair has not been initialized. *** ## `updateOracleState` Updates the oracle price for a token pair and stores it so subsequent calls in the same block don't need to query the DEX again. Also periodically checks if a better fee tier is available. ```solidity function updateOracleState( address collateralToken, address debtToken ) external returns (int64 tickPriceX42, address uniswapPoolAddress) ``` | Parameter | Type | Description | | ----------------- | --------- | ---------------------------- | | `collateralToken` | `address` | The collateral token address | | `debtToken` | `address` | The debt token address | **Returns:** * `tickPriceX42` — updated TWAP price (Q21.42 fixed point) * `uniswapPoolAddress` — address of the DEX pool currently being used > This function is called internally by the Vault during mints/burns. External callers (e.g., keepers) can call it to keep prices fresh. *** ## `initialize` Initializes the oracle for a token pair. Permissionless — anyone can call it. Scans all known fee tiers to find the most liquid pool and sets up the TWAP. ```solidity function initialize(address tokenA, address tokenB) external ``` | Parameter | Type | Description | | --------- | --------- | -------------------------------------------- | | `tokenA` | `address` | First token address | | `tokenB` | `address` | Second token address (order does not matter) | > No-op if already initialized (does not revert). Reverts with `NoUniswapPool` if no pool exists for any fee tier. *** ## `uniswapFeeTierOf` Returns the fee tier currently being used as the oracle source for a token pair. ```solidity function uniswapFeeTierOf( address tokenA, address tokenB ) external view returns (uint24) ``` | Parameter | Type | Description | | --------- | --------- | -------------------------------------------- | | `tokenA` | `address` | First token address | | `tokenB` | `address` | Second token address (order does not matter) | **Returns:** `uint24` — fee tier in hundredths of a basis point (e.g., `3000` = 0.30%). *** ## `getUniswapFeeTiers` Returns all fee tiers known to the Oracle — the 4 default tiers plus any custom ones that have been registered. ```solidity function getUniswapFeeTiers() public view returns (UniswapFeeTier[] memory) ``` **Returns:** Array of `UniswapFeeTier` structs: ```solidity struct UniswapFeeTier { uint24 fee; // Fee in hundredths of a bip (e.g., 3000 = 0.30%) int24 tickSpacing; // Tick spacing for this fee tier } ``` Default fee tiers: `100` (0.01%), `500` (0.05%), `3000` (0.30%), `10000` (1.00%). *** ## `newUniswapFeeTier` Registers a new DEX fee tier so the Oracle can consider it when selecting the best pool. Permissionless — anyone can call it. The fee tier must exist in the DEX factory. ```solidity function newUniswapFeeTier(uint24 fee) external ``` | Parameter | Type | Description | | --------- | -------- | -------------------------------------------------------- | | `fee` | `uint24` | The fee tier to register (must exist in the DEX factory) | > Maximum of 9 total fee tiers (4 default + 5 custom). Reverts if the fee tier already exists or if the limit is reached. *** ## `state` Returns the full oracle state for a token pair. Tokens must be provided in lexicographic order (`token0 < token1`). ```solidity function state( address token0, address token1 ) external view returns (OracleState memory) ``` | Parameter | Type | Description | | --------- | --------- | -------------------- | | `token0` | `address` | Lower address token | | `token1` | `address` | Higher address token | **Returns:** `OracleState`: ```solidity struct OracleState { int64 tickPriceX42; // Last stored price (Q21.42) uint40 timeStampPrice; // Timestamp of last stored price uint8 indexFeeTier; // Current fee tier index uint8 indexFeeTierProbeNext; // Next fee tier to probe uint40 timeStampFeeTier; // Last fee tier probe timestamp bool initialized; // Whether the oracle is initialized UniswapFeeTier uniswapFeeTier; // Current fee tier details } ``` *** ## Constants | Constant | Value | Description | | --------------------- | ---------- | ----------------------------------------------- | | `TWAP_DURATION` | 30 minutes | Duration of the TWAP window (all chains) | | `UNISWAPV3_FACTORY` | varies | Address of the DEX factory | | `POOL_INIT_CODE_HASH` | varies | Pool creation code hash for address computation | # TEA & APE Tokens LP token (ERC1155) and leveraged token (ERC20) interfaces. SIR Protocol uses two token types to represent positions: * **TEA** — an ERC1155 token representing LP positions. One token ID per vault, all managed by the Vault contract. * **APE** — a standard ERC20 token representing leveraged positions. One contract per vault, deployed as a minimal clone. Minting and burning of both tokens happens through the [Vault](/protocol-overview/smart-contract-interfaces/vault) contract. The interfaces below cover transfers, approvals, and queries. {% hint style="info" %} **Chain differences — token naming:** * Ethereum: TEA-{id} / APE-{id} * HyperEVM: HyperTEA{id} / HyperAPE-{id} * MegaETH: MegaTEA{id} / MegaAPE-{id} {% endhint %} *** ## TEA (ERC1155 LP Token) TEA is managed by the Vault contract (which inherits from TEA). Each vault has a unique token ID equal to its `vaultId`. ### `balanceOf` Returns the TEA balance of an account in a specific vault. ```solidity function balanceOf(address account, uint256 vaultId) public view returns (uint256) ``` | Parameter | Type | Description | | --------- | --------- | ----------------------------- | | `account` | `address` | The account to query | | `vaultId` | `uint256` | The vault (token ID) to query | *** ### `balanceOfBatch` Returns TEA balances for multiple account/vault pairs in a single call. ```solidity function balanceOfBatch( address[] calldata owners, uint256[] calldata vaultIds ) external view returns (uint256[] memory) ``` | Parameter | Type | Description | | ---------- | ----------- | ----------------------------------------------- | | `owners` | `address[]` | Array of accounts | | `vaultIds` | `uint256[]` | Array of vault IDs (must match `owners` length) | *** ### `totalSupply` Returns the total supply of TEA for a specific vault. ```solidity function totalSupply(uint256 vaultId) external view returns (uint256) ``` | Parameter | Type | Description | | --------- | --------- | ------------------ | | `vaultId` | `uint256` | The vault to query | *** ### `lockEnd` Returns the timestamp when a user's TEA position in a vault becomes unlocked. Returns `0` if never locked. ```solidity function lockEnd(address account, uint256 vaultId) external view returns (uint40) ``` | Parameter | Type | Description | | --------- | --------- | -------------------- | | `account` | `address` | The account to query | | `vaultId` | `uint256` | The vault to query | {% hint style="info" %} Lock functionality is only active on MegaETH, where LPers can choose to lock TEA during minting to reduce the LP fee. On Ethereum and HyperEVM this always returns `0`. {% endhint %} *** ### `paramsById` Returns the vault parameters for a given vault ID. ```solidity function paramsById(uint48 vaultId) external view returns (VaultParameters memory) ``` | Parameter | Type | Description | | --------- | -------- | ------------ | | `vaultId` | `uint48` | The vault ID | **Returns:** `VaultParameters` — `(debtToken, collateralToken, leverageTier)`. *** ### `numberOfVaults` Returns the total number of vaults that have been created. ```solidity function numberOfVaults() external view returns (uint48) ``` *** ### `uri` Returns the ERC1155 metadata URI for a vault. Returns a `data:` URL encoding a JSON object with name, symbol, decimals, chain ID, token addresses, leverage tier, and total supply. ```solidity function uri(uint256 vaultId) external view returns (string memory) ``` | Parameter | Type | Description | | --------- | --------- | ------------------ | | `vaultId` | `uint256` | The vault to query | *** ### `supportsInterface` ERC165 interface detection. Returns `true` for ERC165, ERC1155, and ERC1155MetadataURI. ```solidity function supportsInterface(bytes4 interfaceId) external pure returns (bool) ``` *** ### `safeTransferFrom` Transfers TEA from one account to another. ```solidity function safeTransferFrom( address from, address to, uint256 vaultId, uint256 amount, bytes calldata data ) external ``` | Parameter | Type | Description | | --------- | --------- | ------------------------------------------------ | | `from` | `address` | Sender address | | `to` | `address` | Recipient address | | `vaultId` | `uint256` | The vault (token ID) | | `amount` | `uint256` | Amount of TEA to transfer | | `data` | `bytes` | Additional data for `onERC1155Received` callback | > On MegaETH, transfers will revert with `TransferToLowerLockEnd` if the sender's lock end timestamp exceeds the recipient's. This prevents circumventing lock periods by transferring to an unlocked wallet. *** ### `safeBatchTransferFrom` Batch transfers TEA across multiple vaults. ```solidity function safeBatchTransferFrom( address from, address to, uint256[] calldata vaultIds, uint256[] calldata amounts, bytes calldata data ) external ``` | Parameter | Type | Description | | ---------- | ----------- | ----------------------------------------------------- | | `from` | `address` | Sender address | | `to` | `address` | Recipient address | | `vaultIds` | `uint256[]` | Array of vault IDs | | `amounts` | `uint256[]` | Array of amounts (must match `vaultIds` length) | | `data` | `bytes` | Additional data for `onERC1155BatchReceived` callback | *** ### `setApprovalForAll` Grants or revokes operator approval for all TEA transfers. ```solidity function setApprovalForAll(address operator, bool approved) external ``` | Parameter | Type | Description | | ---------- | --------- | ---------------------------- | | `operator` | `address` | The operator address | | `approved` | `bool` | Whether to approve or revoke | *** ### `isApprovedForAll` Checks if an operator is approved for all TEA transfers on behalf of an account. ```solidity function isApprovedForAll(address account, address operator) public view returns (bool) ``` *** ## APE (ERC20 Leveraged Token) Each vault has its own APE contract deployed as a minimal clone. APE tokens represent leveraged positions and are standard ERC20 tokens with EIP-2612 permit support. ### `leverageTier` Returns the leverage tier for this APE token (stored as an immutable argument in the clone). ```solidity function leverageTier() public pure returns (int8) ``` **Returns:** `int8` — leverage tier from `-2` to `+2`. *** ### `DOMAIN_SEPARATOR` Returns the EIP-712 domain separator for permit signatures. ```solidity function DOMAIN_SEPARATOR() public view returns (bytes32) ``` *** ### `nonces` Returns the current permit nonce for an address (EIP-2612). ```solidity function nonces(address owner) external view returns (uint256) ``` *** ### Standard ERC20 APE implements the full ERC20 interface plus EIP-2612 permit: | Function | Signature | | ------------------- | -------------------------------------------------------------------------------------------------------- | | `name` | `name() returns (string)` | | `symbol` | `symbol() returns (string)` | | `decimals` | `decimals() returns (uint8)` | | `totalSupply` | `totalSupply() returns (uint256)` | | `balanceOf` | `balanceOf(address account) returns (uint256)` | | `transfer` | `transfer(address to, uint256 amount) returns (bool)` | | `transferFrom` | `transferFrom(address from, address to, uint256 amount) returns (bool)` | | `approve` | `approve(address spender, uint256 amount) returns (bool)` | | `increaseAllowance` | `increaseAllowance(address spender, uint256 amount) returns (bool)` | | `decreaseAllowance` | `decreaseAllowance(address spender, uint256 amount) returns (bool)` | | `allowance` | `allowance(address owner, address spender) returns (uint256)` | | `permit` | `permit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)` | > APE decimals match the collateral token's decimals. Transfers to `address(0)` are not permitted. # Security The Fine Print: What Could Go Wrong? The SIR protocol empowers leveraged trading and liquidity provision, but it's not without risks. While built on robust foundations, potential vulnerabilities might remain: * **Smart Contract Bugs**: Despite being thoroughly audited by multiple independent security firms — see [Audits](/protocol-overview/user-risks/audits) — undiscovered bugs or exploits in SIR's smart contracts could lead to fund losses. These might stem from complex logic in vault mechanics or leverage calculations that audits failed to catch, exposing users to rare but critical failures. {% hint style="info" %} This risk is mitigated by [our beta period and gradual transition to a fully decentralized protocol](/protocol-overview/user-risks/beta-period), during which we can activate Emergency Mode or initiate a Shutdown to protect users if issues arise. {% endhint %} * **Third-Party Dependencies**: SIR relies on battle-tested on-chain DEXes for price data — Uniswap V3 on Ethereum, HyperSwap on HyperEVM, and Kumbaya on MegaETH. While these DEXes' established reliability minimizes concerns, any newly found vulnerability in their smart contracts could theoretically propagate to SIR, potentially disrupting operations or jeopardizing user funds. Though such risk is considered extremely low given the proven stability and track records of these platforms in the DeFi ecosystem. Below, we outline risks specific to leverage users ("Apes") and liquidity providers ("LPers"). ## Risks for Apes (Leverage Users) Apes use SIR to take leveraged positions via vaults. These come with the following risks: 1. **Leverage Peg Breakdown**\ If vaults reach [saturation](https://github.com/SIR-trading/SIR-gitbook/blob/main/protocol-overview/security-and-risks/liquidity-and-leverage/README.md) —where demand for leverage exceeds available liquidity— the target leverage ratio (e.g., `^2`) may falter. This can lead to reduced returns, and/or volatility decay. 2. **Volatility Decay in Saturation**\ SIR eliminates volatility decay on a best-effort basis by maintaining constant leverage within the [convex zone](https://github.com/SIR-trading/SIR-gitbook/blob/main/protocol-overview/security-and-risks/liquidity-and-leverage/README.md#the-limits-of-constant-leverage). However, when a vault enters the [saturation zone](https://github.com/SIR-trading/SIR-gitbook/blob/main/protocol-overview/security-and-risks/liquidity-and-leverage/README.md#the-saturation-zone) — where LP liquidity is insufficient to maintain constant leverage — the same buy-high-sell-low rebalancing dynamic seen in traditional leveraged tokens can occur. The deeper into saturation, the more pronounced the decay. This risk is mitigated by the protocol's [self-balancing convexity loop](/protocol-overview/readme/why-sir-matters#self-balancing-convexity), which incentivizes LP liquidity to keep the convex zone wide. {% hint style="info" %} SIR's convex payout structure means apes gain more on the upside and lose less on the downside compared to traditional perpetuals (*aka* perps) or margin leverage — provided the vault operates within the convex zone. {% endhint %} ## Risks for Liquidity Providers (LPers) LPers supply capital to SIR's pools, earning fees from minting and burning. Their risks include: 1. **Low Activity and Fee Drought**\ In periods of apathy, when apes aren't minting or burning, fee generation drops. This leaves LPers with idle capital and lower returns. {% hint style="info" %} However, [SIR's incentives](https://github.com/SIR-trading/SIR-gitbook/blob/main/protocol-overview/security-and-risks/sir-a-dividend-paying-token/README.md) to selected vaults can potentially offset this by providing a 2nd revenue stream. {% endhint %} 2. **Impermanent Loss (IL)**\ LPers may lose value compared to holding collateral assets when prices rise, but gain relative to holding debt tokens —and vice versa when prices fall. For unopinionated market participants, this dampens volatility rather than acting as a pure loss. # Audits SIR has been audited by multiple independent security firms. After the [March 2025 exploit](/protocol-overview/user-risks/exploit-and-relaunch), the protocol was rebuilt and subjected to four comprehensive audits before relaunching. ## MegaETH Launch Audit | Auditor | Scope | Report | | ---------------------------------------------------------------- | ------------------------- | ---------------------------------------------------------- | | [**Egis Security**](https://www.sir.trading/audits/egis-megaeth) | MegaETH deployment review | [View Report](https://www.sir.trading/audits/egis-megaeth) | ## Post-Relaunch Audits (Ethereum) These four audits were completed on the rewritten codebase before the protocol went live again: | Auditor | Scope | Report | | ---------------------------------------------------------------- | -------------------- | ------------------------------------------------------ | | [**Custodia Security**](https://www.sir.trading/audits/custodia) | Full protocol review | [View Report](https://www.sir.trading/audits/custodia) | | [**Egis Security**](https://www.sir.trading/audits/egis) | Full protocol review | [View Report](https://www.sir.trading/audits/egis) | | [**Syzygy**](https://www.sir.trading/audits/syzygy) | Full protocol review | [View Report](https://www.sir.trading/audits/syzygy) | | [**Guild Audits**](https://www.sir.trading/audits/guild) | Full protocol review | [View Report](https://www.sir.trading/audits/guild) | ## Pre-Exploit Audit (Historical) | Auditor | Scope | Report | | -------------------------------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------- | | [**Egis Security**](https://www.sir.trading/audits/egis-pre-exploit) | Original protocol audit (pre-March 2025) | [View Report](https://www.sir.trading/audits/egis-pre-exploit) | {% hint style="info" %} All audit reports are available at [sir.trading/audits](https://www.sir.trading/audits). {% endhint %} ## Ongoing Security Security is an ongoing commitment. In addition to audits, SIR maintains: * A [Bug Bounty](/protocol-overview/user-risks/bug-bounty) program rewarding high and critical vulnerability disclosures * A [Beta Period](/protocol-overview/user-risks/beta-period) with protocol state controls (Emergency Mode, Shutdown) as safety guardrails * Immutable, non-upgradable core contracts — once deployed, the code cannot be changed # Beta Period Towards a Secure and Immutable Protocol For the safety of its users, the protocol will launch in beta. The protocol has 4 distinct states: 1. **Unstoppable:** The ultimate state, marking the end of the beta period. Here, all parameters are fixed, leaving no room for adjustments. Transitioning to this state signifies that the protocol is fully operational and irreversible, with any persisting issues becoming permanent fixtures. This state is achieved exclusively from the Training Wheels state. 2. **Training Wheels:** The initial state during beta, where protocol fees can be modified. This flexibility is crucial for optimizing the fee structure based on real-world data and feedback. The protocol can revert to this state from Emergency but aims to advance to Unstoppable. 3. **Emergency:** Activated in response to detected bugs or exploits, this state allows for the suspension of new deposits (minting of TEA or APE) while permitting withdrawals (burning of TEA or APE). It's a containment measure designed to mitigate damage, accessible only from Training Wheels. 4. **Shutdown:** The final measure if issues identified in the Emergency state remain unresolved after 20 days. In Shutdown, the protocol enables the withdrawal of any funds left by the owner of the contract, safeguarding user assets. The 20-day waiting period is a safety net against potential misuse by the owner.

SIR protocol state transition diagram

# Bug Bounty ## Overview SIR is committed to the security of our protocol and users' funds. Following the March 2025 exploit and successful relaunch with four independent security audits, we continue to invite security researchers to help identify vulnerabilities in our core smart contracts through our bug bounty program. ## Scope The bug bounty program covers **high and critical severity vulnerabilities** in the SIR core contracts across all deployed chains (Ethereum, HyperEVM, and MegaETH). All verified contract addresses can be found in the [Deployments](/protocol-overview/deployments) section. **Bug Bounty Reward Address:** [`0x589F8D40370C9B5904f83B9C17815DDdB3eb6af9`](https://etherscan.io/address/0x589F8D40370C9B5904f83B9C17815DDdB3eb6af9) This address holds the SIR tokens allocated for bug bounty rewards, visible on-chain for transparency. ### In Scope * Core protocol contracts on all chains * Critical vulnerabilities that could lead to: * Loss of user funds * Protocol insolvency * Unauthorized access to privileged functions * Manipulation of core protocol mechanics ### Out of Scope * Frontend bugs * Third-party integrations * Already known issues * Issues in test contracts or deprecated contracts ## Severity Levels & Rewards The bug bounty address initially holds **20,000,000 SIR tokens**, with plans to add more SIR over time to ensure competitive rewards for security researchers. As the protocol's TVL and SIR token price appreciate, so does the value of the bounty reward. **Bounty Reward:** The full amount of SIR tokens held in the bug bounty address ### High/Critical Severity Eligible vulnerabilities include: * Direct theft of user funds * Permanent or temporary freezing of funds * Protocol insolvency * Theft of yield * Significant protocol manipulation * Unauthorized access to privileged functions High and critical severity vulnerabilities that meet the criteria will be rewarded with **the full amount of SIR tokens available in the bug bounty address**. ## Submission Process 1. **DO NOT** exploit the vulnerability on mainnet 2. Provide a detailed written description of the vulnerability 3. Include proof of concept code or steps to reproduce 4. Submit your findings privately via: * **Discord:** Xatarrer#0002 * **Email:** ## Rules & Guidelines * First reporter of a vulnerability receives the full bounty * Public disclosure before resolution disqualifies the submission * Provide sufficient detail for our team to reproduce and verify * Allow reasonable time for fixes to be implemented * Act in good faith and follow responsible disclosure practices ## Response Timeline * **Initial Response:** Within 48 hours * **Vulnerability Assessment:** Within 7 days * **Bounty Decision:** Within 14 days * **Payout:** Within 30 days of fix deployment ## Legal * No legal action will be taken against researchers acting in good faith * Researchers must comply with all applicable laws * Testing must be done on testnet or local forks only ## Contact For questions about the bug bounty program or to submit findings: * **Discord:** Xatarrer#0002 on our [Discord server](https://t.co/jFXfWEf9Rv) * **Email:** * **GitHub:** [SIR-trading](https://github.com/SIR-trading) *** *This bug bounty program may be updated at any time. Last updated: February 2026* # Exploit & Relaunch What Went Wrong, and What Comes Next ## Incident Overview On **March 30, 2025**, SIR Trading's vault was drained of its entire $355 K TVL when an attacker weaponized Ethereum's new **transient storage** (TSTORE/TLOAD) feature: 1. **Setup** * Attacker deployed a custom Uniswap V3 pool and initialized a vault in our Vault contract. * During `uniswapV3SwapCallback`, the transient storage slot at position 1 was used to verify the caller was a Uniswap pool, however by the end of the execution [that slot was overwritten](https://github.com/SIR-trading/Core/blob/ba212ea3a452b81752e82d5f2b2c55b897e0451d/src/Vault.sol#L300C13-L300C30) by `tstore(1, amount)`, leaving stale data. 2. **Vanity‐Address Exploit** * By brute‐forcing a **CREATE2** address whose numeric value equaled the forged `mintAmount`, the attacker passed our pool-address check. * They repeatedly invoked `uniswapV3SwapCallback`, siphoning all collateral through the compromised slot. 3. **Stolen Funds Trail** * Initial funds (0.3 ETH) came from Railgun. * Attack TX: [`0xa05f047ddfdad9126624c4496b5d4a59f961ee7c091e7b4e38cee86f1335736f`](https://etherscan.io/tx/0xa05f047ddfdad9126624c4496b5d4a59f961ee7c091e7b4e38cee86f1335736f) * Attacker: `0x27defcfa6498f957918f407ed8a58eba2884768c` {% hint style="warning" %} **Root cause:** our callback logic did not clear or re-validate the transient‐storage slot between operations, allowing a crafted value to masquerade as the pool address. {% endhint %} ## **Our Emergency Response** When the exploit hit, we sprang into action using our [protocol’s built-in safety guardrails](https://github.com/SIR-trading/SIR-gitbook/blob/main/protocol-overview/beta-period.md): 1. **Emergency Mode Activated**\ We suspended all new deposits to stop any further loss while still allowing users to withdraw their funds. 2. **Shutdown**\ After 20 days we have permanently locked the protocol to ensure nobody will ever use it. ## **Relaunch Complete** After the exploit, we took comprehensive steps to ensure the protocol's security: 1. **Four Security Audits Completed**\ We successfully completed four thorough security audits. All audit reports are available at . 2. **Protocol is Live Again**\ SIR Trading has been successfully relaunched and is now live at . The protocol has been rebuilt with enhanced security measures and thoroughly vetted by multiple independent auditors to ensure the safety of user funds.