Simplified PnL Documentation

Introduction

Simplified PnL is a revenue sharing mechanism that calculates monthly distributions between Sky (the base rate provider) and Prime Agents (allocation system operators) based on yield-bearing asset performance. The system tracks how Prime Agents deploy Sky's capital across multiple blockchains and protocols, ensuring fair revenue attribution based on actual yields generated.

Core Revenue Principles

The revenue split follows a straightforward model:

Base Rate Priority: Sky receives returns at a 5.05% annual base rate for providing capital
Excess Capture: Prime Agents keep yields generated above the base rate threshold
Loss Protection: Standard assets protect Prime Agents from negative revenue when underperforming

This structure incentivizes Prime Agents to seek high-yielding opportunities while ensuring Sky receives predictable returns on deployed capital.

How It Works

The Simplified PnL system monitors Prime Agent asset deployments across seven blockchains, calculating revenue based on time-weighted average values and historical yields. Rather than using month-end snapshots alone, the system tracks asset values continuously throughout the period to ensure fair attribution.

Supported Blockchains

The system currently operates across EVM-based networks:

Ethereum (primary chain with majority of allocations)
Base
Arbitrum
Optimism
Unichain
Avalanche
Plume

Asset Categories and Treatment

The system classifies assets into distinct categories, each with specific revenue split rules:

Standard Assets:

Most yield-bearing deployments (Morpho vaults, Aave positions, etc.)
Sky receives actual yield up to base rate (5.05%)
Prime Agent revenue floored at zero when underperforming
No downside risk for Prime Agents on these positions

Strategic Assets:

PYUSD and SparkLend USDT positions maintained for ecosystem importance
Sky always charges full base rate regardless of actual performance
Prime Agent pays shortfalls when yields fall below 5.05%
Creates accountability for strategic position management

Real World Assets (RWA):

BlackRock BUIDL and similar tokenized treasury products
Off-chain yields not measurable via on-chain exchange rates
Sky receives 100% of yield/returns generated by these positions
Prime Agent receives zero revenue from these holdings

USDS Savings Products:

SparkLend USDS deposits and spUSDS holdings
Use Sky Savings Rate (SSR, typically ~5%) instead of 5.05% base rate
Aligned with USDS ecosystem policy objectives
Prime Agent keeps excess above SSR threshold

Non-Yielding Reserves:

PSM3 holdings and reserve stablecoins
Serve liquidity functions rather than yield generation
Excluded entirely from PnL calculations
Neither party receives revenue from these positions

Payment Schedule

Revenue calculations operate on a monthly basis using calendar month boundaries. Settlement occurs after month-end once all data collection and yield measurements complete. The process requires:

Complete hourly asset snapshots throughout the month
Historical yield measurements for the period
Time-weighted average calculations across all positions
System state snapshot at period end

Algorithm Details

Time-Weighted Average Calculation

The system calculates revenue using time-weighted averages to account for assets held at varying levels throughout the period:

Time-Weighted Average Value = Σ(Balance × Δt) / Total Period Duration

Where:

Balance = Asset value in USD at each time interval
Δt = Duration of time interval in seconds
Total Period Duration = Total seconds in the calculation period
Σ represents the sum across all time intervals

This approach ensures revenue calculations reflect actual deployment duration rather than arbitrary snapshot timing.

Revenue Split Formulas

Standard Assets

When yields meet or exceed the base rate:

Sky Revenue = TWA Balance × Base Rate × (Days in Period / 365)

Prime Agent Revenue = TWA Balance × (APY - Base Rate) × (Days in Period / 365)

When yields fall below the base rate:

Sky Revenue = TWA Balance × APY × (Days in Period / 365)

Prime Agent Revenue = 0

This flooring mechanism protects Prime Agents from losses on standard deployments.

Strategic Assets

Sky always charges the full base rate:

Sky Revenue = TWA Balance × Base Rate × (Days in Period / 365)

Prime Agent Revenue = TWA Balance × (APY - Base Rate) × (Days in Period / 365)

Prime Agent revenue becomes negative when APY < Base Rate, creating downside risk for these positions.

Real World Assets

Sky receives all yield generated by off-chain positions:

Sky Revenue = TWA Balance × Off-Chain Yield Rate × (Days in Period / 365)

Prime Agent Revenue = 0

Note: Off-chain yields are measured separately and the full yield amount is attributed to Sky.

USDS Savings Products

Using SSR as the baseline instead of base rate:

Sky Revenue = TWA Balance × SSR × (Days in Period / 365)

Prime Agent Revenue = TWA Balance × (APY - SSR) × (Days in Period / 365)

Prime Agent revenue is floored at zero when products underperform SSR.

APY Measurement Methods

Asset yields are measured using two primary approaches based on token mechanics:

Exchange Rate Method:

Used for rebasing tokens (spUSDS, Aave aTokens)
Tracks exchange rate appreciation between period start and end
APY calculated by annualizing rate changes

Balance Method:

Used for non-rebasing yield tokens
Monitors balance growth in reference wallets
Filters out transfers to isolate organic yield

Yield Measurement Failure Handling

When yield measurements fail, the system responds based on configuration:

Default Behavior:

Assets with failed measurements are excluded from calculations
Neither party receives revenue from unmeasurable assets
Errors logged for manual review

Fallback Mode (when explicitly enabled):

Assets default to 0% APY if measurement fails
Strategic assets would generate negative Prime Agent revenue
Should only be used when inclusion is mandatory

Technology Stack

Backend Infrastructure

Programming Language and Framework:

TypeScript with Next.js 14 App Router
API Routes for RESTful endpoints
Server-side rendering for data processing

Database Technology:

PostgreSQL for persistent data storage
Kysely as the SQL query builder
Supabase for database hosting and management
Type-safe database queries with generated schemas

Blockchain Integration:

Alchemy as the primary blockchain data provider
Web3 libraries for contract interactions
Multi-chain support through unified interface

External Service Dependencies:

Alchemy API for blockchain data across all networks
Supabase for database operations and hosting
Sentry for error tracking and monitoring
Discord webhooks for operational notifications

Data Processing Architecture

Time-Series Data Handling:

Hourly snapshot collection system
Time-weighted average calculations
Historical yield tracking and storage

Calculation Engine:

Modular revenue calculation functions
Asset category-specific logic handlers
Error isolation and recovery mechanisms

API Design:

RESTful endpoints for data retrieval
JSON response format with standardized structure
Chain and time-based filtering support

Data Storage and External Entities

Blockchain Data Source - Alchemy

The system uses Alchemy as the primary blockchain data provider across all supported networks.

Alchemy Services Used:

Balance Queries: Retrieving ERC-20 token balances for ALM proxy wallets
Block Data: Fetching block timestamps for historical measurements
Token Metadata: Retrieving symbols, decimals, and protocol information
Historical State: Querying past balances at specific block numbers
Exchange Rates: Fetching wrapper token conversion rates

Database Structure

The system stores snapshots, yields, and metadata in PostgreSQL:

Asset Snapshots:

Hourly records of Prime Agent state per chain
Total AUM, debt, ALM holdings, PSM3 reserves
Detailed asset-level data with quantity, price, and USD value
Enables time-weighted average calculations

Asset Configuration:

Special handling rules per asset type
Venue classifications and exception flags
Determines which revenue formula applies to each asset

Yield Measurements:

Historical APY data by measurement period
Calculation methods and error tracking
Success indicators for validation

System Configuration:

Central registry of tracked assets across all chains
Prime Agent operator definitions
Blockchain network configurations
Infrastructure mappings for monitoring

Event Collection Process

Automated Data Collection

Asset snapshots and yield measurements are collected through scheduled processes:

Hourly Snapshots:

Each Prime Agent/chain combination has scheduled collection times:

Spark/Ethereum: Every hour at :14
Spark/Base: Every hour at :17
Spark/Arbitrum: Every hour at :19
Grove/Ethereum: Every hour at :15
Grove/Avalanche: Every hour at :20

Collections query current balances via Alchemy and store complete snapshots for time-weighted calculations.

Daily Yield Measurements:

Yield calculation runs daily at 2:13 AM UTC:

Processes previous month once complete
Measures APY using exchange rate or balance methods
Stores results with success/failure indicators

Error Handling

The system includes monitoring and recovery mechanisms:

Automated Monitoring:

Sentry integration for error tracking
Discord notifications for failures and completions
Execution logs for historical analysis

Manual Recovery:

Failed snapshots can be manually triggered
Historical gaps identified through validation
Missing yields recalculated on demand

Important Considerations

Validation and Quality Checks

Snapshot Completeness:

Verify hourly collection continuity:

Expected ~24 snapshots per chain per day
Identify gaps that affect time-weighted averages
Compare snapshot counts with expected totals

Value Consistency:

Compare time-weighted averages with final snapshots:

Large discrepancies indicate missing data
TWA should align reasonably with month-end values
Extreme differences suggest collection gaps

Revenue Attribution:

Validate calculation logic per asset category:

Strategic assets charge base rate regardless of performance
RWA assets attribute 100% of yield to Sky
USDS products use SSR instead of base rate
Non-yielding reserves generate zero revenue

System State Components

The PnL calculation includes a comprehensive financial snapshot:

Period End Date: The target settlement date, typically the first day of the following month.

Assets Under Management: Total value across all chains at snapshot time.

Total Debt: Amount borrowed from Sky DAO, tracked globally on Ethereum mainnet.

Non-Accumulated Profit: Calculated as AUM minus debt, representing unsettled historical profits from the transition to monthly settlement cycles.

Multi-Chain Considerations

While capital deploys across seven chains, settlement occurs through unified accounting:

Prime Agents borrow globally from Sky DAO
Deployments span multiple networks for optimization
PnL aggregates performance across all chains
Settlement flows through main debt relationship

Chain filtering in queries affects asset calculations but not system state, which always reflects global position.

Timing and Data Freshness

Collection Schedules:

Hourly snapshots at chain-specific minutes
Period-end snapshot uses closest available data
Not precisely at midnight due to collection timing

Measurement Availability:

Yields computed after month completion
Typically available morning of 1st or 2nd
Requires sufficient historical data

Optimal Query Timing:

After month completely ends
Final snapshots collected (within 1 hour)
Yield measurements completed

Early month queries provide estimates unsuitable for settlement.

Business Logic Deep Dive

Revenue Split Mechanism

The Simplified PnL system implements a sophisticated revenue sharing model that balances risk and reward between Sky and Prime Agents. The core mechanism revolves around the base rate threshold, which acts as a performance benchmark for all asset deployments.

Base Rate Application:

The 5.05% annual base rate represents Sky's cost of capital and minimum expected return. This rate applies uniformly across all standard asset deployments, creating a consistent baseline for performance evaluation. When assets perform above this threshold, Prime Agents capture the excess yield as compensation for their allocation expertise. When performance falls short, the treatment varies by asset category to appropriately distribute risk.

Risk Distribution:

Standard assets implement a protective floor for Prime Agents, ensuring they never incur losses from underperforming positions. This design encourages experimentation with new yield opportunities without fear of negative returns. In contrast, strategic assets like PYUSD and SparkLend USDT positions carry full downside risk, as Prime Agents must pay Sky the base rate regardless of actual performance. This creates strong incentives for careful management of these ecosystem-critical positions.

Time-Based Attribution:

Revenue calculations use time-weighted averages to ensure fair attribution based on actual deployment duration. This prevents gaming through strategic timing of deposits or withdrawals around measurement periods. A position held for 15 days generates exactly half the revenue of an identical position held for 30 days, maintaining proportional fairness across varying deployment strategies.

Special Asset Handling

Strategic Asset Rationale:

PYUSD and SparkLend USDT receive special treatment due to their strategic importance to the Sky ecosystem. These positions may generate yields below the base rate due to market conditions or ecosystem objectives, but Sky still requires its full base rate return. This policy ensures Prime Agents carefully consider the opportunity cost of maintaining these positions versus higher-yielding alternatives.

Real World Asset Treatment:

RWA positions like BlackRock BUIDL generate yields through off-chain mechanisms not reflected in on-chain exchange rates. Since these yields cannot be measured through standard blockchain queries, Sky receives 100% of returns to compensate for the measurement complexity and operational overhead. This policy also reflects the lower risk profile of regulated, institutional-grade assets.

USDS Ecosystem Alignment:

USDS-related products use the Sky Savings Rate instead of the standard base rate to maintain ecosystem consistency. This alignment ensures Prime Agents operating within the USDS ecosystem face appropriate benchmarks that reflect actual savings rates available to USDS holders. The SSR typically approximates 5%, creating similar but distinct economics from standard deployments.

Operational Considerations

Data Quality Requirements:

Accurate PnL calculations depend on complete and consistent data collection. Missing hourly snapshots create gaps in time-weighted averages, potentially skewing revenue attribution. The system requires at least 95% snapshot coverage for reliable calculations, with automated monitoring to detect collection failures.

Yield Measurement Challenges:

Different token types require distinct yield measurement approaches. Rebasing tokens like spUSDS change their exchange rates over time, while non-rebasing tokens maintain constant rates but accrue additional tokens. The system must correctly identify and apply the appropriate measurement method for each asset to ensure accurate yield calculations.

Multi-Chain Complexity:

Operating across seven blockchains introduces synchronization challenges. Each chain has different block times, gas costs, and infrastructure reliability. The system handles these variations through chain-specific collection schedules and error recovery mechanisms, ensuring comprehensive coverage despite network-specific issues.

Settlement Process

Monthly Cycle:

The monthly settlement cycle balances operational efficiency with business requirements. This frequency provides sufficient time for yield generation while maintaining regular cash flows for both parties. Month boundaries align with traditional accounting periods, simplifying integration with existing financial systems.

Settlement Calculation Steps:

Collect all hourly snapshots for the period
Calculate time-weighted average balances per asset
Measure yields using appropriate methods
Apply revenue split formulas based on asset categories
Aggregate results across all chains and assets
Generate final settlement amounts for both parties

Validation Requirements:

Before finalizing settlement, multiple validation checks ensure accuracy:

Snapshot coverage exceeds minimum thresholds
Yield measurements completed successfully
Time-weighted averages align with expectations
Revenue calculations pass sanity checks
System state matches independent sources

Edge Cases and Exceptions

New Asset Onboarding:

When Prime Agents deploy capital to new assets mid-month, the system must handle partial period calculations. Time-weighted averages naturally accommodate this through their duration-based approach, ensuring new deployments contribute proportionally to revenue calculations.

Asset Migration:

Moving funds between venues or chains requires careful tracking to avoid double-counting or gaps. The system uses unique asset identifiers and transaction timestamps to maintain continuity across migrations, preserving accurate time-weighted calculations.

Protocol Failures:

External protocol issues like paused withdrawals or oracle failures can affect yield measurements. The system includes fallback mechanisms to handle these scenarios, either excluding affected assets or applying conservative estimates based on historical performance.

Performance Optimization

Calculation Efficiency:

Processing thousands of hourly snapshots across multiple chains requires optimized algorithms. The system uses PostgreSQL's window functions and aggregation capabilities to perform time-weighted calculations efficiently, reducing computation time from hours to seconds.

Caching Strategies:

Frequently accessed data like asset configurations and yield measurements are cached to reduce database load. The caching layer includes automatic invalidation when underlying data changes, ensuring calculations always use current information.

Parallel Processing:

Chain-specific calculations run in parallel to reduce total processing time. This parallelization extends to yield measurements and snapshot collections, maximizing throughput while maintaining data consistency through proper transaction isolation.

Future Considerations

Scaling Challenges:

As Prime Agents expand to new chains and protocols, the system must scale accordingly. Each new chain adds hourly snapshot requirements and yield measurement complexity. The architecture supports horizontal scaling through additional collection workers and database sharding if needed.

Regulatory Compliance:

Increasing regulatory focus on DeFi systems may require enhanced reporting and audit capabilities. The system's comprehensive data collection and time-based attribution provide a strong foundation for regulatory compliance, with all calculations traceable to source data.

Protocol Evolution:

New DeFi protocols introduce novel yield mechanisms that may not fit existing measurement approaches. The system's modular architecture allows adding new measurement methods and asset categories without disrupting existing calculations, ensuring adaptability to protocol innovations.