# Catalysis Network > Unified Access to ETH, BTC & SOL-backed Economic Security. Official documentation for the Catalysis network, cover pools, stakeholders, node operators, and integration guides. Complete documentation bundle for Catalysis Network following the llmstxt.org standard. This file contains all documentation content in a single document for AI agents and LLMs. Use it for comprehensive context when answering questions about Catalysis. Sections: Introduction, Cover Pools, Stakeholders, Catalysis Core (Network, Node Operators, Restaking Protocols), Mainnet Contracts, Audits, Resources, Glossary. Site: https://docs.catalysis.network ## DeFi Vaults DeFi vault protocols are where coverage becomes a product users can actually choose. They expose **Covered Vaults** (opt-in coverage) alongside **Base Vaults** (no coverage), so premiums and claims are handled within the vault lifecycle. Vault protocols like **[Morpho](https://morpho.org/)** are the **integration surface** for users. They host the vaults representing the underlying strategy/exposure (often curated by groups like **[Gauntlet](https://www.gauntlet.xyz/)** & **[Steakhouse Financial](https://www.steakhouse.financial/)**). ## Base Vault vs Covered Vault --- 1. **Base Vault (Unchanged)**: **The original vault remains fully intact** — same strategy, same TVL, same APY. No coverage logic, capital or risk is imposed on existing LPs. 2. **Covered Vault (Opt-In Layer)**: A separate vault for LPs who want protection. **Deposits are routed 1:1 into the Base Vault**. In exchange for coverage, LPs accept a **small APY haircut** and receive partial principal protection up to the covered amount. 3. **CoverPool (Risk Capital Layer)**: **Each covered vault is paired with a dedicated CoverPool** funded by restaked capital. This pool acts as the onchain source of protection capital. ## FAQs ### Q1. What is a Covered Vault? A **Covered Vault** is an **[ERC4626](https://docs.openzeppelin.com/contracts/4.x/erc4626)-compliant vault** deployed by Catalysis that wraps an existing DeFi vault (the "**Base Vault**") with per-user risk coverage. Depositors in a Covered Vault get the same yield exposure as the Base Vault, minus a small premium haircut — in exchange for **protection against principal loss**. ### Q2. Where does a Covered Vault live — on the vault protocol or on Catalysis? The Covered Vault is a **[Catalysis contract](https://catalysis.network)**. It wraps the Base Vault (which lives on **[Morpho](https://morpho.org)**, **[Euler](https://euler.finance)**, or another supported protocol), but the **coverage accounting** — PPS tracking, shortfall calculations, premium haircuts — all happens at the Catalysis layer. **All deposits are automatically routed to the underlying Base Vault**. The vault position earns yield inside the Base Vault, but the coverage logic sits entirely within the Covered Vault contract. ### Q3. Is the Covered Vault a different strategy than the Base Vault? **No**. The Covered Vault routes all deposits into the paired Base Vault, so the **yield exposure is identical**. The difference is the coverage layer — **Covered Vault depositors pay a small premium haircut** on their yield in exchange for protection against principal loss from covered events. ### Q4. What happens when coverage expires? **Coverage periods have a fixed duration (e.g., 90 days)** starting from when the Coverpool is fully activated — not from the date the covered vault is deployed. **Upon expiry, the Covered Vault is no longer insured and functions equivalently to the Base Vault**. Depositors can withdraw at any time. If coverage is renewed, a new period begins after a brief transition window (typically 24–48 hours). If renewal doesn't happen, depositors who stay in the Covered Vault continue earning the Base Vault's full yield (no premium haircut, since there is no active coverage to pay for). ### Q5. What is the premium haircut? The premium haircut is a small percentage of yield deducted as a coverage premium. It is set by the **Catalysis underwriting engine** using real-time risk data from the **[Credora](https://www.credora.network/)** API (vault rating, probability of shortfall loss, expected loss, etc.). ``` Net Covered Vault APY = Base Vault APY − Premium Haircut ``` For example, if the Base Vault yields 5% APY and the haircut is 75 bps (0.75%), the depositor's net APY is **4.25%**. **Haircuts are vault-specific** and can adjust dynamically if a vault's risk profile changes — though for highly-rated (A-rated) vaults, they tend to be stable. ### Q6. What is the deductible? **The deductible is a per-user loss threshold below which coverage does not pay out**. It functions like a standard insurance deductible — it absorbs small fluctuations and ensures payouts only occur for meaningful losses and not for common idiosyncratic losses. For example, with a 1% deductible on a $1M deposit, the first $10,000 of any shortfall is absorbed by the user. Coverage pays out on any shortfall above that. ### Q7. What events are covered? Coverage applies whenever the Base Vault's PPS (**Price-Per-Share**) declines below a user's deposit PPS. The primary causes of this are: - **Smart contract exploits / hacks** — vulnerabilities in the Base Vault or its underlying strategies - **Bad debt** — unrecoverable losses from undercollateralized or insolvent positions within the Base Vault's lending markets - **Curator errors** — misallocation or operational mistakes by the vault curator - **Strategy failures** — breakdown of yield strategies that leads to principal loss **What's not covered:** market drawdowns, impermanent loss, or reduced yield that does not result in PPS falling below the user's deposit PPS. ### Q8. Is there a lock-up period for depositors? **No**. Covered Vault depositors can withdraw at any time during the active coverage period, subject to the TVL cap. **There is no lock-up**. ### Q9. What is the TVL cap? **The TVL cap is the maximum aggregate deposits the Covered Vault will accept**. It is determined by the size of the Coverpool (underwriting capital) and the vault's tail-risk profile as assessed by the Catalysis underwriting engine. For example, if a vault's worst-case loss probability is 10%, then $1M in the Coverpool can back up to $10M in the Covered Vault (a 10x ratio). The TVL cap scales proportionally as more underwriting capital is delegated. ### Q10. How does coverage actually work? **Coverage is per-user and triggers automatically when a depositor withdraws**. There is no separate claims process, no oracle, no governance vote. At withdrawal, the Covered Vault contract: 1. *Looks up the user's **Price Per Share (PPS)** at the time of deposit* 2. *Compares it to the current PPS from the Base Vault* 3. *If the current PPS is lower, a shortfall exists* 4. *Applies the deductible — coverage only pays out if the shortfall exceeds it* 5. *Slashes the net coverage amount from EigenLayer Duration vaults* 6. *Delivers the current vault value + coverage payout to the user* **From the user's perspective, they simply withdraw and receive their principal back (minus the deductible)**. The mechanics are transparent to them. ### Q11. Who sets the parameters for a Covered Vault? Parameters are set by the **admin** (the Catalysis core team or an authorized curator) at deployment: | Parameter | Set by | |---|---| | Base Vault address | Admin at deployment | | Coverage duration | Admin at deployment | | Deductible | Admin at deployment | | TVL cap | Underwriting engine (scales with Coverpool) | | Premium haircut | Underwriting engine (dynamic, Credora-powered) | Curators cannot modify the premium haircut or TVL cap after deployment — those are controlled exclusively by the Catalysis underwriting engine. --- ## Delegators Delegators supply the capital that backs Catalysis **CoverPools**. In return, they earn **coverage fees (premiums)** while taking on well-defined loss risks. They are the **capacity providers** of the system: - Their capital is the source of underwriting capacity. - CoverPools use that capacity to offer protection to **Covered Vaults**. ## Visualization ## Risk Design Catalysis is designed to **minimize tail risk** for restakers through **strict vault selection, disciplined underwriting and capped downside exposure**. 1. **Tier-1 DeFi vault eligibility**: Coverage is intentionally limited to **ONLY A-rated vaults** curated by **[Gauntlet](https://www.gauntlet.xyz/)** and **[Steakhouse Financial](https://www.steakhouse.financial/)** on Tier-1 protocols such as **[Morpho](https://morpho.org/)**. 2. **Quantitative underwriting**: Vault eligibility and pricing are informed by our robust underwriting engine across **curator quality, protocol risk and asset profile**. 3. **Capped loss scenarios**: Historical data indicates a **<1% chance** of a qualifying vault triggering the maximum payout (e.g., 10% of TVL). ## How Delegators Earn Delegators generally earn a blend of: 1. **Coverage fees (Base APY)**: Premiums paid by **Covered Vault** depositors 2. **Native Staking Rewards (Optional)**: Native ETH staking APY for ETH LSTs (say **$cbETH**) 3. **Restaking Rewards**: Incentives from the underlying restaking layer (say **$EIGEN**) 4. **Catalysis Incentives**: Protocol incentives (**wherever applicable**) ## FAQs ### **Q1. Is Catalysis legally “insurance”?** **NO. Catalysis is not an insurer and does not provide insurance or reinsurance services.** Catalysis provides native onchain risk coverage infrastructure, where: - Terms are transparent and programmatic - Capital providers knowingly take on defined risk - Payouts follow pre-specified smart-contract based rules For more details, please visit our [T&Cs page](https://catalysis.network/t-and-c). ### **Q2. Can delegators lose principal?** **YES.** If a covered trigger occurs, the CoverPool pays out according to its terms. Those payouts can reduce the capital backing the pool (and therefore delegator principal). ### **Q3. What drives my realized returns over time?** Returns generally depend on: - **CoverPool utilization:** How much capacity is actively underwriting - **Premium rates:** Risk-calibrated pricing - **Claims frequency:** How often payout events trigger (**highly unlikely**) ### **Q4. Can I withdraw or reallocate?** Typically, capital allocated to a CoverPool is **locked for a fixed duration (typically ~90 days)**. Depending on the configuration, Catalysis can support **Early withdrawals** (with constraints) or **Withdrawal restrictions** while capacity is actively underwriting. ### **Q5. What types of risks are covered by Catalysis CoverPools?** Coverage is **vault-level and risk-specific**, not protocol-wide. Depending on the vault configuration, covered risks may include: 1. **Curator Risk** – mispricing, parameter misconfiguration, or strategy failure. 2. **Asset-Level Risk** – sudden de-peg, extreme volatility, or collateral impairment. 3. **Bad-Debt Risk** – borrower default, oracle error, or collateral shortfall. 4. **Smart Contract Risk** – vulnerability in vault, Morpho, or token contracts. Each CoverPool explicitly defines what is covered and what is excluded. Delegators should always review the coverpool’s risk specification before allocating. ### **Q6. What should I evaluate before allocating to a CoverPool?** Focus on the pool’s risk boundary and economics: - What events are covered (and explicitly not covered) - Payout limits / maximum loss and how payouts execute - Premium rate assumptions and expected utilization - Any timing constraints (allocation windows, withdrawal rules, cooldowns) ### **Q7. How are payouts calculated if a loss event occurs?** **Payouts are proportional to the loss amount, not binary**. - **Losses are assessed per depositor**, based on changes in the vault’s price per share between deposit and withdrawal. If the price per share at withdrawal is lower than at deposit, the difference is treated as a qualifying loss. - Example: If a depositor enters when 1 share = $1.00 and exits when 1 share = $0.90, the $0.10 difference represents a loss eligible for coverage. For example, **for A-rated Morpho vaults, the maximum payout may be capped at up to 10% of vault TVL, with historical data indicating a very low probability (<1%) of reaching that cap**. ### **Q8. Are losses isolated between different CoverPools?** **YES.** All CoverPools are fully isolated: - Each DeFi vault is paired with its own CoverPool - Losses in one coverpool do not affect other pools (isolated) - There is no shared global pool **(we don’t normalize losses)** This **modular isolation model is intentional** and designed to limit contagion risk. ### **Q9. Who decides which vaults are eligible for coverage?** **Vault eligibility is strictly controlled.** This is currently decided by the **Catalysis Core team**. As we progressively decentralize the protocol, it will be decided by future governance proposals. Eligibility is determined using: - Internal quantitative underwriting models - Curator quality and track record - Protocol risk, asset profile, and historical behavior **Lower-tier or experimental vaults are intentionally excluded during the initial launch phase**. Currently, coverage is limited to only A-rated vaults curated by **Steakhouse Financial and Gauntlet** on Tier-1 DeFi protocols (e.g., **Morpho**) ### **Q10. How is risk monitored over time?** **Risk monitoring is continuous.** - Our underwriting engine parameters are updated with live vault and protocol data - External risk signals and ratings are sourced from **[Credora](https://www.credora.network/)** (via [RedStone](https://www.redstone.finance/)) - Real-time security monitoring is supported by partners such as **[Guardrail](https://www.guardrail.ai/)** and **[Hypernative](https://www.hypernative.io/)** If risk conditions deteriorate materially, new coverage issuance can be paused or repriced. ### **Q11. Is claims resolution fully automated?** Claims resolution is **FULLY AUTOMATED** in the current phase: - Determined by pre-defined smart contract logic - Triggers are programmatically detectable and onchain - There is currently no discretionary governance veto over valid claims - Some edge cases may rely on oracle inputs or offchain verification **The system is designed to move toward a hybrid resolution** as coverage limits scale and governance is in place. ### **Q12. What assets do delegators earn rewards in?** **Delegators earn in the same collateral/asset type as the underwriting capital** they are delegating. Depending on the CoverPool: - Coverage premiums (often in the vault’s base asset or stablecoins) - Restaking rewards from the underlying restaking layer (e.g., EigenLayer) - Catalysis protocol incentives, where applicable **Currently, we don’t support transfers like USDC to ETH since we want to ensure asset liability matching**. But, rewards can be in **$WETH** for **$wstETH** underwriting capital (same base asset conversion). We’ll support more kinds of reward tokens (say **$USDC, $USDT**) in the future. ### **Q13. Can I choose different risk-reward profiles?** **YES.** Catalysis supports multiple CoverPools with different characteristics: - Lower-risk pools backing top-tier vaults with conservative payout caps - Higher-yield pools with higher utilization or broader coverage scope **Delegators can allocate capital across Coverpools based on their risk appetite.** ### **Q14. How long is my capital locked?** CoverPools typically operate with **fixed allocation periods, commonly around 90 days**. But it depends on the specific configuration of CoverPools and the risk reward metrics. ### **Q15. What is the current stage of the protocol?** **Catalysis is currently in a controlled mainnet rollout phase**. It is launching on **Ethereum mainnet** in **[early Q2 2026](https://x.com/0xcatalysis).** For this launch, coverage is limited to top-tier vaults, risk parameters are conservative and scale is intentionally capped. This approach prioritizes correctness and confidence before expanding to other DeFi vaults / protocols. ### **Q16. Why should restakers participate early?** Early participation allows restakers to: - Back one of the first **revenue-generating AVSs** supported by real economic activity - Earn **premium-driven yield** while underwriting the next wave of DeFi adoption - Gain exposure to **high-quality Covered Vaults** with disciplined underwriting - Earn **early catalysis protocol incentives** (where applicable) Catalysis is a first-of-its-kind AVS bringing **vault-native risk coverage** onto restaking rails. This is not incremental — it’s a step-function unlock. ### **Q17. Do you rehypothecate restaker capital?** **NO.** At the current stage, **capital allocated to a CoverPool is not rehypothecated or reused elsewhere**. It’s used 1:1. Capital is only used as underwriting capacity for the specific risks defined by that coverpool. We intentionally avoid rehypothecation today because it introduces **additional layers of correlation and tail risk**, which is not appropriate during an early, controlled rollout. In the future, we may explore underwriting **fully uncorrelated markets** (e.g., RWAs or real-world insurance risks) — but only once the system has matured and risk isolation can be preserved. ### **Q18. Is there real demand for onchain coverage at scale?** **YES. ABSOLUTELY.** - As DeFi and stablecoins go mainstream, major crypto and fintech platforms are launching structured earn products at scale, signaling sustained demand for risk-managed yield. - Products like **[Coinbase Earn](https://www.coinbase.com/en-gb/earn)** and **[Kraken’s vaults with Veda](https://x.com/krakenfx/status/2015809818661970210?s=20)** show that users (**retail and institutional**) want yield that is **risk-adjusted, not just higher APY**. - Institutional allocators **cannot deploy meaningful size without clear downside protection**, a behavior long established in TradFi where lower yield is accepted in exchange for risk mitigation. - Existing coverage markets already indicate **$50M–$100M of coverage demand per Tier-1 protocol like Morpho**, revealing a clear supply gap that covered vaults can unlock natively and efficiently. ### **Q19. When does my delegation start earning premiums?** **Day 1.** - Premium APR is **dynamic** and determined by supply/demand: **coverage demand** vs **available underwriting capacity**. - Premiums typically scale as **Covered Vault TVL** grows and **CoverPool utilization** increases. - In parallel, restakers may continue earning **restaking-layer rewards** (e.g., EigenLayer) and **Catalysis incentives** (where applicable). ### **Q20. When does slashing activate?** **Day 1.** Once your capital is locked for the specified duration, it becomes **slashable** under the pool’s **pre-defined coverage conditions**. ### **Q21: What happens if Catalysis contracts have a bug?** Catalysis contracts are audited by Tier-1 auditors including **[Certora](https://www.certora.com/)** and **[Sigma Prime](https://sigmaprime.io/)**. See the full list of published reports on the **[Audits](/docs/audits/)** page. **That said, smart contract risk is never zero — even Aave is not immune**. If a bug is identified in our contracts, we will fix it promptly and deploy a new audited version via our **upgradeable contract architecture**. In the event a bug is exploited before discovery, we have guardrails in place to **pause the contracts** while we identify and remediate the issue. This is why we are launching coverage conservatively and scaling gradually. ### **Q22: Is the coverage non-custodial? Do you ever take custody of funds?** **NO.** **Catalysis never takes custody of funds.** Underwriting capital remains **custodied in the underlying restaking layer (e.g., EigenLayer)** and is referenced by Catalysis core contracts for underwriting and enforcement logic. Premium and payout flows are executed onchain into the underlying DeFi vault protocol (e.g., Morpho) according to protocol-defined rules. ### **Q23: Is this correlated with EigenLayer AVS slashing risks?** **NO**. **IT HAS ZERO CORRELATION WITH AVS SLASHING RISKS.** Coverage risk is separate from EigenLayer AVS slashing. Losses only occur from economic underwriting events, not validator misbehavior or uptime faults. Catalysis does not rehypothecate stake, underwriting capital is used on a strict 1:1 basis and remains uniquely allocated. ### **Q24: How is this different from Nexus Mutual?** | **Dimension** | Catalysis Coverage | Nexus Mutual | | --- | --- | --- | | **Product** | **Vault-native** risk coverage infrastructure | **Discretionary** onchain insurance mutual | | **Coverage UX** | Embedded **natively inside DeFi vaults** as a first-class primitive | External cover **purchased separately** as a standalone product | | **Underwriting** | **Transparent**, smart contract based model using onchain data with Credora risk ratings; **no discretionary underwriting** | **Discretionary underwriting** by members; opaque capital allocation and offchain claim assessment | | **Pricing** | **Risk-aware**, vault-level pricing driven by Catalysis underwriting engine; **typically 4–5× cheaper** for Tier-1 and A/B-rated vaults | Utilization-based pricing with discretionary parameters; often **materially more expensive** for comparable risk | | **Settlement** | **Programmable, onchain settlement**; DeFi vault-native infrastructure built to scale with institutional vault distribution | **Manual claims process, slower settlement**; legacy insurance logic not designed as vault infrastructure | --- ## Integration Partners Integration partners are **frontends, aggregators and earn platforms** that help users discover and access **Covered Vaults** through familiar experiences — without forcing an external “buy coverage” workflow. They are the **distribution layer** for Catalysis: - They surface covered opportunities where users already allocate capital. - They route deposits into Covered Vaults via standard UX flows and secure vault integrations. ## Visualization --- ## What Catalysis enables 1. **Native integration**: Coverage **integrates directly** with vaults on existing Tier-1 DeFi protocols (Morpho, Euler, Upshift etc). 2. **Competitive Pricing**: Depositors access downside protection with minimal impact on net vault APY. **Typically 25–75 bps, depending on DeFi vault rating.¹** 3. **Fully onchain and transparent**: Coverage terms and payouts are enforced by smart contracts and executed **without manual intervention or committee discretion**. 4. **Opt-in coverage**: Platforms can offer coverage as an opt-in upgrade. Existing vaults and yields remain unchanged, **only users who want protection opt in**. ## FAQs ### Q1. What does the integration process look like for a distribution partner? Integration is straightforward: 1. **UI surfacing**: list **Covered Vaults** alongside **Base Vaults**, and show premium cost + coverage summary. 2. **Routing**: update your deposit/withdraw flows to route to the **Covered Vault** contracts (instead of the Base Vault) when users opt in. 3. **Smart contract hookup (optional)**: if you use routers/bundlers, add the Covered Vault calls to your existing route so the end state is a standard onchain vault position. ### Q2. Is it time-consuming? Typically **NO**. - Most partners ship in **< 2 weeks** (UI + routing + basic checks). - With deeper testing, edge cases and staging cycles, it can take **~3 weeks**. ### Q3. What’s in it for distribution partners? - **Differentiated product**: “covered yield” is a clear upgrade vs standard vault listings. - **Seamless UX**: users opt into protection inside the same vault flow — no external policy step. - **Competitive rates**: users get access to risk coverage at low premium impact on net APY (risk-calibrated). - **Better stickiness**: protection reduces perceived downside, which can improve retention and larger allocations. ### Q4. What’s the most important thing to communicate in the UI? Make the covered vs base choice obvious and comparable: - **Premium cost** (bps or estimated net yield impact) - **Coverage scope** (what is covered / not covered, in plain language) - Key **limits & conditions** (e.g., max coverage capacity, trigger conditions, any relevant constraints) A good default is: **“Base = higher yield, no protection. Covered = slightly lower yield, defined protection.”** ### Q5. What are integration partners not responsible for? - **Pricing or underwriting** (handled by Catalysis + CoverPools) - **Claims decisions or execution** (defined by coverage terms and executed by the system) --- ## Overview **The Catalysis Network coordinates a set of stakeholders that collectively enable onchain, vault-native risk coverage**. Capital allocators supply **underwriting capacity** via restaking protocols, Catalysis structures that capacity into **CoverPools** and DeFi vault protocols expose **Covered Vaults** where premiums and claims are handled at the vault layer. **Integration partners** then distribute these **Covered Vaults** through familiar frontends, **making coverage accessible without adding a separate "external" workflow for users**. ## Visualization ## Key terms - **CoverPool**: A risk-isolated underwriting pool funded by delegator capital. It receives premiums and pays claims when triggered. - **Base Vault**: Standard vault exposure (no coverage). - **Covered Vault**: Vault exposure with an embedded coverage mechanism (premiums + claim crediting handled at the vault layer). - **Adapter**: Integration module that connects Catalysis coverage logic to a specific vault protocol implementation. ## Key Stakeholders | **#** | **Stakeholder** | **Description** | | --- | --- | --- | | **1** | **Delegator (Restaker / LRT)** | - Supplies capital that back CoverPools (**Capacity Providers**)- **Earns yields** in exchange for bearing loss risk- May participate directly or via LRTs and vault curators | | **2** | **Restaking Protocol (EigenLayer)** | - **Custodies and tracks restaked collateral**; enforces slashing / reward distribution- Serves as the **coordination layer** between Catalysis and restakers | | **3** | **Catalysis** | - Smart-contract-based **risk coverage infrastructure** that creates and manages **CoverPools**- **Calculates risk premiums** and provides **vault-native integration** via custom adapters (e.g., Morpho Adapter) | | **4** | **DeFi Protocols (Vault-Based)** | - Vault infrastructure where **coverage is embedded as an opt-in** **Covered Vault** alongside a **Base Vault** (e.g., Morpho)- Defines the **vault-level integration surface** for premiums, claims and accounting via adapters | | **5** | **Integration Partners (Distribution)** | - **Frontends and aggregators that surface Covered Vaults to depositors** and route deposits (e.g., **Superform, Jumper Earn**)- Distribute covered vault opportunities to users without requiring an **external “coverage workflow”** | | **6** | **Covered Vault Depositors (End Users)** | - **Institutions and retail** that opt into coverage via an integration partner **(UI / earn platform)**- Deposit into **Covered Vaults** and pay premiums as a **net APY haircut** - Receive **downside protection** when covered loss triggers occur | --- ## Restaking Protocols Restaking protocols are the infrastructure layer that **custodies and tracks restaked collateral** and provides the **enforcement rails (rewards + slashing)** that underwriting capacity is built on. They act as the **coordination layer** between delegators and Catalysis: - They **custody restaked assets** and expose verifiable accounting of who has delegated what. - They enforce protocol-defined rules for **reward distribution** and **slashing**, which Catalysis can use as **enforcement primitives for underwriting**. - They provide the **delegation primitives** that let capital be allocated toward different underwriting configurations (e.g., **CoverPools**). ## Visualization --- ## FAQs ### **Q1. Which restaking protocols does Catalysis support today?** **Currently:** **[EigenLayer](https://www.eigencloud.xyz/)** and **[Symbiotic](https://symbiotic.fi/)** (both on **Ethereum Mainnet**). Support is implemented via protocol-specific integrations and can expand to additional **restaking and liquidity layers** over time. ### **Q2. Does the restaking protocol take a cut of rewards?** It depends on the restaking layer (and sometimes the LRT / curator you use). Some protocols apply **protocol-defined fees or reward splits** on AVS reward flows (e.g: **[EigenLayer charges 20% fees](https://x.com/eigencloud/status/2016386803062997049?s=20)**). **Catalysis does not control these fees** — partners should refer to the restaking protocol’s latest fee model. ### **Q3. Can delegators choose any supported restaking protocol?** **Yes. Delegators can restake via any supported restaking layer.** Catalysis is designed to utilize underwriting capacity across multiple restaking protocols **in parallel** (capacity remains accounted for within each underlying restaking layer). ### **Q4. Can Catalysis coverage work without a restaking layer?** **In principle, YES**. But it would require rebuilding the same primitives from scratch (collateral accounting, delegation, rewards distribution and slashing guarantees). Using established restaking protocols allows Catalysis to **leverage hardened infrastructure and existing liquidity**, which significantly **accelerates go-to-market**. ## FAQs - Caps, Duration & Incentives ### **Q1: What exactly are delegation caps?** **Delegation Caps** represent phased increases in underwriting capacity. Each cap introduces one or more new **duration-based vaults**, each with a defined size, duration and incentive structure. The Catalysis roadmap currently has **three caps spanning Q1 to Q3 2026**. ### **Q2: Do early restakers earn meaningfully higher returns?** **YES**. Delegators participating in early caps benefit from higher incentives, resulting in meaningfully higher **risk-adjusted returns**. ### **Q3: Is the cap per vault, per CoverPool or global?** **No, Caps are not per vault or per Coverpool.** Each cap generally supports multiple vaults or coverpools depending on the coverage demand and business requirements. ### **Q4: Can caps be increased mid-duration?** **NO**. Once a cap is filled, capital is locked for the full duration of that vault. **New capacity is added only via a new cap.** ### **Q5: Who decides when a new cap is opened?** **The Catalysis Core team** decides the terms and conditions of opening up a new cap. Each new cap increases the overall coverage limit and is opened based on demand, risk appetite and operational readiness. ### **Q6: Can I delegate to multiple caps at the same time?** **NO**. Each cap corresponds to a separate duration-based vault. Capital must be withdrawn from one vault before redeploying into another. ### **Q7: If I've delegated to Cap 1, what happens when the duration ends?** **Withdrawals open at maturity.** You can withdraw your capital or redeploy it into new vaults in the subsequent caps with updated parameters and incentives. ### **Q8: How long do incentives last within a single cap?** Incentives for each cap are designed to last approximately **one full calendar year**. ### **Q9: What incentives apply in each cap?** Each cap may have different **restaking and protocol incentives ($EIGEN, $CAT)**. As a result, the risk-reward profile and APR vary across caps. --- ## Introduction ## What is a Network? A Network in the Catalysis ecosystem refers to any decentralized protocol that provides custom verification mechanisms of off-chain operations. A Network is composed of on-chain contracts for verification and an off-chain network of Operators. The off-chain part consists of client software run by network operators and network-specific validation logic. Operators execute the service on behalf of the Network and then post evidence of their execution on-chain to the Network contracts. Operators play a critical role in ensuring network integrity: - If the Operators perform tasks properly, the Network can distribute rewards. - If the Operators perform tasks maliciously, their delegate stake can be slashed by the Network. Different restaking ecosystems have different names for these Networks: - [EigenLayer](https://www.eigenlayer.xyz/): Autonomous Verifiable Service **(AVS)** - [Symbiotic](https://www.symbiotic.fi/): **Network** - [Satlayer](https://www.satlayer.xyz/): Bitcoin Validated Service **(BVS)** - [Jito](https://www.jito.network/restaking/): Node Consensus Network **(NCN)** - [Kernel](https://kerneldao.com/): Dynamic Validation Network **(DVN)** ## Why Build a Network? Launching new decentralized infrastructure networks requires substantial time and effort to bootstrap capital and operators. Builders should focus on their core product differentiators rather than bootstrapping economic security. Shared security allows developers to "rent" economic security from larger PoS chains like Ethereum, Bitcoin, and Solana. This allows them to focus more on their product’s core value and innovation without the significant overhead of setting up a new consensus mechanism or validator networks from scratch. The key benefits of building a Network that leverages shared security include: - **Security via Restaking**: Leverage restaking mechanism using a variety of assets to secure your Network. - **Focus on your project's unique value**: Spend less time and resources accumulating economic security from scratch. - **Bootstrap your Operator network**: Quickly access a large network of experienced Operators. - **Decentralization and Trust**: Build on trust-minimized, decentralized infrastructure. ## Why Should Networks build on Catalysis? For SSN teams, Catalysis abstraction layer offers unparalleled **flexibility** and **efficiency**. We allow for the creation of “*partial SSNs”* that can operate across multiple restaking platforms, enabling, for the first time, market-wide **price discovery** for economic security. This approach — what we call a “*multi-planetary*” model of shared security — ensures that SSNs aren’t tied to a single restaking protocol. Instead, they can leverage the best features of each platform, optimizing both their security and resiliency. Catalysis also offers a **flexible framework** for developers, giving them the tools they need to experiment with different security configurations and find what works best for their needs. **We provide the infrastructure; while SSN teams bring the innovation.** ## What Networks Can Be Built on Catalysis? The scope of Network design is broad. The Catalysis Network supports a wide range of decentralized services - any off-chain computation that can be verified on-chain. This flexibility allows developers to create custom verification mechanisms tailored to their specific use cases. The only requirement is that evidence of off-chain execution must be posted on-chain to enable verification. Example Use Cases: - **Rollups** → Secure L2 scaling solutions. - **Data Availability Networks** → Ensure reliable, censorship-resistant data storage. - **Decentralized AI** → On-chain verification of AI models and inference. - **Prediction Markets** → Trust-minimized markets to predict outcomes. - **ZK-Verifiable Networks** → Off-chain computation verified with zero-knowledge proofs. - **Decentralized Stablecoins** → Algorithmic and collateral-backed stable assets secured via shared security. - **And More** → Any service that requires trustless on-chain verification. ## Summary of Benefits 1. **Dynamic Rebalancing**: SSNs can dynamically rebalance economic security in real-time across multiple restaking platforms, ensuring optimal performance and cost-effectiveness. 2. **Native Rewards**: SSNs can natively distribute rewards to restakers on any platform where economic security is sourced — eliminating the need for cross-chain transfers or bridging. 3. **Enhanced Buying Power**: By aggregating demand across SSNs, Catalysis enhances buying power, fostering competition among restaking protocols. This leads to better pricing for SSNs. 4. **Unified Interface**: SSN teams can access multiple pools of economic security through a single, unified interface, simplifying the complexity of managing multi-platform operations. 5. **Robust Security**: SSNs built with Catalysis are more resilient against cascading slashings and the migration of restaked assets, offering stronger protection. 6. **Enhanced Developer Experience (DevEx)**: Our Catalyst-SDK streamlines the process of building **universal, robust SSNs**, saving time and reducing duplication of efforts. --- ## Quickstart This quickstart guide walks you through using the **Lumos CLI** to build and deploy an SSN (Shared Security Network) on Catalysis Network. We'll use the official Docker image to simplify setup and ensure consistency across environments. :::info Access Required **To use the Lumos CLI and Catalysis Core, you need to contact the Catalysis team for access.** The Lumos CLI Docker image is currently private and requires proper authentication to pull and use. 📧 **Contact**: [yanshu@catalysis.network](mailto:team@catalysis.network) or reach out via [telegram](https://t.me/xyanshu) to request access. ::: ## Prerequisites Before starting, ensure you have: - **Docker** installed and running - **Access to an Ethereum testnet** (Sepolia, Holesky, Hoodi) with testnet ETH - **RPC endpoint** for your chosen network - **Basic understanding** of blockchain concepts ## Docker Setup We'll use the official Lumos CLI Docker image: {`# Pull the latest image docker pull ghcr.io/0xcatalysis/lumos-cli:v0.2.0 # Create an alias for easier usage alias lumos="docker run --rm -v \\$(pwd):/workspace -v \\$HOME/.catalyst:/root/.catalyst ghcr.io/0xcatalysis/lumos-cli:v0.2.0"`} The volume mounts ensure: - `-v $(pwd):/workspace`: Current directory is accessible for config files - `-v $HOME/.catalyst:/root/.catalyst`: Key storage persists between commands ## Phase 1: Setup & Key Management ### Step 1: Generate Cryptographic Keys Your SSN needs three types of keys for different operations: {`# Generate all keys at once (recommended) lumos key generate-all \\ --task-signing-key-type ecdsa \\ --passphrase-file /workspace/passphrase.txt # OR generate keys individually lumos key generate --name p2p_key --type ecdsa --passphrase-file /workspace/passphrase.txt lumos key generate --name submitter_key --type ecdsa --passphrase-file /workspace/passphrase.txt lumos key generate --name task_signing_key --type ecdsa --passphrase-file /workspace/passphrase.txt`} **Key Types:** - **P2P Key**: For peer-to-peer communication between nodes - **Submitter Key**: For signing and submitting transactions on-chain - **Task Signing Key**: For signing task results and attestations **Key Generation Options:** - `--type`: `ecdsa` or `bls` (ECDSA recommended for most use cases) - `--passphrase-file`: Path to file containing passphrase (more secure than interactive input) - `--key-dir`: Custom directory for key storage (default: `~/.catalyst`) ### Step 2: List and Verify Keys {`# List all generated keys lumos key list # Import existing keys if needed lumos key import \\ --name existing_key \\ --passphrase-file /workspace/passphrase.txt \\ --private-key-file /workspace/private_key.txt`} ## Phase 2: Network Deployment ### Step 3: Register Your Network Deploy the core smart contracts for your SSN: {`lumos network register \\ --name "MyAwesomeSSN" \\ --metadata "https://myssn.com/metadata.json" \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID" \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --output-file /workspace/network_config.json`} **Required Parameters:** - `--name`: Human-readable name for your network - `--metadata`: URL to metadata JSON describing your SSN - `--rpc-url`: Ethereum RPC endpoint for contract deployment - `--private-key-name`: Name of key for transaction signing - `--output-file`: Path to save network configuration (contains contract addresses) **What This Does:** - Deploys `NetworkManager`, `StakeManager`, and `TaskManager` contracts - Registers your SSN on-chain - Outputs contract addresses and configuration to JSON file ### Step 4: Configure Network Assets (Vaults) Add vaults that provide economic security to your network: {`# Add a vault to committee 0 lumos network add-vault \\ --output-file /workspace/network_config.json \\ --vault-address "0x742d35Cc6634C0532925a3b8D3Ac3C3A8D3Ce0C4" \\ --committee-id 0 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID" # Set maximum network limit for the vault lumos network set-max-limit \\ --output-file /workspace/network_config.json \\ --vault-address "0x742d35Cc6634C0532925a3b8D3Ac3C3A8D3Ce0C4" \\ --committee-id 0 \\ --amount 1000000000000000000 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID"`} **Vault Configuration:** - **Vault Address**: Address of the restaking vault (from Symbiotic, EigenLayer, etc.) - **Committee ID**: Numeric identifier for the committee (start with 0) - **Amount**: Maximum stake limit in wei (18 decimal places for ETH) ### Step 5: Configure Task Types Define the types of tasks your SSN will handle: {`# Set task type for committee 0 lumos network set-task-type \\ --output-file /workspace/network_config.json \\ --committee-id 0 \\ --task-type 1 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID" # Set task majority threshold (e.g., 67% = 6700) lumos network set-task-majority \\ --output-file /workspace/network_config.json \\ --committee-id 0 \\ --task-majority 6700 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID"`} **Task Configuration:** - **Task Type**: Numeric identifier for different task categories - **Task Majority**: Percentage threshold for task validation (in basis points: 6700 = 67%) ## Phase 3: Operator Management ### Step 6: Register Operators Operators can register themselves to participate in your network: {`# Register an operator lumos network register-operator \\ --output-file /workspace/network_config.json \\ --operator-address "0x1234567890123456789012345678901234567890" \\ --peer-id "12D3KooWGjwvskBvG7GfqCYWDFfr6CvV8y7Z5aPTq5F4sB9nErWX" \\ --public-key "0x04abc123..." \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID"`} ### Step 7: Add Operators to Committees {`# Add operator to committee 0 lumos network add-operator \\ --output-file /workspace/network_config.json \\ --operator-address "0x1234567890123456789012345678901234567890" \\ --committee-id 0 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID"`} ## Phase 4: Development & Deployment ### Step 8: Scaffold Your SSN Project Generate boilerplate code for your custom SSN logic: {`lumos scaffold \\ --SSN-name "MyAwesomeSSN" \\ --task-names "DataValidation,ComputeProof" \\ --github-username "your-github-username"`} **Scaffold Output:** - Creates a new project directory with template code - Generates `execute()` and `verify()` function templates - Includes Docker configuration and build scripts - Sets up basic project structure with dependencies ### Step 9: Start Relay Node (Optional) For local testing and development, start a relay node to facilitate P2P communication: {`lumos relay \\ --key-id p2p_key \\ --http-address 127.0.0.1:3600 \\ --p2p-tcp-address 127.0.0.1:3500 \\ --p2p-advertise-private-addresses \\ --p2p-relay-loglevel debug \\ --passphrase-file /workspace/passphrase.txt`} **Relay Configuration:** - `--key-id`: P2P key for relay identity - `--http-address`: HTTP endpoint for relay communication - `--p2p-tcp-address`: TCP address for P2P networking - `--p2p-advertise-private-addresses`: Enable for local development - `--p2p-relay-loglevel`: Logging level for debugging ## Management Commands ### Removing Assets and Operators {`# Remove a vault from the network lumos network remove-vault \\ --output-file /workspace/network_config.json \\ --vault-address "0x742d35Cc6634C0532925a3b8D3Ac3C3A8D3Ce0C4" \\ --committee-id 0 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID" # Remove an operator from the network lumos network remove-operator \\ --output-file /workspace/network_config.json \\ --operator-address "0x1234567890123456789012345678901234567890" \\ --committee-id 0 \\ --private-key-name submitter_key \\ --passphrase-file /workspace/passphrase.txt \\ --rpc-url "https://sepolia.infura.io/v3/YOUR_PROJECT_ID"`} ## Security Best Practices 1. **Passphrase Management**: Always use `--passphrase-file` instead of interactive input for automated scripts 2. **Key Storage**: Keep the `~/.catalyst` directory secure and backed up 3. **Private Keys**: Never share private keys or include them in version control 4. **RPC URLs**: Use secure, authenticated RPC endpoints for production deployments 5. **Network Configuration**: Keep your `network_config.json` file secure - it contains critical contract addresses ## Next Steps After completing this quickstart: 1. **Implement Custom Logic**: Edit the scaffolded code to implement your SSN-specific task execution and verification logic 2. **Testing**: Test your SSN on testnet before mainnet deployment 3. **Monitoring**: Set up observability and monitoring for your deployed network 4. **Documentation**: Create operator guides and user documentation for your specific SSN For more detailed information, check out the [Integration Guide](./integration) and [Catalyst SDK Documentation](./catalyst-sdk). ## Troubleshooting ### Common Issues **Docker Volume Permissions**: {`# Fix permission issues on Linux/macOS sudo chown -R \\$USER:\\$USER ~/.catalyst`} **Key Not Found**: {`# Verify keys exist lumos key list # Check key directory permissions ls -la ~/.catalyst/keys`} **RPC Connection Issues**: - Verify RPC URL is accessible - Check network connectivity - Ensure sufficient ETH for gas fees **Transaction Failures**: - Verify private key has sufficient ETH - Check gas price and limits - Confirm contract addresses in network config For additional help, consult the [FAQ section](./faqs) or reach out to the Catalysis community. --- ## Core-SDK **Core SDK** is a comprehensive framework for building and managing **Shared Security Networks (SSNs)** on the Catalysis Network. It can be considered as a _Swiss Army Knife_ to build **Universal Networks**. It enables **plug-and-play** functionality with **full customisability** and provides **standard tooling** to build networks the "right way". Think of it as "**Cosmos-SDK for building SSNs**". It offers built-in **customizable modules** that facilitate rapid development and flexibility to meet each network's specific needs. It is written in **Go**, so it's both performant and fast. ## SDK Modules The following modules are part of the Core-SDK: | **Module** | **Use** | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **BaseApp** | Core application framework that coordinates all components. Provides lifecycle management, dependency injection through wiring, and serves as the entry point for SSN applications. Handles initialization and orchestration of P2P, consensus, execution, state management, and HTTP server components. | | **Listener** | Entry point for task ingestion from various sources (HTTP APIs, smart contract events, external services). Validates incoming tasks, broadcasts them via P2P to other nodes, and forwards valid tasks to the consensus engine for processing. | | **Consensus** | Implements distributed consensus mechanisms with customizable leader election strategies. Manages task lifecycle, coordinates leader election per task round, ensures fault tolerance through fallback handling, and forwards signed results to the execution module. Supports pluggable consensus algorithms and stake-based leader selection. | | **Execution** | Validates signed results from consensus, implements custom SSN business logic through TaskHandler interface, manages attestation creation and broadcasting, collects attestations from network peers, and forwards aggregated attestations to the submitter when quorum is reached. Provides framework for secure task execution and verification. | | **Submitter** | Finalizes tasks by submitting aggregated attestations to on-chain TaskManager contracts. Handles blockchain transactions with retry mechanisms, supports both ECDSA and BLS signature schemes, manages transaction confirmation, and triggers post-submission logic. Implements concurrent submission with exponential backoff for failed attempts. | | **Crypto** | Comprehensive cryptographic module supporting ECDSA and BLS keys with encrypted storage. Provides secure key generation, management, and signing operations. Supports multiple key types (P2P, task signing, submitter keys), implements keystore with passphrase protection, and offers both raw and high-level cryptographic operations. | | **P2P** | Handles peer-to-peer networking using libp2p protocols. Implements peer discovery, connection management, message broadcasting and routing between nodes. Supports customizable stream handlers, error responders, and metadata exchange. Provides health monitoring and automatic reconnection mechanisms for robust multi-node communication. | | **State** | Manages persistent application state across the SSN lifecycle. Provides key-value storage interface for module data, handles state synchronization between components, and supports state queries and updates. Used by various modules to store configuration, peer information, and task processing state. | | **Server** | HTTP API server providing external communication endpoints. Integrates with the listener module to receive tasks via REST APIs, exposes health checks and metrics endpoints, and supports custom route handlers for SSN-specific functionality. Includes both main API server and optional metrics server. | ## Core Modules ### 1. Listener Module The **Listener** module serves as the entry point for task ingestion into the SSN network. It acts as a central hub that receives tasks from various sources and coordinates their distribution across the network. **Responsibilities:** - Receive tasks from multiple sources (HTTP APIs, smart contract events, gRPC services, internal modules) - Validate task structure and integrity before processing - Broadcast tasks to all network peers via P2P communication - Forward validated tasks to the consensus engine for leader election and processing - Handle task timeouts and prevent processing of expired tasks **Core Flow:** 1. **Task Reception:** Accepts tasks from any input source with validation 2. **Task Broadcasting:** Distributes tasks to all network participants via P2P 3. **Consensus Forwarding:** Submits tasks to consensus engine for coordinated processing ### 2. Consensus Module The **Consensus Module** coordinates distributed agreement on task execution through a leader-driven consensus mechanism with customizable strategies. **Core Flow:** 1. **Task Reception:** Receives validated tasks from the listener module 2. **Leader Election:** Executes configurable leader election strategy based on stake, rotation, or custom algorithms 3. **Task Processing:** - If node is elected leader: executes the task and creates signed result - If node is not leader: waits for signed result from elected leader 4. **Fallback Handling:** Implements automatic failover with new leader election if current leader fails or times out 5. **Result Distribution:** Broadcasts signed results to the execution module for attestation **Responsibilities:** - Manage task lifecycle with deduplication of concurrent attempts - Execute pluggable leader election strategies (stake-based, round-robin, custom) - Coordinate task execution with timeout and retry mechanisms - Ensure signed results are properly distributed across the network - Handle consensus failures through automatic leader re-election ### 3. Execution Module The **Execution Module** validates signed results and orchestrates the attestation process across network participants. **Core Flow:** 1. **Result Validation:** Receives and validates signed results from consensus 2. **Business Logic Execution:** Runs custom SSN logic through TaskHandler interface 3. **Attestation Creation:** Generates cryptographic attestations for validated results 4. **Network Broadcasting:** Distributes attestations to all network peers 5. **Quorum Collection:** Aggregates incoming attestations until threshold is met 6. **Submission Trigger:** Forwards aggregated attestations to submitter when quorum is achieved **Responsibilities:** - Validate correctness of signed task results using custom verification logic - Execute SSN-specific business logic through pluggable TaskHandler interface - Create and broadcast cryptographic attestations to network peers - Monitor and collect attestations from other validators - Aggregate attestations and verify quorum requirements are met - Handle attestation timeouts and mismatch scenarios with recovery mechanisms ### 4. Submitter Module The **Submitter Module** handles the final step of task processing by committing results to the blockchain and managing post-processing workflows. **Core Flow:** 1. **Attestation Reception:** Receives aggregated attestations from execution module 2. **Blockchain Submission:** Submits attestations to TaskManager smart contracts 3. **Transaction Management:** Handles gas estimation, transaction broadcasting, and confirmation 4. **Retry Logic:** Implements exponential backoff for failed submissions 5. **Post-Processing:** Executes custom callbacks and triggers reward distribution **Responsibilities:** - Submit aggregated attestation sets to on-chain TaskManager contracts - Support both ECDSA and BLS signature schemes for different blockchain requirements - Manage transaction lifecycle with proper gas handling and confirmation monitoring - Implement robust retry mechanisms with exponential backoff for network issues - Handle concurrent submissions through goroutine-based processing - Execute post-submission logic including rewards distribution and logging ## **Supporting Libraries** 1. **Types Library** – Defines core data structures (Task, SignedResult, Attestation) and interfaces (TaskHandler, Module) used across all components 2. **Errors Library** – Provides structured error handling with context and wrapping capabilities for better debugging and monitoring 3. **Log Library** – Implements structured logging with configurable levels, topics, and output formats for comprehensive observability 4. **Z Library** – Offers logging field utilities for consistent and efficient log message construction across all modules ## **Flow Diagram** ![SDK Flow](./img/sdk-flow-1.png) --- ## Smart Contracts Catalysis utilizes a sophisticated smart contract architecture to enable secure, scalable SSN deployment and management. Our contracts serve as the foundational layer that bridges SSN developers with multiple restaking protocols, providing unified access to economic security. ## Architecture Overview The Catalysis smart contract system employs a modular, upgradeable architecture designed for flexibility and security. At its core, the system consists of several interconnected components that work together to manage SSN lifecycle, operator registration, task execution, and economic incentives. ## Core Components ### CatalysisManager The factory contract that serves as the entry point for deploying new SSN instances. It manages the deployment of all core contracts and maintains upgradeability through beacon proxy patterns. **Key Capabilities:** - **SSN Deployment**: Streamlined deployment of complete SSN infrastructure - **Upgradeable Architecture**: Secure upgrade mechanisms for evolving protocol needs - **Configuration Management**: Centralized management of system parameters ### NetworkManager The orchestration layer that manages SSN operations and administrative functions. This contract serves as the primary interface for SSN configuration and operator management. **Key Capabilities:** - **Operator Registration**: Seamless onboarding of network operators - **Committee Management**: Dynamic assignment and management of operator committees - **Administrative Controls**: Comprehensive governance and parameter management ### StakeManager The economic security layer that interfaces with multiple restaking protocols to aggregate and manage operator stakes across different platforms. **Key Capabilities:** - **Multi-Protocol Integration**: Native support for Symbiotic and EigenLayer with others coming soon - **Stake Aggregation**: Real-time tracking of operator stakes across multiple vaults - **Committee Assignment**: Intelligent stake-weighted operator assignment to committees ### TaskManager The execution layer that handles task submissions, attestations, and consensus mechanisms for SSN operations. **Key Capabilities:** - **Flexible Task Execution**: Support for various task types and execution patterns - **Multi-Signature Support**: Both ECDSA and BLS signature schemes for different use cases - **Consensus Mechanisms**: Configurable voting thresholds and approval processes - **Zero-Knowledge Integration**: Support for ZK proof-based task verification (coming soon) ## Economic Incentives ### Rewards Distribution - **Performance-based**: Rewards tied to successful task completion and network participation - **Proportional Allocation**: Stake-weighted reward distribution - **Cross-protocol**: Unified reward mechanisms across all integrated restaking platforms ### Risk Management - **Graduated Slashing**: Proportional penalties based on violation severity - **Committee Isolation**: Localized risk containment within committee structures - **Appeal Mechanisms**: Governance-based resolution for disputed actions ## Developer Benefits ### Simplified Integration - **Unified Interface**: Single integration point for multiple restaking protocols - **Reduced Complexity**: Abstract away protocol-specific implementation details - **Flexible Configuration**: Customizable parameters for diverse SSN requirements ### Economic Security - **Aggregated Stake**: Access to combined economic security from multiple protocols - **Dynamic Scaling**: Automatic adjustment of security levels based on stake availability - **Risk Distribution**: Spread economic risk across multiple restaking platforms ### Operational Efficiency - **Automated Management**: Streamlined operator and committee management - **Real-time Monitoring**: Continuous tracking of network health and performance - **Upgradeable Infrastructure**: Future-proof architecture that evolves with ecosystem needs ## Contract Interactions Understanding how Catalysis contracts interact provides insight into the protocol's operational flow. Below are the key interaction patterns that enable secure, scalable SSN operations. ### SSN Deployment ```mermaid sequenceDiagram participant Dev as SSN Developer participant CM as CatalysisManager participant Core as Core Contracts Dev->>CM: Deploy SSN CM->>Core: Initialize Components Core->>Core: Configure Network CM-->>Dev: SSN Ready ``` The deployment process establishes a complete SSN infrastructure through a single transaction, automatically configuring all necessary components for immediate operation. ### Operator Onboarding ```mermaid sequenceDiagram participant Op as Operator participant Net as Network participant Stake as StakeManager participant Rest as Restaking Protocol Op->>Net: Register Intent Net->>Stake: Process Registration Stake->>Rest: Verify Eligibility Rest-->>Stake: Confirm Status Stake-->>Op: Registration Complete ``` Operators join the network through a streamlined process that verifies their eligibility and establishes their participation across all integrated restaking protocols. ### Task Execution Flow ```mermaid sequenceDiagram participant Exec as Task Executor participant Att as Attesters participant Task as TaskManager participant Net as Network Exec->>Exec: Execute Task Exec->>Task: Submit Result Task->>Att: Request Attestations Att->>Task: Provide Attestations Task->>Net: Verify Consensus Task-->>Exec: Confirm Completion ``` The task execution model ensures integrity through multi-party attestation and consensus verification, providing robust validation of all network operations. ## Getting Started For SSN developers looking to leverage Catalysis smart contracts: 1. **Architecture Planning**: Review your SSN requirements and determine optimal committee structure 2. **Integration Design**: Plan your task execution flow and attestation mechanisms 3. **Deployment Preparation**: Prepare operator network and restaking protocol integrations 4. **Testing Environment**: Utilize our testnet for comprehensive integration testing ## Next Steps Ready to build with Catalysis? Explore our [Integration Guide](./05-integration.md) for detailed implementation steps, or dive into our [SDK documentation](./03-catalyst-sdk.md) for development tools and examples. For technical support and architectural guidance, connect with our team through our developer channels. --- ## Integration This guide walks through the integration flow for an SSN. The process is split into three key phases: 1. **Setup Phase** – Deploy contracts and initialize the network. 2. **Implementation Phase** – Add your business logic with the SDK. 3. **Deployment Phase** – Package the implementation and hand off to operators. ## 1. **Setup Phase** This phase is focused on bootstrapping your network. ### 🔹 Step 1: Deploy Smart Contracts Use the Lumos CLI to deploy the three core contracts for SSN: - `NetworkManager` - `StakeManager` - `TaskManager` You’ll need to provide details like the **Network Name, SSN Metadata, Chain ID, RPC URL, Deployer Private Key** etc. ```bash lumos network register --flags ``` This deploys the contracts to your specified chain (e.g., Sepolia, or Holesky) and returns a network output JSON with all deployed contract addresses. ### 🔹 Step 2: Share Deployment Info with Operators Once deployed, share the contract addresses and network metadata with your operators. They’ll need this info to register and run nodes. ### 🔹 Step 3: Operator Registration Operators must install the Lumos CLI and register themselves with the SSN using: ```bash lumos network register operator --flags ``` Each operator provides their `operator metadata`, `p2p_peer_id` (used for validator identity) and any additional information needed for your network. The command: - Registers the operator with the NetworkManager - Binds them to the deployed SSN contracts - Stores their registration info on-chain 📌 **This step is initiated by the operator, but requires contract details from the SSN developer.** ### 🔹 Step 4: SSN Owner Adds Committees and Vaults Once operators are registered, the SSN owner configures the network’s security structure: - Create committees using: ```bash lumos committee create --flags ``` - Add vaults (representing sources of economic security) to each committee: ```bash lumos vault add --flags ``` The vaults are registered with the `StakeManager` and mapped to the corresponding committees. These vaults are later used to: - Verify the stake backing each operator - Resolve slashing or reward logic 🛠️ **All of this is still handled using the Lumos CLI. No SDK logic is touched yet.** ## 2. **Implementation Phase** This is where you define the task logic for your network — how tasks are executed and verified. ### 🧱 Step 1: Scaffold Boilerplate Run the scaffold command to generate boilerplate SSN logic: ```bash lumos scaffold --flags ``` This creates a basic project structure with two key functions: - `execute()` — defines how your SSN handles a task - `verify()` — defines how task results are validated ### 🧠 Step 2: Implement Business Logic Implement the `execute` and `verify` methods with your custom task logic. This is the core of your SSN’s behavior. ### ⚙️ Step 3: Package the SSN Client Once the logic is implemented: - Package the SSN code as a Docker image - Prepare a `config.yaml` file with: - Deployed contract addresses (from Setup Phase) - Any SSN-specific runtime parameters 📝 **This config is currently not auto-generated. Developers must manually include the contract addresses from the Setup phase.** ## 3. **Deployment Phase** With everything in place, you’re ready to launch your network & hand it over to Operators. ### 🚀 Step 1: Distribute the Client to Operators Once your SSN logic is packaged: - Share the **Docker image** and the accompanying **`config.yaml`** file with your operators. - Operators run the SSN client using this image + config. The config should include: - `TaskManager`, `StakeManager`, and `NetworkManager` contract addresses - Vault and committee references (as configured in the setup phase) - Any other network-specific runtime parameters At this point, the SSN is live and operators are now fully capable of processing and validating tasks on-chain. ### 📊 Step 2: Monitor with Observability Tools Once deployed, it’s crucial to monitor the behavior and health of your network. - The SSN client includes built-in observability features (metrics, logging & tracing). - These help **SSN developers** monitor task processing, operator participation, error rates and latency. - **Operators** can use these tools to monitor node uptime, rewards processing and slashing exposure. > Good observability makes it easier to debug issues, track liveness and understand network performance over time. --- ## FAQs 1. **How easy is it to build a Network using Catalysis?** Building a Network using Catalysis is fast and seamless. With Catalyst-SDK, you can have your Network up and running in just a few days, saving 80% of time and resources compared to building from scratch. 2. **How does Catalysis make Networks more resilient?** Catalysis ensures resilience by distributing your Network’s security across multiple shared security protocols (SSPs). This minimizes the impact of any single protocol failure. **Example:** If your Network is secured by EigenLayer, Symbiotic, Kernel, and SatLayer, and Kernel faces a security breach or a major liquidity migration, your Network remains secure because it still has economic backing from EigenLayer, Symbiotic and SatLayer. 3. **How does Catalysis compare to other shared security protocols (SSPs)?** Catalysis is **NOT** a shared security protocol - it is a **Security Abstraction Layer** that connects major SSPs like EigenLayer, Symbiotic and Satlayer. With Catalysis, Networks can seamlessly integrate with multiple SSPs instead of being tied to just one. This results in: - **Greater flexibility** → Choose where to source security dynamically. - **Higher resilience** → Avoid dependency on a single SSP. - **Optimized security costs** → Compete for the best economic security pricing. 4. **Isn't ZK verifiability enough for my Network?** No, ZK verification is not enough as it cannot solve for all kinds of faults. ZK is a valid security model only under the assumption of **objective faults** that are **proactively attributable**. However, not all security risks fall into this category. ![ZK vs Cryptoeconomic Security](./img/zk-vs-ces.png) --- ## FAQs(Operators) 1. **What are the prerequisites for a Node Operator to join the Catalysis Network?** There are no prerequisites. If you’re already running a node for a network/SSN on any restaking protocol (EigenLayer, Jito, SatLayer, etc.), you’re automatically part of the Catalysis Network. 2. **What are the main responsibilities of a Node Operator in the Catalysis Abstraction layer?** You need to run a couple of commands to register your node with the Catalysis Network. And then you just run your node as you normally would. Except, now you'll be running the Catalysis-Powered SSN node software. Register your node with the Catalysis Network using a few simple commands, and then continue operating it as usual. Catalysis seamlessly integrates SSN security, **so you only need to run the SSN node software once, regardless of how many restaking protocols the SSN spans**. No additional infrastructure overhead. 3. **Say an SSN exists on Eigenlayer (Ethereum) + Satlayer (Babylon). As a Node Operator, do we need to partner with Eigenlayer and Satlayer to be able to participate?** No, you don’t need to partner with any restaking protocol directly. However, you do need to partner with LRTs/Vault curators to get delegations on Eigenlayer and Satlayer. Catalysis abstracts these integrations, allowing you to run SSNs across multiple restaking protocols without individual agreements. 4. **Does a Node Operator participate at two levels - both the shared security protocol (SSP) layer and the abstraction layer?** No, you only participate at one level: the Catalysis Abstraction Layer. You run one node per SSN. And Catalysis seamlessly manages security delegation across multiple SSPs. 5. **If a Node Operator wants to run an SSN on a new Shared Security Protocol (SSP), do they need stake in that SSP?** Yes, node operators must have economic security delegation on the SSP to participate. For example, if you want to run an SSN on Symbiotic, you need delegated security from Symbiotic vaults. 6. **How are Rewards distributed to Node Operators?** Rewards are distributed directly by the SSPs. If you’re running a Catalysis-Powered SSN (say $100M) secured by EigenLayer ($50M) + Symbiotic ($50M), you’ll receive separate payouts from both EigenLayer and Symbiotic based on your stake and participation. 7. **Do we need to partner with LRTs to run networks on a Shared Security Protocol (SSP)?** No, you don’t need to partner with LRTs directly. Catalysis partners with top LRTs and vault curators across SSPs, allowing you to seamlessly run Networks without separate LRT agreements. However, if you already have LRT partnerships, it can streamline delegation and integration, making the process even smoother. --- ## Introduction(Operators) Node operators are the backbone of the Catalysis Network. They are the "engine" that runs the SSN infrastructure and provide economic security to the network. Catalysis offers substantial advantages for node operators by simplifying the management of SSN infrastructure across multiple restaking platforms. With the **Catalyst-CLI** tool, operators can seamlessly manage their SSN setups from a single interface. This **unified solution** eliminates the need to run separate infrastructure for each platform, instead offering a single node setup that saves both time and effort. A key benefit of Catalysis is the **significant reduction in DevOps engineering expenses**. This not only minimizes development overhead but also ensures that node operators can scale their SSN management to handle thousands of services with minimal effort. Moreover, Catalysis empowers node operators of all sizes to participate in running SSN infrastructure, not just the larger ones. This inclusion contributes to the **decentralization of the node operator set,** addressing a [growing problem](https://restake.watch/) in the restaking ecosystem. ## Advantages - **Simplified Management**: Use the Catalyst-CLI tool to manage SSN infrastructure across multiple restaking platforms from a single interface. - **Unified Node Setup**: Operate a single node setup for all platforms, reducing the need for multiple infrastructure setups. - **Cost Efficiency**: Save on DevOps expenses by avoiding the need for custom tooling for each restaking platform. - **Scalability**: Easily manage thousands of SSNs with minimal overhead. - **Reliability**: SSNs built with Catalyst-SDK minimize technical issues like debugging errors and key management. - **Decentralization**: Enable smaller node operators to participate, promoting a more decentralized ecosystem. - **Focus on Performance**: Spend less time on operations and more on delivering secure and efficient infrastructure. --- ## Running a Node You can run a node using the docker image or the binary of the Network built using the Catalyst-SDK. ## How does it work? The following is the view from the perspective of a node operator running a Network built using Catalysis. - The Network is sourcing economic security across EigenLayer, Symbiotic, Satlayer and Jito. - Each node operator runs a single instance of a Catalysis node client software. ![Simplified Stack](./img/arch-no-101.png) --- ## FAQs(Restaking-protocols) 1. **How does a new restaking protocol integrate into Catalysis?** New restaking protocols integrate with Catalysis through a standardized onboarding process. The Catalysis team collaborates directly with SSP teams to implement required adapters and interfaces, enabling seamless compatibility with the Catalysis Security Abstraction Layer. 2. **Does Catalysis support shared security protocols (SSPs) across all chains?** Not yet. Catalysis currently supports EVM-based SSPs like [Eigenlayer](https://www.eigenlayer.xyz/) and [Symbiotic](https://symbiotic.fi/), as well as Cosmos-based protocols like [Babylon](https://babylonlabs.io/) and [Satlayer](https://satlayer.xyz/). That said, Catalysis is VM-agnostic by design—its flexible architecture allows seamless integration with new restaking protocols as the ecosystem evolves. 3. **What are the benefits for restaking protocols to integrate with Catalysis?** Restaking protocols integrating with Catalysis benefit from demand aggregation, as Catalysis serves as a distribution channel for Networks seeking economic security. They also enjoy simplified onboarding processes that allow high-quality Networks to integrate more easily, boosting participation. --- ## Introduction(Restaking-protocols) ## What is a Shared Security Protocol? Shared Security Protocols (or Restaking Protocols) create a **marketplace for economic security**, enabling decentralized networks to source security from stakers. They act as a coordination layer connecting: - **Stakers** → Provide economic security by delegating assets and maximizing returns. - **Node Operators** → Run network infrastructure and expand into high-value decentralized services. - **Networks** → Acquire security guarantees from restaked assets. ## Why should Shared Security Protocols work with Catalysis? Catalysis brings significant advantages to **shared security protocols (SSPs)** by aggregating demand and acting as a distribution channel, creating a more competitive and fair environment for these platforms. One of the key features Catalysis unlocks is **leveling the playing field** for restaking protocols, allowing them to compete on the strength and efficiency — in terms of both cost and performance — of their offerings. This also opens us opportunities for newer protocols to gain traction. By simplifying the onboarding process for Networks, Catalysis encourages more projects to deploy as Networks, driving overall ecosystem growth. As more Networks are attracted to these platforms, it creates a **win-win situation** where both Network teams and SSPs benefit from increased participation. In addition to driving adoption, Catalysis helps SSPs offer **better features and more reliable economic security**, making their platforms more appealing to Networks seeking robust solutions. The influx of high-quality Networks further enhances the robustness and value of these protocols, fostering a vibrant, **competitive ecosystem** for the future. ## Summary of Benefits - **Demand Aggregation**: Catalysis acts as a distribution channel, aggregating demand for economic security from Networks. - **Level Playing Field**: Provides equal opportunities for all restaking protocols to compete based on features, cost, and performance. - **Streamlined Onboarding**: Simplifies the process for Networks to deploy, driving ecosystem growth. - **Enhanced Features**: Encourages SSPs to offer better features and more reliable economic security. - **Attracting Networks**: Increases participation by enabling high-quality Networks to join the ecosystem. - **Ecosystem Growth**: Fosters a vibrant and competitive environment for shared security protocols. --- ## Restaking Protocols Overview This section covers the overview of Restaking Protocols. --- ## Audits This page lists **official Catalysis smart contract security audits**. Use these reports for due diligence and integrations. Catalysis contracts are audited by Tier-1 firms including **[Sigma Prime](https://github.com/sigp/public-audits)** and **[Certora](https://www.certora.com/)**. **This page is the official reference** for published audit reports; when new audits are completed, we will **update them here**. ## Audit reports --- ## Overview(Catalysis-core) ## Catalysis Core **Catalysis Core** is the first Security Abstraction Layer that unlocks **Unified Access to $20B+ ETH, BTC & SOL-backed Economic Security** across major restaking protocols on Ethereum, Bitcoin & Solana. ![3D Visualization](/img/3D.svg) It introduces a new primitive called **Shared Security Abstraction (SSA)** that separates application logic from the complexities of underlying restaking infrastructure. By standardizing interactions across protocols like EigenLayer, Symbiotic and SatLayer, **Catalysis Core** allows applications and networks to consume restaked security through a single, abstract interface. ![3D Visualization](/img/Catalysis-Network.svg) ## Core Architecture Overview The **Catalysis Core** is built on three core components: 1. **Networks** – Decentralized services, protocols and applications (SSNs) that leverage shared security for verification and decentralization. 2. **Node Operators** – Entities that run network software, perform validation tasks and secure them using the Catalysis stack through restaking protocols. 3. **Restaking Protocols** – Also known as shared security protocols, these allow stakers to restake assets (LSTs, ERC-20s, etc.) to provide security for network validation. They function as a marketplace, connecting networks, node operators and stakers. ![Simplified Stack](./images/arch-1.svg) ## Why build with Catalysis Core? Shared security protocols like EigenLayer, Symbiotic and Satlayer have unlocked a new paradigm for decentralized infrastructure by making it easier to bootstrap decentralized networks (SSNs). **However, launching and managing an SSN remains complex and resource-intensive**. Teams must navigate a wide range of challenges. This includes integrating with restaking protocols, configuring slashing and reward mechanisms, managing a node operator set and ensuring cross-restaking protocol composability. **Catalysis Core** eliminates these barriers, making it easier, faster and more cost-efficient to build and operate SSNs. ## Key Benefits The key benefits of building an SSN using **Catalysis Core** include: 1. **Multi-Ecosystem Security:** Seamlessly integrate restaking protocols across major PoS chains like **Babylon (Bitcoin), Ethereum and Solana**. 2. **Accelerated GTM:** Launch faster with developer-friendly SDKs, clear documentation and up to **80% savings on SSN development costs**. 3. **Unmatched Economic Security:** Tap into **$20B+ in combined TVL** across restaking protocols - ensuring your SSN has the strongest possible security guarantees. 4. **Resilient Infrastructure:** Spread risk across multiple restaking protocols, ensuring your SSN is **robust and reliable** even in adverse conditions across the restaking ecosystem. 5. **Composability at Scale:** Unlock **composable, interoperable crypto-economic security** across restaking protocols. 6. **No Vendor Lock-In:** Stay flexible with **modular integrations**, enabling your SSN to expand beyond one ecosystem. 7. **Dynamic Security Rebalancing:** Real-time control to allocate and **rebalance security** across restaking protocols with a **single unified interface**. It isn't just about simplifying SSN development - **it’s about unlocking the full potential of shared security**. ## The Restaking Stack ![Expanded Stack](./images/full-arch.svg) --- ## CoverPools ## What is a CoverPool A **CoverPool** is a risk-isolated coverage instance in Catalysis that aggregates **committed, slashable restaker delegations** into a pool of **raw coverage capacity**. That capacity is allocated to underwrite risks for specific vaults on **Tier-1 DeFi protocols** CoverPools are isolated across both **underwriting logic** and **economic exposure**. ## What CoverPools do 1. **Connect**: Restakers (capacity providers) ↔ Vaults (e.g., [Morpho](https://morpho.org), [Euler](https://euler.finance)) in a single onchain flow 2. **Aggregate**: Slashable delegations → usable coverage capacity 3. **Issue**: Coverage contracts with explicit terms (limits, pricing, payouts) ## How CoverPools enable modular risk coverage **DeFi Vaults are modular**; each vault’s risk profile is different (protocol mechanics, assets, curator/manager controls, strategy parameters, dependencies). A single global pool either **overprices safe vaults** or **cross-subsidizes risky ones**. CoverPools solve this by **matching vault modularity with coverage modularity**. 1. **Per vault or vault class**: A CoverPool is configured for a specific vault (say Morpho Gauntlet USDC Prime, Morpho Steakhouse ETH) **not “all vaults.”** 2. **Capacity is pool-scoped**: Restakers choose which CoverPool to back; **losses (and incentives) stay contained within that pool**. 3. **Pricing is accurate**: **Risk is priced inside the CoverPool** that takes it and premiums reflect each pool’s mandate. 4. **Coverage stays composable**: **New vault designs don’t break the system**. When vault types evolve (new curators, strategies, protocols), Catalysis can spin up new CoverPools to match them. --- ## Glossary ### 1. DeFi Vault A **DeFi vault** is a smart contract that accepts user deposits and automatically executes predefined blockchain-based yield strategies without manual intervention. Users deposit assets into the vault, and the vault allocates that capital according to preset rules, often managed or configured by a curator or strategy provider. ### 2. Risk Coverage **Risk coverage** is onchain protection attached to a vault deposit that compensates users if pre-defined loss events occur. Instead of treating losses as an unbounded downside, coverage introduces explicit terms — what is covered, how much can be paid out and under what conditions. **You can think of it as "onchain insurance" that is programmable, transparent and unregulated.** ### 3. Coverage Fee (Premium) A **coverage fee (premium)** is the price paid for risk coverage, **typically quoted in basis points (bps) per year**. In vault-native designs, the premium is usually collected seamlessly through vault accounting (often as a small reduction in net APY), **making coverage feel like an integrated feature rather than a separate purchase**. ### 4. Underwriting **Underwriting** is the process of evaluating a vault's risk profile and deciding whether it can be covered, at what pric, and under what limits. It converts qualitative risk (strategy complexity, asset risk, oracle risk, smart contract risk, operational risk) into quantitative parameters like **premium rate, capacity allocation and maximum payout**. ### 5. Covered Vault A **Covered Vault** is a DeFi vault that offers embedded risk coverage as part of the deposit experience. Depositors can choose to enable coverage and receive downside protection under predefined terms, while the vault and coverage layer handle premium collection, accounting and potential payout flows. ### 6. Base Vault A **Base Vault** is the same underlying DeFi vault strategy without coverage enabled. Users in the base vault earn the "full" strategy yield but also face the full downside if something breaks, whereas covered vault users trade a small premium for defined protection. ### 7. Vault-Native Coverage **Vault-native coverage** means coverage is integrated directly into the vault's core workflows—deposit, withdrawal, share accounting, and yield reporting—rather than being an external policy a user must buy and manage separately. This makes protection simpler to adopt, easier to distribute through partners, and more composable with structured yield products. ### 8. Underwriting Capacity **Underwriting capacity** is the total amount of loss exposure that can be safely supported by the capital backing the coverage system. It's effectively the "coverage balance sheet"—how much protection can be issued without overextending the backing capital, after accounting for buffers, limits, and risk constraints. ### 9. DeFi Curator A **DeFi Curator** is the risk manager responsible for configuring and maintaining the base vault's parameters and running yield-generating strategies. Examples: **[Gauntlet](https://www.gauntlet.xyz/), [Steakhouse Financial](https://www.steakhouse.financial/)**. ### 10. Risk Pricing **Risk pricing** is the method used to set premiums based on the probability and severity of potential losses for a given vault. It reflects expected loss, uncertainty, tail risk, and capital availability—so higher-risk vaults pay more, and premiums can adjust as utilization and market conditions change. ### 11. Coverage Limit A **coverage limit** is the maximum amount that can be paid out for a covered vault or policy under defined conditions. Limits make protection explicit and bounded—users know the maximum downside protection they're buying, and the system ensures payouts cannot exceed what was committed. ### 12. Coverage Duration **Coverage duration** is the period during which coverage is active and claims are valid under the policy terms. Duration matters because risk changes over time—shorter durations are easier to price and manage, while longer durations may require more conservative limits or higher premiums. ### 13. Opt-In Coverage **Opt-in coverage** means depositors choose whether they want protected exposure at the moment they deposit (or when they interact with the vault). This preserves flexibility: users who want maximum yield can stay uninsured, while users who care about downside protection can pay the premium and receive defined coverage terms. ### 14. Covered TVL **Covered TVL** is the amount of total value locked in Covered Vaults compared to the Base Vaults. It's a core adoption metric because it measures how much capital users are choosing to protect, not just how much capital is sitting in overall. ### 15. Coverage Penetration **Coverage penetration** is the share of a Base vault's (or ecosystem's) total TVL that is covered—i.e., Covered TVL divided by Base Vaukt TVL. It captures whether protection is becoming the default behavior for depositors, and it's often a leading indicator of institutional readiness. ### 16. Loss Event A **loss event** is a qualifying incident that results in measurable losses to vault depositors and is covered under the policy terms. Depending on design, it can include things like bad debt, oracle failures, exploit-driven losses, or asset-level shocks—so long as it matches the defined conditions for payout. ### 17. Delegator A **delegator** is the capital provider who supplies backing capital that makes coverage possible and earns premiums in return. Delegators take on the risk of loss (within defined constraints) so that vault users can receive protection, creating a market where risk is explicitly priced and transferred. ### 18. Restaked Backing **Restaked backing** refers to using restaked collateral as the economic foundation for underwriting coverage capacity. Instead of relying on traditional insurance balance sheets, coverage capacity is supported by onchain collateral that can credibly back payouts, enabling scalable and transparent coverage for DeFi vaults. --- ## Introduction(Docs) ![Catalysis Logo](/img/catalysis.png) ## What is Catalysis? Catalysis is the **first onchain infrastructure** to **natively integrate coverage** into **DeFi vaults**. **It makes risk coverage a first-class vault primitive** — enabling **Tier-1 DeFi protocols** to offer vaults and structured yield products with **embedded, programmable risk protection** backed by restaked capital. ### Key Highlights 1. **No third-party or custody risk**: Coverage integrates directly with premier vaults on existing **Tier-1 DeFi protocols** (Morpho, Upshift etc). 2. **Competitive Pricing**: LPs access downside protection with minimal impact on net vault APY. Typically 25-75 bps, depending on **risk rating of the DeFi vault**. 3. **Native Vault Coverage**: Institutional LPs don’t need to source or manage **external coverage from third-party protocols**. 4. **Fully onchain and transparent**: Coverage terms and payouts are enforced by smart contracts and executed **without manual intervention** or **committee discretion**. 5. **Simplified Integration UX:** Coverage can be plugged into any protocol with **minimal effort, no custom infra** needed. ## Simplified Architecture ## How It Works Catalysis connects restaked capital, risk underwriting and DeFi vaults into a single, onchain coverage flow. #### 1. **Restakers provide underwriting capacity** Restakers deposit assets such as ETH, BTC and stablecoins into restaking protocols like EigenLayer and Symbiotic. **Catalysis Core** aggregates this restaked capital. This pooled collateral represents the **system’s raw underwriting capacity** — capital that can be programmatically allocated to **cover risks on DeFi vaults**. #### 2. **CoverPools express risk pricing** Catalysis deploys dedicated coverage vaults called **CoverPools**. CoverPools act as the operational layer where capital is committed to defined risk profiles. Each CoverPool sources capacity from Catalysis Core and is configured to underwrite a specific class of risk. For example: an **A-rated USDC lending vault** versus an **A+ WETH-denominated yield vault**, based on risk ratings and underwriting parameters. #### 3. **CoverPools issue onchain coverage to DeFi vaults** Once restakers delegate capacity to a CoverPool, that pool can issue onchain coverage to **selected, high-quality DeFi vaults** on Tier-1 protocols such as **Morpho, Nest Credit and Upshift**. Coverage is **vault-specific, opt-in** and enforced entirely through smart contracts. #### 4. **Premiums and claims are settled programmatically** Coverage premiums paid by covered vault depositors flow directly into the relevant CoverPool and are **automatically distributed to restakers**. If a predefined loss event occurs, **Catalysis Core enforces slashing** on the delegated restaked capital. The slashed funds are then routed to compensate depositors in the covered vault, **up to the covered loss amount**. ## Next Steps To learn about the stakeholders in Catalysis, check out the [Stakeholders overview](./stakeholders/overview.md). Get started by exploring the [Catalysis Core](./catalysis-core/overview.md) to understand the foundational architecture. --- ## Mainnet contracts This page lists **official Catalysis smart contract deployments on Ethereum mainnet**. Use these canonical addresses for integrations and onchain verification. Catalysis contracts are **upgradeable** (proxy-based). **This page is the official reference** for these addresses; when upgrades or new deployments happen, we will **update them here**. Sepolia testnet deployments use the same proxy addresses where applicable; the TimelockController is mainnet-only in the reference deployment set. ## Core contracts ## Coverage contracts ## Vault contracts [EigenLayer AVS](https://app.eigenlayer.xyz/avs/0xe6168092892e545701d92bee10149178be0eedf4/operator-set/1) --- ## Resources The following is a list of references that you can visit for more details about Catalysis Network and the broader risk coverage ecosystem. ## Coverage - **3-piece Blog Series**: 1. [**DeFi and Capital: What the Last Decade Taught Us**](https://x.com/0xcatalysis/status/2014349312801821093) 2. [**Why DeFi Vaults Haven’t Reached Institutional Scale**](https://x.com/0xcatalysis/status/2018685246225674728) 3. [**Vault-Native Risk Coverage: How Catalysis Completes Institutional DeFi**](https://x.com/0xcatalysis/status/2021236666925494321) - **Podcasts** - [Symbiotic Blueprints](https://youtu.be/d4sPgNhVUeo?si=RpM5cZSsw0v7Qids) - [Axal Talking Intentionally](https://x.com/getaxal/status/1981081439136285164) - [Odyssey Podcast](https://www.youtube.com/watch?v=drEv-UeUmLQ) - **Founder's Thoughts**: [X Article](https://x.com/xenowits/status/1968673836317978741) - **Coverage Announcement**: [Blog](https://blog.catalysis.network/blog/catalysis-coverage-announcement) - **Tokensight Article**: [Blog](https://paragraph.com/@tokensightxyz/catalysis-coverage) ## Vaults - **[Vaults: The Future of Noncustodial Finance](https://morpho.org/blog/vaults-the-future-of-noncustodial-finance/)** - [By Morpho](https://morpho.org) - **[What are DeFi Vaults](https://www.rockawayx.com/insights/defi-vaults-explained-2026-guide)** - [By RockawayX](https://www.rockawayx.com) ## Research & Analysis - **Mathematical Research** (Accepted in [MARBLE 2025](https://www.marble-conference.org/marble2025)): [Economic Security of Multiple Shared Security Protocols](https://arxiv.org/abs/2505.03843) - **Tokensight Research** - [A Primer on Catalysis: A research deep-dive](https://paragraph.com/@tokensightxyz/a-primer-on-catalysis) - [Multi vs Single-Protocol Shared Security Networks](https://paragraph.com/@tokensightxyz/catalysis-ssn-deep-dive) - **Presto Research**: [Enabling the Builders: How Catalysis is Unlocking the Next Generation of AVSs](https://www.prestolabs.io/research/enabling-the-builders-how-catalysis-is-unlocking-the-next-generation-of-avss) - **Gauntlet Research**: [Restaking flows and implications on services](https://www.gauntlet.xyz/resources/restaking-flows-and-implications-on-services), [Youtube](https://youtu.be/vuZ1vfDgIbo?si=ZJIqbnvnmQujKva5) - **Chorus.one**: [The state of Ethereum restaking economics - challenges and future directions](https://chorus.one/articles/the-state-of-ethereum-restaking-economics-challenges-and-future-directions) ## Talks & Presentations - [Restaking Day, Dubai 2025](https://www.youtube.com/watch?v=DW33bexlxWo) - [Node Operator problems](https://youtu.be/pmozNGACsGc?si=4-1UNgvlBTswqaM8&t=805) - [ZK is insufficient: Sreeram's SBC Talk](https://www.youtube.com/watch?v=YSuG2kXjLNA)