As liquidity grows, on-chain markets become more efficient. For most users, deeper pools mean tighter spreads, more stable rates, and easier access to capital. But as position sizes increase, the dynamics begin to change. What improves the experience at smaller scales introduces new constraints at larger ones.

This is not a shift in demand. It is a shift in how systems are required to handle capital.

At smaller sizes:

• liquidity appears continuous

• rates are relatively stable

• execution is immediate

At larger sizes:

• Liquidity becomes conditional on utilization, timing, and the behavior of other participants, determining whether the system can absorb sizable movements. 

• Rates respond to allocation flows, adjusting with large inflows (diluting yield) and outflows (repricing as liquidity is freed to support withdrawals and rebalancing). 

• Execution depends on timing and structure. Entering too quickly can lead to slippage and rate declines, while exiting during periods of high utilisation constrains available liquidity and introduces delays. Routing also matters — poor execution paths can significantly impact outcomes. In one recent case, a $50M transaction resulted in a materially worse outcome than expected due to thin liquidity along the execution path and MEV dynamics. 

• What mechanisms exist to absorb stress and maintain system resilience under changing conditions.

The larger the position, the more its movement influences the system itself.

At early stages, markets are optimized around yield. Capital flows to the highest return, and systems are evaluated accordingly. At scale, a different constraint emerges. The key question becomes:

Can capital move through the system without distorting it?

This introduces a new set of considerations:

• depth of available liquidity

• responsiveness of rates to large flows

• ability to enter and exit without fragmentation

• Loss absorption mechanics

Yield remains relevant, but it is no longer sufficient as a decision variable on its own.

2026 has already seen over $450M lost across dozens of incidents. The important point is not the number, it’s where those failures are coming from. 

They are not concentrated in one area. They are happening across control layers, pricing, and execution.

A few examples:

• Key and permission compromise
  In the Step Finance incident, attackers gained access to privileged internal systems rather than exploiting contracts directly, draining around $40M. The failure wasn’t code, it was control mechanisms.

• Minting and logic failure
  In the Resolv case, around $80M of unbacked assets were minted due to missing constraints between issuance and collateral. The system allowed supply to expand beyond what it could support.

• Execution failure under liquidity constraints
  A $50M transaction routed through thin liquidity resulted in an outcome closer to $36k. No exploit occurred, but routing logic, liquidity depth, and MEV dynamics led to a catastrophic execution result.

• Oracle and pricing sensitivity
  Moonwell ($1.8M loss) and Aave’s CAPO misconfiguration ($27M liquidation impact) both highlight how reliance on specific pricing configurations can introduce instability when conditions shift.

Across these cases, the pattern is consistent. Systems are not failing because capital is leaving. They are being tested by how capital moves. The important element in many cases was that nothing was broken, but the outcome is still wrong.

These are not isolated incidents. They point to a set of design requirements that become necessary as capital scales:

• Redundancy in critical inputs
  Reliance on a single pricing source creates fragility. In underlying lending markets, multiple oracle sources with validation and fallback mechanisms (such as TWAP) are used to reduce dependency on any one input.

• Defined constraints on issuance and allocation
  Systems must enforce limits on how capital is created and deployed, rather than relying on open-ended logic that can be pushed beyond safe bounds.

• Liquidity buffers and diversified deployment
  Capital cannot be fully utilised at all times. Maintaining buffers and spreading deployment across venues improves the system’s ability to accommodate withdrawals, without forcing reactive rebalancing.

• Execution-aware design
  Routing, liquidity depth, and transaction timing are not external concerns, they are part of the system itself.

At scale, these are not optimisations, but are reflected in how Spark Savings Vaults are designed to operate.

At scale, the problem is not just where capital is deployed, but how the system is designed to handle it. In isolated markets, liquidity is fragmented and reactive. Each venue operates independently, with utilization, pricing, and access determined locally.

As capital grows, this structure introduces friction:

• liquidity becomes unevenly distributed

• execution depends on navigating multiple venues

• access to capital becomes conditional rather than predictable

This is what drives the shift towards coordinated systems. Instead of deploying capital into a single venue, capital is structured across multiple environments, with allocation and access managed as part of the system itself.

In practice, this changes how the risks outlined earlier are handled:

• Liquidity is not concentrated in a single market
  Spark Savings Vaults deploy capital across different types of credit environments, which are selected and monitored against defined risk parameters and independent assessments, including on-chain lending markets and other structured strategies, rather than relying on a single source of liquidity. This reduces dependency on any one venue and limits the impact of local utilization spikes, pricing dislocations, or execution constraints.

• Access is supported by liquidity buffers
  Not all capital is deployed at once. Allocation operates within governance-defined parameters that set limits on how and where capital can be deployed, with a portion of liquidity intentionally retained to support withdrawals and reduce reliance on immediate rebalancing under changing conditions. This is complemented by system-level buffers, including protocol-level risk capital (Junior Risk Capital), designed to absorb losses within the system under defined conditions, alongside additional backstop capacity from the broader Sky ecosystem, strengthening the system’s ability to maintain resilience under changing conditions, including periods of increased withdrawal demand, without relying on reactive rebalancing or forced position adjustments.

• Allocation follows defined constraints
  Deployment is governed by parameters defined at the system level, setting limits on where and how capital can be allocated. This prevents unrestricted concentration in a single venue, while allowing allocation to adjust within those defined boundaries as conditions change.

• Governance enforced system behavior
  System parameters and allocation constraints are defined through governance-approved ‘spells’, with execution handled through established mechanisms (including multisig where required). This is reinforced by independent audits, third-party risk assessments, and fully transparent configuration and governance.

• Critical inputs are validated across multiple sources
  Pricing is not dependent on a single oracle. Where applicable, pricing relies on multiple feeds with fallback mechanisms (such as TWAP), reducing sensitivity to individual data points or misconfigurations.

• Execution is treated as part of the system
  Capital is not deployed or withdrawn through a single transaction against a single venue. Positions are managed across multiple venues, with adjustments and rebalancing occurring within defined constraints over time. This reduces dependence on any single pool or moment in time, limiting the impact of slippage, liquidity gaps, and timing when moving larger positions.

This does not remove dependency on underlying markets. It changes how capital interacts with them, reducing reliance on any single venue, pathway, or condition.

At larger position sizes, capital is no longer optimized for yield in a single venue. Capital is structured across multiple venues, with a focus on maintaining access to liquidity, managing execution risk, and preserving flexibility under changing conditions. 

In practice, this means Spark positions are increasingly managed around:

Entry and exit are planned, not assumed. Deploying or withdrawing capital is no longer treated as a single action, but as a process that depends on liquidity, timing, and market conditions.

Execution becomes a constraint, not an afterthought. How capital moves, routing, timing, and venue selection becomes as important as where it is allocated. This is also why capital at scale tends to concentrate in highly liquid, well-established assets. Stablecoins and blue-chip collateral provide the depth, pricing reliability, and market integration required to support large movements without introducing additional execution risk. At size, asset selection is not just about return, it is about whether the market can support the position.

Positions are managed across venues over time rather than through single-point execution. Within Spark, capital is not deployed or adjusted through a single transaction against a single market. Instead, positions are maintained across multiple venues, with rebalancing and adjustments occurring as conditions change. This reduces reliance on any one pool or moment in time, and allows capital to move without requiring direct interaction with each underlying market.

This shifts the model from direct, execution-dependent interaction with individual markets to a system that manages allocation, execution, and capital movement across venues within defined constraints.

Spark’s USDT Savings Vault has recently surpassed $1B, with total capital across Spark Savings Vaults now exceeding $4.5B. At this level of scale, system behavior is no longer theoretical, it becomes visible in how capital moves through the system in practice. 

This is not just a milestone in growth. It is a point where system dynamics begin to change. At smaller scales, inefficiencies are harder to detect. Liquidity appears continuous, execution feels immediate, and withdrawal assumptions are rarely tested. At larger scales, these assumptions break down. Capital movements begin to influence the system itself. Liquidity becomes conditional on utilization, timing, and the behavior of other participants, determining whether the system can absorb sizable movements.

This is where differences between systems become more apparent. Not in headline yield or short-term incentives, but in how liquidity is maintained, how positions are adjusted, and how capital moves under real conditions.

$1B is not the ceiling. It is the point where allocation frameworks are tested, execution design becomes observable, and system constraints begin to define outcomes. At this stage, execution is no longer separate from the product, it becomes part of it. And the ability to manage it becomes the defining characteristic of a truly scalable system.