The problem OctantSpark solves

Problem Statement & Benefits

Executive Summary

The Unified Yield Strategy ecosystem solves a critical gap in DeFi: the lack of accessible, safe, and composable yield optimization mechanisms for sustainable public goods funding.

Today, organizations funding public goods rely on:

• ❌ Simple treasury management (no yield)
• ❌ Centralized staking (custody risk, low returns)
• ❌ Manual DeFi interactions (complex, error-prone, expensive)

Our solution provides:

• ✅ Automated Yield Generation: Multi-protocol strategies optimized for different risk/return profiles
• ✅ Transparent & Safe: Health factor automation, formal verification ready, permissionless
• ✅ Easy Integration: Factory pattern enables one-line deployment
• ✅ Community Aligned: Yield funds public goods, not extractive protocols

---

Problems Solved

Problem 1: Public Goods Treasury Depletion

The Situation:
Many public goods organizations operate with fixed budgets that deplete over time:

• Gitcoin, Protocol Guilds, Open Source projects
• Annual funding from Ethereum, L2s, or community
• Burns through reserves at accelerating rate as needs grow
• Eventually fundraising becomes majority of work

Financial Reality:

Year 0: $1,000,000 treasury
Year 1: Spent $200k → $800k left
Year 2: Spent $250k → $550k left (more ambitious)
Year 3: Spent $300k → $250k left (crisis mode)
Year 4: Out of money → Must fundraise immediately

Why Current Solutions Fail:

Example: Impact at Scale

A public goods org with $10M treasury:

Status quo (0% yield):
  Year 1 spend: $500k
  Year 2 spend: $650k
  Year 3 spend: $800k (needs $9.2M remaining after 2 years)
  ✓ Remains solvent

With our system (10% yield):
  Year 1 yield: $1M (spend $500k) → Grow to $10.5M
  Year 2 yield: $1.05M (spend $650k) → Grow to $10.9M
  Year 3 yield: $1.09M (spend $800k) → Grow to $11.2M
  ✓ Grows despite spending!

Annual Impact: $1M treasury × 10% = $100k/year to public goods from yield alone.

Problem 2: Yield Optimization is Complex for Non-Developers

The Situation:
Maximizing yield across Spark, Aave, Lido, and other protocols requires:

1. Deep Protocol Knowledge

   • Understanding chi mechanisms in Spark
   • Navigating Aave health factor mechanics
   • Tracking liquidity incentives
   • Monitoring slippage and execution risk

2. Manual Process Overhead

   • Monitor positions multiple times per week
   • Manually rebalance across protocols
   • Handle health factor breaches
   • Execute tax-aware withdrawals

3. Security Risks

   • Manual transactions increase error likelihood
   • No automated health factor protection
   • Possible loss of funds due to slippage
   • Protocol smart contract risks compound

4. Operational Burden

   • Dedicated staff to manage treasury
   • Ongoing education on DeFi landscape
   • Dependency on specific individuals
   • Prevents scaling

Real Example - Gitcoin Treasury Management

Hypothetical scenario:

Gitcoin's $50M treasury across 3 protocols:
- Spark: $20M earning 8% = $1.6M/year yield
- Aave: $20M earning 7% = $1.4M/year yield
- Staking: $10M earning 3% = $0.3M/year yield
Total: $3.3M/year

But with manual management:
- Lost to slippage: -$50k (1.5%)
- Missed opportunities: -$200k (rebalancing delays)
- Human error: -$100k (wrong transaction)
- Manual labor: -$500k (staff salaries)
Net benefit: Only $2.45M

With our system:
- Automatic rebalancing: -$20k (0.6%)
- Algorithmic optimization: +$100k (captured opportunities)
- Zero human error: $0
- Zero manual labor cost: $0
Net benefit: $3.38M (38% better!)

Problem 3: DeFi Integration Complexity Creates Barriers

The Situation:
Building custom DeFi strategies requires:

1. Smart Contract Expertise

   • Solidity knowledge (scarce skill)
   • Protocol integration experience
   • Security audit requirements
   • Testing and validation

2. Time to Deploy

   • 4-8 weeks per strategy
   • Months to optimize across multiple protocols
   • Additional auditing time
   • Deployment and monitoring setup

3. Ongoing Maintenance

   • Protocol upgrades (Aave v2 → v3 migration)
   • Interest rate changes
   • Liquidity conditions
   • Emergency handling

The Barrier to Entry

Typical Organization Trying to Integrate DeFi:

Week 1-2: Hire contractor, define requirements
Week 3-4: Develop and test custom strategy
Week 5: Security audit (if funding allows)
Week 6: Deploy and monitor

Cost: $50k-$150k in development
Risk: Single implementation, hard to change
Speed: 2 months minimum

With our system:

Day 1: Factory deploy

Challenges I ran into

Challenges & Solutions

Overview

During the development of the Unified Yield Strategy ecosystem, several significant technical challenges emerged. This document details each challenge, the specific bugs encountered, and how they were resolved. These lessons demonstrate the complexity of building production-grade multi-protocol DeFi integrations.

---

Challenge 1: Struct Export and Type Resolution in Factory Pattern

The Problem

When implementing the UnifiedYieldStrategyFactory, we needed to expose deployment records to external consumers (like deployment scripts and client applications). However, Solidity's struct handling in cross-file scenarios created unexpected compiler errors.

Error Message:

Error (7920): Identifier not found or not unique.
   --> script/FactoryDeploymentDemo.s.sol:125:9:
    |
125 |         UnifiedYieldStrategyFactory.DeploymentRecord memory record = factory.getDeployment(sparkStrategy);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Root Cause Analysis

The issue stemmed from how Solidity resolves struct types across contract boundaries:

1. Initial Implementation - Struct defined outside contract scope:

// ❌ This pattern doesn't export the type properly
struct DeploymentRecord {
    address strategyAddress;
    StrategyType strategyType;
    address asset;
    uint256 deploymentTime;
    address deployer;
    string name;
}

contract UnifiedYieldStrategyFactory {
    // ...
}

2. Problem: When external contracts tried to reference UnifiedYieldStrategyFactory.DeploymentRecord, the struct wasn't properly registered as a contract-level type, causing the compiler to fail with "Identifier not found or not unique."

3. Why It Matters: This is a common pitfall when designing factory patterns - structs need to be scoped within the contract to be properly exported through the contract's ABI.

Solution Implemented

Move struct inside contract scope:

contract UnifiedYieldStrategyFactory {
    /// @notice Deployment record for tracking strategy instances
    struct DeploymentRecord {
        address strategyAddress;
        StrategyType strategyType;
        address asset;
        uint256 deploymentTime;
        address deployer;
        string name;
    }

    // ... rest of contract
}

Why This Fixed It

• Structs defined inside contracts are automatically exported as part of the contract's public interface
• External code can now correctly reference UnifiedYieldStrategyFactory.DeploymentRecord
• The ABI properly includes the struct definition for off-chain tools and other contracts

Impact

This change affected:

• ✅ FactoryDeploymentDemo.s.sol:125 - Now correctly reads deployment records
• ✅ All consumer contracts can query deployment history
• ✅ Off-chain indexers and frontends can properly decode struct data

Lesson Learned

Best Practice: Always define data structures within contract scope when they need to be referenced externally. This ensures proper type registration in the contract's ABI and prevents resolver conflicts.

---

Challenge 2: Integrating Multiple Protocol Standards (Spark vs Aave)

The Problem

Spark and Aave V3 have fundamentally different yield mechanisms:

The Core Tension:
Building a unified factory that handles both protocols required abstracting over these differences without losing protocol-specific optimizations.

Root Cause Analysis

When designing DeploymentConfig, we needed:

1. Support for Spark's vault-based approach (simple, no health concerns)
2. Support for Aave's pool-based approach (complex, health factor automation required)
3. Ability to pass leverage parameters only for Aave
4. Clear type safety that prevents misconfiguration

Initial Challenge: How to encode strategy-specific parameters in a unified struct?

// ❌ Problem: How to handle different parameter types?
struct DeploymentConfig {
    // ... common fields
    uint256 aaveLeverage;  // Only for Aave - what if used with Spark?
    address sparkVault;    // Only for Spark - unused for Aave
    // ... more protocol-specific fields = chaos
}

Solution Implemented

Opaque bytes parameter with enum-based decoding:

struct DeploymentConfig {
    StrategyType strategyType;
    address asset;
    string name;
    address management;
    address keeper;
    address emergencyAdmin;
    address donationAddress;
    bool ena