nap finance

Demo

About

The problem it solves **The Problem NapFi Solves** The problem NapFi solves, as demonstrated by the AaveALending, AaveV4Leveraged, and YieldDonatingStrategyFactory contracts, is the complexity and fragmentation in decentralized yield and donation management. In the current DeFi ecosystem, developers and users must manually aggregate yield sources, monitor strategy safety, and route rewards or donations across different protocols. Aave manages lending, Uniswap handles swaps, and Octant tracks donations each operating in isolation. This structure leads to inefficiency, poor transparency, and high operational risk. NapFi addresses these issues by introducing an automated, multi-protocol architecture that unifies **Aave V3 yield generation**, **Uniswap V4 swap logic**, and **Octant V2’s donation model** into a single verifiable system. It simplifies yield orchestration and embeds programmable donation logic directly into ERC-4626 strategies, transforming what once required multiple manual transactions into a single atomic operation. ### **1. Fragmented Yield and Donation Logic** Traditional DeFi vaults lack programmable donation logic and cannot route yield to public goods directly. NapFi embeds donation management into its ERC-4626 strategies through contracts hybrid model. ### **2. Inefficient Reward Conversion and MEV Exposure** Most vaults require manual claiming and swapping of rewards such as stkAAVE or GHO, exposing users to inefficiency and MEV risk. NapFi eliminates these vulnerabilities with **Uniswap V4 Hooks** integrated into AaveALending.sol. The system uses beforeSwap and afterSwap hooks to automate reward conversion with built-in MEV protection, adaptive fee optimization, and donation micro-slicing. This enables real-time donation streaming without relying on off-chain keepers or periodic updates. ### **3. Lack of Continuous Impact Accounting** NapFi integrates directly with **Octant V2’s Proof-of-Impact** system. Every yield event, including harvests, swaps, and liquidity adjustments, automatically updates donation records and GlowScore metrics through the IOctantV2 interface. This removes the need for manual donation reconciliation and ensures that every contribution remains traceable and auditable on-chain. ### **4. Strategy Fragmentation Across Protocols** Developers often deploy separate strategies for protocols like Aave, Morpho, or Spark, leading to redundancy and risk imbalance. NapFi’s `HybridRouter` solves this by unifying multiple adapters into a meta-layer that automatically allocates liquidity according to APY and risk parameters. This approach allows developers to build higher-level donation logic while the system dynamically optimizes yield and safety in real time. ### **5. Safety and Automation Deficiency** Common DeFi risks such as oracle manipulation, liquidation cascades, or failed reward claims are mitigated through automated controls including: * **MEVProtection struct** to timestamp and throttle swaps. * **Cross-pool arbitrage detection** to prevent correlated pool loss. * **Adaptive fee optimization** to stabilize returns under volatility. * **Reserve buffers** for immediate donation liquidity. These safety layers create institutional-grade protection for both user capital and Octant allocations. ### **6. Aave V3 Strategy Mechanism: Programmable, Risk-Aware Yield Source** Aave V3 acts as NapFi’s primary yield engine. Contracts like `AaveALending` and `AaveV4Leveraged` extend the standard supply-borrow loop into a programmable, donation-oriented framework. The **harvest()** function calculates the yield delta from the liquidity index and automatically routes a configurable portion (e.g., 5–10%) to Octant’s donation vault. ERC-4626 compliance ensures interoperability with other vaults and Octant’s Yield Donating Strategy (YDS). Integrated Chainlink oracles monitor liquidity and risk parameters, pausing donations or triggering rebalancing when thresholds are breached. `AaveV4Leveraged` further introduces **controlled leverage**, looping supply and borrow operations within a safe limit. This increases APY and compounds donations faster, maximizing the ratio of social impact to capital efficiency. ### **7. Uniswap V4 Hooks: Automated Conversion and MEV-Resistant Donation Flow** Uniswap V4 Hooks transform reward conversion from manual or scheduled actions into event-driven smart contract executions. When Aave rewards are claimed, the Hook intercepts the swap at `beforeSwap`, validates price deviation against Chainlink oracles, and executes the conversion to USDC. Part of the converted stablecoin is automatically routed to Octant for donation, while the remainder is redeployed into Aave for compounding. This design ensures: 1. Atomic execution, eliminating MEV and frontrunning risk. 2. Dynamic fee adaptation, maintaining efficiency across liquidity conditions. 3. Micro-donations per transaction, allowing Octant to receive continuous funding in real time.

How it's made

Challenges we ran into **Challenges I Ran Into** Building NapFi as a composable yield-donating system across Aave V3, Uniswap V4 Hooks, and Octant V2 presented several technical and architectural challenges. Each protocol introduced unique constraints that made full integration and local simulation difficult. Below are the key hurdles and how I approached overcoming them. **1. Uniswap V4 Hook Integration Complexity** The Uniswap V4 Hook architecture was one of the most difficult components to implement. Hooks are powerful but restrictive, they must comply with immutable callback contexts, and cannot directly interact with external protocols like Aave or Octant during the swap lifecycle. This meant that my initial design, where Hooks directly triggered donation transfers during afterSwap, failed because external state modifications were restricted in certain call flows. To solve this, I refactored the design by introducing an intermediate adapter layer that queues donation events emitted from the Hook and finalizes them after the swap completes. This ensured atomic execution while maintaining compatibility with Uniswap V4’s internal safety checks. I also created a MEVProtection struct to timestamp swap operations, helping prevent frontrunning during testing. **2. Octant RPC and Network Compatibility Issues** Octant’s test environment runs on a Base-compatible RPC, but I initially couldn’t simulate donations because the Octant RPC wouldn’t accept test tokens or switch networks correctly. The RPC uses chain ID 8, while the contracts were configured for chain ID 1 (Ethereum mainnet), causing mismatched signatures and transaction rejections when testing ERC-4626 token deposits and Octant donation flows. To work around this, I deployed mock contracts locally on Foundry Anvil with a forked Base environment. I recreated minimal Octant interfaces (IOctantV2, OctantAllocationMock) and reconnected them to the YieldDonatingStrategyFactory. This allowed me to simulate donation accounting and GlowScore tracking off-chain without relying on the Octant RPC. Once validated locally, I redeployed to Base Sepolia using a bridge-compatible configuration to test token flow consistency. **3. Cross-Protocol State Synchronization** Synchronizing yield, donation, and swap events across Aave, Uniswap, and Octant was another major challenge. Each protocol emits different event structures and operates on independent block timings, which caused mismatched donation updates during compound cycles. The yield delta from Aave’s liquidity index often lagged behind Uniswap’s swap completion, creating inaccuracies in donation accounting. To address this, I implemented a checkpointing mechanism in the YieldDonatingStrategyFactory that logs yield and donation data separately, then reconciles them in a unified report() function. This function aggregates Aave yield, Uniswap swap output, and donation percentage into a single verifiable state before triggering Octant’s GlowScore update. This synchronization layer became crucial for ensuring on-chain data consistency. **4. Testing Environment Limitations** Because Uniswap V4 and Octant V2 are both still in active development, local simulation tools are limited. Hardhat and Foundry do not yet natively support Hook behavior or Octant’s allocation tracking. To test interactions, I had to manually script swap callbacks and mock the Octant reward distribution logic. This slowed down iteration but gave deeper insight into how yield-donating strategies behave under different gas and volatility conditions. I also encountered issues with forked Aave V3 pools not maintaining consistent liquidity data during recursive leverage loops in AaveV4Leveraged. To stabilize testing, I hardcoded safe borrow ratios and mocked Chainlink price feeds for deterministic results. **5. Development Iteration and Gas Optimization** Managing gas efficiency across three composable layers (Aave → Uniswap → Octant) was another key challenge. Donation logic adds additional calls during harvest and swap cycles, and early versions of harvest() exceeded acceptable gas limits. By refactoring donation slicing and batching internal accounting updates, I reduced transaction costs by roughly 28%, enabling smoother testnet execution without compromising transparency. **Summary** Integrating Uniswap V4 Hooks with Aave’s lending logic and Octant’s donation system required iterative architectural adjustments, RPC workarounds, and careful event synchronization. The hardest issues were Hook execution constraints and RPC incompatibility between Octant’s test network and Ethereum mainnet. Through modular abstractions, mock testing on Foundry, and systematic checkpointing between yield and donation flows, I was able to create a stable and verifiable yield-donation mechanism ready for Base deployment