Spark Liquidity Layer

The Spark Liquidity Layer (SLL) operates as a non-custodial capital allocator for Spark across DeFi/CeFi and TradFi opportunities. It has been operating without fault since November 2024. At its core, the SLL is designed to ensure that capital movement is constrained, predictable, and bounded under all conditions, including periods of market stress.

Risk Architecture

The key security feature of the SLL is that Spark governance must set approved venues in advance, subject to strict rate limits. The automation wallets can only move funds between these pre-approved venues at the defined rate limits.

These constraints ensure that capital cannot be rapidly drained from any single venue, and that allocation changes occur gradually rather than reflexively under stress conditions. This directly addresses a core failure mode observed in recent market events: unconstrained capital movement leading to rapid liquidity depletion and cascading stress across markets.

The threat model assumes a RELAYER can be fully compromised. Smart-contract constraints are designed to prevent value from moving outside the ALM system, while rate limits, slippage constraints, and emergency freezing bound the damage such a relayer can cause.

Even under this assumption, capital remains restricted to predefined venues and rate limits, ensuring no single component can introduce unbounded risk to the system.

In concrete contract terms, four mechanisms enforce these properties:

• Whitelist by rate-limit key. Every action on the controllers is gated by a keccak256 rate-limit key, typically combined with the target address (vault, pool, aToken, OTC exchange, destination domain). A venue with no governance-configured rate-limit key reverts on first interaction — there is no path to an unapproved address.
• Linear regeneration with a hard ceiling. Each rate limit has a maxAmount (absolute ceiling), a slope (tokens-per-second regeneration), and a lastAmount consumed at the last action. The current limit is min(slope · elapsed + lastAmount, maxAmount). A compromised relayer's per-window exposure is bounded by the configured ceiling; sustained pressure is bounded by the slope.
• Per-venue slippage floors. Curve, Uniswap V4, AAVE, and OTC operations require a non-zero maxSlippage configured per pool / aToken / exchange. The convention is inverted from common DeFi usage: 0.999e18 means "the resulting value must be at least 99.9% of expected"; a value of 0 disables the integration.
• Bounded OTC exposure. OTC swaps go through dedicated OTCBuffer contracts. Only one outstanding swap per whitelisted exchange can be in flight; a new send is blocked until the prior swap has been claimed back (subject to slippage and a configurable recharge).

Roles

The SLL uses a small set of governance-controlled operational roles:

• RELAYER — can call controller functions to move capital between approved venues. These calls remain constrained by approved integrations, balances, slippage checks where applicable, and rate limits.
• FREEZER — can immediately revoke a compromised RELAYER from the controllers via removeRelayer, and (where the freezable proxy variant is used) detach a compromised controller from the ALMProxy via removeController. Governance can then reassign or reissue relayer credentials.

Monitoring

The SLL is actively monitored across several independent layers:

• Price movements and collateral valuations across all venues where SLL capital is deployed.
• Oracle deviation and liveness tracking, including heartbeat checks and price-deviation thresholds, to detect stale or manipulated feeds.
• Utilization rate alerts on sudden spikes that may signal abnormal borrowing activity or liquidity stress at integrated venues.
• LTV distribution tracking across active borrower positions in markets where the SLL is allocated, to identify concentration near liquidation thresholds.
• Real-time threat detection through third-party security monitoring, with automated alerts routed to on-call team members for immediate response.
• Sky ecosystem-level oversight on top of Spark-internal monitoring.

Public dashboards: data.spark.fi, info.skyeco.com.

Liquidity Backstop

The SLL can inject capital into a SparkLend reserve, a Morpho vault curated by Spark, or a Spark Savings vault to support depositor withdrawals while liquidations or redemptions settle through normal channels. This backstop is bounded by approved venues, rate limits, and risk parameters set by governance.

Where to Verify

Atlas Sources

The following Sky Atlas sections govern the controls described above:

• A.6.1.1.1.2.6.1 — Allocation System Primitive
• A.6.1.1.1.2.6.1.2.1.1 — Spark Liquidity Layer Architecture
• A.6.1.1.1.2.6.1.2.1.1.1 — Spark Liquidity Layer Addresses
• A.6.1.1.1.2.2.2 — Spark Root Edit Primitive

FAQ

What integrations are supported by SLL?

The ALM Controller currently supports the following integration types:

• USDS minting and burning via the Sky allocation system, and 1:1 USDS↔DAI conversion
• Mainnet PSM swaps between USDS and USDC; PSM3 deposits and withdrawals on supported L2s
• USDC bridging via Circle CCTP, and per-asset OFT bridging via LayerZero
• AAVE-compatible lending markets, including SparkLend and Aave v3
• ERC-4626 vaults, including Spark-curated Morpho vaults
• Curve stableswap pools (add liquidity, remove liquidity, swaps), restricted to 1:1 stablecoin pools
• Uniswap V4 stablecoin pools (mint / increase / decrease positions, swaps), restricted to 1:1 hookless pools with governance-configured tick limits
• OTC desks via dedicated OTCBuffer contracts (bounded per-exchange outstanding exposure)
• Ethena USDe minting and burning, including delegated-signer management; sUSDe cooldown and unstaking
• EtherFi weETH staking, withdrawal request, and claim (via a dedicated WEETHModule that handles the withdrawal NFT)
• Lido wstETH staking, withdrawal request, and claim via the Lido withdrawal queue
• Maple Finance redemption requests and cancellations
• Superstate USTB subscriptions
• SPK farm staking and reward claiming
• Spark Vault take for funded routes
• Generic rate-limited ERC-20 transfers to whitelisted (asset, destination) pairs

Additional integrations can be onboarded over time through governance-controlled configuration and controller upgrades.

What networks are supported by SLL?

The following networks are currently supported by the SLL:

• Ethereum
• Base
• Arbitrum
• Optimism
• Unichain
• Avalanche

Additional networks will be integrated on a continuous basis.

What are the liquidity constraints for cross-chain liquidity?

The SLL ensures there is always ample liquidity for users to enter or exit Spark Savings vaults on supported networks. Sky aims to keep a substantial portion of USDS collateral backing in cash reserves, providing a healthy buffer for redemptions even at large volumes.

Why is there a 1-of-2 SAFE authorized on the ALM Controller contract?

This SAFE is used as a smart wallet for the SLL automation to enable batching of transactions and rotating of hot wallet keys (the second signer). Funds are not custodied by this wallet, and it is only capable of allocating to governance-approved venues. This is similar to the ALLOCATOR role in the Morpho curation model.

How are new venues onboarded?

A venue becomes usable only when governance sets a non-zero rate limit for the corresponding key (typically keccak256(LIMIT_<ACTION>, <venue address>)). Until that key is configured, every relayer call targeting that venue reverts. New venues are onboarded with conservative rate limits and expanded as operational experience accumulates.

Where are whitelists enforced in the ALM Controller contract?

Every allocation function in the ALM Controller has an associated call to the RateLimits contract. This request for a rate limit is keyed on the asset, pool, or destination argument, which provides an implicit whitelist on that parameter. If the target is not whitelisted, the rate limit returns zero and the call reverts.

Has the Spark Liquidity Layer been audited?

Yes, you can find the audit reports here: Spark Liquidity Layer Audit Reports

Who controls the Spark Liquidity Layer?

Sky Governance determines the use cases supported by the SLL, such as networks and protocols, as well as the accepted risk parameters for each use case, including rate limits, maximum fund amounts or maximum volumes.