Problems Solved & Use Cases

The Problem

• Public goods funding gap
  Public goods struggle to secure recurring funding. Traditional donations are one‑off; DeFi yield is typically kept by users or protocols. Funding is often single‑cause, missing the chance to support a portfolio of public goods.

• Friction in impact investing
  Many people want to support causes without sacrificing principal. Existing flows force a trade‑off (yield or impact), involve manual harvesting + sending, and introduce cognitive overhead that makes recurring impact unlikely.

• Fragmented DeFi infrastructure
  Building yield strategies across assets requires swaps, market selection, and protocol integration. Cross‑asset allocation typically implies custom code, higher surface area, and audit burden.

• Trust & transparency
  Donors want to know where funds go and confirm that donations occur. Multi‑cause distribution and the timing of donations need to be provable on‑chain.

What Problems It Solves

Problem 1: Sustainable public‑goods funding
Solution: Automatic, multi‑recipient yield donation

• 100% of realized yield is donated on‑chain using preset split mixes:
  Crypto‑Maxi (60% crypto public goods / 20% humanitarian / 20% hygiene),
  Balanced (40% / 30% / 30%),
  Humanitarian‑Maxi (20% / 40% / 40%).
• Donations recur as TVL accrues yield; no manual steps. Realization occurs at controlled checkpoints (harvest/fee‑take), then routed.

Problem 2: Capital preservation vs. impact
Solution: Keep principal; donate only yield

• Users deposit into ERC‑4626 single‑asset vaults (WETH/USDC/USDT/DAI) that supply to Aave v3.
• Depositors keep their original principal (subject to protocol/market risks); all net yield is directed to public goods according to the chosen mix.
• No performance/management fees to the team; the design focuses on donation‑first economics.

Problem 3: Complex DeFi integration
Solution: Composable architecture + agent orchestration

• Instead of a heavy multi‑strategy vault, Ajey uses four small, single‑asset ERC‑4626 vaults + an agent orchestrator that:

  • monitors Aave v3 yields across WETH/USDC/USDT/DAI,
  • executes migrations between vaults (e.g., DAI → USDT) via a whitelisted swap aggregator,
  • enforces slippage/deadline guards and role‑gated execution.

• This keeps code surface minimal and auditable while achieving multi‑asset optimization.

Problem 4: Trust & transparency
Solution: On‑chain verification, explicit addresses

• All donations are on‑chain to published recipients; transactions and amounts are independently verifiable.
• ERC‑4626 share/accounting and event logs provide a clear audit trail (deposits, harvests, migrations, donations).
• Role‑gated actions and explicit allowlists (swap aggregator) reduce discretionary risk.

Who Can Use It

• Impact investors
  Preserve principal while delivering automated, recurring, verifiable donations to multiple causes.

• DAOs & organizations
  Align treasury management with mission: deploy idle capital to Aave v3 and stream yield to public goods—without new operational overhead.

• DeFi users
  Prefer a hands‑off experience: deposit once; the system reallocates between Aave markets and donates yield by default.

• Developers & builders
  Compose on a standard ERC‑4626 interface; integrate Ajey as a building block for impact‑driven apps and dashboards.

How It Makes Existing Tasks Easier/Safer

Easier: Automated donation process

• Before: Manual yield harvesting; manual transfers; high chance of forgetting; per‑donation gas.
• After: Automatic donation at each realization event; no manual steps; batched/efficient flows; predictable cadence.

Safer: Capital preservation

• Before: Donation‑focused products sometimes commingle principal and donations; unclear rules and costs.
• After: Principal remains in ERC‑4626 vaults supplying Aave v3; only yield is routed to causes; no team take or hidden performance fees.

Easier: Integration & maintenance

• Before: Build cross‑asset logic from scratch; maintain complex debt/queue code; multiple audits.
• After: Single‑asset vaults + orchestrator pattern; small contracts; standard interfaces; easier testing and review.

Safer: Smart‑contract execution

• Before: Ad‑hoc donation logic, manual mistakes, centralized gatekeepers.
• After: Role‑gated orchestrator, whitelisted swap aggregation, slippage/deadline checks, on‑chain logs.

Easier: Multi‑asset composability

• Before: Integrate each protocol/asset pair separately; custom swap plumbing; brittle migrations.
• After: One ERC‑4626 pattern across assets; orchestrator performs asset swaps + reallocation between Aave markets.