Debt-Based PnL Methodology

The debt-based PnL methodology is the computational framework used within Sky Protocol's Monthly Settlement Cycle to determine the net financial obligation between each Prime Agent and Sky Core. Under this model, Prime Agents — currently Spark, Grove, and Obex — borrow USDS from Sky Core through Allocator Vaults at the Agent Credit Line Borrow Rate, which equals the Base Rate (equivalent to the Sky Savings Rate plus 30 basis points). The methodology calculates maximum debt fees and then deducts reimbursements for idle capital, sUSDS holdings, and Sky Direct Exposure adjustments to arrive at a net settlement amount.

This approach represents Stage 1 of Sky's "Simplified PnL" implementation, as codified in Atlas section A.2.5.1.2.2.1 ^[2]. The defining characteristic of Stage 1 is that Allocator Vault stability fees are set to zero on-chain — meaning no interest accrues automatically within the Ethereum Virtual Machine — while the equivalent obligations are calculated off-chain and settled via governance Executive Votes ^[2]. This design choice prioritizes calculation transparency and auditability during the protocol's early maturation phase, deferring on-chain automation to later infrastructure stages.

The methodology is operated by Denna Labs, which performs calculations at the close of each monthly period and publishes results to the Sky Forum for independent verification by the Core Council Risk Advisor ^[34]. The first operational cycle covered July through August 2025, with the settlement conducted in September 2025 ^[4]. Since that inaugural cycle, the scope has expanded from initial Demand Side Primitives to encompass the full suite of Supply Side calculations for all active Prime Agents, including per-chain tracking across Ethereum mainnet and Layer 2 networks.

At its core, the debt-based PnL methodology answers a single question: of the total interest that Prime Agents would have owed at the full Agent Credit Line Borrow Rate, how much should they actually pay after accounting for idle capital, sUSDS holdings that already accrue yield internally, and Sky-owned exposures that Prime Agents implement but do not economically bear? The answer to that question — expressed as a net USDS amount per Prime per month — forms the basis of the Sky Core Executive Vote that transfers funds between Prime Allocator Vaults and Sky's Surplus Buffer.

Conceptual Framework

The debt-based PnL methodology is grounded in a specific theory of how Prime Agents relate to Sky Core economically. Prime Agents are not standalone entities operating with their own capital; they are borrowers who access Sky Core's credit creation capacity through Allocator Vaults, deploy that borrowed USDS into yield-generating strategies ^[36], and owe Sky a defined interest charge on the borrowed capital ^[21]. The debt creates a financial obligation — analogous to interest on a loan — that the methodology must quantify precisely each period.

The intellectual challenge is that this obligation cannot simply be read from an on-chain state. Under Stage 1, the on-chain stability fee for Prime Allocator Vaults is set to zero, meaning the Maker protocol's core accounting engine does not accumulate any interest charge against Prime debt ^[2]. The off-chain methodology must therefore replicate what on-chain accrual would have produced, using time-weighted averages of daily debt snapshots and rate data, and then apply the appropriate deductions before arriving at the net settlement figure ^[19]. This off-chain replication must be auditable — every daily input, every intermediate calculation, and every adjustment must be traceable to primary data sources — because the resulting Executive Vote mints new debt into Prime Allocator Vaults, directly affecting the protocol's balance sheet.

The methodology also reflects a layered philosophy about what capital counts as truly "borrowed" for PnL purposes. A Prime Agent borrowing $10 billion from Sky Core and holding $1 billion of that in idle stablecoins is not actually deploying $10 billion productively. The idle portion earns the Agent Rate (Base Rate minus 10 basis points for standard holdings), so charging the full Base Rate on the entire $10 billion would over-state the Prime's effective cost. Similarly, sUSDS already accrues the Sky Savings Rate internally — charging the full Base Rate on sUSDS holdings without acknowledging the embedded SSR accumulation would double-count the Sky Spread. The deduction logic systematically corrects for these effects, ensuring that the net settlement amount reflects only the genuine economic cost of the Prime's deployment decisions.

The Debt-Based Approach

The starting point for every monthly PnL calculation is maximum debt fees: the total interest that would have accrued if the full Agent Credit Line Borrow Rate applied to the Prime's entire outstanding debt for the entire period, with no adjustments ^[10]. This figure serves as a theoretical ceiling — the most the Prime could possibly owe — before reimbursements reduce it to the actual net amount.

The word "maximum" is deliberate. The methodology is structured as a ceiling minus deductions, rather than as a bottom-up revenue calculation. This design choice has practical advantages: it grounds the calculation in a verifiable on-chain fact (the outstanding debt balance) rather than in a reconstruction of yield earned across dozens of protocols, chains, and asset classes. The reimbursement deductions are then applied systematically, each with its own data source and formula, to arrive at the net figure.

Under Stage 1, Allocator Vault stability fees are set to zero on-chain ^[2]. This means that if one were to query the Maker protocol's vat contract for accumulated debt fees on a Prime's Allocator Vault, the result would be zero. The off-chain methodology produces the economically equivalent amount that would have accrued under a non-zero stability fee equal to the Agent Credit Line Borrow Rate. When the Executive Vote executes, it mints this calculated amount as new debt on the Allocator Vault — replicating the effect of on-chain accrual in a single discrete step rather than continuously.

Rate Hierarchy

The entire calculation rests on a coherent rate hierarchy defined in Atlas Article A.3. Understanding the relationships between these rates is prerequisite to understanding why the deduction structure takes the form it does.

Rate	Definition	Relationship	Atlas Reference
Base Rate	Key interest rate defining all others	—	A.3.1.2.1
Sky Savings Rate (SSR)	Rate earned by sUSDS holders	Base Rate − 0.3%	A.3.1.2.2.1
Agent Credit Line Borrow Rate	Rate Primes pay on debt	= Base Rate (default)	A.3.1.2.5.1
Agent Rate	Rate Primes earn on idle USDS/DAI/sUSDS	Base Rate − 0.1%	A.3.1.2.3.1
Distribution Reward Fee	Ecosystem reward component	0.2% of the 0.3% spread	A.2.8.2.2.2.3.1
Sky Spread	Sky's retained margin	0.1% of the 0.3% spread	A.2.8.2.2.2.3.3

The 30-basis-point spread above the SSR decomposes as follows: 20 basis points represent the Distribution Reward Fee, which compensates for the ecosystem rewards that sUSDS holders receive through the integration boost mechanism, and 10 basis points represent the Sky Spread, which is Sky Protocol's retained margin ^[6] ^[7]. Together, these sum to the 30-basis-point gap between the SSR and the Base Rate.

The rate relationships can be expressed algebraically:

Base Rate = SSR + 0.20% (Distribution Reward Fee) + 0.10% (Sky Spread)
         = SSR + 0.30%

Agent Credit Line Borrow Rate = Base Rate (= SSR + <span class="citation-group">0.30%) <sup><a href="#source-9" class="source-link" data-source-num="9" data-source-title="Agent Credit Line Borrow Rate - A.3.1.2.5.1" data-source-url="/atlas#A.3.1.2.5.1" data-source-type="web">[9]</a></sup></span>
Agent Rate = Base Rate − 0.10% (= SSR + <span class="citation-group">0.20%) <sup><a href="#source-8" class="source-link" data-source-num="8" data-source-title="Agent Rate - A.3.1.2.3.1" data-source-url="/atlas#A.3.1.2.3.1" data-source-type="web">[8]</a></sup></span>

This means that Primes pay 30 basis points more than what sUSDS holders earn on their deposits. That 30-basis-point spread is the cost of access to Sky Core's credit creation capacity. The 10-basis-point gap between the Agent Rate and the Agent Credit Line Borrow Rate represents the Sky Spread — Sky's retained margin on the difference between what Primes earn on idle capital and what they owe on borrowed capital.

The Base Rate itself is a governance-set parameter, maintained by the Core Executor Agents in consultation with the Core Council Risk Advisor ^[5] ^[20]. It applies uniformly across all Prime Agents as the default Agent Credit Line Borrow Rate — there are no per-Prime borrow rate differentials in the current implementation, beyond the subsidized borrowing program described in the Borrow Rate Subsidy section below.

Calculation Methodology

The debt-based PnL calculation proceeds through five sequential steps, each producing an intermediate figure that feeds into the final net settlement amount. The process is deterministic: given the same input data (daily debt snapshots, SSR rate history, asset balances, and external price feeds), the calculation produces the same output regardless of who runs it. This determinism is essential because independent verification by the Core Council Risk Advisor must reach a consistent result.

The five steps are: (1) compute Maximum Debt Fees as the theoretical ceiling; (2) compute Idle Stablecoin Reimbursements for capital not actively deployed; (3) compute sUSDS Profit adjustments for holdings that already accrue SSR internally; (4) compute Sky Direct Exposure Adjustments for assets that Prime Agents implement but Sky owns; and (5) compute the net settlement amount by subtracting total reimbursements from Maximum Debt Fees, and applying any applicable Borrow Rate Subsidy. Each step uses a defined data source and formula. The following subsections describe each in detail.

Step 1: Maximum Debt Fees

Maximum Debt Fees represent the total interest that would accrue if the Agent Credit Line Borrow Rate applied to the Prime's full outstanding debt for every day of the measurement period, without any adjustments. The formula is ^[10]:

Maximum Debt Fees = Time-Weighted Average Debt × Base Rate (prorated to period)

The Time-Weighted Average (TWA) debt is computed from daily snapshots taken at midnight UTC block numbers. For each day in the period, the system records the outstanding USDS balance in the Prime's Allocator Vault (the vat gem balance). The time-weighted average is then:

TWA Debt = Σ(Debt_i × Duration_i) / Total_Duration

where Debt_i is the debt level on day i, Duration_i is the number of milliseconds that debt level was in effect, and Total_Duration is the total period length in milliseconds. This granularity matters because the Base Rate can change within a month as the Sky Core Council adjusts SSR, which in turn shifts the Base Rate. The system blends rate segments using time-weighted averages: each distinct SSR level produces a corresponding Base Rate segment, and the monthly rate is computed as a time-weighted blend of all segments during the period.

To illustrate with a concrete example:

Monthly period: November 1–30, 2025 (30 days)
Time-weighted average debt: $5,000,000,000
Base Rate during period:
  Nov 1–14: SSR 8.45% → Base Rate 8.75% APY (14 days)
  Nov 15–30: SSR 8.20% → Base Rate 8.50% APY (16 days)

Blended monthly rate:
  = (8.75% × 14 + 8.50% × 16) / 30 = (122.5 + 136.0) / 30 = 8.617% APY

Prorated to 30 days:
  = 8.617% / 365 × 30 = 0.7083%

Maximum Debt Fees = $5,000,000,000 × 0.7083% = $35,416,667

The debt snapshot at each daily block captures the total outstanding principal in the Allocator Vault's urn. If debt is drawn down or repaid mid-period, the TWA reflects only the actual period of indebtedness. This ensures that Primes are not charged for debt they did not hold, and are charged for the full balance on days they did hold it.

For SSR rate data, the system syncs rate change events from the sUSDS contract on an hourly basis, storing each event with its block timestamp. When computing the blended rate for a period, these events serve as segment boundaries. Intra-day rate changes are handled with millisecond precision: if SSR changes at 14:00 UTC on November 15, the November 15 rate contribution is split proportionally between the morning rate and the afternoon rate.

Step 2: Idle Stablecoin Reimbursement

Prime Agents do not deploy 100% of borrowed USDS into yield-generating positions at all times. Capital in transit, reserves held in ALM proxy wallets, and structural minimums in lending protocol positions create idle balances that earn the Agent Rate rather than the full deployment return. The methodology reimburses Primes for the Agent Rate earned on these idle balances, recognizing that charging the full debt fee on idle capital would penalize Primes for operational realities outside their control ^[8].

Idle asset sources include:

USDS, DAI, and USDC held directly in ALM Proxy wallets
Idle portions of lending positions in SparkLend, Morpho Blue, Aave, and Curve pools
USDS held in PSM3 liquidity reserves on Layer 2 chains

For idle balances in lending protocols, the calculation must account for utilization. A $100 million Morpho vault position with 80% utilization has $20 million idle — sitting in the vault as unborrowed liquidity reserve. Only that idle $20 million earns the Agent Rate; the deployed $80 million generates lending yield that is accounted for separately through the net debt fee mechanism. Utilization data for SparkLend positions comes from on-chain pool queries at the midpoint of each measurement period. For Morpho positions, utilization is sourced from the Morpho GraphQL API. For Curve pools, the system computes daily ratios of stablecoin versus sUSDS within the pool from on-chain pool contract data.

The reimbursement formula is:

Idle Stablecoin Reimbursement = TWA Idle Balance × Agent Rate (prorated to period)

For standard holdings, the Agent Rate is Base Rate minus 10 basis points ^[8]. However, Spark receives the full Base Rate (not the Agent Rate) on USDS and sUSDS balances held in PSM contracts — a Spark-specific exception reflecting its role as the primary PSM operator ^[16]. This exception applies to PSM3 balances on all chains where Spark operates PSM infrastructure (Base, Arbitrum, Optimism, Unichain).

Step 3: sUSDS Profit

When a Prime Agent holds sUSDS — the savings token that represents deposited USDS earning the Sky Savings Rate — the position already accrues the SSR internally through the sUSDS vault's share price appreciation. If the methodology treated sUSDS the same as idle USDS, it would implicitly assume the Prime earns nothing on those holdings, understating reimbursements and overstating the net amount owed ^[15].

The sUSDS Profit module corrects for this by recognizing that the Prime holds sUSDS which already earns the SSR, and the full Agent Rate to which the Prime is entitled on those holdings is Base Rate (= SSR + 30bps). Since sUSDS already delivers the SSR component internally, the incremental supplement owed to the Prime is only the 30-basis-point spread above SSR ^[15]:

sUSDS Profit = TWA sUSDS Balance × 30bps (annualized, prorated to period)

The 30-basis-point spread is derived from the rate hierarchy defined in the Atlas ^[6]. It decomposes into:

20 bps: Distribution Reward Fee — the supplement that compensates for ecosystem rewards that sUSDS holders receive through integration boosts, which Prime Agent sUSDS positions do not capture in the same form ^[17]
10 bps: Sky Spread — Sky's retained margin ^[7]

The sUSDS Profit module applies only to sUSDS held in ALM (Asset-Liability Management) positions that the Prime Agent manages directly. sUSDS held in PSM3 contracts follows a separate calculation path (the PSM3 sUSDS Profit module) because PSM3 assets are classified as Sky Direct Exposures and are governed by the Sky Direct Exposure reimbursement rules rather than the standard sUSDS Profit formula.

An important accounting distinction arises between Ethereum mainnet and Layer 2 chains. On Ethereum, sUSDS in ALM positions is already credited through the sUSDS Profit module at the SSR, leaving the 30bps spread as the net charge to the Prime — the spread is implicitly retained as the difference between the Base Rate charged on debt and the SSR credited on sUSDS. On Layer 2 chains, sUSDS held in PSM3 contracts follows a separate accounting path through the PSM3 sUSDS Profit module, which applies the 30bps spread directly. This separation ensures that sUSDS is never double-counted across modules while maintaining consistent economic treatment regardless of which chain holds the position.

The time-weighted average sUSDS balance uses the same daily snapshot methodology as the debt balance, with each day's position captured at midnight UTC and time-weighted over the full measurement period.

Step 4: Sky Direct Exposure Adjustment

Sky Direct Exposures are a specialized category of capital deployment where Sky Protocol retains direct economic ownership of assets while delegating implementation to a Prime Agent ^[11]. Because Sky — not the Prime — bears the economic risk and captures the yield on these exposures, Prime Agents are not charged the Agent Credit Line Borrow Rate on capital deployed into Sky Direct Exposures, and all yield flows exclusively to Sky's Surplus Buffer ^[12].

The Sky Direct Exposure Adjustment quantifies this relief. For each Sky Direct Exposure held by a Prime, the system computes:

Sky Direct Exposure Adjustment = max(0, Base Rate Cost − Actual Revenue)

This formula has an important asymmetry: it is floored at zero. If a Sky Direct Exposure generates actual yield that exceeds the Base Rate cost, no reimbursement is necessary — the Prime simply owes no net amount on that portion of debt, and all yield above the Base Rate flows to Sky. If actual yield falls short of the Base Rate cost, the Prime is reimbursed for the shortfall, ensuring it does not subsidize Sky's direct investments from its own capital ^[12].

Current Sky Direct Exposures as of February 2026 include ^[13]:

Treasury Bills — Grove investments in BUIDL, JTRSY, and USTB tokenized on Ethereum
Collateralized Loan Obligations — Grove's investment in JAAA on Ethereum
Peg Stability Modules — Spark and Grove USDC held in PSM3 contracts on Base, Arbitrum, Optimism, and Unichain
Curve Pools — Spark's USDT position in the sUSDS/USDT Curve pool on Ethereum

No Risk Capital requirements apply to Sky Direct Exposures, and they do not count toward or against a Prime's Actively Stabilizing Collateral calculations ^[30] ^[31].

Actual revenue for each exposure is computed from price appreciation over the measurement period. For tokenized treasury bills and CLOs, the system fetches the token's NAV price at period start and period end, computes the holding period return, and compares it to the Base Rate cost on the equivalent USDS balance. For PSM3 USDC positions, actual revenue is determined by the yield earned on the USDC through the custodian (such as Coinbase Custody), measured against the Base Rate cost.

Step 5: Net Amount

The final settlement amount aggregates all preceding components:

Net Amount = Maximum Debt Fees
           − Idle Stablecoin Reimbursement
           − sUSDS Profit
           − Sky Direct Exposure Adjustments
           − PSM3 Idle Reimbursement
           − PSM3 sUSDS Profit
           − Borrow Rate Subsidy (where applicable)

A positive net amount means the Prime owes Sky Core: the Executive Vote transfers that amount from the Prime's Allocator Vault to Sky's Surplus Buffer ^[21]. A negative net amount — which would occur if total reimbursements exceeded the Maximum Debt Fees — means Sky Core owes the Prime: a mechanism exists for debt reduction in the Prime's Allocator Vault by the corresponding amount, though this outcome is uncommon in normal operating conditions.

The net amount is calculated independently for each Prime Agent (Spark, Grove, Obex) and then aggregated into a single Executive Vote that covers all Primes simultaneously. The vote includes a line-item breakdown per Prime, enabling governance participants to verify that the correct amounts are being settled before approval.

Per-Prime Agent Calculation Paths

Each of the three active Prime Agents — Spark, Grove, and Obex — has a distinct calculation path reflecting its unique portfolio composition, operational mandate, and any agent-specific exceptions negotiated through the Prime Program Ecosystem Accord or equivalent governance processes. The debt-based PnL system runs parallel calculation modules for each Prime, then aggregates the results into the five-step framework described above. Understanding per-Prime calculation paths is essential for interpreting the monthly settlement documents published to the Sky Forum and for auditing any specific component of the net settlement amount.

The differences between Prime calculation paths are not arbitrary. They reflect genuine differences in how each Prime deploys capital: Spark operates across multiple chains with a heterogeneous portfolio spanning DeFi lending, PSM infrastructure, and Curve liquidity; Grove focuses on institutional credit (real-world assets) with a more concentrated portfolio; and Obex operates a single exposure through an ERC-4626 vault. These structural differences require different data sources, different utilization calculation methods, and different treatment of special categories like RWA revenue and PSM custody yield.

One universal principle applies across all three Primes: the calculation uses daily snapshots taken at midnight UTC, with time-weighted averaging over the full measurement period. The system maintains continuity by using the most recently confirmed snapshot for any day that falls between collection intervals, ensuring the calculation produces a complete result for every day in the measurement period.

Spark

Spark is Sky Protocol's DeFi-focused Prime Agent, operating SparkLend, Spark Savings, and the Spark Liquidity Layer across Ethereum mainnet, Base, Arbitrum, Optimism, and Unichain ^[22]. Its PnL calculation involves the highest number of parallel modules, reflecting the breadth of its capital deployment and its unique role as the primary PSM3 operator on Layer 2 chains.

Module	Calculation	Description
Debt Fees	TWA debt × (SSR + 30bps)	Maximum debt fees on Ethereum Allocator Vault debt
Idle Stablecoins	TWA idle balance × Base Rate (or Agent Rate)	USDS/DAI/USDC in ALM wallets + idle lending (SparkLend, Morpho, Aave, Curve)
sUSDS Profit	TWA sUSDS × 30bps spread	sUSDS held in ALM positions × annualized spread, prorated to period
Sky Direct Exposure — PSM3 USDC	TWA USDC in L2 PSM3 × Base Rate vs. actual yield	USDC in PSM3 on Base, Arbitrum, Optimism, Unichain
PSM3 Idle USDS	TWA USDS in PSM3 × Base Rate	USDS liquidity reserves in L2 PSM3 contracts
PSM3 sUSDS Profit	TWA sUSDS in PSM3 × 30bps	sUSDS held in L2 PSM3 × spread, prorated to period

Spark-specific calculation rules:

PSM Agent Rate premium — Spark earns the full Base Rate — not the standard Agent Rate (Base Rate minus 10bps) — on USDS and sUSDS balances held in PSM contracts ^[16]. This premium reflects Spark's operational responsibility for maintaining PSM liquidity on Layer 2 chains and its role as Sky's primary peg stability infrastructure.
Lending utilization sources — For SparkLend positions, the idle portion is derived from on-chain pool utilization queried at the period midpoint. For Morpho Blue vault positions, utilization is sourced from the Morpho GraphQL API at the period midpoint. For Curve pool positions (such as the sUSDS/USDT pool), daily utilization ratios are computed from on-chain pool contract state.
Curve pool date gate — The sUSDS/USDT Curve pool was added as a Sky Direct Exposure effective November 1, 2025. All Sky Direct Exposure modules — including the Curve pool — return zero for any days before November 1, 2025. This date gate prevents retroactive reimbursement for periods before the Sky Direct Exposure framework was operationally active.
PYUSD treatment — Spark maintains a Curve pyUSD pool position as part of its ALM deployment. Unlike the sUSDS/USDT Curve pool (which is a Sky Direct Exposure), PYUSD is treated as Spark's own investment risk: Spark pays the full Agent Credit Line Borrow Rate on funds borrowed to invest in PYUSD and realizes the full profit and loss on those positions ^[37]. The PYUSD portion of the pool receives no idle stablecoin reimbursement.
Multi-chain tracking — Spark's Ethereum Allocator Vault is the source of all outstanding debt. L2 chain positions (on Base, Arbitrum, Optimism, Unichain) are tracked for reimbursement purposes — PSM3 balances and idle L2 assets generate reimbursements even though the corresponding debt sits on Ethereum mainnet. Allocation data for each chain is collected hourly, with daily figures derived from the snapshot closest to midnight UTC.

For lending positions involving both deployed and idle capital, the idle portion is calculated by applying the complement of the utilization rate to the total position size. A SparkLend pool with total liquidity of $1 billion and 85% utilization has $150 million idle, generating an Agent Rate reimbursement on that $150 million for the days it was in that configuration. The midpoint utilization approach simplifies the calculation compared to daily utilization tracking, at the cost of some precision for pools with highly variable utilization within a given month.

Spark's calculation produces the most data-intensive output of the three Primes, given its multi-chain presence and heterogeneous asset mix. The monthly XLSX workbook for Spark contains separate worksheets for Ethereum mainnet (debt, ALM idle, ALM sUSDS), Base (PSM3 idle, PSM3 sUSDS, Sky Direct Exposure USDC), Arbitrum, Optimism, and Unichain — along with a summary sheet computing the net settlement amount across all modules.

Grove

Grove is Sky's institutional credit Prime Agent, focused on real-world asset investments including tokenized treasury bills and collateralized loan obligations ^[23]. Its calculation path is more concentrated than Spark's, reflecting a portfolio centered on a small number of high-value RWA positions rather than a diversified DeFi lending and liquidity provision strategy.

Module	Calculation	Description
Debt Fees	TWA debt × (SSR + 30bps)	Maximum debt fees on Ethereum Allocator Vault debt
RWA Exposure	max(0, Base Rate Cost − Actual Revenue)	For JHLCO, JHST, BUIDL, USTB on Ethereum
PSM3 USDC Sky Direct	TWA USDC in L2 PSM3 × Base Rate vs. actual yield	USDC in PSM3 on L2 chains operated by Grove

Grove-specific calculation rules:

RWA price sources — Daily prices for JHLCO (Janus Henderson CLO token) and JHST (Janus Henderson short-term treasury token) are sourced from the Centrifuge GraphQL API, which provides NAV prices for tokenized real-world assets. BUIDL (BlackRock's tokenized treasury fund) and USTB prices are sourced from on-chain contract data.
JHLCO position cap — The Janus Henderson CLO position carries a $325 million cap. If the actual balance of JHLCO tokens exceeds this cap on any given day, both the revenue calculation and the principal calculation for that day are pro-rated to the capped amount. Any exposure above $325 million is not treated as a Sky Direct Exposure — it reverts to standard allocation treatment with full Agent Credit Line Borrow Rate applicability and no Sky Direct Exposure reimbursement. This cap prevents unbounded expansion of Sky Direct Exposure relief for a single position.
Actual revenue from NAV appreciation — For each RWA token, actual revenue is computed as the change in NAV price from period start to period end, applied to the time-weighted average token balance during the period. This holding period return is compared to what the Base Rate would have yielded on an equivalent USDS balance over the same period. If NAV appreciation outpaces the Base Rate, no reimbursement is due. If NAV appreciation falls short, Grove receives reimbursement for the difference.
PSM ownership and positive carry — Grove assumed operational and accounting ownership of a subset of PSM3 operations in 2025, paying the Base Rate on all associated assets ^[25]. Grove can generate positive carry if the USDC yield exceeds the Base Rate cost for the period ^[35]. In that case, the Sky Direct Exposure adjustment for PSM3 USDC is zero (floored at zero per the formula), and the positive carry accrues to Sky.
No idle stablecoin module — Grove does not operate a separate idle stablecoin calculation module analogous to Spark's ALM idle reimbursement. Grove's non-RWA assets in PSM3 are handled exclusively through the Sky Direct Exposure path. This simplification reflects Grove's portfolio structure: unlike Spark, Grove does not maintain large USDS/DAI positions in DeFi lending protocols where idle capital is a meaningful structural component.

The absence of a separate idle stablecoin module means Grove's calculation involves fewer intermediate figures than Spark's, making it somewhat more straightforward to audit. The principal complexity in Grove's calculation comes from the RWA revenue attribution — specifically, ensuring that NAV prices are sourced consistently from approved data feeds, and that the JHLCO cap is applied correctly on days when the position exceeds the $325 million threshold.

Obex

Obex is Sky Protocol's incubator Prime Agent, operationalizing a turnkey solution for the development and launch of new Prime and Halo Agents within the Sky ecosystem ^[24]. Its calculation path is the simplest of the three active Primes, reflecting a portfolio currently concentrated in a single ERC-4626 vault position (Maple Finance's syrupUSDC).

Module	Calculation	Description
Debt Fees	TWA debt × (SSR + 30bps)	Maximum debt fees on Ethereum Allocator Vault debt

Obex-specific calculation rules:

No reimbursements — Unlike Spark and Grove, Obex receives no reimbursements of any kind. There are no idle stablecoin reimbursements, no sUSDS profit adjustments, and no Sky Direct Exposure adjustments. Obex owes the full Maximum Debt Fees to Sky Core each period.
No borrow rate subsidy — Obex is explicitly excluded from the borrow rate subsidy program introduced in January 2026. The subsidy is limited to Spark and Grove under the Prime Program Ecosystem Accord ^[14]. Obex pays the full Agent Credit Line Borrow Rate on its entire outstanding debt with no subsidy offset.
No Sky Direct Exposures — Obex does not hold any Sky Direct Exposures. The Maple syrupUSDC position is Obex's own capital deployment, not a Sky-owned exposure.
No PSM3 operations — Obex does not operate PSM3 contracts on any chain.

The simplicity of Obex's calculation path means its monthly workbook is substantially shorter than Spark's or Grove's. Obex's Net Amount equals its Maximum Debt Fees — no deductions apply.

Borrow Rate Subsidy

Beginning January 1, 2026, Spark and Grove receive a subsidized borrow rate on up to $1 billion of eligible debt each, under the Prime Program Ecosystem Accord ^[14]. The subsidy is structured as a linear ramp-up that starts at the US Treasury 3-month T-bill rate on January 1, 2026, and converges to the full Agent Credit Line Borrow Rate over 24 months, completing in December 2027.

The subsidized rate formula is ^[18] ^[32]:

Subsidized Rate = T-Bill Rate + ((Base Rate − T-Bill Rate) × T / 24)

where T is the month counter beginning at 1 for January 2026 and reaching 24 for December 2027. This produces a smooth linear interpolation from the T-bill rate to the full Base Rate over the 24-month program period.

Month	T	Example (Base Rate 8.75%, T-Bill 4.25%)	Effective Subsidized Rate
Jan 2026	1	4.25% + (4.50% × 1/24)	4.44%
Apr 2026	4	4.25% + (4.50% × 4/24)	5.00%
Jul 2026	7	4.25% + (4.50% × 7/24)	5.56%
Jan 2027	13	4.25% + (4.50% × 13/24)	6.69%
Jun 2027	18	4.25% + (4.50% × 18/24)	7.63%
Dec 2027	24	4.25% + (4.50% × 24/24)	8.75%

Key program parameters:

Eligible debt is capped at $1 billion per Prime per day for subsidy purposes ^[14]
If a Prime's total outstanding debt falls below $1 billion on a given day, the subsidy reimbursement for that day is proportionally reduced — the Prime receives subsidy only on the debt it actually has, not on the full $1 billion cap ^[26]
Borrowing above $1 billion incurs the full Agent Credit Line Borrow Rate with no subsidy on the excess portion ^[27]
The 3-month T-bill rate is sourced daily from the US Treasury XML data feed and time-weighted for any days where the rate changes
The subsidy amount is calculated daily (using the T-bill rate for each day and the eligible debt for that day) and aggregated over the monthly period for settlement

The subsidy USD amount for a given month is:

Subsidy USD = Σ_daily [(Base Rate − Subsidized Rate) × min(Daily Debt, $1B) × (1/365)]

This daily aggregation accommodates changes in both the T-bill rate and the outstanding debt balance throughout the month. The resulting subsidy is subtracted from the Net Amount as a final adjustment, reducing the amount the Prime owes to Sky Core.

The economic rationale for the subsidy is that Spark and Grove, as the two largest and most established Prime Agents, are still in the process of building out their risk capital and revenue infrastructure. The subsidy reduces their effective borrowing cost during this buildout phase, enabling them to scale without the full Base Rate burden that would apply to a fully mature Prime Agent. The 24-month linear ramp ensures a predictable trajectory toward full cost recovery.

Infrastructure and Data Pipeline

The debt-based PnL methodology relies on an automated data pipeline that collects on-chain snapshots at regular intervals, computes time-weighted averages, integrates external data feeds, and generates auditable XLSX workbooks to support the independent verification process. A key design objective is reproducibility: the calculation inputs must be derivable without manual data collection, so that the Core Council Risk Advisor can independently query the same on-chain data and reach the same result.

Data Collection

The pipeline collects hourly on-chain snapshots for each Prime across all chains where they operate — Ethereum, Base, Arbitrum, Optimism, and Unichain. Each snapshot records the Prime's Allocator Vault debt, ALM asset balances, and PSM3 positions at that point in time. The daily figure used in calculations is derived from the snapshot taken closest to midnight UTC; the hourly cadence provides data continuity in the event that any individual snapshot is unavailable.

In addition to on-chain state, the pipeline collects daily external data feeds: token prices (USDS, DAI, USDC, sUSDS) for balance valuation, RWA net asset values (JHLCO, JHST, BUIDL, USTB) for RWA-backed positions, and the 3-month US T-bill rate used in the borrow rate subsidy calculation.

Time-Weighted Average Computation

The TWA computation is the mathematical core of the methodology. For any balance or rate that changes during the measurement period, the time-weighted average is computed as:

TWA = Σ(Value_i × Duration_i) / Total_Duration

The computation proceeds as follows:

All snapshot values for the measurement period are collected and sorted chronologically
Each pair of consecutive snapshots defines a segment over which the value is treated as constant
Duration is computed in milliseconds between snapshot timestamps
Where no snapshot exists at the exact start of a period, the last available snapshot before that point is used to ensure data continuity across the full period
The total duration is the exact millisecond span from period start to period end, normalized to a year-fraction for rate application

The same TWA approach handles both balance calculations (debt, idle stablecoin, sUSDS) and rate calculations (SSR blending for the Base Rate). For SSR, the segment boundaries are the rate change events sourced from the sUSDS contract, and the TWA produces the blended annual rate applicable to the full period.

All interest rates in the calculation pipeline are expressed as per-second rates, matching the native format in which the SSR is stored on-chain (a per-second accumulation rate in RAY format at 1e27 scale). The 30bps sUSDS spread and all derived rates are converted to the same per-second form, so that daily interest is computed as balance × perSecondRate × 86,400 without intermediate unit conversions. This convention allows the TWA engine to handle intra-day rate changes — such as an SSR update mid-period — by simply weighting each per-second rate by the exact number of seconds it was active.

External Data Sources

Source	Data Provided
Blockchain RPC providers	Historical blockchain state for balance and debt queries
Morpho GraphQL API	Vault utilization for Spark's Morpho idle stablecoin calculations
Centrifuge GraphQL API	Daily NAV prices for Grove's JHLCO and JHST tokens
US Treasury XML feed	Daily 3-month T-bill rates for borrow rate subsidy
SparkLend on-chain contracts	Pool utilization at period midpoints for SparkLend idle calculations
Curve pool contracts	Daily stablecoin/sUSDS ratios for Curve pool idle calculations

Output Format

At period close, the calculation engine generates one XLSX workbook per Prime per month. Each workbook contains:

A summary sheet with the Net Amount and all intermediate figures
A debt fees sheet with daily debt snapshots and TWA computation
Per-module sheets for each reimbursement category (idle stablecoins, sUSDS profit, Sky Direct Exposure adjustments, PSM3 modules, borrow rate subsidy where applicable)
A rate data sheet showing the SSR history and blended Base Rate for the period
An external data sheet showing RWA prices, T-bill rates, and utilization figures sourced from external feeds

These workbooks are shared with the Core Council Risk Advisor for independent verification. The Allowed Deviation between the two independent calculations is defined in the Atlas ^[34]; if the calculations agree within that tolerance, the agreed figure proceeds to Executive Vote without further reconciliation.

Monthly Settlement Cycle

The debt-based PnL calculation does not operate in isolation — it sits within the broader Monthly Settlement Cycle (MSC) governed by Atlas Article A.2.5 ^[1]. The MSC is the complete governance and operational process through which net revenue calculations, risk capital adjustments, and operational payments are synchronized across the Sky ecosystem on a monthly basis. Understanding the MSC provides the institutional context for the debt-based PnL methodology: who calculates what, who verifies it, and what governance action implements the resulting transfers.

The MSC is significant not only as an accounting mechanism but as a coordination mechanism. Prime Agents operate semi-autonomously throughout the month, making their own deployment decisions within governance-approved parameters. The MSC provides the moment of collective accounting when all deployed capital is assessed, all yield is attributed, and the net financial obligations between each Prime and Sky Core are settled. This periodic settlement creates predictability for both Prime Agents (who know exactly what they will owe each month) and for Sky's Surplus Buffer (which receives a defined inflow from Prime settlements).

Implementation Stages

The Atlas defines three implementation stages for the MSC, representing a progression from manual off-chain calculation toward fully automated on-chain settlement:

Stage	Name	Interest Mechanism	Settlement Method	Status
1 (Current)	Simplified PnL	Off-chain calculation; Vault stability fees = 0	Executive Vote	Active
2	Virtual Base Rate	Off-chain calculation; full Atlas formulas	Executive Vote	Planned
3	On-chain Base Rate	Interest accrues on-chain continuously	Executive Vote for residuals only	Future

Stage 1 is currently active ^[2]. Its defining characteristic is that Prime Allocator Vault stability fees are set to zero on-chain — meaning no interest accumulates automatically — while the equivalent obligation is computed off-chain and settled via Executive Vote at month-end.

Stage 2 will upgrade the calculation to the full Atlas formula set, computing a "Virtual Base Rate" that precisely tracks what would have accrued under the complete rate hierarchy ^[28]. Stage 2 remains a governance-configured off-chain calculation but uses more sophisticated formulas that eliminate the simplifications necessary in Stage 1. The settlement mechanism remains Executive Vote-based.

Stage 3 brings interest accrual fully on-chain, with the Base Rate applied directly to Prime Allocator Vaults so that interest accumulates continuously within the protocol's core accounting engine ^[29]. Under Stage 3, the role of Executive Votes shifts from implementing the entire settlement to addressing only residual amounts not captured by on-chain accrual. This stage reduces the trust assumptions in the settlement process, since the primary interest calculation becomes verifiable directly from on-chain state.

Settlement Process

The monthly settlement follows a defined operational process ^[3] ^[34]:

At the close of the measurement period (typically the last day of the month), Core GovOps creates a forum post in the "Sky Core" category tagged monthly-settlement-cycle, opening the settlement process formally.
Denna Labs publishes an "Initial Calculation" within 7 calendar days of period close. This includes the XLSX workbooks and a written summary of the net settlement amount per Prime.
The Core Council Risk Advisor reviews the Initial Calculation and publishes an independent calculation, also within the 7-day window or shortly after.
If the two independent calculations agree within the Allowed Deviation defined in the Atlas, the agreed amount is finalized without further reconciliation.
Core GovOps packages the finalized settlement figures into a Sky Core Executive Vote, which specifies the USDS transfer amounts per Prime.
Upon passage of the Executive Vote by MKR/SKY token holders, the settlement is executed: the specified USDS amounts are transferred from Prime Allocator Vaults to Sky's Surplus Buffer.

The 7-calendar-day window for Initial Calculation publication is a governance commitment — Denna Labs must publish within this window or provide a documented explanation for any delay. The forum post format creates a public audit trail accessible to any governance participant who wishes to examine the calculation methodology or challenge specific figures.

Settlement History

The MSC has been operational since mid-2025, with each cycle expanding in scope as new Prime Agents and asset categories were onboarded ^[4]:

Period	Settlement Date	Notes
July–August 2025	September 2025	Initial cycle; Demand Side Primitives only
September 2025	October 2025	First Supply Side calculation; Spark only
October 2025	November 2025	Full Spark and Grove calculations; Obex added
November–December 2025	January 2026	Combined two-month period ^[33]
January 2026	February 2026	First cycle with borrow rate subsidy for Spark and Grove

The November–December 2025 combined period was established by Atlas Article A.2.4.1.2.1.6.4, which specified that no separate December 2025 cycle would be conducted ^[33]. Subsequent periods have returned to the standard monthly cadence.

The scope expansion from "Demand Side Primitives only" in the July–August 2025 inaugural cycle to the full multi-Prime, multi-chain, Sky-Direct-Exposure-adjusted calculation as of January 2026 reflects the rapid maturation of Sky Protocol's operational infrastructure. The debt-based PnL methodology has had to evolve in parallel, adding new modules (PSM3 idle, PSM3 sUSDS, JHLCO cap, borrow rate subsidy) with each major scope expansion.

Laniakea: From Monthly to Automated Settlement

The transition from manual monthly settlement to automated daily settlement is governed by the Laniakea implementation roadmap, an eleven-phase progression (Phase 0 through Phase 10) that incrementally introduces infrastructure, automation, and market mechanisms. The five-step debt-based PnL methodology described in this article — gross debt fees, idle credit offset, sUSDS profit sharing, SDE reimbursement, and net settlement amount — remains structurally stable across all phases. What changes is the measurement period over which the calculation is applied (monthly to daily), the degree of automation in data collection and verification, and the governance mechanisms that trigger settlement. The underlying accounting logic is designed to be cadence-agnostic.

The transition is not merely a change in frequency. Monthly settlement concentrates all accounting, verification, and governance action into a single event, creating a 30-day window of unresolved obligation between Prime Agents and Sky Core. Daily settlement compresses this window to 24 hours, reducing counterparty exposure and enabling more responsive capital management. The infrastructure investments required to support this compression are substantial, which is why the roadmap proceeds through defined phases rather than as a single step.

Phase 1: Infrastructure Foundation (Current)

Laniakea Phase 1 focuses on pragmatic delivery of foundational infrastructure while manual settlement continues unchanged. The phase does not alter the settlement cadence or introduce settlement tracking — its purpose is to establish the tooling layer that subsequent phases build upon.

Phase 1 delivers several architectural components relevant to PnL infrastructure:

Diamond PAU — Modular, upgradeable Allocation System contracts implementing the EIP-2535 Diamond standard. Each allocation target (SparkLend, Morpho, PSM3, etc.) is implemented as a separate facet, enabling new allocations to be added without redeploying the entire contract. This modularity simplifies future additions to the debt-based PnL calculation when new allocation targets are introduced.
Synome-MVP — An operational database storing risk parameters, NFAT records, and configuration data for Prime Agent allocation systems. Synome serves as the machine-readable complement to the Sky Atlas, providing structured data that automated systems can consume. For PnL calculations, Synome provides authoritative configuration data such as Sky Direct Exposure caps and special rate exceptions.
lpla-verify beacon — A low-power beacon that monitors Prime positions and calculates Capital Ratio Requirements in read-only mode. Critically, lpla-verify does not track settlement status, detect late payments, or calculate penalties — these capabilities are deferred to the lpla-checker beacon introduced in Phase 2. lpla-verify provides continuous position monitoring between formal settlement events but does not participate in the settlement process itself.
Configurator Unit — Enables GovOps teams to manage Prime operations without requiring Governance Spells for routine parameter changes. The two-tier access model (aBEAMs for Core Council, cBEAMs for GovOps) reduces latency between governance decisions and implementation, which becomes increasingly important as settlement frequency rises in later phases.

Under Phase 1, the debt-based PnL methodology itself does not change — the same five-step calculation applies with the same monthly cadence and Executive Vote settlement mechanism. The infrastructure changes improve the quality and timeliness of inputs to the calculation, and lpla-verify provides continuous independent position monitoring, but the settlement process remains manual.

Phase 2: Formalized Monthly Settlement

Laniakea Phase 2 formalizes the monthly settlement cycle that Phase 1 runs manually. The headline deliverable is lpla-checker, a beacon that extends lpla-verify's monitoring capabilities with settlement tracking, completeness verification, late payment detection, and penalty calculation. Where lpla-verify observes positions passively, lpla-checker actively verifies that settlement obligations are met and flags delinquency.

Phase 2 introduces a structured monthly timeline with three distinct periods:

Active Period — The interval during which Prime Agents deploy capital and accrue obligations under the debt-based PnL methodology.
Settlement Window — A defined window following the Active Period during which all calculations are finalized, verified by lpla-checker, and prepared for execution.
Moment of Settlement — The instant at which settlement parameters take effect and obligations are resolved.

Phase 2 also introduces prepayment obligations and penalty mechanics. Primes must prepay their calculated interest to the Generator before the Moment of Settlement. Late payments incur penalties calculated as:

Penalty = Owed Amount × Penalty Rate × Time Late

The Penalty Rate is a governance-set parameter (for example, 0.1% per hour of lateness). In early phases, a temporary forgiveness process allows penalties to be waived through governance action, acknowledging that operational processes are still maturing. All penalty events are logged in Synome, creating an auditable record.

A key constraint introduced in Phase 2 is that all PnL calculations must be deterministic and reproducible from on-chain data combined with Synome inputs. This requirement ensures that lpla-checker can independently replicate any calculation and that settlement outcomes are verifiable by any party with access to the same data sources.

Phase 3: Daily Settlement

Laniakea Phase 3 transitions operations from a formalized monthly cadence to a daily settlement cycle. The canonical daily schedule operates on a fixed 24-hour interval:

Period	Timing	Duration
Active Window	16:00 UTC → 13:00 UTC	21 hours
Processing Window (Lock)	13:00 UTC → 16:00 UTC	≤ 3 hours
Moment of Settlement	16:00 UTC	Instant

The interest calculation formula reflects the daily period:

Daily Interest = Average Outstanding Debt × (Annual Base Rate / 365)

During the Processing Window (13:00 to 16:00 UTC), GovOps automation finalizes calculations, computes prepayment obligations, and submits them for verification by lpla-checker. At 16:00 UTC, the Moment of Settlement occurs: new parameters take effect and penalties begin accruing against any unmet obligations. Primes must complete prepayment before 16:00 UTC or face the penalty mechanics introduced in Phase 2.

Phase 3 settlement is governance-directed, not autonomous. GovOps teams operate the automation tooling that performs the calculations, but the process does not run on an autonomous sentinel. There are no sealed-bid auctions for risk capital at this stage — OSRC and Duration capacity continue to be allocated through governance-set parameters. The weekly settlement cycle documented in Laniakea represents an alternative cadence design but is not a mandatory intermediate step in the main roadmap, which proceeds directly from formalized monthly (Phase 2) to daily (Phase 3).

The 3-hour processing window is the most demanding operational constraint in the daily model. All data collection, TWA computation, module calculations, verification, and execution must complete within this window. This effectively requires the debt-based PnL calculation to be fully automated with deterministic output that lpla-checker can verify in parallel.

Beyond Phase 3: LCTS, Generator PAU, and Auction Activation

Later phases of the Laniakea roadmap introduce structural changes to the debt accounting layer and market-based allocation mechanisms, though the core PnL methodology continues to apply.

Phase 4 launches the Liquidity Constrained Token Standard (LCTS) with srUSDS as the first Generator-level product. In pre-auction mode, the Core Council sets the srUSDS rate directly. LCTS operates on the same daily cadence established in Phase 3, with a single-generation model (lock at 13:00, settle at 16:00 UTC).

Phase 6 introduces the Generator PAU, a fundamental restructuring of the debt accounting layer. The current architecture assigns each Prime Agent its own ilk within MCD. Under Generator PAU, all Primes interact with a single Generator ilk through an ERC4626 interface, replacing the per-Prime ilk model. This change affects how debt positions are represented on-chain but does not alter the PnL calculation logic — the five-step methodology applies identically to debt measured through the Generator PAU interface.

Phase 9 deploys stl-base, the autonomous sentinel, and activates sealed-bid auctions for OSRC and Duration capacity. This is the point at which market-based price discovery replaces governance-directed allocation, introducing a carry mechanism for risk capital pricing. Prior to Phase 9, all allocation decisions remain under governance control.

Key Differences Across Settlement Cadences

Aspect	Phase 1 (Current)	Phase 2	Phase 3	Phase 9+
Frequency	~30 days (manual)	~30 days (formal)	1 day	1 day
Interest Formula	debt × rate / 12	debt × rate / 12	debt × rate / 365	debt × rate / 365
Settlement Method	Executive Vote	Formalized + lpla-checker	GovOps automation	Autonomous stl-base
Position Monitoring	lpla-verify	lpla-checker	lpla-checker	lpla-checker
Settlement Tracking	None	lpla-checker	lpla-checker	lpla-checker
Prepayment Required	No	Yes	Yes	Yes
Penalty Mechanics	None	With forgiveness	Active	Active
Risk Capital Auction	None	None	None	Sealed-bid (OSRC)
Debt Interface	Per-Prime ilks	Per-Prime ilks	Per-Prime ilks	Generator PAU (ERC4626)
Processing Window	7+ calendar days	Settlement Window	≤ 3 hours	≤ 3 hours
Counterparty Exposure	~30 days	~30 days	1 day	1 day

The progression from Phase 1 through Phase 9 represents a systematic reduction in counterparty risk and governance overhead. The window during which Prime Agent obligations to Sky Core remain unresolved shrinks from a month to a single day, while allocation decisions transition from governance-directed to market-based. Throughout this progression, the debt-based PnL calculation itself — the five steps from gross debt fees to net settlement amount — remains the stable analytical core, applied with increasing frequency and decreasing manual intervention.

Governance-Defined Parameters and Edge Cases

The debt-based PnL calculation incorporates several parameters, position limits, and date-dependent adjustments that are defined by Atlas governance rather than derived algorithmically from on-chain state. These are deliberate economic design choices — each reflects a specific governance rationale concerning rate composition, subsidy structure, exposure limits, or the timing of arrangement activation. Understanding why each parameter exists clarifies the economic logic of the settlement methodology and provides context for interpreting the monthly workbooks.

Rate and Subsidy Parameters

The sUSDS spread of 30 basis points above the SSR is applied in both the sUSDS Profit and PSM3 sUSDS Profit modules. This spread is not an arbitrary margin — it equals the sum of two governance-defined rate components: the Distribution Reward Fee of 20 basis points (A.2.8.2.2.2.3.1) and the Sky Spread of 10 basis points (A.2.8.2.2.2.3.3) ^[17] ^[7]. The Distribution Reward Fee compensates for ecosystem rewards that sUSDS holders receive through integration boosts, which Prime Agent sUSDS positions do not capture in the same form. The Sky Spread represents Sky's retained margin on deployed capital. Together, these components define the full Agent Credit Line Borrow Rate as SSR + 30bps, and the 30bps spread in the sUSDS Profit modules reflects the incremental supplement owed to Primes above what sUSDS already earns internally through the SSR.

The Borrow Rate Subsidy program — effective January 1, 2026, with a 24-month duration (T = 1 for January 2026 through T = 24 for December 2027) and a $1 billion debt cap per Prime per eligible day — is structured to support Spark and Grove during the buildout phase of their risk capital infrastructure ^[14] ^[18]. The subsidy reduces each eligible Prime's effective borrowing cost by interpolating between the US Treasury 3-month T-bill rate and the full Base Rate, following the formula defined in the Atlas (A.2.8.2.2.2.2.2). The 24-month linear ramp ensures a predictable trajectory toward full cost recovery, preventing abrupt rate increases that could destabilize Prime operations during scaling. The $1 billion cap prevents unlimited subsidy exposure — any debt above this threshold incurs the full Agent Credit Line Borrow Rate with no subsidy offset ^[27]. The January 2026 start date reflects the governance approval timeline under the Prime Program Ecosystem Accord.

Position Limits and Date Gates

Grove's JHLCO (Janus Henderson CLO) position carries a governance-imposed allocation cap of $325 million. This cap reflects the maximum CLO exposure that governance has approved as a Sky Direct Exposure. On any day when the actual JHLCO balance exceeds $325 million, both the revenue calculation and the principal calculation for that day are pro-rated to the capped amount. Exposure above the cap reverts to standard allocation treatment with full Agent Credit Line Borrow Rate applicability and no Sky Direct Exposure reimbursement. The cap ensures that the PnL calculation respects the governance-approved exposure limit and prevents unbounded expansion of Sky Direct Exposure relief on a single concentrated position.

The sUSDS/USDT Curve pool's idle stablecoin calculation applies only from November 1, 2025, onward. This date gate corresponds to the activation date of the Sky Direct Exposure arrangement for this Curve pool. Before that date, the pool had no relationship to Sky's Direct Exposure framework, and there was no capital deployed under Sky Direct Exposure terms to account for. The date gate ensures that the idle stablecoin reimbursement is applied only to the period during which the governance-approved arrangement was in effect.

Lending Utilization Sources

For idle stablecoin calculations in Spark's ALM modules, utilization data flows from different sources depending on the lending protocol, reflecting the distinct data availability characteristics of each platform:

SparkLend — On-chain query to the pool's getReserveData function at the midpoint of the measurement period. The supply and borrow balances at that point determine the utilization ratio applied to the entire period.
Morpho Blue — Vault utilization from the Morpho GraphQL API, queried at the period midpoint. The utilization ratio is applied to compute the idle fraction of each Morpho position.
Aave — On-chain query similar to SparkLend, using the Aave pool's data provider contracts.
Curve pools — Daily ratios of stablecoin versus sUSDS within the pool are computed from on-chain pool balance queries. Unlike the midpoint approach used for lending protocols, Curve pool utilization is calculated daily and time-weighted, reflecting the higher volatility of AMM pool composition relative to lending protocol utilization.

Risk and Limitations

The debt-based PnL methodology, as implemented under Stage 1 of the Monthly Settlement Cycle, carries several categories of risk and limitation that are important for governance participants and protocol analysts to understand. These do not represent flaws unique to the current implementation — they are inherent characteristics of any off-chain calculation system that interfaces with on-chain financial data at a monthly settlement frequency.

Calculation Risk

The most fundamental limitation of Stage 1 is that the off-chain calculation is not trustlessly verifiable by Ethereum node operators. Until Stage 3 brings interest accrual fully on-chain, the settlement amounts in each Executive Vote are the product of a calculation that governance participants must evaluate based on the published XLSX workbooks and the independent verification by the Core Council Risk Advisor. This creates a trust requirement — governance participants trust that both independent calculations (Denna Labs' and the Risk Advisor's) are methodologically correct and that the inputs sourced from the blockchain and external APIs are accurate.

The two-calculation verification model provides a meaningful check against errors: if Denna Labs' calculation contains a systematic error, the independent Risk Advisor calculation will likely diverge by more than the Allowed Deviation, triggering reconciliation. However, if both calculations use the same erroneous assumptions — for example, both using the wrong block number for a midpoint utilization query — the verification process would not catch the error.

Blockchain reorganizations present a theoretical risk for daily snapshot data. If a block containing a significant position change is later reorganized out of the canonical chain, the corresponding snapshot could be incorrect. In practice, Ethereum reorganizations beyond one or two blocks are extremely rare, and the hourly snapshot cadence means any reorganized block would be quickly superseded by the next snapshot.

Data Source Dependencies

The calculation depends on multiple external data sources beyond the Ethereum blockchain:

The Morpho GraphQL API for Morpho vault utilization
The Centrifuge GraphQL API for Grove's RWA token NAV prices
The US Treasury XML feed for daily T-bill rates

Any of these APIs could experience outages, return incorrect data, or change their data format without notice. The calculation system has retry logic for API failures, but a multi-day API outage could require manual intervention to obtain the necessary data through alternative means before settlement can proceed. For the US Treasury feed in particular, government XML data formats have historically been stable, but the reliance on an external government service introduces a dependency outside the control of Sky Protocol.

Parameter Governance Risk

The governance-defined parameters embedded in the PnL calculation — rate spreads, subsidy terms, position caps, and date gates — must be updated whenever Atlas governance modifies the underlying economic arrangements. If a governance decision establishes a new rate exception, adjusts a position cap, or activates a new Sky Direct Exposure arrangement at the start of a period but the calculation system is not updated to reflect the change in time, the settlement for that period would be incorrect and would require a correction in a subsequent cycle. The dual-calculation verification model mitigates this risk — a parameter mismatch between Denna Labs' calculation and the Risk Advisor's independent calculation would surface as a deviation exceeding the Allowed Deviation threshold — but the possibility of both parties applying stale parameters simultaneously, while unlikely, cannot be entirely excluded.

Transition Risk

The progression from Stage 1 to Stage 3 of the interest mechanism, and from monthly to daily settlement cadence under the Laniakea roadmap, introduces operational risk at each transition point. Changing the settlement frequency requires recalibrating the prorating of annual rates (from /12 to /365), adjusting the time-weighted average computation windows, and managing the processing deadline reduction from days to hours.

Each cadence change also requires coordination between the calculation infrastructure, the verification process, and the governance execution layer. A misconfiguration at any of these layers — incorrect rate proration, stale snapshot data, or delayed settlement execution — could result in over- or under-settlement for the transition period. The phased approach — Stages 1 through 3 for the interest mechanism, Phases 1 through 9 for settlement infrastructure — is designed to minimize this risk by introducing changes incrementally with verification checkpoints between each phase.

Sky Direct Exposures — Capital exposures held by Sky Protocol but implemented through Prime Agent Allocation Systems, covering treasury bills, CLOs, PSM3 positions, and Curve pools
Spark Capital Allocation — Complete technical walkthrough of how capital flows through Spark's Allocation System from Sky Core through to DeFi lending markets
Sky Savings Rate — The foundational rate that defines the Base Rate hierarchy and all downstream interest rates in the PnL methodology
Spark — Sky Protocol's DeFi-focused Prime Agent with the most complex debt-based PnL calculation path
Grove — Sky's institutional credit Prime Agent, focused on real-world assets and tokenized securities
Obex — Sky Protocol's incubator Prime Agent with a simplified single-vault PnL calculation
Laniakea Phase 1 — Infrastructure foundation delivering Diamond PAU architecture, Synome-MVP, and lpla-verify beacon while manual settlement continues
Laniakea Phase 2 — Formalized monthly settlement with lpla-checker, prepayment obligations, and penalty mechanics
Laniakea Phase 3 — Daily settlement cycle with 3-hour processing windows and governance-directed automation
Laniakea Roadmap — Full eleven-phase implementation roadmap from Phase 0 through Phase 10
Prime Settlement Methodology — The five-step calculation methodology applied across all settlement cadences
Weekly Settlement Cycle — Alternative weekly settlement cadence design documented within the Laniakea framework