DEV Community: N DIVIJ

Building CanopySplit: A Deep Dive into Octant V2 Yield Donating Strategies

N DIVIJ — Sun, 09 Nov 2025 22:02:34 +0000

Introduction

CanopySplit is a multi-layer DeFi protocol that transforms idle capital into climate impact. Users deposit WETH, earn yield through Aave v3, and automatically split 100% of profits among climate recipients—all while keeping their principal withdrawable at any time.

This technical deep-dive covers:

Octant V2 Yield Donating Strategy architecture
ERC-4626 vault integration with Aave v3
Epoch-based donation splitting mechanics
Custom Uniswap v4 hook for swap fee donations
Production deployment challenges on Sepolia

Live on Sepolia:

Strategy: 0x0D1d8AE2dD0e4B06ca0Ef2949150eb021cAf6Ce9
Splitter: 0xda5fA1c26Ec29497C2B103B385569286B30EC248
Asset (WETH): 0xC558DBdd856501FCd9aaF1E62eae57A9F0629a3c

Architecture Overview

┌─────────────┐
│ User Wallet │
└──────┬──────┘
       │ deposit WETH
       ▼
┌──────────────────────────────┐
│ Aave4626YieldDonatingStrategy│ (ERC-4626 vault)
│ - Deposits to Aave v3        │
│ - Mints shares to users      │
│ - Reports profit → splitter  │
└──────────────┬───────────────┘
               │ mint donation shares
               ▼
┌──────────────────────────────┐
│ TriSplitDonationSplitter     │
│ - Holds strategy shares      │
│ - Epoch-based allocation     │
│ - 3 climate recipients       │
└──────┬───────────────────────┘
       │ distribute()
       ▼
┌─────────────────────────────────┐
│ Recipients (50% / 30% / 20%)    │
│ - Planters                      │
│ - MRV (Monitoring/Verification) │
│ - Maintenance                   │
└─────────────────────────────────┘

Part 1: Octant V2 Yield Donating Strategy

The Core Concept

Octant V2 introduces Yield Donating Strategies (YDS), which extend ERC-4626 with donation mechanics:

interface IYieldDonatingStrategy is IERC4626 {
    function report() external returns (uint256 profit, uint256 loss);
    function setDonationSplitter(address splitter) external;
}

Key innovation: When report() is called:

Calculate profit = currentAssets - lastRecordedAssets
If profit > 0: Mint shares to splitter (not to users!)
If loss > 0: Burn donation shares first, protecting user capital

This means:

Users keep 100% of principal
Donations absorb losses first
No performance fees

Implementation: Aave4626YieldDonatingStrategy

We built an ERC-4626 wrapper around Aave v3:

contract Aave4626YieldDonatingStrategy is YieldDonatingTokenizedStrategy {
    IERC4626 public immutable vault; // ATokenVault

    constructor(
        IERC20 asset_,
        IERC4626 vault_,
        string memory name_,
        address management_,
        address keeper_
    ) YieldDonatingTokenizedStrategy(asset_, name_, management_, keeper_) {
        vault = vault_;
        asset_.forceApprove(address(vault_), type(uint256).max);
    }

    function totalAssets() public view override returns (uint256) {
        uint256 shares = vault.balanceOf(address(this));
        return vault.convertToAssets(shares);
    }

    function _deployFunds(uint256 amount) internal override {
        vault.deposit(amount, address(this));
    }

    function _freeFunds(uint256 amount) internal override {
        vault.withdraw(amount, address(this), address(this));
    }
}

Why ERC-4626?

Composability: Any ERC-4626 vault can plug in
Non-rebasing: Fixed shares, yield in convertToAssets()
Safety: Vault enforces supply caps and liquidity checks

The report() Flow

function report() external onlyKeepers returns (uint256 profit, uint256 loss) {
    uint256 currentAssets = totalAssets();
    uint256 lastAssets = lastRecordedAssets;

    if (currentAssets > lastAssets) {
        profit = currentAssets - lastAssets;

        // Mint shares to splitter (donation\!)
        uint256 sharesToMint = convertToShares(profit);
        _mint(donationSplitter, sharesToMint);

        emit Reported(profit, 0);
    } else if (currentAssets < lastAssets) {
        loss = lastAssets - currentAssets;

        // Burn donation shares first
        uint256 splitterShares = balanceOf(donationSplitter);
        uint256 splitterAssets = convertToAssets(splitterShares);

        if (splitterAssets >= loss) {
            uint256 sharesToBurn = convertToShares(loss);
            _burn(donationSplitter, sharesToBurn);
        } else {
            _burn(donationSplitter, splitterShares);
            // Remaining loss socialized across all shares
        }

        emit Reported(0, loss);
    }

    lastRecordedAssets = totalAssets();
}

Critical insight: Minting shares (instead of transferring assets) means donations continue earning yield until distributed.

Part 2: Aave v3 Integration

ATokenVault: ERC-4626 Wrapper for Aave

contract ATokenVault is ERC4626, Ownable {
    IPool public immutable aavePool;
    IERC20 public immutable aToken;

    constructor(
        IERC20 asset_,
        IPoolAddressesProvider provider
    ) ERC4626(asset_) ERC20("Aave WETH Vault", "aWETHv") {
        aavePool = IPool(provider.getPool());
        aToken = IERC20(aavePool.getReserveData(address(asset_)).aTokenAddress);
    }

    function totalAssets() public view override returns (uint256) {
        return aToken.balanceOf(address(this)); // aTokens auto-accrue
    }

    function _deposit(address caller, address receiver, uint256 assets, uint256 shares) 
        internal override 
    {
        SafeERC20.safeTransferFrom(asset(), caller, address(this), assets);
        SafeERC20.forceApprove(asset(), address(aavePool), assets);

        aavePool.supply(address(asset()), assets, address(this), 0);

        _mint(receiver, shares);
        emit Deposit(caller, receiver, assets, shares);
    }

    function _withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares) 
        internal override 
    {
        if (caller \!= owner) {
            _spendAllowance(owner, caller, shares);
        }

        _burn(owner, shares);
        aavePool.withdraw(address(asset()), assets, receiver);

        emit Withdraw(caller, receiver, owner, assets, shares);
    }
}

Deployed on Sepolia:

Vault: 0x6938238e57CBe1b4B51Eb3B51389cEf8d3a88521
Asset: WETH (0xC558DBdd856501FCd9aaF1E62eae57A9F0629a3c)
Aave Provider: 0x012bAC54348C0E635dCAc9D5FB99f06F24136C9A

Part 3: TriSplit Donation Splitter

Epoch-Based Allocation

struct Recipient {
    address addr;
    string role;
}

struct Policy {
    uint256 epoch;
    uint256[3] basisPoints; // [5000, 3000, 2000] = 50%, 30%, 20%
}

contract TriSplitDonationSplitter {
    Recipient[3] public recipients;
    Policy public currentPolicy;
    Policy public upcomingPolicy;
    IERC4626 public vault;

    function distribute() external {
        uint256 shares = vault.balanceOf(address(this));
        uint256 assets = vault.redeem(shares, address(this), address(this));

        uint256[3] memory amounts;
        for (uint256 i = 0; i < 3; i++) {
            amounts[i] = (assets * currentPolicy.basisPoints[i]) / 10_000;
            IERC20(vault.asset()).safeTransfer(recipients[i].addr, amounts[i]);
        }

        emit Distributed(currentPolicy.epoch, amounts, recipients);
    }

    function rollEpoch() external onlyOwner {
        currentPolicy = upcomingPolicy;
        upcomingPolicy.epoch++;
        emit EpochRolled(currentPolicy.epoch);
    }

    function setUpcomingPolicy(uint256[3] calldata bps) external onlyOwner {
        require(bps[0] + bps[1] + bps[2] == 10_000, "Must sum to 100%");
        upcomingPolicy.basisPoints = bps;
        emit UpcomingPolicySet(upcomingPolicy.epoch, bps);
    }
}

Why epochs?

Recipients know their allocation in advance
Owner can adjust future weights without disrupting current distributions
Full on-chain transparency via events

Current allocation:

Planters: 50% (0xF9b2eFCAcc1B93c1bd7F898d0a8c4b34aBD78E53)
MRV: 30% (0x9261432cab3c0F83E86fa6e41E4a88dA06E7ecc6)
Maintenance: 20% (0x89C13e8e5a81E775160322df9d7869893926A8Cc)

Part 4: Uniswap v4 Hook (Local PoC)

Extending Donations to Swap Fees

contract TriSplitDonationHook is BaseHook {
    struct HookConfig {
        address donationTarget;
        uint256 donationBps; // 100 = 1%
    }

    mapping(PoolId => HookConfig) public configs;

    function afterSwap(
        address,
        PoolKey calldata key,
        IPoolManager.SwapParams calldata params,
        BalanceDelta delta,
        bytes calldata
    ) external override returns (bytes4, int128) {
        PoolId poolId = key.toId();
        HookConfig memory config = configs[poolId];

        if (config.donationTarget \!= address(0)) {
            Currency currency = params.zeroForOne ? key.currency0 : key.currency1;

            uint256 amountIn = params.zeroForOne 
                ? uint256(int256(-delta.amount0())) 
                : uint256(int256(-delta.amount1()));

            uint256 donation = (amountIn * config.donationBps) / 10_000;

            poolManager.take(currency, config.donationTarget, donation);

            emit DonationExecuted(poolId, donation, config.donationTarget);
        }

        return (this.afterSwap.selector, 0);
    }
}

Testing on Anvil:

# Deploy v4 infrastructure
forge script script/00_DeployV4.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Deploy hook
forge script script/00_DeployHook.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Initialize pool
forge script script/05_EnsureInitialized.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Add liquidity
forge script script/02_AddLiquidity.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Configure hook (1% donation)
forge script script/04_SetHookConfig.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Execute swap (triggers donation\!)
forge script script/03_Swap.s.sol --broadcast --rpc-url http://127.0.0.1:8545

Part 5: Frontend Architecture

Dynamic Asset Detection

Instead of hardcoding USDC/WETH, we read the asset dynamically:

export function useAssetInfo(strategyAddress: Address) {
  const { data: assetAddress } = useReadContract({
    address: strategyAddress,
    abi: StrategyABI,
    functionName: 'asset',
  });

  const { data: symbol } = useReadContract({
    address: assetAddress,
    abi: ERC20ABI,
    functionName: 'symbol',
  });

  const { data: decimals } = useReadContract({
    address: assetAddress,
    abi: ERC20ABI,
    functionName: 'decimals',
  });

  return { assetAddress, symbol, decimals };
}

Benefits:

Works with any ERC-20 asset
No frontend redeployment needed
Correct decimal formatting

Role-Based Access Control

function AppPage() {
  const { address } = useAccount();
  const { data: management } = useReadContract({
    address: ADDRS.sepolia.strategy,
    abi: StrategyABI,
    functionName: 'management',
  });

  const isManagement = address === management;

  return (
    <>
      <DepositForm />
      <WithdrawForm />

      {isManagement && (
        <Button onClick={handleReport}>Report Profit/Loss</Button>
      )}
    </>
  );
}

Event Tracking

export function useLifetimeDonations(splitterAddress: Address) {
  const { data: logs } = useContractEvent({
    address: splitterAddress,
    abi: SplitterABI,
    eventName: 'Distributed',
    fromBlock: 0n,
  });

  const totalDonated = useMemo(() => {
    if (\!logs) return 0n;
    return logs.reduce((sum, log) => {
      const [epoch, amounts] = log.args;
      return sum + amounts.reduce((a, b) => a + b, 0n);
    }, 0n);
  }, [logs]);

  return { totalDonated, eventCount: logs?.length ?? 0 };
}

Real-World Challenges

Challenge 1: Sepolia Gas Cap (16.7M)

Problem: Contract creation bytecode exceeded Sepolia's per-tx gas limit.

Solution:

# foundry.toml
optimizer = true
optimizer_runs = 1
via_ir = false
bytecode_hash = "none"
cbor_metadata = false

forge clean && forge build
forge create YieldDonatingTokenizedStrategy --gas-limit 0xFD0000 --legacy

Challenge 2: WETH Pivot

Problem: Aave v3 Sepolia USDC had supply cap issues.

Solution: Switched to WETH (18 decimals, no supply cap).

export USDC_UNDERLYING=0xC558DBdd856501FCd9aaF1E62eae57A9F0629a3c  # WETH\!

Challenge 3: Permit2 Allowance

Problem: Swaps reverted with InsufficientAllowance.

Root cause: Granted allowance to PoolManager, but Router calls transferFrom().

Solution:

// Grant allowance to Router, not PoolManager
permit2.approve(address(token0), address(swapRouter), type(uint160).max, type(uint48).max);

Challenge 4: Token Decimals

Problem: USDC (6 decimals) vs WETH (18 decimals) mismatches.

Solution: Created patching script for local testing:

FakeUSDC fake = new FakeUSDC(); // decimals() = 6
vm.etch(token0Addr, address(fake).code);

Key Innovations

Epoch-Based Splits: Unlike single-recipient YDS, we route to 3 recipients with dynamic weights
Multi-Adapter Support: Idle, Aave v3, and ERC-4626 strategies all feed the same splitter
Dynamic Asset Detection: Frontend works with any ERC-20 without hardcoding
Hooks Integration: Extended YDS concept to Uniswap v4 swap fees
Loss Protection: Donation shares burn first, protecting user capital

Conclusion

CanopySplit demonstrates how Octant V2's Yield Donating Strategies can be extended with:

Multi-protocol integrations (Aave v3, Uniswap v4)
Flexible donation mechanics (epoch-based splits, loss protection)
Production-ready UX (dynamic asset detection, role-based access)

The architecture is composable, transparent, and gas-efficient. All code is open-source and ready for judges to test.

Key takeaways for builders:

ERC-4626 is the perfect abstraction for yield strategies
Epoch-based policies provide flexibility without disrupting current operations
Dynamic asset detection makes frontends future-proof
Testnet gas limits are real—optimize aggressively
Always verify contract addresses exist on-chain before trusting deployment logs

Resources

GitHub: https://github.com/N-45div/CanopySplit
Sepolia Strategy: 0x0D1d8AE2dD0e4B06ca0Ef2949150eb021cAf6Ce9
Sepolia Splitter: 0xda5fA1c26Ec29497C2B103B385569286B30EC248
Octant V2 Docs: docs.octant.app

Built with ❤️ for the Octant V2 hackathon. Questions? Reach out on Twitter @godlovesu_n

Introducing "Resilient Response" - Empowering Disaster Relief and Management

N DIVIJ — Wed, 16 Aug 2023 08:14:21 +0000

Hey there, fellow developers and enthusiasts of this beautiful Dev Community

I'm thrilled to introduce you to a project that's very close to my heart - "Resilient Response", an open-source application designed to revolutionize disaster relief and management efforts. 🚀

🔗 Links:

Website: https://resilient-response.vercel.app/
GitHub:

N-45div / Resilient-Response

Our team is excited to announce the development of a cutting-edge web application both for mobile and desktop for the GDSC Solution Challenge 2023. With a mission to empower communities to withstand and recover from natural disasters, our app focuses on building resilience through innovative technology.

Resilient Response

Resilient Response is a web application developed to foster connectivity and provide vital information during periods of crisis. This application was conceived as part of the 2023 Solution Challenge, which aligns with the overarching mission to address the United Nations' 17 Sustainable Development Goals by leveraging Google technology. The Resilient Response web app offers users the ability to register and access chat interfaces to stay informed about events occurring in their geographic area. In addition to real-time weather updates, the application also displays the locations of available shelters during times of emergency.

Our video presentation Live Demo

Our team is excited to announce the development of a cutting-edge web application both for mobile and desktop for the GDSC Solution Challenge 2023. With a mission to empower communities to withstand and recover from natural disasters, our app focuses on building resilience through innovative technology.We believe that by harnessing the…

View on GitHub

Project Overview:
Disasters can strike unexpectedly and wreak havoc on communities. The key to minimizing their impact lies in effective coordination and rapid response. This is where Resilient Response comes in. It's a powerful application that combines cutting-edge technology with a user-friendly interface to streamline disaster relief operations.

Key Features:

🗺️ Geolocation Integration: With the integration of geolocation services, "Resilient Response" allows responders to locate the nearest available shelters relative to the user's current position. This functionality ensures efficient utilization of resources and quicker response times.

📱 Mobile Compatibility: In disaster scenarios, being able to access vital information on-the-go is crucial. Resilient Response is designed to work seamlessly on mobile devices, ensuring that responders can stay connected and informed, even in challenging environments.

💡 Open Source Collaboration: Resilient Response is an open-source project, driven by collaboration and community involvement. Developers from all backgrounds can contribute to its growth, enhancing its capabilities and extending its reach.

🎨 Design and User Experience: Create intuitive interfaces that empower users to navigate through critical information effortlessly, even in stressful situations.

Innovative Hand Gesture Recognition: Utilizing TensorFlow, a powerful machine learning framework, we've developed an intelligent algorithm that can identify and interpret hand gestures even in low-light or dark environments. This allows survivors to communicate their presence and condition to rescuers without relying solely on verbal communication, which might not be feasible in noisy or chaotic situations.

Why Hand Gestures?
Hand gestures are a universal form of communication that transcends language barriers. By incorporating this technology into "Resilient Response," we're enabling survivors, including those who might be injured or unable to speak, to make themselves understood and request assistance in a clear and intuitive way.

🤖 Machine Learning Enthusiasts: If you have expertise in machine learning, TensorFlow, or computer vision, your insights and skills can help us refine and enhance the hand gesture recognition algorithm.

🧩 Testing and Feedback: We're actively seeking individuals who can test the hand gesture recognition feature in various environments and provide valuable feedback for improvements.

Current Status and Future Vision of "Resilient Response"

Current Status:
As of now, the "Resilient Response" project has reached a significant milestone. The core features that form the foundation of the application are in place and have been rigorously tested. Our team has poured countless hours into refining the user interface, optimizing performance, and ensuring the application's reliability, even in challenging scenarios.

We've received valuable feedback from early users and collaborators, which has helped us fine-tune the user experience and identify areas for improvement. The project's GitHub repository has been bustling with activity, showcasing the collective efforts of developers who believe in the mission of enhancing disaster relief and management.

Looking Forward:
While we've come a long way, there's still much to be done. Our vision for the future of "Resilient Response" is bold and ambitious, and we're excited to share some of the key areas we're focusing on:

🌐 Real-time Communication: Resilient Response provides a platform for real-time communication between first responders, volunteers, and affected individuals. Whether it's sending alerts, sharing critical information, or coordinating rescue missions, the application ensures that everyone is on the same page.

🌟 Enhanced User and Community Customization: We're working on expanding the application's customization options, allowing different organizations and regions to tailor the platform to their specific needs. Flexibility is key, as each disaster scenario is unique.

🗺️ Geospatial Mapping: With integrated geospatial mapping, Resilient Response enables responders to visualize affected areas, assess damage, and plan their actions more efficiently. The map-based interface enhances decision-making and resource allocation.

🔗 Integration with Emergency Services: Our goal is to forge partnerships with emergency services and governmental agencies to seamlessly integrate "Resilient Response" into their operations. This collaboration can lead to more coordinated and efficient disaster response efforts.

🔮 Predictive Analytics: Leveraging the power of data, we aim to develop predictive models that can forecast disaster trends and help communities prepare in advance. This proactive approach can save lives and resources.

📚 Comprehensive Documentation: As the project evolves, we understand the importance of clear and comprehensive documentation. We're investing in creating resources that make it easy for developers to understand and contribute to the project.

Join Us in Shaping the Future:
I'm extending an open invitation to all of you to be a part of this exciting journey. Your skills, insights, and passion can contribute to the success of "Resilient Response" in ways that are beyond measure. Whether you're a seasoned developer, a creative designer, a data aficionado, or someone who simply cares deeply about making a positive impact, there's a role for you here.

Let's continue collaborating on GitHub, engaging in discussions, and pushing the boundaries of what technology can achieve in disaster relief and management. Together, we can make a tangible difference in the lives of people around the world.

If you have any questions, ideas, or suggestions, please don't hesitate to reach out. Together, we can make a significant impact!

Once again 🔗 Links:

Website: https://resilient-response.vercel.app/
GitHub: Resilient Response

Thank you for reading the post .. Have a great day ahead !