# Spark Security Framework

> Bounded Risk, Explicit Loss Hierarchy, and Coordinated Liquidity

**Published by:** [Spark](https://paragraph.com/@spark-11/)
**Published on:** 2026-05-14
**URL:** https://paragraph.com/@spark-11/spark-security-framework

## Content

Most on-chain liquidity systems remain reactive by design. Spark’s architecture is designed differently: constrained capital movement, explicit loss absorption layers, programmatic liquidity management, and bounded risk at every layer of the system. Over the past year, Spark has expanded the security architecture across Spark Savings, SparkLend, and the Spark Liquidity Layer. This post explains how the system is structured today, how losses would be absorbed under stress, and the additional mechanisms currently being implemented across the broader Sky ecosystem. Spark continues to evolve its security and risk framework. This post also reflects the next proposed update to the Sky loss absorption waterfall, which remains pending governance approval at the time of writing. The updated structure is described as it would exist following passage, with the relevant changes clearly identified. Spark SavingsSpark Savings is a suite of non-custodial savings vaults. Users deposit stablecoins, USDT, USDC, USDS and PYUSD into permissionless vaults designed around coordinated liquidity and transparent capital allocation. Capital Structure and Seniority Spark Savings operates within the broader Sky allocation framework. When users deposit stablecoins into Spark Savings vaults, Spark borrows an equivalent amount of USDS from Sky through the Allocation System Primitive* and coordinates that capital across approved liquidity venues and credit markets via the Spark Liquidity Layer. All USD-denominated Spark Savings deposits are backed 1:1 by USDS. For each unit of stablecoin deposited, an equivalent unit of USDS is maintained within the Spark Liquidity Layer to satisfy redemptions. Spark Savings depositors share the same seniority as USDS holders within the broader Sky ecosystem. Losses are designed to be absorbed across the Sky Surplus Buffer, the Sky Protocol-owned capital reserves, the SKY Token backstop, and other protocol defined backstop facilities before propagating across broader Spark Savings exposure. The Loss Absorption WaterfallSpark Savings operates within a protocol-defined loss absorption framework designed to progressively distribute losses across multiple layers of risk capital and recapitalization mechanisms before losses propagate across broader Spark Savings depositor exposure. The updated waterfall introduces the Genesis Capital Backstop as a distinct layer preceding the SKY Token Backstop, further expanding the system’s loss absorption capacity before losses would propagate across broader USDS exposure.Layer 1: Prime Agent Risk Capital The first layer of loss absorption sits at the Prime level and consists of three distinct sub-layers of internal and external risk capital allocated against Spark’s activities.Internal Junior Risk Capital (IJRC) Spark’s treasury capital held against risk-weighted allocations. Spark absorbs losses first through the ‘Tip JRC’ mechanism before external junior capital is affected.External Junior Risk Capital (EJRC) Additional junior capital sourced from other ecosystem participants, designed to absorb losses alongside remaining IJRC once the Tip JRC threshold is breached.External Senior Risk Capital (srUSDS) A planned external senior risk capital layer designed to absorb losses only after all junior risk capital has been exhausted. This structure is conceptually similar to Aave Umbrella, though Spark’s framework additionally incorporates dedicated internal and external junior risk capital layers that absorb losses prior to senior capital exposure.Layer 2: Surplus BufferAfter all Prime Agent Risk Capital has been exhausted, losses progress to the Sky Protocol Surplus Buffer. The Surplus Buffer consists of protocol surplus accumulated through stability fees, liquidation penalties, and other system revenues retained within Sky Core. This capital functions as Internal Senior Risk Capital and is designed to absorb losses before any recapitalization mechanisms are activated. Unlike Prime-level risk capital, which is allocated directly against specific activities and exposures, the Surplus Buffer operates at the system level across the broader Sky ecosystem. Layer 3: Genesis Capital Backstop The Genesis Capital Backstop introduces an additional ecosystem-level layer of loss absorption positioned between the Surplus Buffer and the SKY Token Backstop. This layer is composed of Aggregate Backstop Capital: excess Genesis Capital held across participating Sky ecosystem entities, including Spark, Grove, Keel, Skybase, and other Genesis Agents, above their Allocated Genesis Capital requirements. The Genesis Capital Backstop is designed to expand the system’s dedicated recapitalization capacity before reliance on SKY token issuance and is activated only under predefined protocol conditions during a SKY Backstop Event. Layer 4: SKY Token Backstop If all prior layers of risk capital and surplus buffers are exhausted, the Sky Protocol can initiate the SKY Token Backstop to recapitalize the system and address residual bad debt. During an active backstop event, the protocol can generate and distribute additional SKY tokens as part of the recapitalization process. This mechanism is designed to provide a scalable, governance controlled source of recapitalization capacity during extreme system stress scenarios. The SKY Token Backstop operates as a protocol-level recapitalization mechanism rather than capital pre-allocated to any individual Prime, venue, or market exposure. Layer 5: Final System Resolution Layer As a final system-level resolution mechanism, residual deficits may ultimately be socialized across broader USDS exposure only after all protocol defined risk capital, surplus buffers, and recapitalization mechanisms have been exhausted. Under this framework, Sky can adjust the USDS target price below $1 in order to resolve any remaining system deficit. This mechanism is designed exclusively for extreme tail-risk scenarios in which the SKY Token Backstop itself becomes non-functional or reaches its predefined issuance limits before the system can be fully recapitalized. Under the current framework, affected USDS holders would also receive SKY token distributions as part of the broader recapitalization and resolution process. This layer represents the final stage of loss resolution across the broader Sky ecosystem. Note: Certain components of the loss absorption framework described above, including the Genesis Capital Backstop preceding the SKY Token Backstop, reflect a governance proposal currently progressing through the Sky Atlas Edit Weekly Cycle (week of April 20, 2026) and are not yet active at the time of writing. The remainder of the framework reflects the current Sky Atlas structure.Liquidity ArchitectureSpark Savings is designed around coordinated liquidity management rather than utilization-driven liquidity rationing. The Spark Liquidity Layer coordinates inventory across Spark Savings, SparkLend, the Sky PSM, and other approved venues in order to support predictable redemption capacity under changing market conditions. Spark Savings vaults maintain substantial available liquidity buffers. The Spark Savings USDT vault currently maintains an immediately available liquidity buffer exceeding $10 million USDT for redemptions, while the Spark Savings USDC vault has access to billions of dollars of redemption capacity through integration with the Sky PSM. At the vault level, Spark Savings contracts maintain dedicated liquidity buffers for standard withdrawal activity, allowing typical withdrawals to be fulfilled atomically on-chain. For larger withdrawals, Spark provides an asynchronous liquidity intents mechanism. Users can submit signed withdrawal requests for any amount, with the Spark Liquidity Layer coordinating liquidity movement and settlement across the broader system. Under normal operating conditions, large withdrawal requests are typically fulfilled in under one minute within approximately five Ethereum blocks. This architecture is intended to reduce dependency on static idle liquidity by coordinating capital dynamically across the broader Spark and Sky ecosystem. Transparency and Risk Monitoring Spark Savings operates with real-time transparency into backing assets, allocation activity, and liquidity conditions across the broader Spark and Sky ecosystem. Live system data is available through data.spark.fi, info.skyeco.com, and the Spark App, providing visibility into vault balances, allocation activity, liquidity buffers, and broader protocol metrics. Spark Saving Vaults are also independently assessed by Credora, with full risk reports accessible directly within the Spark App as well as the Credora website. Spark is engaging with additional independent institutional risk and ratings providers to expand third-party assessment and due diligence coverage for institutional users. Recovery Modes and Stress Events During periods of severe market stress or potential system impairment, Spark can place Savings vaults into recovery mode as part of broader risk mitigation procedures. Recovery mode allows withdrawal coordination mechanisms to be temporarily adjusted in order to support orderly liquidity management and equitable treatment across all participants during extreme conditions. These controls are designed to operate consistently with the broader Sky loss resolution framework applying the principle of equitable loss socialization across the system.SparkLendSparkLend is Spark’s permissionless money market, designed around bounded risk, constrained collateral exposure, and layered liquidity controls. The protocol operates with a deliberately narrow collateral set, multi-source oracle pricing, strict rate limits, and protocol level loss absorption mechanisms intended to reduce dependency on any single market, issuer, liquidity venue, or operational component. The rsETH market disruption earlier this year reinforced the importance of this layered approach. SparkLend’s risk architecture is designed so that failures in any individual component, including oracle infrastructure, collateral issuers, liquidators, or secondary market liquidity, do not automatically propagate into system wide bad debt.Restricted Collateral SetSparkLend maintains a deliberately narrow collateral universe designed to reduce dependency on fragmented liquidity, complex redemption assumptions, and correlated market stress across long-tail assets. ETH e-mode exposure is limited to assets with comparatively deeper liquidity and more established market structure, currently only wstETH. Spark is also in the process of fully removing BTC e-mode exposure through a publicly communicated governance deprecation process, currently scheduled for June 8, 2026. This approach is intended to prioritize predictable liquidation behavior, stronger market depth during stress events, and simpler dependency assumptions across collateral markets rather than maximizing collateral breadth or leverage opportunities. Minimal Rehypothecation Collateral supplied to SparkLend reserves remains within the reserve system and is not redeployed into external yield strategies or secondary leverage loops. This design reduces dependency on external liquidity conditions, counterparty exposure, and recursive leverage structures that can amplify stress during periods of market volatility.Rate LimitsEvery cross-module capital flow into and out of SparkLend is rate-limited at the smart-contract level. Deposits, withdrawals, cross-chain bridging, and PSM swaps each operate within predefined throughput constraints designed to bound capital movement under changing market conditions. Rather than allowing unlimited capital to move instantly between markets or infrastructure layers, these controls enforce explicit limits on how much liquidity can enter or leave specific pathways over a defined period of time. On top of these controls, Spark’s allocation framework enforces per market debt ceilings alongside inventory minimum and maximum bands across supported venues. Together, these mechanisms are designed to constrain how much capital can move through any individual route or operational pathway over a given period of time, reducing dependency on instantaneous liquidity and limiting the impact of localized stress events.Three-Oracle MedianSparkLend pricing is aggregated using a multi-source oracle architecture drawing from RedStone, Chainlink, and Chronicle. When all three oracles return valid, non-stale values, the median price is used. When two valid sources are available, their average is used, with additional fallback logic available under degraded conditions. This architecture is designed to reduce dependency on any single oracle provider or pricing source when determining collateral values and liquidation thresholds, helping mitigate risks associated with oracle outages, misconfigurations, stale pricing, or transient market anomalies. For selected assets, Spark also incorporates TWAP-based and exchange-rate pricing mechanisms as fallback pricing systems designed to maintain pricing continuity under degraded oracle conditions or periods of market stress and liquidity fragmentation.Killswitch Oracle for Pegged AssetsFor collateral assets that rely on exchange-rate or redemption-based pricing assumptions, including wstETH, weETH, cbBTC, WBTC, and LBTC, Spark incorporates an additional peg-ratio oracle designed to independently monitor divergence between market pricing and underlying asset value. The killswitch continuously compares an asset’s observed market price against its exchange-rate reference. When deviations breach predefined per-asset thresholds, SparkLend can halt new borrowing activity against the affected collateral type. This mechanism is designed to prevent users from posting collateral experiencing structural pricing dislocation at stale face-value assumptions and extracting healthy debt against impaired collateral during periods of market stress or liquidity fragmentation. The peg-ratio oracle operates independently from SparkLend’s primary multi-oracle pricing system, providing an additional layer of protection against oracle drift, redemption impairment, or severe market dislocation.Programmatic Liquidity InjectionSparkLend’s liquidity architecture is designed around coordinated inventory management rather than static liquidity pools. Through the Spark Liquidity Layer, USDS, USDC, and USDT liquidity can be programmatically reallocated into and out of SparkLend based on utilization, target borrow conditions, available system inventory, and broader allocation constraints across approved venues. When utilization increases, the Spark Liquidity Layer can deploy additional idle liquidity into SparkLend in order to support borrowing demand, withdrawals, and liquidation activity. If liquidity conditions or allocation opportunities elsewhere in the system become more favorable, idle capital can rotate across other approved venues within Spark’s broader allocation framework. This is a core property of Spark’s architecture: Spark is the largest depositor in its own market, allowing liquidity to respond programmatically to system demand rather than being constrained entirely by passive depositor behavior or utilization-driven liquidity rationing.Planned ImprovementsContinuous Collateral Risk Review Spark is expanding collateral risk assessment into a continuous review framework covering not only each asset’s standalone risk profile, but also its broader dependency structure, including issuers, custodians, oracle systems, secondary market liquidity, and redemption mechanisms. The objective is to continuously reassess how collateral behaves under changing market structure, liquidity conditions, and cross-system dependencies rather than treating risk parameters as static. Graduated Oracle Design Work is underway on a more graduated oracle framework that defaults to hard-coded or exchange-rate pricing under normal conditions and shifts toward market pricing only when sustained deviations are observed. The objective is to preserve protection against flash crashes, oracle wicks, and transient liquidity dislocations while enabling faster automated responses to genuine structural depegs or redemption impairment events. This framework is designed to complement the existing killswitch system rather than replace it, introducing a more adaptive response layer between short-term market volatility and severe collateral failure scenarios. Risk Steward Framework Spark is implementing a bounded risk steward framework designed to accelerate risk parameter updates during periods of market stress or rapidly changing liquidity conditions. Under this model, a predefined set of risk controls, including LTV reductions, supply cap adjustments, and rate model changes, can be updated within tightly constrained operational boundaries without waiting for the full governance spell process. The framework is designed to enable faster responses to time sensitive risk events while keeping all steward actions constrained by governance defined parameters and subject to ongoing oversight from Spark and Sky governance.Spark Isolated MarketsPooled lending markets provide strong capital efficiency and user experience benefits, but they also introduce shared risk across participants within the same liquidity environment. For collateral with elevated, unique, or chain-specific risk characteristics, Spark supports isolated markets through Morpho-based infrastructure. Isolated lending allows risk to be priced more precisely for each collateral type and enables specific collateral markets to be adjusted, deprecated, or removed without affecting the broader pool. Spark also uses isolated markets as the preferred framework for non-Ethereum on-chain lending. This enables integration with exchanges, custodians, and fintech distribution partners without requiring Spark to deploy and maintain fully replicated infrastructure across every chain environment. Going forward, Spark intends to prioritize isolated markets with multi-source oracle resilience rather than dependency on any single oracle provider and expand native Spark App support for participating in lending markets across additional chains.The Spark Liquidity LayerThe Spark Liquidity Layer (SLL) is a non-custodial capital allocation system operating across approved DeFi, CeFi, and TradFi liquidity venues. The system has operated continuously since November 2024.The core security property of the SLL is constraint by design. All allocation venues must be pre-approved through governance and operate within predefined rate limits and allocation constraints. Automation wallets can only move capital between approved venues and within governance-defined operational boundaries. This is designed to constrain how quickly capital can move from any individual venue and cause allocation changes to occur gradually rather than reflexively during periods of market stress. The SLL is explicitly designed around constrained automation. Even under the assumption that an automation wallet becomes compromised, capital movement remains restricted by predefined venue whitelists, throughput limits, and allocation controls. The framework is designed so no single operational component can independently create unbounded system exposure. Spark has already reduced or deprecated exposure across multiple external markets as part of a broader derisking effort and intends to remain proactive as liquidity conditions, market structure, and risk-adjusted opportunities evolve. The protocol is also developing more adaptive monitoring and automation systems designed to detect broader market stress events and coordinate defensive risk responses across the allocation framework.BridgesThe Sky and Spark ecosystem currently operates two live cross-chain bridge systems designed around constrained trust assumptions, redundancy, and bounded cross-chain risk exposure.SkyLinkSkyLink is the official Sky governance and token bridge, responsible for cross-chain Sky governance messaging alongside cross-chain USDS transfers. The governance bridge currently operates with a 4-of-7 DVN configuration designed to provide diversified verification and redundancy across independent validation providers. The token bridge currently operates with a 2-of-2 DVN configuration, with planned upgrades. SkyLink is currently deployed on Solana and Avalanche.Spark Governance Bridge (Avalanche)Spark operates a dedicated governance bridge supporting Spark Savings USDC on Avalanche. The bridge currently operates with a 2-of-2 DVN configuration and is expected to transition toward the broader SkyLink 4-of-7 verification model as part of ongoing bridge hardening efforts. There is no associated token bridge connected to this system, and cross-chain capital exposure remains intentionally limited, currently approximately $2 million. Conclusion Spark’s security architecture is the product of deliberate system design rather than any individual mechanism or control. The loss absorption waterfall, constrained capital movement, oracle systems, liquidity coordination mechanisms, and bounded governance and risk frameworks are intended to operate as a cohesive stack, reducing dependency on any single market, oracle, venue, or operational component. The objective is not to eliminate risk entirely, but to ensure that failures remain bounded, observable, and progressively absorbed rather than cascading uncontrollably across the system. As Spark continues to expand across savings, lending, and liquidity coordination, the underlying design principle remains the same: scalable on-chain credit infrastructure requires predictable liquidity, transparent risk architecture, and constrained system behavior under stress.

## Publication Information

- [Spark](https://paragraph.com/@spark-11/): Publication homepage
- [All Posts](https://paragraph.com/@spark-11/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@spark-11): Subscribe to updates
- [Twitter](https://twitter.com/sparkdotfi): Follow on Twitter