1. Yield Strategy Integration Complexity

Challenge: Integrating with both Aave v3 and Spark Protocol simultaneously required understanding different interfaces - Aave uses direct lending pools while Spark uses the sDAI wrapper. The strategies needed to handle deposits, withdrawals, and yield harvesting differently for each protocol.

Solution:

• Created abstracted

  IYieldStrategy

  interface with standardized

  deposit()

  ,

  withdraw()

  , and

  harvest()

  methods
• Implemented protocol-specific logic in separate

  AaveStrategy

  and

  SparkStrategy

  contracts
• Built

  YieldAggregator

  to manage allocation and coordinate between strategies
• Used extensive testing (33 tests) to verify each strategy independently and together

Code Example:

interface IYieldStrategy {
    function deposit(uint256 amount) external;
    function withdraw(uint256 amount) external;
    function harvest() external returns (uint256 yield);
    function totalAssets() external view returns (uint256);
}

2. Quadratic Funding Score Calculation

Challenge: Implementing the quadratic funding formula on-chain was tricky - needed to calculate square roots efficiently without floating-point math, handle edge cases (0 votes, 0 voters), and prevent overflow/underflow issues.

Solution:

• Implemented Babylonian square root algorithm in Solidity for gas efficiency
• Added comprehensive edge case handling (checks for 0 values)
• Used two-pass distribution: first calculate all scores, then proportionally distribute
• Stored intermediate values to avoid recalculation
• Tested with multiple voting scenarios to verify fairness

Code Implementation:

// Babylonian method for square root
function sqrt(uint256 x) internal pure returns (uint256) {
    if (x == 0) return 0;
    uint256 z = (x + 1) / 2;
    uint256 y = x;
    while (z < y) {
        y = z;
        z = (x / z + z) / 2;
    }
    return y;
}

// Quadratic funding score
quadraticScores[i] = sqrt(projects[i].totalVotes) * projects[i].uniqueVoters;

3. ERC-4626 Vault Share Calculation

Challenge: When yield is donated to the splitter, it shouldn't dilute existing depositors' shares. The vault needed to track yield separately and convert it to shares for the splitter without affecting the share price for regular depositors.

Solution:

• Separated yield harvesting from user deposits/withdrawals
• When harvesting, mint new pgDAI shares directly to splitter based on yield amount
• Used

  convertToShares()

  to calculate correct share amounts
• Maintained 1:1 principal-to-share ratio for depositors through careful accounting
• Added extensive tests for share price stability

Key Insight: Yield is deposited as new DAI, converted to shares, and those shares go to splitter - regular users' shares remain unaffected.

4. Tenderly Fork Deployment & Configuration

Challenge: Initial deployment on Tenderly fork failed due to constructor parameter mismatches, address ordering issues, and configuration verification problems. Contracts deployed but weren't properly connected.

Solution:

• Created comprehensive deployment script (

  DeployTenderly.s.sol

  ) with step-by-step execution
• Added validation checks after each deployment step
• Implemented

  verify-deployment.sh

  script to confirm all connections
• Used

  cast

  commands to verify state on-chain
• Documented deployment addresses and configuration in

  TENDERLY_DEPLOYMENT.md

Lessons Learned:

• Always verify deployment order (dependencies first)
• Check contract connections immediately after deployment
• Use verification scripts to catch configuration issues early
• Document everything for reproducibility

Key Takeaways:

✅ Modular architecture made complex integrations manageable
✅ Comprehensive testing caught edge cases early
✅ Clear documentation explains both implementation and usage
✅ Gas-efficient patterns from established libraries (OpenZeppelin)
✅ Iterative deployment with verification at each step prevented major issues