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 refills at a fixed rate up to an absolute ceiling. See Rate Limits.
• 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).

Rate Limits

Every capital flow through the SLL is rate-limited at the smart-contract level. Deposits into and withdrawals from venues, cross-chain bridging, and PSM swaps each operate within predefined throughput constraints that bound capital movement under changing market conditions.

Rather than allowing unlimited capital to move instantly between markets or infrastructure layers, these controls set explicit limits on how much liquidity can enter or leave a specific pathway over a defined period of time.

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. A venue becomes usable only once governance sets a non-zero rate limit for it (see How are new venues onboarded?).

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 constrain how much capital can move through any individual route over a given period, reducing dependency on instantaneous liquidity and limiting the impact of localized stress events.

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 relayer from the ALMProxyFreezable via removeAllocator. On Diamond PAU deployments, an AdministeredAgent acts as the relayer, and Soter freezer (revoker) and grantor multisigs can remove or add the hot wallets it uses. 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.finance, 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)
• 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
• SPK farm staking and reward claiming
• Spark Vault take for funded routes
• Generic rate-limited ERC-20 transfers to whitelisted (asset, destination) pairs

The controller also supports Ethena USDe minting and burning, sUSDe cooldown, Maple redemptions and Superstate USTB subscriptions, but these were offboarded in the September 10, 2026 spell by setting their rate limits to zero, along with Aave Core USDe, the Morpho v1 DAI and USDS vaults, Curve PYUSD/USDS, sUSDS/USDT and weETH/WETH-ng, B2C2, and the Anchorage USDT and USAT transfer routes.

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

Which venues were added recently?

Venues onboarded in 2026 include:

• Binance OTC swaps through an OTCBuffer (June 18, 2026)
• Uniswap v4 USDG/USDS and RLUSD/USDS pools, and Curve RLUSD/USDC for swaps (August 13, 2026)
• SparkLend USDG and RLUSD (August 27, 2026)
• Sentora RLUSD Morpho Vault V2 (0xFC8C624B6080a0a780583799f2A862DE936F6E22), with a 10M RLUSD limit and 100M RLUSD per day of regeneration (September 10, 2026)
• USDT bridging to Arbitrum and X Layer through LayerZero (July 2 and July 16, 2026)
• Transfers to Paxos (February 26, 2026)

The October 22, 2026 spell also bridged 100M sUSDS from the Ethereum ALM Proxy to the Arbitrum ALM Proxy. The full current configuration is published with each spell on the Sky Forum.

What networks are supported by SLL?

The following networks are currently supported by the SLL:

• Ethereum
• Base
• Arbitrum
• Optimism
• Unichain
• Avalanche
• Robinhood
• X Layer

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.

How does the SLL interact with Liquidity Intents?

The SLL is the liquidity source for Savings Liquidity Intents. When a user wants to withdraw more than a Spark Savings vault holds as idle liquidity, they submit a request to the Savings Vault Intents contract on Ethereum or X Layer. The SLL then brings liquidity back into the vault and fulfills the request. The user keeps their vault shares until fulfillment.

The SLL steps in this flow are rate limited like any other SLL action:

1. Deploying deposits. The SLL's ALM Proxy holds TAKER_ROLE on each Spark Savings vault. The relayer calls takeFromSparkVault to move deposits from the vault to the ALM Proxy, then allocates them to approved venues. This is limited by the LIMIT_SPARK_VAULT_TAKE key for that vault.
2. Request. The user calls request() on the intents contract, which emits a RequestCreated event. The vault must be whitelisted for intents, and the amount must sit within that vault's minimum and maximum.
3. Preparing liquidity. The Spark ALM Planner picks up the request offchain. The relayer unwinds positions through the ALM Controller, for example by redeeming from an ERC-4626 vault or bridging USDC back with CCTP. Each step uses its own rate limit.
4. Refilling the vault. The relayer calls transferAsset(asset, vault, amount) to send the underlying asset from the ALM Proxy back into the vault. This is limited by the LIMIT_ASSET_TRANSFER key for that asset and vault.
5. Fulfillment. An address with the RELAYER role on the intents contract calls fulfill(). The intents contract calls redeem() on the vault, which sends the assets directly to the user's recipient address. This call does not go through the ALM Controller. It redeems the full request or reverts, and it must happen before the request deadline.

Liquidity for a vault can sit on another network. X Layer spUSDC is an example: the SLL can take USDC from the vault, bridge it to Ethereum with CCTP, and deploy it there. To fill an intent, the relayer redeems on Ethereum, bridges the USDC back to X Layer, and transfers it into spUSDC before calling fulfill(). The October 8, 2026 spell whitelisted X Layer spUSDC for intents and gave the RELAYER role on the X Layer intents contract to the spUSDC PAU AdministeredAgent, alongside the ALM relayer multisig.

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.