# Introduction ## Maximizing veAERO Efficiency Through Permalocked Liquidity iAERO is a liquid staking protocol for Aerodrome Finance that enables users to maintain liquidity while earning optimised voting rewards through permanently locked veAERO positions. ### Core Benefits 🔒 **Maximum Voting Power** - Vault maintains permanently locked veAERO for maximum rewards\ 💧 **Stay Liquid** - Receive tradeable iAERO tokens representing your deposit\ 🎁 **Dual Rewards** - Earn both LIQ emissions and staking rewards\ ⚡ **Auto-Compounding** - Vault automatically manages and optimizes positions\ 🗳️ **Automated Voting** - Smart allocation system optimizes votes across all gauges\ 🤖 **Set & Forget** - No weekly voting, no rebase management, no manual claiming ### The "Cake and Eat It Too" Protocol Remember when your parents said you can't have your cake and eat it too? Well, they never met iAERO. **Traditional veAERO:** Lock for 4 years, lose access to capital, vote every week, or watch your voting power decay faster than your New Year's resolutions. **iAERO:** Deposit once, stay liquid forever, let the robots handle the voting while you sleep. It's like hiring a personal assistant for your veAERO, except this one actually shows up to work. ### Why Liquid Staking Beats Locking | The Old Way (veAERO) | The iAERO Way | | ---------------------------- | --------------------------- | | 🔐 Lock for 4 years | 💧 Stay liquid always | | 📉 Voting power decays | 📈 Vault maintains max lock | | 🗓️ Vote every week manually | 🤖 Automated optimal voting | | 😴 Miss votes = lose rewards | 💰 Never miss rewards again | | 🔧 Rebase every week | ⚙️ Auto-rebasing by keeper | | 🏝️ Can't vote on vacation | 🌴 Earn while you sleep | ### The Math That Makes You Rich(er) **Solo Locking:** You lock 1000 AERO, vote when you remember, probably miss 30% of epochs because life happens. **iAERO Chad Move:** * Deposit veNFT with 1000 AERO locked → Get 950 iAERO (5% fee) * Earn from 100% of epochs (robots don't sleep) * Get bonus LIQ tokens (emissions halve over time - early = good) * Your voting power compounds with everyone else's * Trade iAERO if you need liquidity ### Automated Voting: The Secret Sauce Our voting manager doesn't just vote - it votes *optimally*: 1. **Scans all gauge bribes** - Finds where the money is 2. **Calculates ROI per pool** - Math nerds rejoice 3. **Allocates proportionally** - More bribes = more votes 4. **Executes flawlessly** - Every. Single. Week. 5. **You do nothing** - This is the best part ### The "But Wait, There's More" Section 🎰 **No Impermanent Loss** - This isn't an LP position\ 📊 **Transparent Metrics** - All votes and rewards on-chain\ 🏛️ **Battle-Tested veNFT Tech** - Built on Aerodrome's proven systems\ 🔄 **Instant Entry/Exit** - No waiting periods for iAERO trading\ 💎 **LIQ Governance Token** - Because one token wasn't enough\ 🛡️ **Multi-sig Protected** - Your funds are SAFU ### Real Talk: Who Is This For? ✅ **Perfect for:** * veAERO holders who want voting rewards without the lock * Degens who can't commit to 4 years of anything * Protocols wanting liquid veAERO exposure * Anyone who forgets to vote (so, everyone) ❌ **Not for:** * People who enjoy manual weekly voting * Masochists who like locked tokens * Anyone allergic to yields ### The TL;DR iAERO turns your veAERO into a yield-generating, liquid, auto-voting machine. You get the max voting rewards of a 4-year lock without the 4-year lock. The vault does all the work, you collect all the rewards (minus a tiny fee because we need to eat too). ### Quick Links * [Launch App](https://iaero.finance) - Start earning now * [How It Works](https://github.com/iaeroProtocol/iaero/blob/main/getting-started/how-it-works.md) - 5-minute deep dive * [Smart Contracts](https://github.com/iaeroProtocol/iaero/blob/main/technical/contracts.md) - For the code curious * [Voting Strategy](/protocol-mechanics/voting-strategy) - How we optimize ### Join the Revolution Stop choosing between liquidity and yields. With iAERO, you're not just staking - you're upgrading to Staking 2.0. *Disclaimer: No actual cakes were harmed in the making of this protocol. Past performance doesn't guarantee future results, but our robots are pretty good at their job.* ### 🚀 Coming Soon: Next-Level DeFi Composability #### Staked iAERO Receipt Tokens (stiAERO) We're launching **stiAERO** - a receipt token for staked iAERO that unlocks a whole new world of capital efficiency. **What This Means For You:** 🏦 **Borrow Against Your Staking Position** * Use stiAERO as collateral in lending markets * Access liquidity without unstaking or losing rewards * Keep earning while your tokens work as collateral 💰 **Ultimate Capital Efficiency** * Stack yields: staking rewards + lending/borrowing strategies * Loop strategies: Borrow → Buy more iAERO → Stake → Repeat * Never choose between earning and liquidity again 🔄 **Tradeable Staking Positions** * Sell your staking position without unstaking * Buy pre-staked positions from others * Create secondary markets for yield-bearing tokens 📈 **Enhanced Yield Strategies** * **Delta-neutral farming**: Borrow stables against stiAERO * **Leveraged staking**: Borrow iAERO to increase position * **Yield arbitrage**: Borrow when rates < staking APR 🎯 **Real Use Cases** * Need quick liquidity? Borrow against stiAERO instead of unstaking * Want more exposure? Loop your position for up to 3-5x rewards * Market downturn? Borrow stables without selling your stack **The Power of Composability:** Your Journey: AERO → iAERO → stiAERO → Collateral → Loan → More Yield Deposit AERO, get iAERO (liquid) Stake iAERO, get stiAERO (still liquid!) Use stiAERO as collateral Borrow against it Still earn full staking rewards Use loan for anything you want **Why This Changes Everything:** Traditional staking locks your capital in one place. With stiAERO, your capital works in multiple protocols simultaneously: * ✅ Earning in iAERO staking * ✅ Serving as collateral * ✅ Enabling borrowing power * ✅ Remaining liquid and tradeable **Expected Launch**: Q1 2026 **Supported Platforms** (Planned): * Native iAERO lending market * Morpho Finance integration * Other Aerodrome ecosystem lending protocols This isn't just an upgrade - it's a complete reimagining of what staked assets can do. Get ready to put your iAERO to work in ways you never imagined. *** ### 🔮 Future Roadmap **Phase 1** (Current) * ✅ Core protocol launch * ✅ iAERO and LIQ tokens * ✅ Automated voting system * ✅ Multi-token reward distribution * ✅ stiAERO receipt tokens **Phase 2** (Q4 2025) * 🔄 Lending market integration * 🔄 Advanced yield strategies **Phase 3** (Q1 2026) * 🎯 Options and derivatives * 🎯 Cross-chain expansion **Phase 4** (Q1 2026) * 🌐 Coming to a veNFT near you * 🌐 Governance V2 * 🌐 Protocol-owned liquidity expansion Stay tuned - the best is yet to come. # What is iAERO? iAERO is a liquid staking derivative protocol built on top of Aerodrome Finance's veAERO system. ## The Problem Traditional veAERO locking requires users to choose between: * **Liquidity** - Keeping AERO liquid but earning no voting rewards * **Rewards** - Locking AERO for up to 4 years but losing access to capital ## The Solution iAERO solves this dilemma by: 1. **Pooling deposits** into a protocol-owned vault 2. **Permanently locking** veAERO positions for maximum voting power 3. **Issuing iAERO tokens** as liquid receipts for deposits 4. **Distributing rewards** to iAERO stakers ## How It Works ### Key Components * **PermalockVault**: Manages veAERO NFTs and deposits * **iAERO Token**: 1:1 receipt token for AERO deposits (minus fees) * **LIQ Token**: Bonus emission token with halving schedule * **StakingDistributor**: Handles reward distribution to stakers * **RewardsHarvester**: Claims and processes Aerodrome rewards # Our Unique Proposition ## Core Tagline **"The veAERO Position That Pays You When Others Exit"** *** ## The 6 Core USPs ### 1. 🤖 Automated, Optimized Voting **Tagline:** *"Set-it-and-forget-it veAERO that never misses a beat"* **What it means:** * Our algorithm votes optimally across all Aerodrome pools every single epoch * ROI-maximized allocation based on bribes, fees, and strategic value * 100% participation rate - never miss rewards due to forgetting to vote **User benefit:** * No weekly voting hassle * Maximum returns from every epoch * Professional-grade optimization you can't do manually **Soundbite:** *"You sleep, we maximize. Every. Single. Week."* *** ### 2. 💰 One-Click Reward Management **Tagline:** *"Your yield, your way - instantly"* **What it means:** * Convert ALL rewards to USDC with one click * Or auto-compound everything back into iAERO * No manual swapping through multiple tokens **User benefit:** * Cash out to stables when you need liquidity * Maximize compounding when you're accumulating * Save time and gas fees **Soundbite:** *"One click. All rewards. USDC or compound. Done."* *** ### 3. 🔓 True Exit Liquidity **Tagline:** *"Sell anytime, instantly, to the protocol"* **What it means:** * Protocol owns the iAERO/AERO liquidity pool * Sell your iAERO directly without searching for buyers * No 4-year lock, no waiting periods **User benefit:** * Exit whenever you need capital * No price discovery issues * No dependence on DEX liquidity depth **Soundbite:** *"Locked veAERO? That's so 2023. Welcome to liquidity."* *** ### 4. 🔥 The Exit Liquidity Flywheel (THE KILLER FEATURE) **Tagline:** *"Every seller makes you richer"* **What it means:** * When users sell iAERO, the protocol buys it back * Protocol does NOT stake the purchased iAERO * Same rewards distributed among fewer stakers * Your APR increases automatically **The Math:** ``` Scenario: 1000 AERO worth of rewards per epoch Before sale: - 100 stakers share 1000 AERO - Each gets 10 AERO (10% APR) After 20 users sell: - 80 stakers share same 1000 AERO - Each gets 12.5 AERO (12.5% APR) - That's a 25% yield boost from sellers ``` **User benefit:** * You profit from "paper hands" * More deposits + more sellers = compounding APR * Natural churn works IN YOUR FAVOR * Already delivering substantially higher yields than standard veAERO **Soundbite:** *"In most protocols, dilution kills yields. Here, sellers boost them. We built it backwards."* **Why this is revolutionary:** This inverts the traditional liquid staking problem. Usually: * More users = rewards split more ways = lower APR ❌ With iAERO: * More users deposit → Some sell for liquidity → Protocol accumulates unstaked iAERO → Higher APR for remaining stakers ✅ *** ### 5. 💎 LIQ Token Flywheel **Tagline:** *"The same magic, now for governance"* **What it means:** * LIQ tokens use identical mechanics * Sellers concentrate yields among holders * Diamond hands are rewarded structurally **User benefit:** * Dual flywheel effect (iAERO + LIQ) * LIQ becomes more valuable to hold over time * Early adopters benefit most **Soundbite:** *"Stake LIQ, watch sellers pump your yields. It's that simple."* *** ### 6. 📈 stiAERO - Borrow Against Your Yield **Tagline:** *"Stake once, earn twice"* **What it means:** * Stake iAERO → Receive stiAERO receipt token * Use stiAERO as collateral in lending protocols * Keep earning full staking rewards while borrowing **Current status:** * ✅ stiAERO is LIVE * 🔄 Lending protocol integration coming Q1 2026 **User benefit:** * Capital efficiency maximized * Borrow without unstaking * Loop strategies possible (3-5x yield potential) * Access liquidity without sacrificing rewards **Advanced strategies enabled:** 1. **Leverage loop:** Stake iAERO → Borrow against stiAERO → Buy more iAERO → Repeat 2. **Delta-neutral:** Borrow stables, hedge position, capture yield spread 3. **Liquidity access:** Need capital? Borrow instead of selling **Soundbite:** *"Your staked position just became a yield-generating credit line."* *** ## The Complete Value Stack When you hold staked iAERO, you get: 1. ✅ **Optimized voting rewards** (automated) 2. ✅ **Trading fees** from voted pools 3. ✅ **Bribes** from protocols 4. ✅ **LIQ emissions** (bonus token) 5. ✅ **APR boosts** from seller exits (unique to iAERO) 6. ✅ **Exit liquidity** whenever you need it 7. ✅ **Borrowing power** via stiAERO (coming soon) **No other veAERO position offers all of this.** *** ## Comparison Matrix | Feature | Traditional veAERO | Other Liquid Staking | iAERO Protocol | | --------------------- | ------------------ | -------------------- | ------------------------- | | **Lock Period** | 4 years | None | None | | **Voting** | Manual weekly | Automated | Automated + ROI optimized | | **Exit Liquidity** | Sell at discount | DEX dependent | Protocol-owned pool | | **Seller Impact** | Neutral | Dilutes slightly | **Increases your APR** 🚀 | | **Reward Management** | Manual swaps | Varies | One-click USDC/compound | | **Leverage** | Not possible | Not available | stiAERO borrowing | | **Typical APR** | Base rate | \~Base rate | **Base + flywheel boost** | *** ## Real Performance Data As of 25th Nov 2025 * Current iAERO staker APR: 39% * LIQ staking yield: 11.7% * Standard veAERO APR: 26% (veAERO Maxi relay) * Yield advantage: +14.67% (after normalising LIQ yield for $ relative notional) *** ## Why This Works (The Economics) ### Traditional Liquid Staking Problem: ``` Protocol stakes everything → More users = More stakers → Same rewards split more ways → APR decreases ``` ### iAERO Solution: ``` Users deposit → Get iAERO → Some sell (need liquidity) → Protocol buys but DOESN'T stake → Same rewards → Fewer stakers → APR increases ``` ### The Sustainable Model: * Not a ponzi - no external dependencies * Works because of natural liquidity needs * Protocol accumulates value (unstaked iAERO) * Long-term stakers rewarded structurally * More deposits = more potential yield concentration *** ## Key Objections & Responses ### "Sounds too good to be true" **Response:** "It's just math. When someone sells, we don't stake what we buy back. Same rewards, fewer stakers. Check the contracts - it's all on-chain and verifiable." ### "What if everyone stakes forever?" **Response:** "Then you get base veAERO yields plus optimal voting - still great. But realistically, people need liquidity. We've already seen 10% of users sell, proving natural churn exists." ### "How is this sustainable?" **Response:** "We're not paying from reserves or printing tokens. The mechanism is: people deposit → some need exit liquidity → we provide it → their yield gets redistributed. It's concentration mechanics, not inflation." ### "Why haven't others done this?" **Response:** "They didn't own their liquidity pool or they stake everything they buy. We designed the tokenomics specifically to create this flywheel effect." *** *Last Updated: November 2025* *For latest data and metrics:* [*app.iaero.finance*](https://app.iaero.finance) # veAERO Community Alignment ## The 98% Revenue Commitment to veAERO Holders iAERO demonstrates unprecedented alignment with the Aerodrome ecosystem by directing **98% of all veAERO revenues back to the community**: * **80%** flows directly to iAERO stakers * **10%** builds protocol-owned reserves (defending the peg and strengthening the protocol) * **8%** rewards LIQ stakers (governance participants) * **Only 2%** retained for operations This means veAERO depositors who stake both iAERO and LIQ immediately capture **88% of their original voting income** while gaining: * Full liquidity of their position * Upside exposure to protocol growth through LIQ * Future collateralization opportunities via stiAERO * Automated optimal voting across all epochs ## The Staker's Advantage: Benefiting from Short-Term Sellers The protocol's structure creates a powerful flywheel that rewards long-term alignment: ### Mathematical Reality: * If 25% of iAERO holders sell rather than stake, remaining iAERO stakers receive **>100%** of their original veAERO yield * If 67% of LIQ remains unstaked, LIQ stakers receive an additional **24%** effective yield boost * Combined scenario: Committed stakers could earn **125%+ of original veAERO rewards** This mechanism ensures that patient, aligned participants benefit directly from short-term traders. Every seller increases yields for stakers, creating natural selection for long-term Aerodrome supporters. ## Permanent Protocol Alignment ### Critical commitments to Aerodrome: 1. **Irreversible Lock**: All veAERO locked in iAERO vaults will **NEVER** be unlocked or sold. This permanently removes sell pressure and strengthens the entire veAERO ecosystem. 2. **Optimal Voting Execution**: Our automated system ensures 100% voting participation with mathematically optimized bribe capture, maximizing value for the Aerodrome ecosystem. 3. **Compounding Network Effects**: As iAERO grows, more AERO gets permanently locked, increasing scarcity and value for all veAERO holders - not just iAERO users. 4. **Ecosystem Integration**: stiAERO will enable new DeFi primitives on Aerodrome, from lending markets to leveraged strategies, driving more activity and fees to the protocol. ## Why This Matters for Aerodrome iAERO isn't extracting value from Aerodrome - it's amplifying it: * **Stronger Locks**: Converting temporary locks to permanent ones * **Better Participation**: 100% voting vs typical 60-70% manual participation * **Deeper Liquidity**: iAERO pairs create new trading opportunities * **Innovation Catalyst**: Liquid staking unlocks new DeFi use cases on Base * **Aligned Incentives**: Protocol success directly correlates with AERO value ## The Bottom Line iAERO makes veAERO better for everyone: * **For users**: Maximum rewards without sacrificing liquidity * **For Aerodrome**: More permanent locks, consistent voting, ecosystem growth * **For builders**: New composable primitives to build upon We're not competing with veAERO - we're evolving it. By solving the liquidity/reward tradeoff, we make locking more attractive, driving more value to Aerodrome. **Join us in building the future of liquid staking on Aerodrome.** # What is stiAERO? ## Your Staking Position, Now With Superpowers ### The One-Liner stiAERO is what happens when your staked iAERO decides it's too good for just one job. It's a receipt token that proves you're staking while letting you use that proof as collateral across DeFi. ### The "Why Should I Care" Part Remember when you had to choose between: * Staking for that juicy 25% APY (veAERO yield as of Sep 25) * Having liquid funds for other opportunities * Using your assets as collateral With stiAERO, that's like choosing between breathing, eating, and sleeping. Why choose? Do all three. ### How This Magic Works **The Old World (Boring)** ``` Stake iAERO → Locked in staking → Earn rewards → Can't do anything else ``` **The stiAERO World (Galaxy Brain)** ``` Stake iAERO → Get stiAERO receipt → Earn rewards → Use as collateral → Borrow → Deploy capital → Still earning → Repeat ``` ### The Math That Makes Your Accountant Nervous Let's say you have $10,000 worth of iAERO: **Virgin Staker:** * Stakes iAERO * Earns 25% APY = $2,500/year * Capital locked, can't do anything else * Total return: 25% **Chad stiAERO User:** * Stakes iAERO, gets stiAERO * Earns 25% APY = $2,500/year * Uses stiAERO as collateral * Borrows $5,000 stables at 8% APY (Careful about liquidations!!) * Deploys borrowed funds at 15% APY * Net from borrowing: 7% of $5,000 = $350/year * Total return: $2,850/year = 28.5% APY * Still has $5,000 liquid to ape into the next big thing ### Real Use Cases (Not Financial Advice!) #### 🏦 **The Leverage Loop Legend** * Deposit iAERO, get stiAERO * Use stiAERO as collateral * Borrow AERO * Stake borrowed AERO for more stiAERO * Repeat until you're either a genius or need therapy * Potential APY: 25% × leverage ratio (handle with care) #### 💊 **The Stablecoin Pill** (APYs may fluctuate) * Your iAERO position: Earning 25% APY * Borrow stables at 8% against stiAERO * Net profit: 17% on borrowed amount * Use stables for real life (boring) or more defi (based) * Never sell your stack, never stop earning #### 🎰 **The Degen Arbitrage** * Market dip? Borrow stables against stiAERO * Buy the dip without unstaking * Market pump? Take profits * Pay back loan * Keep original position + staking rewards + trading profits * Your risk manager hates this one trick #### 🛡️ **The Protection Play** * Worried about short-term volatility? * Don't unstake (that's for quitters) * Borrow stables as insurance * If market dumps: You have dry powder * If market pumps: You're still fully exposed * Heads you win, tails you win more ### The "But Wait, There's Even More" Section **🔄 Transferable Yields** * Lend your stiAERO to a friend (or enemy) * Sell your staking position without unstaking * Create yield derivatives (for the real sickos) **🎯 Protocol Integrations** * Use in any protocol that accepts ERC20 collateral * Lending markets love stable yield-bearing assets * 25% APY backing = Prime collateral ### The Risk Section (Because Legal Makes Us) ⚠️ **Liquidation Risk**: Borrow responsibly or get rekt ⚠️ **Smart Contract Risk**: Code is law until it isn't ⚠️ **Rate Risk**: APYs can change faster than your ex's mood But let's be real - you're already in DeFi. You eat risk for breakfast. ### Why This Changes Everything Traditional finance: "You can't use the same dollar twice" stiAERO: "Hold my beer" Your iAERO position becomes: 1. **A yield generator** (25% APY staking) 2. **Loan collateral** (borrow against it) 3. **A tradeable asset** (sell the receipt) 4. **A governance tool** (still counts for voting) 5. **A flex** ("Yeah, I'm earning while borrowing while earning") ### The Technical Bits (For Nerds) * **Token Standard**: ERC20 (because we're not monsters) * **Minting**: 1:1 with staked iAERO * **Burning**: Only on unstake * **Transferable**: Yes (this is the whole point) * **Supply**: Equals total staked iAERO * **Oracle-friendly**: Easy price feeds (staked amount × iAERO price) ### Integration Roadmap **Wave 1 - Native** (Live Now) * ✅ stiAERO minting/burning * ✅ Full staking rewards * ✅ Transfer functionality **Wave 2 - Money Markets** (Q1 2026) * 🔜 Native iAERO lending pool * 🔜 Collateral ratios optimized for 25% APY * 🔜 Borrowing against stiAERO **Wave 3 - Ecosystem** (Q2 2026) * 🎯 Sonne Finance integration * 🎯 Other Aerodrome lending protocols * 🎯 Cross-collateral strategies **Wave 4 - Galaxy Brain** (Q3 2025) * 🧠 stiAERO/iAERO loops * 🧠 Structured products * 🧠 Options and futures * 🧠 We don't even know yet ### The TL;DR stiAERO turns your staking position into a Swiss Army knife of DeFi possibilities. Stake, earn 25% APY, use as collateral, borrow, deploy, profit. It's not just a receipt token - it's a permission slip to break the rules of capital efficiency. ### FAQ (Frequently Awesome Questions) **Q: Can I lose my staked iAERO if I get liquidated?** A: Only if you borrow and don't manage your position. The stiAERO gets liquidated, not the underlying stake. Don't be a degen (or do, we're not your mom). **Q: What's the catch?** A: You have to be smart enough to use it properly. That's literally it. **Q: Why would anyone lend against this?** A: 25% APY backing = happy lenders. Predictable yield = low risk collateral. Math = your friend. **Q: Can I do \[insert crazy strategy]?** A: Probably. If it involves stiAERO generating yield while doing something else, the answer is yes. ### Ready to Transcend? Stop choosing between staking and liquidity. With stiAERO, you're not just participating in DeFi - you're speedrunning it. 🚀 [Stake Now](https://github.com/iaeroProtocol/iaero/blob/main/getting-started/app.iaero.finance) *** *Not financial advice. Side effects of stiAERO may include: excessive yields, capital efficiency addiction, and explaining loop strategies at parties. Please stake responsibly.* # What is LIQ? ## The Governance Token of iAERO LIQ (Liquid) is the native governance and value accrual token of the iAERO protocol. It's designed to align long-term stakeholders with protocol success through voting rights and revenue sharing. ## Token Purpose ### 1. Protocol Revenue Sharing LIQ stakers receive 8% of all protocol revenues (80% of the treasury's 10% share). This creates a direct value flow from protocol usage to LIQ holders. ### 2. Governance Rights LIQ holders vote on critical protocol decisions: * Fee parameters * Treasury allocation * Strategic partnerships * Protocol upgrades * Voting strategy adjustments ### 3. Incentive Alignment Early participants receive higher LIQ emissions, rewarding early adoption and long-term commitment to the protocol. ## How to Earn LIQ ### Primary Distribution: Mining Rewards When you deposit AERO into iAERO, you receive LIQ tokens as a bonus: * **Starting Rate**: 1 LIQ per 1 iAERO minted * **Halving Schedule**: Rate cuts in half every 5M LIQ minted * **Your Share**: 80% (20% goes to treasury) **Example Deposit:** * Deposit: 1,000 AERO * Receive: 950 iAERO (after 5% fee) * Bonus: 950 LIQ (at 1:1 rate) * Net to you: 760 LIQ (after 20% treasury share) ### Liquidity Provision Incentives (Coming Soon) iAERO/AERO Pool Rewards Program We're launching a dedicated incentive program for iAERO/AERO liquidity providers to ensure deep, stable liquidity. Dual Reward Structure: LIQ Emissions: Direct LIQ rewards for LP stakers (separate from deposit emissions) Trading Fee Boost: Protocol-funded bribes to the iAERO/AERO gauge How It Works: Add liquidity to iAERO/AERO pool on Aerodrome Stake your LP tokens in our incentive contract Earn LIQ rewards on top of normal trading fees Protocol votes for its own pool, directing emissions Planned Incentive Rates: Initial: 10,000 LIQ per week distributed pro-rata to LPs Decreases by 10% monthly to find sustainable equilibrium Minimum 1,000 LIQ per week floor Why This Matters: Better Pricing: Deeper liquidity = less slippage Peg Stability: More liquidity helps maintain iAERO/AERO ratio Additional Yield: Stack LP fees + AERO emissions + LIQ rewards Protocol Growth: Liquid markets attract more users Target Metrics: $5M+ TVL in iAERO/AERO pool <2% price impact on $100k swaps Daily volume >$500k Launch Timeline: 4-6 weeks after protocol launch, once initial liquidity established This creates a sustainable liquidity flywheel where the protocol directly incentivizes its most important trading pair, ensuring users can always enter and exit positions efficiently. ## LIQ Tokenomics ### Supply Cap: 100 Million Total Supply: 100,000,000 LIQ ├── Community Mining: 60,000,000 (40%) ├── Treasury Vesting: 10,000,000 (10%) ├── Team Vesting: 10,000,000 (10%) ├── Investor Vesting: 20,000,000 (20%) └── Unallocated Reserve: 20,000,000 (20%) ### Emission Schedule | LIQ Minted | Rate | Per iAERO | Estimated Time | | ---------- | ------- | --------- | -------------- | | 0-5M | 1.0x | 1.000 | Months 0-3 | | 5-10M | 0.5x | 0.500 | Months 3-8 | | 10-15M | 0.25x | 0.250 | Months 8-18 | | 15-20M | 0.125x | 0.125 | Months 18-36 | | 20-25M | 0.0625x | 0.0625 | Years 3-5 | ### Why Halvings Matter * **Decreasing Inflation**: Supply growth slows over time * **Early Advantage**: First movers get most LIQ per dollar * **Scarcity**: Later users compete for fewer tokens ## Value Accrual Mechanisms ### Direct Revenue Flow Protocol Fees (10% of all rewards) └→ TreasuryDistributor ├→ 80% to LIQ stakers (8% of total) └→ 20% to Treasury ops (2% of total) ### What LIQ Stakers Earn * AERO tokens * USDC from bribes * ETH from fees * Various protocol tokens * Any future protocol revenues ### Staking LIQ 1. Stake LIQ in dedicated staking contract 2. Earn proportional share of revenues 3. Claim rewards anytime 4. No lock period required ## Use Cases ### For Investors * **Revenue Share**: Passive income from protocol fees * **Governance Power**: Influence protocol direction * **Speculation**: Benefit from protocol growth ### For Protocols * **Meta-governance**: Control how iAERO votes * **Partnership Stakes**: Align with iAERO ecosystem * **Liquidity Mining**: Incentivize specific behaviors ### For Users * **Bonus Rewards**: Extra tokens on top of iAERO * **Community Participation**: Vote on proposals * **Fee Reduction**: Potential future benefits for holders ## LIQ vs iAERO | Aspect | iAERO | LIQ | | --------------------- | ------------------- | -------------------- | | **Represents** | Staked AERO | Protocol ownership | | **Supply** | Uncapped | 100M max | | **Earning Method** | Deposit AERO | Deposit AERO or vest | | **Staking Rewards** | 80% of vote rewards | 8% of vote rewards | | **Primary Utility** | Liquidity + yield | Governance + yield | | **Price Correlation** | Tied to AERO | Independent | ## Future Utility Expansion ### Planned Features * **Vote Boosting**: Lock LIQ for increased iAERO rewards * **Fee Discounts**: Reduced protocol fees for LIQ holders * **Exclusive Pools**: LIQ-gated investment opportunities * **Bribe Direction**: Vote on bribe allocation strategy ### Potential Developments * Cross-chain governance * Protocol-to-protocol negotiations * Revenue from additional products * Partnership revenue shares ## Getting LIQ ### Option 1: Earn Through Deposits 1. Deposit AERO into iAERO vault 2. Receive LIQ automatically 3. Earlier deposits = more LIQ per AERO ### Option 2: Buy on Market * **DEX**: Aerodrome (LIQ/USDC, LIQ/AERO pairs) * **Aggregators**: Use Matcha, 1inch for best price * **OTC**: Large trades via Discord ### Option 3: Liquidity Provision * Provide liquidity to iAERO or LIQ pairs * Earn trading fees + potential emissions * Risk of impermanent loss ## Risks and Considerations ### Token Risks * **Protocol Dependency**: Value tied to iAERO success * **Emission Pressure**: High early supply growth * **Liquidity Risk**: May have limited exit liquidity * **Regulatory**: Governance tokens face evolving regulations ### Mitigation Strategies * Dollar-cost average during high emission periods * Stake to earn revenues while holding * Participate in governance for long-term value * Provide liquidity to deepen markets ## FAQ **Q: Is LIQ required to use iAERO?** A: No, LIQ is a bonus token. You can use iAERO without holding LIQ. **Q: Can I stake both iAERO and LIQ?** A: Yes! Stake iAERO for 80% of rewards, LIQ for 8% of rewards. **Q: Will there be more LIQ after 100M?** A: No, 100M is the absolute maximum supply forever. **Q: What happens when emissions end?** A: LIQ becomes purely a revenue-sharing and governance token. **Q: Can LIQ be burned?** A: Yes, anyone can burn their LIQ tokens permanently. ## Summary LIQ is your stake in the iAERO protocol's future. Early depositors receive the most LIQ, creating strong incentives for early adoption. With revenue sharing, governance rights, and a capped supply, LIQ captures value as the protocol grows. Whether you're here for the yields, the governance, or the upside potential, LIQ represents your seat at the table in the liquid staking revolution. # Key Concepts ## What Problem Does iAERO Solve? Aerodrome's veAERO model creates a dilemma: lock your AERO for up to 4 years to maximize voting rewards, or keep it liquid and earn nothing. Most users end up somewhere in between - locking for shorter periods and getting suboptimal rewards, or forgetting to vote and missing out entirely. iAERO eliminates this trade-off by pooling user deposits into a protocol-managed vault that maintains maximum voting power while giving users liquid tokens they can trade anytime. ## How It Works: The 30-Second Version 1. **You deposit veAERO NFTs or AERO** into the vault 2. **Vault locks it permanently** in veAERO for maximum voting power 3. **You receive iAERO tokens** (95% of deposit after 5% fee) 4. **You receive bonus LIQ tokens** (governance/rewards token) 5. **Stake your iAERO** to earn 80% of all voting rewards 6. **Vault votes automatically** every week using optimal strategy 7. **Trade iAERO anytime** if you need liquidity ## Your First Deposit: Step-by-Step ### Prerequisites * AERO tokens or veAERO NFT in your wallet * ETH for gas fees (Base network) * Connected wallet (MetaMask, Rabby, etc.) ### Step 1: Connect Your Wallet Navigate to [iaero.finance](https://iaero.finance) and connect your wallet. Make sure you're on Base network. ### Step 2: Choose Deposit Type **Option A: Deposit AERO** * Best for: Fresh AERO holders * Process: Simple one-click deposit * You get: iAERO + LIQ tokens **Option B: Deposit veNFT** * Best for: Existing veAERO holders * Process: Transfer your veNFT to vault * You get: iAERO + LIQ based on locked amount ### Step 3: Enter Amount * Minimum: 1 AERO * Maximum: 10,000,000 AERO per transaction * Fee: 5% (goes to protocol treasury) ### Step 4: Approve & Deposit 1. Approve the vault to spend your AERO 2. Confirm the deposit transaction 3. Receive your iAERO and LIQ tokens ### Step 5: Stake Your iAERO Don't leave your iAERO idle! Stake it immediately to earn rewards: 1. Go to the "Stake" tab 2. Enter your iAERO amount 3. Confirm staking transaction 4. Start earning automatically 5. Receive stiAERO receipt token ## Understanding the Tokens ### iAERO - Your Liquid Staking Token * **What it represents**: Your share of the vault's veAERO * **Exchange rate**: 1 AERO = 0.95 iAERO (after 5% fee) * **Utility**: Stake for rewards, trade on DEXs, use as collateral (coming soon) * **Supply**: Uncapped, minted on deposits ### LIQ - Bonus Governance Token * **What it represents**: Governance rights and protocol ownership * **Emission rate**: Starts at 1 LIQ per iAERO, halves every 5M * **Utility**: Stake for protocol revenue share, governance voting * **Supply**: Capped at 100M total ## Rewards Explained When you stake iAERO, you earn from multiple sources: ### Weekly Aerodrome Rewards * Voting bribes from protocols * Trading fees from gauges * AERO emissions ### Distribution Breakdown Total Rewards ├── 80% → iAERO stakers (you!) ├── 10% → Protocol treasury └── 10% → Peg defense fund ### Claiming Rewards * Rewards accumulate automatically * Claim anytime with no penalty * Multiple tokens (AERO, USDC, ETH, etc.) * Auto-compound by restaking ## Common Questions **Q: Can I get my AERO back?** A: No, deposits are one-way. But you can sell iAERO on the open market anytime. **Q: How often are rewards distributed?** A: Weekly, after each voting epoch. Keepers harvest and distribute automatically. **Q: Is there a lock period for staking?** A: No! Stake and unstake iAERO instantly with no cooldown. **Q: What happens to my voting power?** A: It's pooled with everyone else's and voted optimally by the protocol. ## Risk Considerations * **Smart Contract Risk**: Contracts are unaudited (audit pending) * **No Redemption**: Cannot convert iAERO back to AERO * **Price Risk**: iAERO may trade below intrinsic value * **Centralization**: Voting controlled by protocol multisig ## Next Steps ✅ **Completed first deposit?** Great! Now: 1. [Stake your iAERO](/user-guides/staking-iaero) for rewards 2. [Add liquidity](/user-guides/providing-liquidity) to iAERO/AERO pool 3. [Learn about LIQ](https://github.com/iaeroProtocol/iaero/blob/main/getting-started/tokenomics/liq-token.md) tokenomics # Fees & Earnings Users sometimes ask why the protocol takes a “rake” (deposit fee + weekly splits) and whether that’s extractive. This section shows, with formulas and concrete examples, why the design **shifts value from short‑term sellers to long‑term aligned users**, so that people who **stake iAERO** *and* **stake LIQ** can, in many scenarios, **earn more than 100% of a plain veAERO baseline**. *** ## The Flows (What Happens to Every Dollar of Rewards) Let **R** be the total weekly rewards the vault harvests from the veAERO strategy (bribes/fees/gauge rewards), normalized to a common unit (e.g. USD or AERO): * **80% → iAERO stakers** (via the Staking Distributor). * **10% → TreasuryDistributor** → **80% of this (8% of R) → LIQ stakers** → **20% of this (2% of R) → Protocol operations**. * **10% → Peg Defense Reserve** (used only when iAERO trades **below $0.85** to defend the peg and become buyer of last resort). Additionally, on **deposit**, the protocol mints **5% iAERO** to the treasury (the depositor gets 95%). That 5% is **protocol‑owned iAERO** (POI) which we typically **stake**. As sellers push price below $0.85, peg defense buys **more** iAERO at a discount, increasing POI. **Policy:** The protocol routes **80% of the protocol’s own iAERO staking rewards** to **LIQ stakers** (on top of the 8% base TreasuryDistributor flow). > Bottom line: **Sellers fund the protocol’s iAERO stack (via deposit fee + cheap peg buys)** → the protocol **stakes** that iAERO → **80%** of that **staking income** is **re‑routed to LIQ stakers**. If you are *both* an iAERO staker and a LIQ staker, you capture value in both streams. *** ## Notation (What Variables Mean) * **R** – total weekly harvested rewards (normalized). * **x** – your share of the **iAERO staking pool** (0–1). * **y** – your share of the **LIQ staking pool** (0–1). * **P** – the **protocol’s share of the iAERO staking pool** (0–1). (Grows from the 5% mint on deposits and from peg defense buys below $0.85.) * **Price threshold:** Peg defense *only buys* when iAERO **< $0.85**. *** ## Your Weekly Income (Formula) Your income has two legs: 1. **iAERO staking leg (80% of R):** You receive your pro‑rata share: $$ I\_{\text{iAERO}} = x \cdot 0.80 \cdot R $$ 2. **LIQ staking leg:** It receives: * **Base 8%** of R (from TreasuryDistributor), **plus** * **80% of the Protocol’s iAERO rewards**. Protocol’s iAERO rewards are **P × 80% × R**; routing **80%** of that to LIQ stakers adds **0.64·P·R** to the LIQ pool. So the **LIQ pool** distributes $(0.08 + 0.64P) \cdot R$, and **you** get: $$ I\_{\text{LIQ}} = y \cdot (0.08 + 0.64 P) \cdot R $$ **Total weekly income to a user who stakes both iAERO and LIQ:** $$ \boxed{I\_{\text{total}} = x \cdot 0.80R ;+; y \cdot (0.08 + 0.64P),R} $$ > **Key idea:** As **P** rises (more protocol‑owned iAERO from fees + cheap peg buys), the **LIQ pool** grows **non‑linearly** via the **+0.64 P** term. Sellers → more protocol iAERO → more flow to LIQ stakers. *** ## “More than 100%” – What Does That Mean? When people say “more than 100% of veAERO rewards,” they mean: compared to a **plain veAERO baseline** where a user with **1% of the veAERO** would expect **1% of R** each week, a user who **stakes iAERO (x)** and **also stakes LIQ (y)** can **exceed** that simple baseline because they tap **two** spigots (iAERO and LIQ), and **LIQ’s spigot** gets boosted by sellers via **P**. You’re not minting extra tokens out of thin air; you’re **capturing more of the pie** because: * **Some holders sell** iAERO under peg → protocol accumulates iAERO **cheaply**. * Protocol **stakes** those tokens → routing **80%** of that **staking income** to **LIQ stakers**. * If **you** are a LIQ staker, **you** get that incremental flow. *** ## Numerical Examples ### Example A – Baseline, No Protocol Share (P = 0) * **R = $100,000** weekly. * You stake **x = 1%** of iAERO; **y = 2%** of LIQ. * **P = 0** (no protocol iAERO yet). Income: * iAERO: $$1% \times 80% \times 100{,}000 = $800$$ * LIQ: $$2% \times (8% + 0.64\cdot 0)\times 100{,}000 = 0.02 \times 0.08 \times 100{,}000 = $160$$ * **Total = $960** **Plain veAERO baseline (1% of R) = $1,000.** Here you’re at **96%** of that baseline. (Reasonable when P=0.) *** ### Example B – Sellers Push Below $0.85 → Protocol P = 25% * Still **R = $100,000**; **x = 1%**, **y = 2%**. * Now **P = 25%** (protocol accumulated iAERO from deposit fees + cheap peg buys during drawdowns and staked it). Income: * iAERO: $$1% \times 80% \times 100{,}000 = $800$$ * LIQ: $$2% \times (8% + 0.64 \cdot 0.25) \times 100{,}000 = 0.02 \times (0.08 + 0.16)\times 100{,}000 = 0.02 \times 0.24 \times 100{,}000 = $480$$ * **Total = $1,280** **Plain veAERO baseline (1% of R) = $1,000.** Now you’re at **128%** of the baseline. The **extra $280** comes **entirely** from owning **LIQ** while **P > 0**. *** ### Example C – Peg Defense Buys at a Discount (Why P Grows Faster) If the Peg Reserve buys iAERO at **$0.80** using its **10% of R** budget: * Weekly peg budget \~ **0.10·R = $10,000**, * Price **$0.80** → it acquires **$10,000 / 0.80 = 12,500 iAERO** for the same spend, * Those tokens are **staked**; over time, **P** rises **faster** the deeper the discount. This is why drawdowns **help long‑term stakers**: sellers fund the protocol’s iAERO bag at a discount, and **80% of that bag’s yield** flows to **LIQ stakers**. *** ## Deposit Fee (5%) Is a Permanent Tailwind for P On every deposit: * User mints **95% iAERO** to themselves, * Protocol mints **5% iAERO** to treasury (protocol‑owned), * **Total iAERO issued = 100% of AERO deposited.** If both user and protocol stake at similar rates, the protocol’s **baseline share of the staking pool** starts near **\~5%** and **rises** as peg buys accumulate. Even **without** drawdowns, **P** trends upward with growth. *** ## What’s the Maximum “Community Capture”? At the **system** level, the split is always **80/10/10** of **R**. We don’t “create” extra rewards. But for **you**, if you hold **both** iAERO and LIQ, you combine: * Your **iAERO share** of the **80%**, **plus** * Your **LIQ share** of **(8% + 0.64·P)**. That’s how your **personal** capture can be **>100% of a plain veAERO baseline**, especially when **P** rises due to sellers. *** ## Edge Cases & FAQs * **Q: Does this guarantee >100%?** **No.** It depends on **P** (protocol iAERO share), your **x** and **y**, the weekly **R**, and market conditions. When there are few sellers and P stays small, your combined capture may sit near or below 100% of a plain veAERO baseline. * **Q: Is the peg always defended?** The **peg reserve buys only below $0.85**. It is **opportunistic**, not a constant market maker. * **Q: Why not send 100% to iAERO stakers?** The 10% → **TreasuryDistributor** (of which **8%** reaches **LIQ stakers**) and 10% → **Peg Reserve** make the system **antifragile**: sellers subsidize long‑term holders, and there’s capital dedicated to **buying at a discount** when it matters most. * **Q: Isn’t the 5% deposit fee just a tax?** It’s a **commitment device**: it seeds **protocol‑owned iAERO** that is **staked**, and **80%** of those earnings are **recycled to LIQ stakers**. Over time, this **transfers value from churn to conviction**. * **Q: Where does my LIQ yield come from?** Two places: (i) **8%** of weekly R (via TreasuryDistributor), and (ii) **80% of the protocol’s iAERO staking rewards** $\Rightarrow 0.64·P·R$ flows to the LIQ pool. When **P** grows, LIQ yield grows. *** ## TL;DR * **Sellers** of iAERO → increase **protocol iAERO** (via peg buys & the 5% deposit fee). * Protocol stakes that iAERO and routes **80% of its staking income** to **LIQ stakers**. * If **you** stake **iAERO** (**x**) **and** **LIQ** (**y**), your weekly income is: $$ I\_{\text{total}} = x \cdot 0.80R ;+; y \cdot (0.08 + 0.64P),R $$ * As **P** rises (especially during drawdowns), **LIQ** yield **accelerates**. * That’s how aligned users can **exceed** a plain **veAERO** baseline; not by printing new rewards, but by **capturing more of the pie** that sellers walk away from. > **Not financial advice.** Actual outcomes depend on markets, vote results, pool composition, and protocol params. The peg reserve only acts **below $0.85**. *** ## Worked “Quick Calculator” For a back‑of‑the‑envelope check: * Pick **R** (weekly rewards in USD). * Estimate your **x** (share of iAERO staking pool). * Estimate your **y** (share of LIQ staking pool). * Estimate **P** (protocol’s share of iAERO staking). > Rough guide: start \~**5%** from deposits; rises when iAERO **< $0.85** and peg defense buys; can be materially higher in stress. Then compute: * **iAERO leg:** $x \cdot 0.80 \cdot R$ * **LIQ leg:** $y \cdot (0.08 + 0.64P)\cdot R$ * **Total = sum**. Compare to a **plain veAERO baseline** of $x \cdot R$. If $y > 0$ and **P** is meaningful, you’ll often see **Total > $x \cdot R$**. *** ### Example Card (Doc Sidebar) > **Example:** $$R=$100k$$, $x=1%$, $y=2%$, $P=25%$ > > * iAERO: $$0.01 \times 0.80 \times 100k = $800$$ > * LIQ: $$0.02 \times (0.08+0.64 \times 0.25)\times 100k = $480$$ > * **Total = $1,280** vs plain veAERO baseline $$= 0.01\times 100k = $1,000$$. **You capture 128%** of the plain veAERO baseline. *** # Rewards Harvesting ## Overview The iAERO Protocol Reward Swapper is a powerful automation tool that transforms the tedious process of managing dozens of reward tokens into a single click. Instead of manually swapping 50+ different tokens every week—dealing with approvals, finding routes, monitoring slippage, and tracking dust balances—you can now convert everything to USDC or compound it back into iAERO instantly. **Time savings: \~2 hours per week → \~10 seconds** ⚡ *** ## Industry First: A Feature Others Haven't Built To our knowledge, **iAERO Protocol is the first and only liquid staking protocol to offer automated batch reward swapping** at this scale and sophistication. ### Why Is This Unique? Most liquid staking protocols stop at claiming rewards: * **Lido, Rocket Pool, Frax**: Rewards come in a single token (ETH, rETH, etc.) * **Yearn, Convex**: Multi-token rewards, but no batch conversion tools * **Beefy, Harvest**: Auto-compound single tokens, but can't handle diverse reward streams * **Standard veNFT protocols**: Leave users to manually manage everything **iAERO is different because:** 1. ✅ We deal with **50+ different reward tokens weekly** (the complexity problem) 2. ✅ We built **intelligent routing** across multiple DEXs 3. ✅ We handle **scam filtering, FOT tokens, and edge cases** automatically 4. ✅ We provide **one-click conversion** to either stables (USDC) or compounding (iAERO) 5. ✅ We make it **economically viable** through batching and gas optimization > **💡 Competitive Insight:** Most protocols avoid this problem by simplifying their reward structure to a single token. We embraced the complexity because **we participate in Aerodrome's full incentive ecosystem**—which means more yield sources, but also more tokens to manage. Instead of limiting our yield potential, we built the tooling to handle the complexity. The result? **You get maximum yields with minimum effort.** No other protocol offers this combination. ### Why Haven't Others Done This? Building a production-grade multi-token batch swapper is **hard**: * **Quote aggregation** across DEXs with different interfaces * **Dynamic slippage** calculation based on token value and liquidity * **Failure recovery** when some tokens can't be swapped * **Gas optimization** through intelligent batching * **Security** through whitelisting and validation * **Scam token filtering** to protect users * **Fee-on-transfer token support** (many tokens charge fees on transfer) * **Stale quote handling** (crypto prices change every second) Most protocols either: 1. Don't have this problem (single token rewards) 2. Have the problem but leave it to users 3. Tried to build it and gave up due to complexity We invested the engineering time because **we believe user experience matters**. Your time is valuable. Manual reward management is a tax on your attention and productivity. This isn't just a nice-to-have feature—**it's a fundamental reimagining of how reward management should work in DeFi**. *** ## ⚠️ **Critical: How Token Swapping Works** > **IMPORTANT:** The "Claim & Convert" and "Sweep Wallet" operations will swap **ALL tokens in your wallet** that are registered in the protocol's token registry—not just newly claimed rewards. **What gets swapped:** * ✅ Newly claimed rewards from the current week * ✅ Leftover tokens from previous weeks * ✅ Dust amounts you've accumulated * ✅ **Any token you're manually holding that's in the registry** **If you want to HOLD a specific token:** You must move it to a different wallet address BEFORE using the swap functions. The protocol cannot distinguish between "rewards I want to swap" and "tokens I'm intentionally holding." **Example scenario:** * You claim 100 AERO as rewards * You already have 500 AERO in your wallet from last week that you're saving * You click "Claim & Convert to USDC" * **Result:** ALL 600 AERO will be swapped to USDC **Why it works this way:** The batch swapper checks your wallet balance for all registered tokens and swaps everything it finds. This is by design—it ensures you never leave dust behind and truly "one-click" converts everything to your target asset. *** ## The Problem We Solved When you stake iAERO, you earn rewards from Aerodrome's voting incentives. This is fantastic for yields, but creates an operational challenge: ### Traditional Reward Management (The Old Way): 1. **Claim** rewards across multiple pools ⏱️ *5 minutes* 2. **Identify** what tokens you received 🔍 *3 minutes* 3. **Check** each token's value and liquidity 💰 *5 minutes* 4. **Find** optimal swap routes for each token 🗺️ *10 minutes* 5. **Approve** each token individually 📝 *20 minutes* (if doing them all) 6. **Execute** 50+ individual swaps 🔄 *60+ minutes* 7. **Deal** with failed transactions and slippage 😤 *10-30 minutes* 8. **Track** dust amounts too small to swap 🧹 *5 minutes* **Total: 2-3 hours of tedious work every single week.** And you'd likely skip tokens worth less than $5 because the gas fees and time weren't worth it. That's yield left on the table. *** ## The Solution: Intelligent Batch Swapping Our Reward Swapper automates this entire process with sophisticated on-chain orchestration: ### One-Click Operations: **1. Claim & Convert to USDC** * Claims all pending rewards from the distributor * Swaps everything to USDC automatically * Sends clean stables to your wallet * Perfect for taking profits or DCA strategies **2. Claim & Compound** * Claims all pending rewards * Converts everything to iAERO * Maximizes long-term accumulation **3. Sweep Wallet** (Advanced) * Swaps reward tokens already in your wallet * No claiming required * Useful for accumulated dust or external rewards * Converts everything to USDC **⚠️ Important Note on Token Selection:** The system swaps ALL tokens in your wallet that are in the protocol's registry. It does not distinguish between: * Rewards you just claimed this week * Tokens you've been holding from previous weeks * Tokens you acquired externally and deposited to this wallet If you want to keep certain tokens (e.g., manually managing AERO for other purposes), move them to a different wallet address before clicking "Claim & Convert" or "Sweep Wallet." ### What Happens Under the Hood: 1. **Registry Scan** 🔍 * Checks all known reward tokens from the protocol registry * Identifies what you have in distributor + wallet 2. **Pre-Screening** 🛡️ * Filters out scam tokens with no price data * Validates token contracts are legitimate * Prevents wasting gas on worthless tokens 3. **Smart Routing** 🗺️ * Fetches real-time quotes from 0x aggregator * Calculates optimal slippage for each token * Routes through best available DEX (Aerodrome, Uniswap V3, or aggregator) 4. **Batched Execution** ⚡ * Processes 8 tokens per transaction * Simulates each swap before executing * Continues even if some tokens fail * Reports exactly what succeeded vs failed 5. **Safety Checks** ✅ * Validates quotes aren't stale * Adjusts slippage based on token value and liquidity * Skips tokens with excessive price impact * Ensures minimum output amounts *** ## Token Approvals: What You Need to Know ### How Approvals Work Before the Reward Swapper can swap a token, it needs your permission (approval) to spend that token on your behalf. This is standard for all DeFi protocols. **Two Approval Strategies:** #### Strategy 1: Infinite Approval (Recommended) * Approve each token for maximum amount (2^256-1) * Only needs to be done **once per token, ever** * Future swaps happen instantly without re-approval * Saves \~$0.50-$2 in gas fees per token, per swap #### Strategy 2: Exact Amount Approval * Approve only the specific amount you're swapping * Requires re-approval every single time * More transactions = more gas fees * More tedious but maximum control ### The First-Time Experience **When you first use the swapper:** The frontend will automatically request approvals for any tokens that need them. You'll see transactions like: ``` 1. Approve USDC (Pending...) 2. Approve WETH (Pending...) 3. Approve AERO (Pending...) [...continues for each unique token...] ``` **After initial setup**, if you chose infinite approvals, future swaps just work—no approval pop-ups, no extra transactions, no delays. *** ## Is Infinite Approval Safe? (Yes, Here's Why) You might reasonably worry: "If I approve infinite amounts, can the contract steal my tokens?" **The answer is NO, and here's exactly why:** ### 1. **Smart Contract Architecture** 🏗️ The Reward Swapper contract is designed with multiple security layers: **Access Controls:** * Only whitelisted addresses can call swap functions * Owner cannot arbitrarily swap user tokens * No functions that allow owner to transfer your tokens directly **Whitelisted Operations Only:** * Only approved DEX routers can be used (Aerodrome, Uniswap V3, 0x, 1inch, Odos) * Only approved function selectors are callable * Only approved output tokens are allowed (USDC, iAERO, AERO, etc.) **Built-In Safety Mechanisms:** ```solidity - ReentrancyGuard: Prevents recursive calls - Ownable: Clear ownership model - SafeERC20: Safe token operations - No delegatecall: Cannot execute arbitrary code - No payable functions (except ETH wrapping) ``` ### 2. **Allowance Reset After Each Swap** 🔄 This is **critical**: After every swap, the contract resets the allowance back to zero: ```solidity // From RewardSwapper.sol: if (routerUsed != address(0)) { IERC20(s.tokenIn).forceApprove(routerUsed, 0); } ``` This means: * Even if a router is compromised, it can only use tokens during an active swap * Your infinite approval to the *swapper* doesn't translate to infinite approval to *external protocols* * The swapper only grants temporary, transaction-scoped approvals to routers ### 3. **You Control Execution** 🎮 The swapper **cannot act on its own**. Every swap requires: 1. You initiate the transaction 2. You sign with your wallet 3. The transaction executes your plan 4. Tokens go where **you** specified (recipient) The contract has **zero ability** to: * Initiate swaps on its own ❌ * Send your tokens to arbitrary addresses ❌ * Change swap parameters mid-flight ❌ * Access your tokens when you're not actively using it ❌ ### 4. **Open Source & Audited** 📖 * Full contract source code is available * Logic is transparent and verifiable * Uses battle-tested OpenZeppelin libraries * No hidden backdoors or admin functions that touch user funds * Community can audit every line ### 5. **Comparison to Manual Swapping** ⚖️ When you manually swap on Aerodrome or Uniswap: * You approve tokens to *their* router contracts * Those approvals often persist indefinitely * You're trusting those protocols just as much The Reward Swapper actually adds an **extra layer of validation** because it only allows pre-approved routers and functions. ### What You're Actually Trusting With infinite approval, you're trusting: 1. ✅ The Reward Swapper contract won't have exploitable bugs 2. ✅ The owner won't add malicious routers to the whitelist 3. ✅ The underlying DEXs (Aerodrome, Uniswap) won't have exploits Note: You're **already trusting #3** every time you use those DEXs directly. *** ## Real-World Time Savings: A Case Study Let's compare a typical week for an iAERO staker: ### Scenario: 50 Reward Tokens Worth $500 Total **Manual Swapping (Old Way):** | Action | Time | Gas Cost | | ---------------------------------- | ----------- | ---------- | | Check what rewards you have | 5 min | $0 | | Identify valuable vs dust tokens | 5 min | $0 | | Find swap routes for 50 tokens | 10 min | $0 | | Approve 20 new tokens individually | 30 min | \~$0.2 | | Execute 50 separate swaps | 60 min | \~$5 | | Deal with 5 failed transactions | 15 min | \~$0.5 | | Track dust (<$1 each) | 5 min | $0 | | **TOTAL** | **130 min** | **\~$5.7** | *** **Reward Swapper (New Way):** | Action | Time | Gas Cost | | ------------------------------------------------ | ---------- | ---------- | | Click "Claim & Convert to USDC" | 5 sec | $0 | | Wait for approval transactions (first time only) | 2 min | \~$0.2 | | Wait for batched swap execution | 30 sec | \~$3 | | **TOTAL (First Time)** | **3 min** | **\~$3.2** | | **TOTAL (Every Time After)** | **35 sec** | **\~$3** | *** ### The Long-Term Picture Over a year of weekly claims: **Manual:** * Time: 130 min × 52 weeks = **113 hours** (nearly 5 full days!) **Reward Swapper:** * Time: 3 min first week + (35 sec × 51 weeks) = **33 minutes total** **Savings:** * Time saved: **112.5 hours** * Sanity saved: **Priceless** 😌 *** ## Advanced Features ### 1. **Intelligent Slippage Management** 🎯 The swapper doesn't use a one-size-fits-all slippage setting. Instead: **High-value tokens** (>$100): * Uses 1.5-2% slippage * Worth optimizing for best price * Lower risk of MEV **Medium-value tokens** ($20-$100): * Uses 3-5% slippage * Balanced approach * Acceptable MEV risk for speed **Low-value tokens** ($5-$20): * Uses 5-10% slippage * Getting it done matters more than perfect price * Skip if price impact too high **Dust tokens** (<$5): * Uses up to 15% slippage * Just get rid of it * Skip entirely if liquidity is terrible This optimization means you get the best execution for valuable tokens while still converting dust that would otherwise sit in your wallet forever. ### 2. **Fee-on-Transfer Token Support** 🛡️ Some reward tokens charge fees when transferred (like reflection tokens). The swapper handles this: * Uses `useAll: true` flag * Checks actual balance received, not quoted amount * Adjusts swap amounts accordingly * Prevents "insufficient balance" errors ### 3. **Pre-Flight Simulation** ✈️ Before executing the full plan, the system: 1. Simulates each individual swap 2. Identifies which swaps will fail 3. Removes failing swaps from the batch 4. Only executes swaps that will succeed This means you never waste gas on doomed transactions. ### 4. **Graceful Failure Recovery** 🔄 If a batch has some failing swaps: * Successful swaps still complete * Failed swaps are logged with reason * You get partial execution * Can retry failed tokens later * Contract continues processing remaining tokens ### 5. **Scam Token Filtering** 🚫 The pre-screening phase automatically filters out: * Tokens with no price data (likely scams) * Tokens with zero liquidity * Tokens that fail contract validation * Honeypot contracts This protects you from wasting gas trying to swap worthless tokens or getting rugged during a swap. *** ## User Experience Flow ### For First-Time Users: **1. Claim & Convert to USDC** (Full Process) ``` You: Click "Claim & Convert to USDC" ↓ System: "Checking rewards..." ↓ System: "Found 47 reward tokens ($523 total)" ↓ System: "Pre-screening tokens..." ↓ System: "Filtered out 3 scam tokens" ↓ System: "Checking approvals..." ↓ You: Sign 15 approval transactions (one-time setup) ↓ System: "Approved all tokens! Starting swap..." ↓ System: "Processing batch 1/6..." System: "Processing batch 2/6..." [... continues ...] System: "Processing batch 6/6..." ↓ System: "✅ Swapped 44 tokens → $517 USDC" System: "⚠️ 3 tokens failed (see console for details)" ↓ You: $517 USDC in wallet (took 3 minutes total) ``` ### For Returning Users: ``` You: Click "Claim & Convert to USDC" ↓ System: "Checking rewards..." ↓ System: "Found 52 reward tokens ($487 total)" ↓ System: "Processing batch 1/7..." [... continues ...] System: "Processing batch 7/7..." ↓ System: "✅ Swapped 52 tokens → $482 USDC" ↓ You: $482 USDC in wallet (took 35 seconds total) ``` *** ## Failed Token Reporting When swaps fail, you get a detailed console report: ``` ⚠️ === FAILED TOKENS REPORT === 5 tokens failed during the swap process: 📋 Failed during: PRE_SCREENING • SCAM1 Address: 0x1234... Reason: No valid price data - likely scam token • SCAM2 Address: 0x5678... Reason: No valid price data - likely scam token 📋 Failed during: SLIPPAGE_TOO_HIGH • RARE Address: 0xabcd... Reason: Value $2.50 too low for 8.5% impact (needs 10.5% but max is 5%) 📋 Failed during: SIMULATION_FAILED • HONEYPOT Address: 0xdef0... Reason: Aggregator swap failed (contract revert) • FOT_BAD Address: 0x9999... Reason: Insufficient balance after fee 📝 === ADDRESSES TO DE-REGISTER === Consider removing these from the token registry: 0x1234... // SCAM1 - No valid price data 0x5678... // SCAM2 - No valid price data 0xdef0... // HONEYPOT - Contract revert ``` This transparency helps you: * Understand what went wrong * Decide whether to retry later * Identify permanently broken tokens * Maintain a clean token registry *** ## Gas Optimization The Reward Swapper is highly gas-efficient: ### Batch Processing * Processes 8 tokens per transaction * Amortizes gas overhead across multiple swaps * Cheaper than 8 individual transactions ### Smart Multicall Usage * Balance checks happen in parallel * Approval checks bundled together * Minimizes RPC calls ### Dust Floor Protection * Skips tokens below configured minimum ($0.01 default) * Prevents wasting gas on meaningless amounts * Configurable per-token if needed *** ## Security Considerations ### What's Protected ✅ 1. **Access Control**: Only authorized callers can execute plans 2. **Output Validation**: Only whitelisted output tokens allowed 3. **Router Validation**: Only approved DEXs can be used 4. **Selector Validation**: Only whitelisted function calls allowed 5. **Reentrancy Protection**: ReentrancyGuard on all entry points 6. **Slippage Protection**: Configurable per-swap slippage limits 7. **Amount Validation**: Quoted amounts must match actual amounts 8. **Allowance Hygiene**: Allowances reset to zero after each swap ### What You Should Know ⚠️ 1. **Smart Contract Risk**: Like all DeFi, there's inherent smart contract risk 2. **DEX Risk**: Swaps depend on underlying DEX security (Aerodrome, Uniswap, etc.) 3. **Price Oracle Risk**: Relies on 0x price quotes for routing 4. **MEV Risk**: Large swaps may be subject to MEV (but individual reward amounts are typically small) ### Best Practices 1. ✅ **Start Small**: Test with smaller amounts first 2. ✅ **Monitor First Swap**: Watch the console logs during your first swap 3. ✅ **Check Output**: Verify you received expected amounts in USDC/iAERO 4. ✅ **Review Failed Tokens**: Check the console for any failures 5. ✅ **Keep Registry Clean**: Remove permanently broken tokens from registry *** ## FAQ ### Q: Why do I need to approve tokens? **A:** This is a fundamental requirement of ERC-20 tokens. Any protocol that wants to move your tokens needs explicit permission. There's no way around this—it's baked into the Ethereum token standard. ### Q: Should I use infinite approval or exact amounts? **A:** **Infinite approval is recommended** for these reasons: * One-time setup per token * Massive gas savings over time * The contract is designed with this use case in mind * Security protections make it safe However, if you prefer maximum control, exact amounts work fine—just be prepared for frequent re-approvals. ### Q: What if a swap fails? **A:** The swapper uses graceful failure recovery: * Other swaps in the batch still execute * Failed swap is logged with reason * You can retry later if desired * Contract continues processing remaining tokens * No funds are lost—they stay in your wallet ### Q: Can I choose which tokens to swap? **A:** Currently, the one-click operations swap all eligible tokens. If you want granular control: 1. Use the "Claim All" button first 2. Then manually swap individual tokens 3. Or use the individual "Claim" buttons per token A future update may add token selection to the swapper. ### Q: What happens to dust amounts? **A:** Tokens below the dust floor ($0.01 by default) are automatically skipped. This prevents wasting gas on amounts that aren't worth the transaction cost. If you accumulate dust over time and want to sweep it, the "Sweep Wallet" function will attempt to convert even small amounts when you're doing a batch anyway. ### Q: Why did some tokens get filtered out? **A:** The pre-screening phase filters: * Scam tokens with no price data * Zero-liquidity tokens * Broken contract addresses * Honeypot contracts This protects you from wasting gas and potentially dangerous tokens. ### Q: How often should I use this? **A:** Most users swap rewards weekly after epoch ends (Thursday after 12pm UTC). But you can: * Accumulate for multiple weeks to reduce transaction frequency * Swap immediately if you need liquidity * Let dust accumulate and sweep monthly There's no requirement to swap on any schedule. ### Q: What's the difference between "Claim & Convert" and "Sweep Wallet"? **A:** **Claim & Convert:** 1. Claims pending rewards from the distributor contract 2. **Then swaps ALL tokens in your wallet** (both newly claimed + any pre-existing holdings) 3. Use when you have pending rewards to claim 4. ⚠️ **WARNING**: This will swap ALL tokens in the registry, including tokens you were holding from previous weeks **Sweep Wallet:** 1. Only swaps tokens already in your wallet 2. Doesn't claim anything from distributor 3. Use for accumulated dust or external rewards 4. Faster (no claim transaction needed) 5. Same behavior as "Claim & Convert" regarding which tokens get swapped (ALL tokens in registry) **Key Point:** Both operations swap ALL tokens found in your wallet that are in the protocol's registry. If you want to hold a specific token (e.g., manually managing your AERO), you must move it to a different wallet address BEFORE using either operation. ### Q: Why don't other liquid staking protocols have this feature? **A:** Great question! There are a few reasons: **1. They don't have the problem (yet):** * Most protocols simplify by only distributing rewards in 1-2 tokens * This limits yield potential but avoids complexity * Easier to build, but leaves money on the table **2. They tried and couldn't solve it:** * Building a production-grade batch swapper is engineering-intensive * Requires handling: quote aggregation, dynamic slippage, failure recovery, scam tokens, FOT tokens, gas optimization, and more * Many protocols started building this and gave up **3. They don't prioritize UX:** * Some protocols assume users will handle it themselves * "Not our problem" approach to reward management * Focus on protocol mechanics, not user experience **4. They didn't want to invest the resources:** * This feature required significant development time * Smart contract complexity increases audit costs * Ongoing maintenance as DEXs and aggregators evolve **iAERO's Philosophy:** We believe **user experience is a feature**, not a luxury. We participate in Aerodrome's full incentive ecosystem (50+ reward tokens), which maximizes yields. But we also believe you shouldn't need a computer science degree to manage those yields. So we built the tooling. And now we have a competitive advantage—users who try it don't want to go back to manual swapping. **The result?** We're the only protocol where "claim rewards" actually means "get USDC in your wallet" or "get more iAERO staked"—not "get 47 random tokens you now need to deal with." ### Q: Is this better than manually swapping valuable tokens? **A:** For tokens worth >$100, you might get slightly better execution by manually routing through Aerodrome or finding the optimal path yourself. But the time savings, convenience, and gas efficiency usually outweigh the potential 0.1-0.5% better execution you might achieve manually. For most users, the answer is **yes, this is better**, especially when you factor in your time value. ## **One more consideration:** If you're manually managing some tokens (e.g., accumulating AERO to stake elsewhere), you'll need to move them to a separate wallet before using the Reward Swapper. The system doesn't know which tokens you want to keep vs. swap—it treats ALL tokens in your wallet as "rewards to convert." ## Tips & Tricks ### 1. **Batch Your Weekly Claims** 📅 Instead of claiming every day, wait until Thursday after the epoch ends and claim everything at once. You'll: * Have more rewards to swap (better routes) * Pay gas once instead of multiple times * Spend 35 seconds instead of hours ### 2. **Use "Sweep Wallet" for External Rewards** 🧹 If you receive tokens from other sources (airdrops, other protocols, etc.), you can add them to the registry and use "Sweep Wallet" to convert them along with your iAERO rewards. ### 3. **Monitor the Console** 🖥️ The console logs provide valuable insights: * Which tokens succeeded * Why tokens failed * Price impact for each token * Slippage used per swap *** ## Coming Soon: Advanced Features We're constantly improving the Reward Swapper. Future enhancements may include: * **🎯 Token Selection UI**: Pick which tokens to swap * **⚙️ Custom Slippage**: Override automatic slippage per token * **🔄 Auto-Compound Scheduling**: Set it and forget it * **💎 NFT Reward Support**: Handle NFT rewards automatically * **🌐 Multi-Chain Support**: Swap rewards across chains *** ## Conclusion: Setting the Standard for DeFi UX The Reward Swapper represents a fundamental shift in how DeFi reward management works—and **iAERO is leading this change**. While other protocols leave users to wrestle with dozens of reward tokens manually, we asked: *"What if we actually built the tooling users need?"* The result is the **first and only automated batch reward conversion system** that handles the full complexity of multi-token yield farming: * 50+ tokens per week * Multiple DEX integrations * Intelligent routing and slippage * Scam protection and failure recovery * Gas optimization through batching ### The Competitive Moat This isn't just a feature—**it's a competitive advantage**: 1. **Other protocols can't easily copy this** (it took significant engineering investment) 2. **Users who experience it won't want to go back** (like going from dial-up to broadband) 3. **It compounds over time** (every week saves another 2 hours) 4. **It attracts power users** (sophisticated DeFi participants value their time) ### Why This Matters for the Protocol Users who don't have to spend 2 hours per week managing rewards are: * ✅ More likely to stake long-term (less friction = more stickiness) * ✅ More likely to compound (one-click compounding is frictionless) * ✅ More likely to recommend iAERO to others (word-of-mouth growth) * ✅ Less likely to churn to competitors (even if yields are similar elsewhere) **User experience is a moat.** And right now, we have the best reward management UX in DeFi. ### By the Numbers Instead of treating you like a full-time portfolio manager who loves spending hours on mundane token swaps, we treat you like what you are: **someone who wants to maximize yields with minimum hassle**. **Annual Impact:** * ⏱️ **112 hours saved** (nearly 5 full days of your life back) * 🧠 **Zero cognitive overhead** (no more "I should swap my rewards... later") * 🗑️ **Zero dust left behind** (every dollar of yield captured) * 😌 **Dramatically less frustration** (no more failed transactions or slippage hunting) **Cost:** * \~3 minutes first-time setup * \~35 seconds every week after **That's a 19,300% time efficiency improvement** (from 130 min to 35 sec). If your time is worth $15/hr (minimum wage), you're saving **$1,680 in time value** **Total annual benefit: \~$4,780** For free. Because we believe DeFi should work for you, not the other way around. ### The Vision This is just the beginning. The Reward Swapper proves that **DeFi protocols CAN prioritize user experience** without sacrificing decentralization or security. As other protocols wake up to this reality, we'll already be 10 steps ahead, building the next set of tools that make complex DeFi simple. Because at the end of the day, **the best protocol isn't the one with the highest APY**—it's the one you actually enjoy using. Welcome to veAERO 2.0. Welcome to actually enjoying DeFi again. Welcome to having your time back. 🚀 *** ## Quick Reference ### One-Click Actions | Button | What It Does | Best For | | --------------------------- | ---------------------------------------------- | ---------------------------------- | | **Claim & Convert to USDC** | Claims all rewards + swaps to USDC | Taking profits, paying bills, DCA | | **Claim & Compound** | Claims all rewards + swaps to iAERO + restakes | Long-term accumulation, max gains | | **Sweep Wallet** | Swaps all tokens in wallet (no claim) | Cleaning up dust, external rewards | ### Time Required | Operation | Time | | ---------------------------- | ------------ | | First time (with approvals) | \~3 minutes | | Subsequent swaps | \~35 seconds | | Manual approach (comparison) | \~2 hours | *** **Questions or issues?** Check the console logs first—they'll tell you exactly what happened. If something seems wrong, reach out in Discord or create a GitHub issue with the console output. **Happy swapping!** 🎉 *** *Last updated: November 2025*\ *Smart Contract:* [*RewardSwapper.sol*](https://basescan.org/address/0x25f11f947309df89bf4d36da5d9a9fb5f1e186c1)\ *Documentation:* [*docs.iaero.finance*](https://docs.iaero.finance) # Auto-USDC Vault ## Deposit iAERO once. Earn USDC every Thursday. No clicking around. Tired of claiming 21 different reward tokens every epoch and manually swapping each one to USDC? The Auto-USDC Vault does it all for you, weekly, with one signature at the end to claim. You deposit iAERO. The keeper handles the rest. You click claim when you want your USDC. That's it. *** ## What it does The Auto-USDC Vault wraps the protocol's existing iAERO staking. On every Thursday epoch boundary: 1. **Claims** every reward token your stake earned (AERO, WETH, USDbC, EIGEN, weETH, bribe tokens — everything) 2. **Converts** each one to USDC via the same battle-tested 0x router that powers the regular Rewards page 3. **Buckets** the USDC by epoch, ready for you to pull Your iAERO stake is yours — withdraw any time, instantly, no cooldown. *** ## Core Features 🪙 **Set-and-forget** - Deposit once, USDC accrues weekly without lifting a finger ⚡ **Instant withdrawals** - No cooldown, no lockup. Get your iAERO back any time. 🔄 **Multi-tier retry** - Keeper does up to 3 sweep passes per epoch to catch every token 🛡️ **Battle-tested swap path** - Uses the same RewardSwapper + 0x v2 integration that handles rewards on the main page 🎯 **Per-batch quote refresh** - 0x quotes are refreshed seconds before each swap broadcast, not bundled up-front 📊 **Pro-rata fair distribution** - USDC split by your share at each epoch's Thursday 00:00 UTC snapshot 🔐 **Withdraw protected** - Even if admin pauses, withdrawal stays open *** ## How it works ``` You deposit iAERO ────► Vault stakes it in EpochStakingDistributor (instant) │ Every Thursday 00:00 UTC ──► keeper claims rewards ──► swaps everything to USDC │ USDC bucketed per epoch ◄──── │ You click "Claim USDC" ◄──── (any time) ``` The keeper runs \~1 hour after each Thursday epoch boundary. Your USDC entitlement for an epoch = (your share at the epoch start) × (vault-wide USDC harvested that epoch) ÷ (total shares at epoch start). *** ## How To Use ### Step 1: Get iAERO If you don't already have iAERO, lock AERO via the standard [iAERO lock flow](https://app.iaero.finance). 1 AERO → 1 iAERO, permanent lock, you get a liquid receipt. ### Step 2: Open the Auto-Vault tab In the iAERO app, the **Auto-Vault** tab is the fifth tab (vault icon). You'll see a brief intro and your position. ### Step 3: Deposit 1. Enter the iAERO amount (or click **MAX**) 2. Click **Deposit** — first deposit asks for an iAERO approval (one signature) 3. Confirm the deposit signature 4. Your iAERO is now auto-staked. You'll see it under "Your deposit". ### Step 4: Wait for Thursday The keeper processes the previous epoch's rewards every Thursday around 01:00 UTC. After it runs, a green banner appears at the top of the tab: **"Pending USDC ready to claim"**. ### Step 5: Claim USDC Click **Claim USDC** in the banner. One signature, USDC arrives in your wallet. You can claim: * Any time after the keeper runs — there's no deadline * Multiple epochs at once (the contract handles it in one tx) * Even after withdrawing your iAERO principal ### Step 6 (optional): Withdraw Click the **Withdraw** toggle, enter amount (or MAX), confirm. iAERO returns instantly. Pending USDC remains claimable separately. *** ## Reward eligibility — the snapshot rule The underlying distributor uses a balance-at-epoch-start model. The Auto-Vault inherits this exactly: * **Your USDC share for an epoch is based on your vault balance at that epoch's boundary (Thursday 00:00 UTC).** * Deposit *before* Thursday 00:00 UTC → you earn for the upcoming week * Deposit *after* Thursday 00:00 UTC → you earn starting from the *next* Thursday There's no timing edge to chase — the snapshot decides. ### Worked example You deposit 100 iAERO on Wednesday 23:55 UTC. 5 minutes later the epoch boundary triggers. The snapshot at that boundary includes your 100 iAERO. You earn a pro-rata share of next week's USDC. If you'd deposited Thursday 00:05 UTC instead, you'd start earning from the *following* Thursday. *** ## The Fee **Zero protocol fee.** The vault charges no skim. You receive your full pro-rata share of the underlying epoch rewards, minus only the swap slippage paid to 0x's underlying DEX routes (typically 0.3% per swap, capped by the keeper's slippage logic). *** ## Auto-Vault vs. regular Stake tab Both options earn the same underlying rewards. The difference is *what you have to do with them*: | | Auto-Vault | Regular Stake (uses stiAERO) | | -------------------------------------- | ----------------------- | ---------------------------- | | Receive a transferable receipt token | ❌ no | ✅ stiAERO (ERC20) | | Auto-claim rewards weekly | ✅ yes | ❌ click claim per epoch | | Auto-convert to USDC | ✅ yes | ❌ click convert per epoch | | Choose which reward tokens to keep raw | ❌ everything → USDC | ✅ | | Compose with other DeFi protocols | ❌ shares aren't a token | ✅ stiAERO is ERC20 | | Withdraw lockup | none | none | | Underlying yield | same | same | Pick Auto-Vault if you want to **set and forget**. Pick regular Stake if you want **per-token control** or to **use your position as collateral elsewhere**. *** ## Frequently Asked Questions **Q: Do I need to do anything between claims?** No. The keeper runs weekly. Just open the app and click claim when you want your USDC. **Q: What happens if a reward token has no liquidity / can't be swapped?** The keeper attempts up to 3 retry sweeps with progressively higher slippage tolerance. Anything genuinely unswappable stays in the vault until admin resolves it manually. Your iAERO principal is never at risk. **Q: Can I lose my iAERO?** No. iAERO is permanently protected by the vault contract — even the admin role cannot rescue it. Withdrawals are always 1:1. **Q: What about my pending USDC?** Same — USDC is protected from admin rescue. Only your own `claimUSDC` call can move it, and only your pro-rata share for each epoch you held shares in. **Q: Do I get a receipt token (like stiAERO)?** **No** — by deliberate design. Your position lives in the vault contract's `sharesOf[your_address]` mapping. We don't issue a transferable token because of the epoch-snapshot reward model: transferring a receipt mid-week would create ambiguous "who earns this epoch's USDC" semantics. If you need a transferable ERC20 position, use the regular **Stake** tab (gives you stiAERO). **Q: Can I use my Auto-Vault position as collateral elsewhere?** Not directly — no transferable token. For DeFi composability use the Stake tab (stiAERO is a standard ERC20). **Q: Why pull-claim instead of auto-pushing USDC to my wallet?** Pulling lets you control claim timing (tax year, gas costs). Most major DeFi vaults (Curve, Convex, Yearn v2) use the same pattern. The frontend surfaces a prominent banner so you never miss a claim. **Q: How is APR calculated?** Last 4 epochs of vault-wide USDC harvested, annualized, divided by current vault TVL in USD. It's an estimate — actual returns vary with Aerodrome reward levels and vault TVL. **Q: Who runs the keeper?** A protocol-operated bot. The keeper EOA holds the `KEEPER_ROLE` and can be revoked + replaced by the multisig at any time. The contract supports `unfinalize(epoch)` if late rewards arrive after a premature finalization. **Q: Is this audited?** The vault contract was through 4 internal audit rounds (7 fixes applied) plus a 50-test Foundry suite (45 unit + 5 fork tests). 256-run fuzz on the pro-rata math. All 10 protocol contracts are under multisig control. Source verified on [Basescan](https://basescan.org/address/0xFE5c929677D97723dc822C86c93c7e2D1B59c774). **Q: Can I deposit on behalf of someone else?** No — only `msg.sender` can deposit for themselves. Prevents griefing. *** ## Contract Reference | Contract | Address | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Auto-USDC Vault** | [`0xFE5c929677D97723dc822C86c93c7e2D1B59c774`](https://basescan.org/address/0xFE5c929677D97723dc822C86c93c7e2D1B59c774) | | iAERO | [`0x81034Fb34009115F215f5d5F564AAc9FfA46a1Dc`](https://basescan.org/address/0x81034Fb34009115F215f5d5F564AAc9FfA46a1Dc) | | USDC (Base) | [`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`](https://basescan.org/address/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) | | EpochStakingDistributor | [`0x781A80fA817b5a146C440F03EF8643f4aca6588A`](https://basescan.org/address/0x781A80fA817b5a146C440F03EF8643f4aca6588A) | | RewardSwapper (Base) | [`0x25F11F947309df89bF4D36DA5D9A9fb5F1E186c1`](https://basescan.org/address/0x25F11F947309df89bF4D36DA5D9A9fb5F1E186c1) | | Treasury Multisig (admin) | [`0x1039CB48254a3150fC604d4B9ea08F66f4739D37`](https://basescan.org/address/0x1039CB48254a3150fC604d4B9ea08F66f4739D37) | ### Key functions | Function | Caller | Notes | | ------------------------------------- | ------ | ----------------------------------------- | | `deposit(uint256)` | user | Auto-stakes into upstream distributor | | `withdraw(uint256)` | user | Always open, even when paused | | `claimUSDC(uint256[] epochs)` | user | Up to 50 epochs per call | | `previewUSDC(address, uint256)` | view | Per-epoch pending lookup | | `previewUSDCMany(address, uint256[])` | view | Batch pending lookup | | `harvest(...)` | keeper | Per-epoch claim + swap orchestration | | `pause()` / `unpause()` | admin | Withdraw + claim remain open during pause | | `unfinalize(uint256)` | admin | Re-open epoch if late rewards arrive | | `rescue(address, address, uint256)` | admin | iAERO, USDC, stiAERO permanently blocked | ### Events ```solidity event Deposited (address indexed user, uint256 amount); event Withdrawn (address indexed user, uint256 amount); event Harvested (uint256 indexed epoch, uint256 usdcGained, bool finalized); event Claimed (address indexed user, uint256 indexed epoch, uint256 usdc); ``` *** ## Security Model | Property | How it's enforced | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | User principal (iAERO) cannot be drained by anyone | `rescue()` explicitly blocks iAERO | | Earned USDC cannot be drained by admin | `rescue()` explicitly blocks USDC | | Vault's downstream receipt (stiAERO) cannot be drained | `rescue()` blocks the upstream's `receiptToken()` | | Reentrancy | `nonReentrant` on every state-changing function; chained protection from upstream + swapper | | Withdrawal liveness | `withdraw()` is NOT pause-gated | | Claim liveness | `claimUSDC()` is NOT pause-gated | | Double-claim | `claimedByUser[user][epoch]` enforces idempotency | | Compromised keeper | Bounded to one week of unclaimed rewards via slippage; multisig revokes role instantly | | First-depositor share manipulation | Defused by a 1-iAERO seed deposit at deploy time | *** ## The TL;DR The Auto-Vault is the lazy man's iAERO staking. Same yield as the regular Stake tab, but you don't have to babysit it. * **Deposit asset:** iAERO * **Reward asset:** USDC, claimed weekly * **Withdrawal:** Instant, no cooldown * **Fee:** Zero protocol skim * **Claim:** Pull model (you click) * **Receipt token:** None (use Stake tab if you need stiAERO) Connect → Deposit iAERO → Wait until Thursday → Claim USDC → Repeat. *** ## Links * 🚀 [Launch the app](https://app.iaero.finance) * 🏠 [iAERO Protocol](https://iaero.finance) * 📖 [Verified contract](https://basescan.org/address/0xFE5c929677D97723dc822C86c93c7e2D1B59c774) * 💬 [Discord](https://discord.gg/iaero) *** *Disclaimer: The Auto-Vault is a smart contract on Base mainnet. Smart contracts carry inherent risk. Always verify transactions before signing. Past yields do not guarantee future returns. Not financial advice.* # Token Sweeper ## Turn Your Dust Into Dollars (or ETH) Got 47 random tokens cluttering your wallet like forgotten leftovers in your fridge? Token Sweeper is your DeFi spring cleaning solution - batch swap all that dust into USDC or WETH in a few batches and let us take all the hassle out of it. No more clicking through 47 individual swaps. No more paying 47 separate gas fees. No more wondering "wait, what even is this token?" *** ## ⚠️ Alpha Notice **Token Sweeper is currently in alpha.** This means: * 🧪 Features are still being tested and refined * 🐛 You might encounter bugs (please report them!) * 🚧 UI/UX improvements are ongoing * 💡 Your feedback directly shapes the product We're actively developing new features including **cross-chain bridging** and **multi-aggregator price comparison** to get you even better rates. Use at your own risk, start with small amounts, and remember: alpha software gonna alpha. *** ## Core Features 🔍 **Smart Wallet Scanning** - Automatically finds all your ERC-20 tokens across 9 chains 💰 **Batch Swaps** - Swap 10, 20, or 50 tokens in ONE transaction 🎯 **Best Rates** - Routes through 100+ DEXs via 0x aggregator 🛡️ **Spam Filtering** - Automatically hides scam tokens and honeypots 📊 **Price Impact Warnings** - Know exactly what you're getting before you commit 🔬 **Simulation First** - Every swap is dry-run tested before execution ➕ **Manual Token Add** - Found a token we missed? Add it yourself *** ## The Fee **0.05% (5 basis points)** That's it. Swap $1,000 of tokens, pay $0.50 in protocol fees. For context: * Uniswap: 0.30% (6x more) * Most aggregators: 0.10-0.30% * Us: 0.05% The fee helps keep the robots running and the devs caffeinated. *** ## Supported Chains | Chain | Status | Notes | | ---------------- | ------ | ------------------------------------ | | 🔵 **Base** | ✅ Live | Home chain, best tested | | ⟠ **Ethereum** | ✅ Live | Higher gas, bigger swaps recommended | | 🔴 **Arbitrum** | ✅ Live | Fast & cheap | | 🔴 **Optimism** | ✅ Live | Fast & cheap | | 🟣 **Polygon** | ✅ Live | Very cheap gas | | 🟡 **BNB Chain** | ✅ Live | Watch for tax tokens | | 🔺 **Avalanche** | ✅ Live | C-Chain supported | | 📜 **Scroll** | ✅ Live | ZK rollup | | 🟢 **Linea** | ✅ Live | ZK rollup | *** ## How To Use Token Sweeper ### Step 1: Connect Your Wallet Click "Connect Wallet" and choose your preferred wallet. We support all major wallets via WalletConnect and browser extensions. ### Step 2: Select Your Chain Make sure you're connected to the chain where your dust lives. The sweeper will automatically detect your network. ### Step 3: Scan Your Wallet Click **"Scan Wallet"** to discover all tokens in your wallet. This typically takes 10-30 seconds depending on how many tokens you have. > 💡 **Pro Tip**: If you know you have a token that wasn't detected, use the manual token input field to add it by address. ### Step 4: Review Your Tokens You'll see a list of all detected tokens with: * Current balance * Estimated USD value * Price per token Tokens are pre-selected for sweeping. **Uncheck** any you want to keep. ### Step 5: Choose Your Output Pick what you want to receive: * **USDC** - Stable value, good for taking profits * **WETH** - Stay in ETH, good for gas reserves ### Step 6: Preview Quotes Click **"Sweep X Tokens to USDC/WETH"** to fetch quotes. You'll see: * Input value vs output value * Price impact percentage * Which tokens have high slippage > ⚠️ **High Impact Warning**: Tokens with >5% price impact need "Force" enabled to swap. This protects you from bad trades. ### Step 7: Approve & Execute 1. **Approve tokens** - One-time approval for each token 2. **Confirm the swap** - Review final amounts 3. **Execute** - Sign the transaction ### Step 8: Collect Your Bag Watch the magic happen. Your USDC or WETH will arrive in your wallet once the transaction confirms. *** ## Do's and Don'ts ### ✅ Do's | Do This | Why | | ------------------------------ | ---------------------------------------- | | **Check price impact** | High impact = you're getting a bad rate | | **Use "Force" carefully** | Only for tokens you REALLY want to dump | | **Scan after airdrops** | New tokens appear all the time | | **Report spam tokens** | Click ✕ to mark scams - helps everyone | | **Refresh if prices seem off** | Prices cache for 5 mins | | **Check the output preview** | Know what you're getting before you sign | ### ❌ Don'ts | Don't Do This | Why | | ---------------------------------------- | -------------------------------------------------------- | | **Don't sweep tokens you want to keep** | Double-check your selection! | | **Don't ignore high price impact** | >10% impact means bad liquidity | | **Don't use on BNB tax tokens** | They'll fail - use PancakeSwap directly | | **Don't expect miracles from honeypots** | If you can't sell it on Uniswap, we can't sell it either | | **Don't include your main holdings** | This is for DUST, not your retirement fund | *** ## Real Talk: What Can and Can't Be Swept ### ✅ Works Great * Standard ERC-20 tokens * DEX LP tokens (converted to underlying value) * Governance tokens * Meme coins with liquidity * Airdropped tokens (legitimate ones) * Yield farming rewards ### ⚠️ Might Have Issues * Very low liquidity tokens (high slippage) * Recently launched tokens (no DEX pools yet) * Rebasing tokens (amounts change constantly) * Tokens with transfer limits ### ❌ Won't Work * Honeypots (can't be sold by design) * Tax tokens on BSC (>5% transfer tax breaks routing) * Scam airdrop tokens (no liquidity, no value) * NFTs (this is for ERC-20 tokens only) * Native ETH/BNB/MATIC (only ERC-20 wrapped versions) *** ## Contract Addresses All swaps execute through our audited RewardSwapper contract: ### RewardSwapper Contracts | Chain | Contract Address | Verified | | ------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **Base** | `0x25f11f947309df89bf4d36da5d9a9fb5f1e186c1` | [BaseScan ↗](https://basescan.org/address/0x25f11f947309df89bf4d36da5d9a9fb5f1e186c1) | | **Ethereum** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [Etherscan ↗](https://etherscan.io/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **Arbitrum** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [Arbiscan ↗](https://arbiscan.io/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **Optimism** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [OP Etherscan ↗](https://optimistic.etherscan.io/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **Polygon** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [PolygonScan ↗](https://polygonscan.com/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **BNB Chain** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [BscScan ↗](https://bscscan.com/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **Avalanche** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [Snowtrace ↗](https://snowtrace.io/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **Scroll** | `0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a` | [ScrollScan ↗](https://scrollscan.com/address/0x75f57Faf06f0191a1422a665BFc297bcb6Aa765a) | | **Linea** | `0x679e6e600E480d99f8aeD8555953AD2cF43bAB96` | [LineaScan ↗](https://lineascan.build/address/0x679e6e600E480d99f8aeD8555953AD2cF43bAB96) | ### Output Token Addresses (USDC) | Chain | USDC Address | Decimals | | --------- | -------------------------------------------- | --------- | | Base | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | 6 | | Ethereum | `0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48` | 6 | | Arbitrum | `0xaf88d065e77c8cC2239327C5EDb3A432268e5831` | 6 | | Optimism | `0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85` | 6 | | Polygon | `0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359` | 6 | | BNB Chain | `0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d` | **18** ⚠️ | | Avalanche | `0xB97EF9Ef8734C71904D8002F8b6Bc66Dd9c48a6E` | 6 | | Scroll | `0x06eFdBFf2a14a7c8E15944D1F4A48F9F95F663A4` | 6 | | Linea | `0x176211869cA2b568f2A7D4EE941E073a821EE1ff` | 6 | > ⚠️ **Note**: BNB Chain USDC uses 18 decimals, unlike other chains which use 6. *** ## Security Model ### How Your Tokens Stay Safe 1. **You approve to RewardSwapper** - Not to random aggregator contracts 2. **Simulation before execution** - Every swap is tested before real execution 3. **Slippage protection** - Default 3% max slippage prevents sandwich attacks 4. **No infinite approvals by default** - Only approves what's needed 5. **Contract is verified** - Read the code yourself on block explorers ### What You're Trusting * **RewardSwapper contract** - Our battle-tested swap router * **0x Aggregator** - Industry-standard DEX aggregation * **The underlying DEXs** - Uniswap, Curve, Balancer, etc. ### What We Can't Protect Against * Tokens that are designed to be unsellable (honeypots) * Market conditions changing between quote and execution * Blockchain congestion causing delayed transactions * You accidentally including tokens you wanted to keep *** ## Troubleshooting ### "No swappable tokens found" * Make sure you're on the correct chain * Try clicking "Re-scan" to fetch fresh data * Some tokens may have zero balance after fees ### "Quote failed" for a specific token * Token may have no liquidity on DEXs * Token may be a honeypot/scam * Try marking it as spam and sweeping the rest ### "Transaction reverted" * Slippage exceeded - try increasing slippage or use "Force" * Token has transfer tax - common on BSC * Approval may have expired - refresh and try again ### "High price impact" warning * Token has low liquidity * You're selling a large portion of the pool * Consider selling smaller amounts or accepting the loss ### Stuck on "Checking approvals" * Wallet may need a refresh * RPC might be slow - wait or try again * Check that you have enough native token for gas *** ## Coming Soon ### 🌉 Cross-Chain Bridging Sweep tokens on Arbitrum, bridge proceeds to Base, all in one flow. ### 🔀 Multi-Aggregator Routing Compare quotes from 0x, 1inch, Paraswap, KyberSwap, and more - automatically pick the best rate for each token. ### 📊 Analytics Dashboard See your sweeping history, total value recovered, gas saved vs individual swaps. ### 🤖 Scheduled Sweeps Set it and forget it - auto-sweep new airdrops weekly. ### 🎯 Custom Output Tokens Sweep to any token, not just USDC/WETH. *** ## The TL;DR Token Sweeper batch-swaps your wallet dust into USDC or WETH. * **Fee**: 0.05% (five basis points) * **Chains**: 9 (Base, ETH, Arb, OP, Polygon, BSC, Avax, Scroll, Linea) * **Status**: Alpha (use small amounts first) * **Safety**: Simulated before execution, slippage protected Connect wallet → Scan → Select tokens → Preview → Sweep → Profit. Stop leaving money scattered across your wallet. Let the robots do the cleanup. *** ## Links * 🚀 [Launch Token Sweeper](https://sweeper.iaero.io) * 🏠 [iAERO Protocol](https://iaero.io) * 💬 [Discord](https://discord.gg/iaero) * 🐦 [Twitter](https://twitter.com/iaaboratory) * 📖 [GitHub](https://github.com/iaeroProtocol) *** *Built with ❤️ by* [*iAERO Protocol*](https://iaero.io) *Disclaimer: Token Sweeper is provided as-is. Always verify transactions before signing. Not financial advice. Past sweeping performance does not guarantee future dust accumulation. Please sweep responsibly.* # Vault System ## Overview The PermalockVault is the core contract that manages all veAERO NFT positions and user deposits. It maintains maximum voting power by keeping positions permanently locked while issuing liquid iAERO tokens to users. ## Core Components ### Deposit Management The vault accepts two types of deposits: * **AERO tokens**: Direct deposits that create new veAERO positions * **veNFT transfers**: Existing veAERO positions transferred to vault management ### NFT Position Structure **Primary NFT** * The main veAERO position that receives all deposits and merges * Maintained at maximum lock duration (4 years) * Automatically rebased every \~3 months to maintain max lock * Holds the majority of voting power **Additional NFTs** * Temporary holding state for newly deposited veNFTs * Queued for merging into primary position * Merged during maintenance operations to minimize gas costs ### Automated Management **Rebase Operations** * Checks if lock duration < 3.75 years (4 years - 3 months) * Extends lock back to maximum 4 years * Maintains optimal voting power without manual intervention **Merge Operations** * Combines multiple NFTs into primary position * Reduces management overhead * Consolidates voting power for efficiency ## Fee Structure ### Protocol Fee: 5% Applied on all deposits: * User deposits 100 AERO * 95 iAERO minted to user * 5 iAERO minted to treasury This fee: * Funds protocol development * Provides treasury reserves * Aligns long-term incentives ### No Exit Fees * No fees for trading iAERO * No fees for unstaking * No additional performance fees ## Security Features ### Deposit Guards Prevents accidental NFT transfers: * `_expectedNftSender`: Validates sender address * `_expectedNftId`: Confirms correct NFT * `_expectingNft`: Guards transfer window Only accepts NFTs during active deposit transactions. ### Access Control * **Owner**: Protocol multisig for critical functions * **Authorized**: Voting manager and rewards collector * **Keeper**: Automated maintenance operations * **Users**: Can only deposit, not withdraw ### Emergency Controls * Pause mechanism for deposits * Emergency pause for critical issues * Sweep functions for stuck tokens (not user deposits) ## Vault Accounting ### Key Metrics Tracked * `totalAEROLocked`: Sum of all AERO in vault * `totalIAEROMinted`: Total iAERO supply issued * `nftLockedAmount[id]`: AERO per NFT position * `primaryNFT`: Current primary NFT ID ### Status Function Returns comprehensive vault state: * Total user deposits * Protocol fees collected * Primary NFT details * Voting power * Rebase/merge status ## Integration Points ### With iAERO Token * Vault has exclusive minting rights * Mints on deposits only * Cannot burn or redeem ### With Voting Manager * Executes votes through `executeNFTAction` * Maintains vote delegation * Claims bribes and fees ### With Rewards Harvester * Sweeps collected rewards * Enables reward distribution * Maintains treasury flow ## Operational Flow 1. **User Deposits** → Vault receives AERO/veNFT 2. **Token Minting** → Issues iAERO and LIQ to user 3. **Position Management** → Creates/increases veAERO lock 4. **Maintenance** → Keeper rebases/merges positions 5. **Voting** → Manager executes optimal votes 6. **Rewards** → Harvester collects and distributes ## Risk Considerations ### No Redemption Mechanism * Deposits are one-way * Cannot convert iAERO back to AERO * Relies on secondary market liquidity ### Centralization Points * Multisig controls critical functions * Keeper required for maintenance * Voting strategy determined by protocol ### Smart Contract Risk * Complex NFT interactions * Cross-contract dependencies * Unaudited code (initially) # veNFT Management #### Primary NFT Management **Selection Criteria** * First valid NFT becomes primary * Highest balance preferred * Must not be expired * Must be owned by vault **Maintenance Schedule** * Rebase every \~3 months * Merge on new deposits * Weekly voting execution * Continuous optimization ### Advanced NFT Functions #### Merging Operations **Why Merge?** * Consolidates voting power * Reduces gas costs * Simplifies management * Improves capital efficiency **Merge Rules** * Only merge into primary * Source NFT destroyed * Balances combined * Voting power consolidated **Auto-Merge Triggers** * New deposit received * Maintenance called * Gas optimization batch #### Rebase Operations **Purpose**: Maintains maximum voting power by extending lock duration **When Rebasing Occurs** * Lock duration < 3.75 years * Called by keeper * Part of maintenance routine **Process Example** if (timeRemaining < MAX\_LOCK - 3 months) { extendLock(MAX\_LOCK\_DURATION); } Enables: * Gauge voting * Bribe claiming * Fee collection * Delegation ### NFT Security Model #### Ownership Structure * Vault owns NFTs permanently * Users cannot withdraw NFTs * Only authorized contracts can execute actions #### Protected Functions * **Transfer**: Disabled except deposits * **Merge**: Only vault-controlled NFTs * **Split**: Not supported * **Burn**: Never allowed #### Emergency Procedures **Stranded NFT Recovery** For NFTs sent outside deposit flow: * Owner can rescue if not managed * Requires proof of non-management * One-time recovery option **Failed Merge Handling** * Retry in next maintenance * Manual merge by owner * Skip if consistently failing ### Optimization Strategies #### Gas Optimization * Batch merges when possible * Combine rebase with merge * Skip unnecessary operations * Cache state reads #### Voting Power Maximization * Always maintain max lock * Merge quickly after deposits * Never let positions expire * Compound all rewards #### Management Efficiency * Automate via keepers * Monitor merge success * Track rebase schedule * Alert on anomalies ### Integration with Aerodrome #### Gauge Voting * Vote on liquidity gauges * Direct emissions * Maximize bribes * Optimize returns #### Reward Claims * Collect trading fees * Harvest bribes * Claim emissions * Process rebases #### Compatibility * Supports all veAERO functions * Handles permanent locks * Manages standard locks * Processes all reward types ### User Considerations #### Before Depositing NFTs * Check lock isn't expired * Disable auto-max lock * Verify ownership * Understand permanence #### After Depositing * NFT permanently in vault * Receive iAERO tokens * Cannot reclaim NFT * Voting automated #### Benefits vs Direct Holding * No manual voting needed * No rebase management * Liquid iAERO tokens * Professional optimization * Compound efficiency ### Technical Specifications #### Supported Operations | Operation | Supported | | ------------- | --------- | | Deposit | ✅ | | Merge | ✅ | | Extend lock | ✅ | | Vote | ✅ | | Claim rewards | ✅ | | Withdraw | ❌ | | Split | ❌ | | Reduce lock | ❌ | | Transfer out | ❌ | #### Gas Costs (Estimated) | Operation | Gas Cost | | -------------- | ---------- | | Deposit veNFT | \~200k gas | | Merge NFTs | \~150k gas | | Rebase lock | \~100k gas | | Vote execution | \~300k gas | These operations are optimized and batched where possible to minimize costs. # Voting Strategy ## Overview The iAERO voting strategy optimizes veAERO voting power allocation across Aerodrome gauges to maximize returns for iAERO stakers. Unlike manual voting, our system uses data-driven decisions based on bribes, fees, and strategic value. ## Core Principles ### 1. ROI Maximization Every vote aims to generate maximum value per unit of voting power ### 2. Automated Execution No manual intervention - votes execute programmatically each epoch ### 3. Transparent Allocation All voting decisions are on-chain and verifiable ## The Optimization Algorithm ### Step 1: Data Collection Each epoch, the system collects: * **Bribe Values**: USD value of all bribes per pool * **Historical Fees**: Past fee generation by pool * **Base Revenue**: Strategic value assignments * **Pool Health**: TVL, volume, and gauge status * **Current Votes**: Essential for calculating ROV (Return on Vote) ### Step 2: Score Calculation **Components:** * **Bribes**: Current epoch bribes converted to USD via oracles * **Discount Factor**: Usually 100%, can be adjusted for risk * **Base Revenue**: Keeper-assigned strategic value * **Historical Performance**: 30-day average fees generated * **Current Votes**: Votes given to pool so far during epoch ### Step 3: Weight Allocation ### Step 4: Rebalancing Remaining weight after constraints is redistributed using the "largest remainder" method to ensure exactly 100% allocation. Constraints and Limits Minimum Vote Weight Threshold: 0.05% (5 basis points) Reason: Gas efficiency and impact threshold Pools below minimum receive no votes Maximum Pool Allocation Cap: 70% of voting power Reason: Risk diversification Prevents single pool domination Eligible Pools Must have active gauge Must be whitelisted by keeper Must have sufficient liquidity Oracle Integration Price Feeds All bribes valued using Chainlink oracles: Real-time price discovery Manipulation resistance Multi-token support Supported Bribe Tokens AERO USDC/USDT ETH/WETH Major protocol tokens Staleness Protection Maximum oracle age: 3600 seconds Fallback: Skip pools with stale prices ### Strategic Considerations Base Revenue Assignments Keepers can assign base revenue to pools for strategic reasons: High Priority Pools: iAERO/AERO - Maintain protocol liquidity AERO/USDC - Core ecosystem pair Strategic partner pools ### Example Assignments: iAERO/AERO: $10,000 base revenue (ensures consistent votes) AERO/USDC: $5,000 base revenue Partner pools: $1,000-3,000 based on agreements Multi-Epoch Planning Bribes can be deposited for multiple epochs: Provides vote certainty for bribers Smooths out weekly volatility Enables long-term partnerships ### Execution Timeline Weekly Cycle Wednesday 23:00 UTC: Epoch ends Thursday 00:00 UTC: New epoch begins Thursday 00:00-23:59 UTC: Voting window 00:00-12:00: Data collection and calculation 12:00-18:00: Keeper review period 18:00-23:59: Vote execution Friday: Rewards distribution Performance Metrics Key Indicators Vote Efficiency: $ earned per veAERO voting power Bribe Capture Rate: % of available bribes earned Execution Rate: % of epochs successfully voted Historical Performance Typical returns by source: Bribes: 60-70% of total Trading fees: 20-30% of total AERO emissions: 10-20% of total Manual Override While fully automated, the system includes safety overrides: Keeper Intervention Authorized keepers can: Adjust base revenue values Add/remove eligible pools Execute votes with custom weights Emergency Procedures If automation fails: Keeper alerts triggered Manual vote execution Post-mortem analysis Competitive Advantages vs Manual Voting Never misses epochs (100% participation) Optimizes across all pools (not just familiar ones) Responds to real-time bribes (data-driven) vs Other Managers Transparent algorithm (fully on-chain) No hidden deals (all bribes visible) Decentralized execution (multiple keepers) ### Future Improvements Machine Learning Integration Predict future bribe patterns Optimize for multi-epoch outcomes Adapt to market conditions Cross-Protocol Voting Coordinate with other protocols Joint voting strategies Shared liquidity initiatives ### Governance Integration LIQ holder input on strategy Community pool priorities Revenue sharing adjustments ### Example Allocation Here's a typical epoch allocation: PoolBribesBaseScoreWeightAERO/USDC$50,000$5,000$55,00027.5%iAERO/AERO$20,000$10,000$30,00015.0%ETH/USDC$40,000$0$40,00020.0%WBTC/ETH$35,000$0$35,00017.5%Others (10 pools)$40,000$0$40,00020.0%Total$185,000$15,000$200,000100% This allocation maximizes returns while maintaining strategic positions in key pools. Verification All votes can be verified on-chain: Check VotingManager contract for execution View vote transaction on Basescan Verify weights on Aerodrome UI Calculate expected vs actual returns The strategy is fully transparent and auditable, ensuring alignment with iAERO staker interests. # Depositing AERO ## Prerequisites * AERO tokens in your wallet * ETH for gas fees * Connected wallet to the dApp ## Steps ### 1. Navigate to Lock AERO Tab Select the "Lock AERO" tab in the application. ### 2. Enter Amount Input the amount of AERO you wish to deposit. ### 3. Approve AERO If this is your first deposit, approve the vault contract to spend your AERO. ### 4. Deposit Click "Deposit AERO" and confirm the transaction. ### 5. Receive Tokens You'll receive: * **iAERO**: 95% of your deposit amount * **LIQ**: Based on current emission rate ## Important Notes ⚠️ **One-way conversion**: AERO → iAERO is irreversible\ ⚠️ **5% protocol fee**: Deducted from deposits\ ✅ **Immediate liquidity**: iAERO is immediately tradeable # Depositing veNFTs ## Overview Users can deposit existing veAERO NFTs into the vault to receive iAERO and LIQ tokens. ## Prerequisites * Own a veAERO NFT * NFT must not be expired * Disable auto-max lock if enabled ## Steps ### 1. Select Your NFT In the "Deposit veNFT" section, select your NFT from the dropdown. ### 2. Approve & Deposit 1. Approve the vault to transfer your NFT 2. Click "Deposit veNFT" 3. Confirm the transaction ### 3. Automatic Processing The vault will: * Transfer your NFT to the vault * Merge it with existing positions (if applicable) * Issue the depositor with iAERO and LIQ tokens ## Troubleshooting **"Wallet mutated calldata"**: Disable transaction protection in your wallet **NFT not merging**: Likely the NFT is auto-locked. The protocol will unlock and merge in its next maintenance period; nothing the depositor needs to do. # Staking iAERO ## Why Stake iAERO? Holding iAERO in your wallet earns nothing. Staking it in the StakingDistributor earns you 80% of all protocol voting rewards. This includes bribes, fees, and emissions from Aerodrome. ## How to Stake ### Step 1: Navigate to Staking Go to the "Stake iAERO" tab in the app at [app.iaero.finance](https://app.iaero.finance) ### Step 2: Enter Amount * Enter the amount of iAERO to stake * You can stake any amount, no minimum * Use "MAX" button to stake entire balance * If you don't yet have iAero, click the green "Buy iAero" button to buy it directly on Aerodrome. ### Step 3: Approve (First Time Only) If this is your first time staking: 1. Click "Approve iAERO" 2. Confirm the approval transaction 3. Wait for confirmation ### Step 4: Stake 1. Click "Stake iAERO" 2. Confirm the transaction 3. Your iAERO is now earning rewards! ## Understanding Your Position ### Staking Dashboard Shows: * **Your Staked Balance**: Amount of iAERO staked * **Pool Share**: Your % of total staked iAERO * **Pending Rewards**: Claimable tokens earned * **APR**: Current annualized return ### No Lock Period * Unstake anytime with no penalty * No cooldown or waiting period * Instant liquidity when needed ## Claiming Rewards ### Manual Claiming 1. Click "Claim Rewards" 2. Select tokens to claim (or claim all) 3. Confirm transaction 4. Tokens sent to your wallet ### Reward Tokens Include: * AERO (main rewards) * USDC (bribe payments) * ETH (protocol fees) * Various protocol tokens ### Compounding Strategy For maximum returns: 1. Claim AERO rewards 2. Deposit AERO back to vault for more iAERO 3. Stake the new iAERO 4. Repeat weekly ## Unstaking ### How to Unstake 1. Go to staking dashboard 2. Enter amount to unstake 3. Click "Unstake" 4. Receive iAERO instantly ### Partial Unstaking * Unstake any amount up to your balance * Remaining balance keeps earning * No need to unstake everything ## Rewards Math ### How Rewards Are Calculated Your share of rewards = (Your Staked iAERO / Total Staked iAERO) × Total Rewards **Example:** * You stake: 1,000 iAERO * Total staked: 100,000 iAERO * Your share: 1% * Weekly rewards: $10,000 * Your earnings: $100 ### APR Calculation APR = (Weekly Rewards × 52) / Total Value Staked × 100 ## Advanced Strategies ### 1. Auto-Compound LoopAERO → iAERO → Stake → Earn AERO → Repeat Compounds your position over time ### 2. Diversified Claiming * Claim stables (USDC) for expenses * Reinvest AERO for growth * Hold other tokens for speculation ### 3. Tax Optimization * Track cost basis of deposits * Consider claiming schedule for tax purposes * Keep records of all transactions ## Common Issues **"Insufficient balance"** * Check you have iAERO in wallet * Ensure it's not already staked **"Transaction failed"** * Increase gas limit * Check network congestion * Ensure sufficient ETH for gas **"No rewards showing"** * Rewards update after weekly distribution * May take 24-48 hours after epoch ends * Check if you were staked during earning period ## FAQ **Q: When do rewards appear?** A: After each weekly epoch ends and keepers distribute (usually Thursday/Friday) **Q: Can I lose my staked iAERO?** A: No, staking is non-custodial. Only you can withdraw. **Q: What's the minimum stake time?** A: None! Stake for 1 minute or 1 year, your choice. **Q: Do I earn while unstaking?** A: You earn until the moment you unstake. # Providing Liquidity ## Why Provide Liquidity? Adding liquidity to the iAERO/AERO pool: * Earns trading fees (0.3% of volume) * Earns additional AERO emissions (if gauged) * Helps maintain iAERO peg to AERO * Supports protocol growth * earns LIQ community emissions ## Understanding the Pool ### Pool Type: Variable Rate (Volatile) * Not a stable pool (prices can diverge) * Standard xy=k AMM formula * Suitable for correlated but not pegged assets ### Expected Price Relationship * iAERO should trade near 0.85 AERO * May trade at premium if high demand * May trade at discount if low demand ## How to Add Liquidity ### Step 1: Prepare Tokens You need both tokens in the pair: * iAERO tokens * AERO tokens **Optimal Ratio**: Check current pool ratio on Aerodrome ### Step 2: Navigate to Aerodrome 1. Go to [aerodrome.finance/liquidity](https://aerodrome.finance/liquidity) 2. Search for "iAERO/AERO" pool 3. Click "Add Liquidity" ### Step 3: Enter Amounts * Enter amount of iAERO * AERO amount auto-calculates based on pool ratio * Or enter AERO and let iAERO auto-calculate ### Step 4: Approve Tokens 1. Approve iAERO spending (if needed) 2. Approve AERO spending (if needed) 3. Wait for confirmations ### Step 5: Add Liquidity 1. Click "Supply" 2. Review terms and price impact 3. Confirm transaction 4. Receive LP tokens ## Managing Your Position ### LP Token Benefits * Represents your pool share * Automatically earns fees * Can be staked in gauge for emissions * Transferable and tradeable ### Staking LP in Gauge 1. Go to Aerodrome Finance Dashboard 2. Find iAERO/AERO position 3. Stake LP tokens 4. Earn additional AERO emissions ## Impermanent Loss Considerations ### What Is IL? Impermanent loss occurs when token prices diverge from deposit ratio. ### iAERO/AERO Specific Factors * **Lower IL Risk**: Both tokens tied to AERO value * **Main Risk**: iAERO depegging significantly from expected ratio * **Mitigation**: Fees often offset IL for correlated pairs ### IL Scenarios **Scenario 1: iAERO trades at premium** * You'll have more AERO, less iAERO * Good if you're bullish on AERO **Scenario 2: iAERO trades at discount** * You'll have more iAERO, less AERO * Good if you believe peg will restore ## Calculating Returns ### Total Returns = 1. **Trading Fees** (0.3% of volume) 2. **Plus: Emissions** (if staked in gauge) 3. **Plus/Minus: IL** (from price changes) 4. **Plus: iAERO staking** (if you stake remaining iAERO) ### Example APR Calculation * Pool TVL: $1,000,000 * Daily Volume: $100,000 * Daily Fees: $300 * Annual Fees: $109,500 * Base APR: 10.95% * Plus emissions: +20-50% APR (varies) ## Removing Liquidity ### How to Withdraw 1. Go to your liquidity positions 2. Select iAERO/AERO position 3. Choose % to remove (25%, 50%, 100%) 4. Click "Remove" 5. Receive both tokens proportionally ### If Staked in Gauge 1. First unstake from gauge 2. Then remove liquidity 3. Two-step process ## Risk Management ### Risks to Consider * **Smart Contract Risk**: Unaudited protocols * **IL Risk**: Price divergence between tokens * **Liquidity Risk**: May face slippage on large withdrawals * **Opportunity Cost**: Could earn more just staking iAERO ### Risk Mitigation * Start with small position * Monitor price ratios regularly * Consider single-sided staking if unsure * Keep some dry powder for rebalancing ## Advanced Strategies ### 1. Range Positioning If using Slipstream (concentrated liquidity): * Set range around 0.80-1.0 AERO per iAERO * Tighter range = more fees but more IL risk * Monitor and rebalance as needed ### 2. Gauge Voting * Vote for iAERO/AERO gauge with your veAERO * Increases emissions to the pool * Higher APR for all LPs ## FAQ **Q: Which is better - staking or LPing?** A: Depends on risk tolerance. Staking is simpler and safer. LPing potentially earns more but has IL risk. **Q: Can I lose tokens providing liquidity?** A: You can't lose tokens, but value can decrease from IL if prices diverge significantly. **Q: How often are LP rewards paid?** A: Trading fees accumulate in real-time. Emissions paid weekly if staked in gauge. **Q: Should I provide equal dollar values?** A: The pool automatically requires the current ratio. You can't choose arbitrary ratios. # iAERO Token # LIQ Token Economics ## Overview LIQ is the governance and incentive token of the iAERO ecosystem, designed with a deflationary emission schedule and multiple value accrual mechanisms. ## Token Specifications * **Token Name**: Liquid * **Symbol**: LIQ * **Max Supply**: 100,000,000 LIQ * **Decimals**: 18 * **Token Type**: ERC20 with Permit ## Supply Distribution Total Supply: 100,000,000 LIQ ├── Community Emissions: 30,000,000 (40%) ├── Treasury Vesting: 10,000,000 (10%) ├── Team Vesting: 10,000,000 (10%) ├── Investor Vesting: 30,000,000 (20%) └── Remaining: 20,000,000 (20%) - Protocol reserves ## Emission Schedule ### Community Emissions (60M LIQ) LIQ follows a halving schedule for community emissions: * **Initial Rate**: 1 LIQ per 1 iAERO minted * **Halving Interval**: Every 5,000,000 LIQ minted * **Treasury Take**: 20% of all user emissions #### Halving Timeline | Milestone | Total Minted | Emission Rate | Per iAERO | | --------- | ------------ | ------------- | ---------- | | Start | 0 | 1.0x | 1.0 LIQ | | Halving 1 | 5,000,000 | 0.5x | 0.5 LIQ | | Halving 2 | 10,000,000 | 0.25x | 0.25 LIQ | | Halving 3 | 15,000,000 | 0.125x | 0.125 LIQ | | Halving 4 | 20,000,000 | 0.0625x | 0.0625 LIQ | | ... | ... | ... | ... | ### Vesting Schedule (20M LIQ) 20% of supply is linearly vested over 3 years: * **Treasury**: 10,000,000 LIQ (3 years linear) * **Team**: 10,000,000 LIQ (3 years linear) * **Daily Release**: \~9,132 LIQ per day per stream * **Vesting Contract**: LIQLinearVester.sol ## Value Accrual Mechanisms ### 1. Staking Rewards (80% of Protocol Revenue) LIQ stakers receive the majority of protocol rewards: Protocol Revenue Flow: ├── 80% → LIQ Stakers (via TreasuryDistributor) └── 20% → Treasury Operations ### 2. Governance Rights LIQ holders control: * Voting on protocol parameters * Treasury allocation * Strategic partnerships * Protocol upgrades ### 3. Deflationary Pressure * **Capped Supply**: Hard cap at 100M * **Halving Emissions**: Decreasing inflation over time * **Burn Mechanism**: Users can burn LIQ tokens ## Staking LIQ Stake LIQ to earn protocol revenues: * **Contract**: StakingDistributor (for LIQ staking) * **Rewards**: 80% of treasury's 10% protocol fee share * **Tokens**: AERO, USDC, ETH, and other bribes * **Compounding**: Auto-compound by restaking rewards ## Treasury Management The protocol treasury receives: * 20% of all LIQ emissions * 10% of all protocol fees * Vested allocation (10M over 3 years) Treasury funds are used for: * Protocol development * Liquidity provision * Strategic partnerships * Security audits # Reward Distribution ## Sources of Rewards 1. **Aerodrome Voting Rewards** * Bribes from protocols * Trading fees from gauges * AERO emissions 2. **Partner Incentives** * Direct bribes to the vault * Partnership rewards ## Distribution Flow Aerodrome Rewards → RewardsHarvester → Distribution ├── 80% to iAERO stakers ├── 10% to treasury └── 10% to peg reserve ## Claiming Process ### For iAERO Stakers 1. Stake iAERO in the StakingDistributor 2. Rewards accumulate automatically and distribute after each epoch ends 3. Claim anytime through the UI ### Reward Tokens Common reward tokens include: * AERO * USDC * ETH * Various protocol tokens ## Compounding The vault automatically: * Claims all available rewards weekly * Processes and distributes to stakers * Reinvests protocol fees # Vesting Schedule ## Overview 40,000,000 LIQ (40% of total supply) is allocated to long-term stakeholders through linear vesting contracts. ## Vesting Streams ### Stream 0: Treasury * **Amount**: 10,000,000 LIQ * **Duration**: 3 years (1,095 days) * **Start**: Token Generation Event (TGE) * **Daily Release**: \~9,132 LIQ * **Purpose**: Protocol development and operations ### Stream 1: Team * **Amount**: 10,000,000 LIQ * **Duration**: 3 years (1,095 days) * **Start**: Token Generation Event (TGE) * **Daily Release**: \~9,132 LIQ * **Purpose**: Team incentive alignment * #### Stream 2: Investors * **Amount**: 20,000,000 LIQ * **Duration**: 3 years (1,095 days) * **Start**: Token Generation Event (TGE) * **Daily Release**: \~9,132 LIQ * **Purpose**: Investor incentive alignment ## Vesting Mechanics ### Linear Release Tokens vest linearly over time: Vested(t) = Total × (t - start) / duration ### Claiming * **Pull Model**: Anyone can trigger claims * **Recipient**: Funds go directly to beneficiary * **No Admin Control**: Immutable once deployed ## Vesting Chart ## Contract Details **LIQLinearVester.sol** * Holds 20M LIQ at deployment * Immutable beneficiaries * No pause or modification functions * Rescue function for non-LIQ tokens only # Vesting Chart ```markdown ## LIQ Token Distribution & Vesting | Allocation | Amount | Vesting Period | Release Schedule | |------------|--------|----------------|------------------| | **Emissions** | 70M LIQ | Ongoing | Halving every 5M distributed | | **Treasury** | 20M LIQ | 3 years | Linear monthly unlock | | **Team** | 10M LIQ | 3 years | Linear monthly unlock | ### Vesting Timeline | Milestone | Unlocked Amount | Breakdown | |-----------|----------------|-----------| | **Month 0** | 0 LIQ | Fully locked | | **Month 12** | ~8.33M | Treasury: 5.55M, Team: 2.78M | | **Month 24** | ~16.67M | Treasury: 11.11M, Team: 5.56M | | **Month 36** | 30M | Treasury: 20M, Team: 10M (fully vested) | ### Claiming Process | Step | Function | Description | |------|----------|-------------| | 1 | `vested()` | Check vested amount | | 2 | `releasable()` | View claimable tokens | | 3 | `claim()` | Claim specific stream | | 4 | `claimAll()` | Batch claim both streams | ``` # Smart Contracts Overview ## Core Protocol Contracts ### PermalockVault.sol **Purpose**: Main vault managing veAERO NFTs and deposits **Key Functions**: * `deposit()`: Deposit AERO tokens * `depositVeNFT()`: Deposit existing veNFTs * `executeNFTAction()`: Execute actions on managed NFTs * `performMaintenance()`: Rebase and merge NFTs **Permissions**: * Owner: Protocol Multi-sig * Authorized: Voting manager, rewards collector * Keeper: Maintenance operations ### iAEROToken.sol **Purpose**: Liquid receipt token for deposited AERO **Features**: * ERC20 + Permit * Minting restricted to vault * 1:1 backing (minus fees) * Transferable and tradeable ### LIQToken.sol **Purpose**: Governance and incentive token **Features**: * 100M max supply * Minting restricted to vault * Burnable by holders * ERC20 + Permit ## Contract Interactions graph TD User\[User] Vault\[PermalockVault] iAERO\[iAERO Token] LIQ\[LIQ Token] SD\[StakingDistributor] LSD\[LIQ StakingDistributor] RH\[RewardsHarvester] TD\[TreasuryDistributor] VM\[VotingManager] Treasury\[Treasury] ``` User -->|Deposit AERO| Vault Vault -->|Mint| iAERO Vault -->|Mint| LIQ User -->|Stake iAERO| SD User -->|Stake LIQ| LSD RH -->|80%| SD RH -->|10%| TD TD -->|80% of 10%| LSD TD -->|20% of 10%| Treasury VM -->|Execute Votes| Vault Vault -->|Vote| Aerodrome ``` ## Reward Distribution ### StakingDistributor.sol **Purpose**: Distribute rewards to iAERO stakers **Mechanism**: * Accumulator-based rewards * Multi-token support (ERC20 + ETH) * No lockup required * Pro-rata distribution ### RewardsHarvester.sol **Purpose**: Claim and distribute Aerodrome rewards **Distribution**: * 80% → iAERO stakers * 10% → TreasuryDistributor (splits 80/20) * 10% → Peg defense reserve ### TreasuryDistributor.sol **Purpose**: Split treasury's share between LIQ stakers and operations **Split** (of the 10% it receives): * 80% → LIQ stakers (8% of total) * 20% → Treasury operations (2% of total) # Contract Addresses ## Core Tokens * **iAERO**\ `0x81034Fb34009115F215f5d5F564AAc9FfA46a1Dc` * **LIQ**\ `0x7ee8964160126081cebC443a42482E95e393e6A8` * **stiAERO**\ `0x72C135B8eEBC57A3823f0920233e1A90FF4D683D` ## Treasury * **Treasury MultiSig**\ `0x1039CB48254a3150fC604d4B9ea08F66f4739D37` ## Staking & Rewards * **PermalockVault**\ `0x180DAB53968e599Dd43CF431E27CB01AA5C37909` * **StakingDistributor (Epoch Distributor)**\ `0x781A80fA817b5a146C440F03EF8643f4aca6588A` * **RewardsHarvester**\ `0x77f90d2dDB15Ffe28fa322aDA351d11da3B8bFe5` * **RewardsSwapper**\ `0x25f11f947309df89bf4d36da5d9a9fb5f1e186c1` * **VotingManager**\ `0xA0EBbdeD0E201a9C37F4Bffbb831CB8Db9FEd0B8` * **LIQ Staking Distributor**\ `0xb81efc6be6622Bf4086566210a6aD134cd0CDdA4` * **LIQ Linear Vester**\ `0xF1d25F4ee64988Afad0f1612cc3d540725F319Db` * **TreasuryDistributor**\ `0xD36b84EeFd1F481a737595C8212c43A9cD76C8e0` * **Auto-USDC Vault**\ `0xFE5c929677D97723dc822C86c93c7e2D1B59c774` ## Aerodrome Integrations * **RewardsSugar**\ `0xD4aD2EeeB3314d54212A92f4cBBE684195dEfe3E` * **AERO**\ `0x940181a94a35a4569e4529a3cdfb74e38fd98631` * **Aerodrome VOTER**\ `0x16613524e02ad97eDfeF371bC883F2F5d6C480A5` * **veAERO**\ `0xeBf418Fe2512e7E6bd9b87a8F0f294aCDC67e6B4` * **Aerodrome Router**\ `0xcF77a3Ba9A5CA399B7c97c74d54e5b1Beb874E43` # Audit PermaLock Vault **Contract Address:** `0x9322A2155815CD636A16e66BEF717B1B848e3248`\ **Auditor:** Independent Security Review\ **Date:** September 2025 **Network:** Base Mainnet ## Executive Summary The PermalockVault V5 contract implements a permalocking mechanism for AERO tokens via veAERO NFTs, with a 5% protocol fee structure and dual-token emission system (iAERO and LIQ). The audit identified several critical issues in earlier versions that have been successfully mitigated in the deployed version. ## Critical Issues Identified & Mitigated ### 1. Reentrancy Vulnerability (FIXED) **Original Issue:** State variables updated after external calls in deposit functions\ **Risk:** Potential reentrancy attacks allowing manipulation of accounting\ **Mitigation:** State updates moved before external calls (lines 229-230, 269-270)\ **Status:** ✅ RESOLVED ### 2. Emission Rate Overflow (FIXED) **Original Issue:** Uncapped halvings could cause emission rate to become 0 after \~256 halvings\ **Risk:** Complete failure of LIQ emission system\ **Mitigation:** Added 100-halving cap in `calculateLIQAmount` (lines 411, 417)\ **Status:** ✅ RESOLVED ### 3. Gas Griefing Attack (FIXED) **Original Issue:** Unbounded loop in `_mergeAllNFTs` function\ **Risk:** DoS attack by adding excessive NFTs making deposits impossibly expensive\ **Mitigation:** Added MAX\_MERGES limit of 10 per operation (line 551)\ **Status:** ✅ RESOLVED ### 4. NFT Transfer Vulnerability (FIXED) **Original Issue:** `executeNFTAction` allowed arbitrary calls including NFT transfers\ **Risk:** Authorized users could steal managed NFTs\ **Mitigation:** Strict selector whitelist allowing only merge/increase operations\ **Status:** ✅ RESOLVED ### 5. Silent Failure on LIQ Cap (FIXED) **Original Issue:** Function silently returned when LIQ cap reached\ **Risk:** Users pay fees but receive no LIQ tokens\ **Mitigation:** Added explicit revert with clear error message (line 532)\ **Status:** ✅ RESOLVED ## Medium Severity Issues ### 1. Emergency Recovery Mechanism **Risk:** Owner could abuse rescue mechanism\ **Mitigation:** 48-hour timelock, requires pause + emergency state, predefined safe address\ **Status:** ✅ ACCEPTABLE with proper governance ### 2. Centralization Risk **Risk:** Owner has significant control\ **Mitigation:** Ownership transferred to multisig, time-locked operations\ **Status:** ✅ ACCEPTABLE with multisig ## Security Features Implemented 1. **Reentrancy Guards:** All external functions protected 2. **Access Control:** Role-based permissions with clear separation 3. **Pause Mechanism:** Emergency pause capability for incident response 4. **Input Validation:** Comprehensive checks on all user inputs 5. **Decimal Validation:** Ensures all tokens are 18 decimals 6. **NFT Intake Guards:** Prevents accidental NFT transfers 7. **Safe Math:** Solidity 0.8.24 built-in overflow protection ## Economic Security 1. **Supply Cap Enforcement:** LIQ minting respects 100M cap with proper distribution 2. **Fee Structure:** Immutable 5% protocol fee prevents manipulation 3. **Treasury Split:** 20% of LIQ emissions to treasury ensures sustainability 4. **Halving Mechanism:** Predictable emission schedule with overflow protection ## Operational Security ### Access Control Hierarchy * **Owner:** Contract administration (multisig) * **Keeper:** Maintenance operations only * **Voting Manager:** Gauge voting delegation * **Rewards Collector:** Protocol fee claiming ### Emergency Procedures 1. Pause mechanism for immediate response 2. 48-hour timelock for NFT rescue operations 3. Sweep functions for recovering stuck tokens (excluding protocol tokens) ## Testing Recommendations 1. Implement comprehensive unit tests for all functions 2. Conduct integration testing with veAERO 3. Perform gas optimization analysis 4. Execute formal verification of critical invariants ## Post-Deployment Requirements * [x] Grant MINTER\_ROLE on iAERO to vault * [x] Grant MINTER\_ROLE on LIQ to vault * [x] Set keeper address * [x] Set voting manager * [ ] Set rescue safe address * [ ] Deposit initial veNFT to establish primary * [ ] Set rewards collector ## Conclusion The PermalockVault V5 contract demonstrates robust security practices with all critical vulnerabilities from earlier versions successfully mitigated. The implementation follows established patterns for DeFi protocols with appropriate access controls, emergency mechanisms, and economic safeguards. The contract is suitable for production use following completion of remaining setup steps. **Risk Rating:** LOW (with multisig governance)\ **Recommendation:** APPROVED for mainnet deployment *** *This audit is based on contract version deployed at block height 35146801 and does not cover any subsequent modifications.* ### Configuration Requirements * **Vault:** * `setVotingManager()` * `setAuthorizedTarget(, true)` * Vault must **own** a valid `primaryNFT`. * **Manager:** * `setKeeper(, true)` * `setOracle(address(0), ETH/USD, …, true)` * `setOracle(, , …, true)` for each token * `setAllowedBribeToken(, true)` (or batch with oracles). * Add pools: `addPools([pool1, pool2, ...])`. ### Operational Notes * **Refunds** are available if: epoch passed + grace, and **either** epoch wasn’t executed **or** the pool wasn’t included. * **Treasury claims** are chunked (bounded by `MAX_CLAIM_CHUNK`=50). * Auto‑allocation ensures **exact 10,000 bps** after min/cap and remainders. *** ## PermalockVault\_V5 — Function Table **Purpose:** Custodies and manages veAERO NFTs, mints iAERO/LIQ on deposits, gates veAERO actions, and exposes sweep/rescue + controlled maintenance (merge/rebase). Acts as the **hub** for both Harvester and VotingManager. ### Immutables & Constants * `AERO`, `veAERO`, `iAERO`, `LIQ`, `treasury` (all **18d**) * Fees & limits: `PROTOCOL_FEE_BPS=500` (5%), `MIN_DEPOSIT=1e18`, `MAX_SINGLE_LOCK=10,000,000e18` * Emissions: `baseEmissionRate` (init `1e18`), halving every `HALVING_STEP=5,000,000e18` LIQ minted ### Access Model * **Owner:** pausing, emergency flags, role/target authorization, rescue, keeper, emissions rate (pre‑mint only). * **Authorized:** can call `executeNFTAction`. * **Keeper or Owner:** `performMaintenance`. * **RewardsCollector:** permitted to sweep rewards (to **self** only). ### User / Public Functions | Function | Signature | Access | Guards | Notes | | --------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------: | -------------------------------------------------------: | ------------------------------------------------------------------------------------------------------------------------------------------ | | **previewDeposit** | `(uint256 aeroAmount) → (iAeroToUser, iAeroToTreasury, liqToUser)` | Public | view | Validates amount within min/max. | | **previewDepositVeNFT** | `(uint256 tokenId) → (iAeroToUser, iAeroToTreasury, liqToUser, lockedAmount)` | Public | view | Reads veAERO lock (must be > 0). | | **deposit** | `(uint256 amount)` | Public | **nonReentrant, whenNotPaused, notEmergencyPaused** | Increases **existing** `primaryNFT` lock; mints iAERO & LIQ (with treasury split). Auto‑merge optional. | | **depositVeNFT** | `(uint256 tokenId)` | Public | **nonReentrant, whenNotPaused, notEmergencyPaused** | Guarded ERC‑721 intake; marks managed; choose/promote primary; optional merge; mints iAERO & LIQ. | | **performMaintenance** | `()` | **Keeper/Owner** | **nonReentrant** | Merges additional → primary (max 10 per call); rebase primary to max if needed. **Not paused** by Pausable. | | **executeNFTAction** | `(uint256 tokenId, address target, bytes data) → bytes` | **Authorized/Owner** | **nonReentrant** | Target must be in `authorizedTargets`. If `target==veAERO`, only `increaseAmount/increaseUnlockTime/merge` allowed; **transfers blocked**. | | **sweepERC20** | `(address[] tokens, address to) → uint256[] amounts` | **Owner/RewardsCollector** | **nonReentrant** | Owner cannot sweep **AERO**; collector can (for rewards) but **must** sweep to self. Never sweeps `iAERO`/`LIQ`. | | **sweepETH** | `(address to) → uint256 amount` | **Owner/RewardsCollector** | **nonReentrant** | Collector must sweep to self. | | **rescueVeNFT** | `(uint256 tokenId, address to)` | **Owner** | **nonReentrant** | For veAERO **not managed** by vault. | | **rescueERC721** | `(address token, uint256 tokenId, address to)` | **Owner** | **nonReentrant** | Non‑veAERO ERC‑721 only. | | **setRescueSafe** | `(address safe)` | **Owner** | — | Break‑glass destination. | | **proposeManagedRescue** | `(uint256 tokenId, string reason)` | **Owner** | `paused && emergencyPause` | Starts a **time‑locked** rescue plan (`RESCUE_DELAY`=48h). | | **cancelManagedRescue** | `(uint256 tokenId)` | **Owner** | — | Cancels plan. | | **executeManagedRescue** | `(uint256 tokenId)` | **Owner** | **nonReentrant**, time ≥ ETA, `paused && emergencyPause` | Transfers managed veNFT to `rescueSafe` and cleans bookkeeping. | | **calculateLIQAmount** | `(uint256 iAeroAmount) → uint256` | Public | view | Applies halving schedule vs. `totalLIQMinted`. | | **getCurrentEmissionRate** | `() → uint256` | Public | view | Current halved rate. | | **vaultStatus** | `() → rich struct` | Public | view | TVL, protocol share, primary NFT stats, merge/rebase hints. | | **getManagedNFTs** | `() → uint256[]` | Public | view | IDs (primary + additional managed). | | **getNFTInfo** | `(uint256 tokenId) → tuple` | Public | view | Managed flag, amounts, voting power, unlock time, primary?, permanent? | | **getTotalValueLocked** | `() → uint256` | Public | view | Alias of `totalAEROLocked`. | | **getProtocolShareBPS / getProtocolEffectiveShare** | `() → uint256` | Public | pure | Returns `PROTOCOL_FEE_BPS`. | | **receive** | `()` | — | — | Accepts ETH. | | **onERC721Received** | `(...) → selector` | — | — | Validates only expected veAERO transfers initiated by `depositVeNFT`. | ### Owner / Admin Functions | Function | Signature | Notes | | ----------------------- | ------------------------- | -------------------------------------------------------------- | | **setKeeper** | `(address keeper)` | Keeper can run maintenance. | | **setAuthorized** | `(address account, bool)` | Grants `executeNFTAction` right. | | **setAuthorizedTarget** | `(address target, bool)` | Must include Aerodrome **Voter**. | | **setVotingManager** | `(address mgr)` | Also sets `authorized[mgr]=true`. | | **setRewardsCollector** | `(address coll)` | Also sets `authorized[coll]=true`. **Required** for Harvester. | | **setBaseEmissionRate** | `(uint256 rate)` | **Only before** any LIQ minted. | | **setEmergencyPause** | `(bool)` | Additional kill‑switch for deposits. | | **pause / unpause** | `()` | Standard Pausable. | ### Configuration Requirements * **At Deploy:** Supply **18‑decimals** `AERO`, `iAERO`, `LIQ`, `veAERO`, `treasury`. * **Before First Deposit:** If you will change emissions, call `setBaseEmissionRate(...)` (cannot change after first LIQ mint). * **Wire Modules:** * `setRewardsCollector(Harvester)` * `setVotingManager(VotingManager)` * `setAuthorizedTarget(AerodromeVoter, true)` * **Optional:** `setKeeper()` for maintenance; `setEmergencyPause(true)` if you need break‑glass prior to operations; configure rescue safe & plans. ### Operational Notes * **Owner cannot sweep AERO** (safety), but **RewardsCollector can** (for rewards routing). * `performMaintenance` is **not paused** by `Pausable`—use `emergencyPause`/pause + rescue controls when necessary. * `executeNFTAction` **blocks veAERO transfers**; only growth/extend/merge actions permitted. *** # Audit Voting Manager Optimised **Client:** iAero Protocol **Date:** 2025-09-05 **Audited artifact:** `VotingManagerOptimised.sol` (Solidity ^0.8.24) **Standards/Libraries:** OpenZeppelin v5 series (`Ownable`, `ReentrancyGuard`, `Pausable`, `Math`, `SafeERC20`) **External deps:** * `IVoter` / `IVoterTime` (Aerodrome-style voting window & epoch math) * `IPermalockVault` (selector-allowlisted `executeNFTAction`) * Chainlink-style `AggregatorV3Interface` price feeds *** ## 1) Executive Summary `VotingManagerOptimised` manages epoch-based voting for a custodial veNFT (held by an external PermalockVault) and handles bribe deposits/refunds in ERC-20 and ETH with USD thresholding via oracles. Keeper roles execute votes either with explicit weights or via an auto-allocation algorithm that uses bribes + base revenue signals. Per-epoch records enable claims to treasury when a pool was actually voted; otherwise depositors may refund after a grace period. Storage is partitioned by `(pool, epochId)` and includes pruning. **Assessment:** The contract exhibits a strong baseline: pervasive `nonReentrant`, CEI discipline, fee-on-transfer-safe ERC20 intake (balance diff), oracle validation (stale/round checks + decimals normalization), per-epoch mutexing, and explicit refund/claim windows. Observed risks are bounded and acceptable given the client’s stated risk appetite. **Overall risk:** Low–Medium. *** ## 2) In-Scope Components * `VotingManagerOptimised` (full contract) * External interfaces assumed correct: `IVoter`, `IVoterTime`, `IPermalockVault`, `AggregatorV3Interface`. * Out of scope: concrete voter/gauge implementations, concrete vault implementation, token contracts, oracle deployments. *** ## 3) Threat Model & Assumptions * **Admin/keeper honesty:** Owner is trusted; keepers are semi-trusted (can add pools/execute votes within contract rules). * **Vault policy:** `IPermalockVault.executeNFTAction` enforces a **per-target selector allowlist** such that only `IVoter.reset` and `IVoter.vote` are permitted for `voter`. Any deviation would be operational, not a flaw here. * **Oracles:** USD price oracles are configured correctly, up-to-date, and correspond to the intended tokens (or ETH at `address(0)`). * **voter/epoch schedule:** `IVoterTime` returns sensible epoch boundaries (weekly cadence). * **Tokens:** Standard ERC-20 semantics; no malicious reentrancy from token callbacks (we use `nonReentrant` and CEI regardless). *** ## 4) Methodology * Manual line-by-line review for access control, reentrancy, CEI, math/overflow, oracle handling, epoch arithmetic, and storage growth. * Adversarial reasoning for bribe lifecycle (deposit → claim/refund → prune), keeper voting flows, and external call rollback behavior. * Gas and UX notes where they intersect with safety. *** ## 5) Findings Severity scale: **C**ritical / **H**igh / **M**edium / **L**ow / **I**nformational ### M-1 — Allocation reducer can over-shrink a pool during final canonicalization **Location:** `_calculateOptimalAllocation()` — final “reduce to exactly 10\_000 bps” branch. **Issue:** When total weights exceed 10\_000 bps, the reducer chooses largest donors and may skip donors that cannot give without violating `minVoteWeightBPS`. The current approach can set a donor’s allocation to `0` temporarily while searching alternative donors, which can unintentionally persist a zero allocation. **Impact:** Minor allocation distortion vs policy intent; not a safety issue. **Recommendation:** Use a non-mutating skip of ineligible donors and compute `take = min(excess, alloc[i] - minVoteWeightBPS)`; do not write `0` to “skip.” **Client stance:** Acceptable. *** ### M-2 — No local voting window pre-check **Location:** `executeVotesWithWeights`, `executeVotesAuto`. **Issue:** The functions rely on `IVoter` to revert if outside the voting window. **Impact:** Operational (wasted gas, noisier ops). **Recommendation:** Add `require(inVotingWindow(), "not in voting window")` before attempting actions. **Client stance:** Acceptable. *** ### L-1 — Epoch start underflow guard is implicit **Location:** `_epochStart(t) = epochVoteStart(t) - 1 hours`. **Issue:** If external schedule ever returned `≤ 1 hour`, subtraction would underflow. **Impact:** View/function revert if upstream schedule is misconfigured. **Recommendation:** Add `require(vs > 1 hours, "bad schedule")` defensively. **Client stance:** Acceptable. *** ### I-1 — Operational dependency: vault allowlist must enable `reset` and `vote` **Location:** Calls via `IPermalockVault.executeNFTAction` to `voter`. **Issue:** If the vault’s selector allowlist is not properly seeded (or later restricted), votes will revert. **Impact:** Operational availability only. **Recommendation:** Codify allowlist seeding in deployment runbooks/multisig scripts; monitor events. **Client stance:** Understood. *** ### I-2 — Pruning reorders bribe slices **Location:** `pruneBribes` (swap-and-pop). **Issue:** Intended; indices are not promised stable. **Impact:** UI/indexing should not assume stable ordering. **Recommendation:** Document for integrators. **Client stance:** Acceptable. *** ## 6) Positive Observations * **Reentrancy:** All state-mutating externals use `nonReentrant`; reward/refund payers use CEI and avoid external state dependencies. * **Fee-on-transfer safety:** ERC-20 bribe intake uses `before/after` balance-diff to compute `received`. * **Oracle hygiene:** Validates `enabled`, `feed != 0`, `answer > 0`, `answeredInRound >= roundId`, and staleness; normalizes decimals to 1e18. * **Refund safety:** Refunds require (epoch ended + grace) AND (not executed OR executed but pool not voted). Prevents treasury double-spend collisions. * **Emergency withdrawal policy:** Blocks ETH and any **allowed** bribe tokens from sweeping—protects refundable user funds. * **Mutex & rollback:** `epochLock` prevents concurrent votes; `try/catch` reverts with lock cleanup. *** ## 7) Recommended Tests (High-value) 1. **Bribe lifecycle (ERC-20 & ETH):** deposit across multiple epochs; enforce per-epoch USD minimums; ensure claims are transferable only when pool voted; refunds after grace only when not voted (or not executed). 2. **Oracle decimals & staleness:** feeds with 6/8/18 decimals; stale feed → revert paths. 3. **Auto allocation edges:** * Zero scores → revert. * Sum < 100% → top-up best pool. * Sum > 100% → reducer keeps non-zero pools above `minVoteWeightBPS`. * Cap & min interplay; largest-remainder distribution respects cap. 4. **Voting window:** success inside window; revert via downstream outside window. 5. **Mutex failure:** Force a revert in the second `executeNFTAction` call and assert `epochLock` resets. *** ## 8) Compatibility & Deployment Notes * **Solidity:** ^0.8.24 is compatible with OZ v5. * **EVMs:** No assembly beyond event array shrinking in a view; standard opcodes only. * **Clients (ethers v6):** ABI surface is standard; large arrays handled in views. * **Ops:** Ensure vault allowlist grants `IVoter.reset` and `IVoter.vote` selectors for the configured `voter`. Keepers should be managed via multisig and can be rotated. *** ## 9) Conclusion From a security perspective, `VotingManagerOptimised` is well-structured and appropriate for production given your stated risk tolerance. The identified issues are mainly **operational or allocation-policy nits** rather than exploitable vulnerabilities. If you later want to harden UX and allocation determinism, the suggested patches are straightforward and do not alter core behavior. **Final rating:** **Low–Medium risk** (acceptable). ## VotingManagerOptimised — Function Table **Purpose:** Bribe intake, oracle‑valued scoring, and execution of Aerodrome votes via the Vault’s veNFT. Handles **refunds** for unused bribes and **treasury collection** for used bribes. ### Core Parameters * `minBribeUSDPerEpoch` (default `10e18`) * `bribeDiscountBPS` (default `10_000`=100%) * `maxPoolAllocationBPS` (default `7_000`=70%) * `minVoteWeightBPS` (default `5`=0.05%) * `refundGraceSeconds` (default 1 day after epoch end) ### Access Control * **Owner:** pause/unpause, oracles, allowed bribe tokens, keeper set, global params, remove pools, emergency withdraw (restricted). * **Keeper:** add pools, set base revenue per epoch, execute votes (auto or manual weights). ### External/Public Functions | Function | Signature | Access | Guards | Notes | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------: | ---------------------------------------: | --------------------------------------------------------------------------------------------------- | | **constructor** | `(address vault, address voter, address treasury)` | — | — | Enables ETH as bribe token by default; still need **ETH oracle**. | | **setOracle** | `(address token, address feed, uint48 maxStaleSec, bool enabled)` | **Owner** | — | For `token=address(0)` configures **ETH/USD**. | | **batchConfigureOracles** | `(address[] tokens, address[] feeds, uint48[] maxStale, bool[] enabled, bool alsoSetAllowed)` | **Owner** | — | Optional `alsoSetAllowed` to set `allowedBribeTokens`. | | **batchSetAllowedBribeTokens** | `(address[] tokens, bool[] allowed)` | **Owner** | — | Controls accepted bribe tokens. | | **setAllowedBribeToken** | `(address token, bool allowed)` | **Owner** | — | Single‑token allow/disallow. | | **getPriceUSD** | `(address token) → uint256 1e18` | Public | view | Reverts if oracle missing/stale/bad. | | **getOracleMeta** | `(address token) → (feed, maxStale, enabled, decimals)` | Public | view | Helper for UI/ops. | | **activePoolsSlice** | `(uint256 start, uint256 max) → address[]` | Public | view | Paginates active pools. | | **currentEpochId** | `() → uint256` | Public | view | Epoch start timestamp (aligned). | | **isEpochStart** | `(uint256 ts) → bool` | Public | view | Epoch alignment helper. | | **inVotingWindow** | `() → bool` | Public | view | Uses Aerodrome Voter window. | | **depositBribe** | `(address pool, address token, uint256 amount, uint256 epochs)` | Public | **nonReentrant, whenNotPaused** | ERC‑20 path; splits across `epochs` (1–8); each slice must meet `minBribeUSDPerEpoch`. | | **depositETHBribe** | `(address pool, uint256 epochs)` | Public | **payable, nonReentrant, whenNotPaused** | Requires ETH oracle to be configured/enabled. | | **claimTreasuryBribes** | `(address pool, uint256 epochId, uint256 start, uint256 maxCount)` | Public | **nonReentrant** | Only if `epoch.executed && pool was voted`; transfers slices to Treasury. Chunked. | | **refundMyBribes** | `(address pool, uint256 epochId, uint256 start, uint256 maxCount)` | Public | **nonReentrant** | After `epoch + WEEK + refundGraceSeconds` and if not consumed; refunds caller’s slices. | | **pruneBribes** | `(address pool, uint256 epochId, uint256 maxScan)` | Public | **nonReentrant** | Compacts paid/refunded entries (swap‑and‑pop). | | **executeVotesWithWeights** | `(address[] pools, uint256[] weightsBps)` | **Keeper/Owner** | **nonReentrant, whenNotPaused** | Validates weights (min/cap) and exact 10\_000 sum. Resets then votes via Vault. | | **executeVotesAuto** | `()` | **Keeper/Owner** | **nonReentrant, whenNotPaused** | Computes proportional weights from **(discounted bribes + base revenue)** with min/cap, then votes. | | **addPools** | `(address[] pools)` | **Keeper/Owner** | — | Adds active pools (checks gauge exists & `isAlive`). | | **removePool** | `(address pool)` | **Owner** | — | Removes from active set. | | **setKeeper** | `(address who, bool status)` | **Owner** | — | Grants operator rights. | | **setParams** | `(uint256 minBribeUSDPerEpoch, uint256 bribeDiscountBPS, uint256 maxPoolAllocationBPS, uint256 minVoteWeightBPS)` | **Owner** | — | Caps: discount ≤ 100%; cap ≤ 100%; min within (0,100%]. | | **setRefundGrace** | `(uint256 seconds_)` | **Owner** | — | Refund grace after epoch end. | | **setBaseRevenueForEpoch** | `(address[] pools, uint256[] epochIds, uint256[] usdAmounts)` | **Keeper/Owner** | — | Requires `isEpochStart(epochId)`; stored in USD 1e18. | | **pause / unpause** | `()` | **Owner** | — | Halts bribe deposits and voting (claims/refunds use time guards). | | **emergencyWithdraw** | `(address token, uint256 amount)` | **Owner** | **nonReentrant** | **Forbidden** for ETH and **allowed bribe tokens**. For stranded ops funds only. | | **view helpers** | `getActivePools, getPoolInfo, getBribeCount, getBribes, getBribeAt, nextUnpaidBribeIndex, canRefund, nextRefundableBribeIndex, previewClaimTotals, getOptimalAllocation, wasExecuted, canExecuteVotes, getDepositedBribesUSD` | Public | view | Pagination and state introspection. | | **receive** | `()` | — | — | Accepts ETH bribes. | # Audit iAero & LIQ ## Security Audit Report: iAEROToken **Contract Address:** `0x81034Fb34009115F215f5d5F564AAc9FfA46a1Dc`\ **Date:** September 2025 **Network:** Base Mainnet ### Executive Summary iAEROToken is an ERC20 receipt token representing permalocked AERO positions. The contract implements role-based access control for minting with optional burning functionality. ### Critical Issues #### None Identified ### High Severity Issues #### 1. Unrestricted burnFrom Function **Issue:** `burnFrom` bypasses ERC20 allowance checks, allowing BURNER\_ROLE to burn any user's tokens without approval\ **Risk:** Users' tokens can be burned without consent if BURNER\_ROLE is compromised\ **Recommendation:** Add allowance check or remove function if not required ```solidity function burnFrom(address from, uint256 amount) external onlyRole(BURNER_ROLE) { _spendAllowance(from, msg.sender, amount); // ADD THIS _burn(from, amount); } ``` **Status:** ⚠️ UNRESOLVED (function exists but BURNER\_ROLE never granted) ### Medium Severity Issues #### 1. No Initial MINTER\_ROLE Assignment **Issue:** Constructor doesn't grant MINTER\_ROLE to any address\ **Risk:** Requires manual setup post-deployment\ **Mitigation:** MINTER\_ROLE granted to vault via multisig\ **Status:** ✅ RESOLVED post-deployment ### Low Severity Issues #### 1. Redundant Zero Checks **Issue:** Manual zero address checks duplicate OpenZeppelin's internal validation\ **Impact:** Minor gas inefficiency\ **Status:** ℹ️ INFORMATIONAL #### 2. Missing Emergency Pause **Issue:** No pause mechanism for emergency situations\ **Impact:** Cannot halt operations in case of exploit\ **Status:** ℹ️ ACCEPTABLE (simple token contract) ### Security Features * **Access Control:** OpenZeppelin AccessControl with DEFAULT\_ADMIN\_ROLE * **ERC20Permit:** Gasless approvals via signatures * **Role Separation:** Distinct MINTER and BURNER roles * **Input Validation:** Amount and address checks ### Deployment Status * [x] Contract deployed and verified * [x] DEFAULT\_ADMIN\_ROLE held by multisig * [x] MINTER\_ROLE granted to PermalockVault * [x] BURNER\_ROLE not assigned (good security practice) ### Conclusion The iAEROToken contract is secure for production use with the current configuration. The unresolved `burnFrom` issue poses no immediate risk as BURNER\_ROLE is not assigned. **Risk Rating:** LOW\ **Recommendation:** APPROVED *** ## Security Audit Report: LIQToken **Contract Address:** `0x7ee8964160126081cebC443a42482E95e393e6A8`\ **Date:** September 2025 **Network:** Base Mainnet ### Executive Summary LIQToken is a governance token with a fixed maximum supply of 100 million tokens, mintable only by authorized contracts with built-in supply cap enforcement. ### Critical Issues #### None Identified ### High Severity Issues #### None Identified ### Medium Severity Issues #### 1. Supply Cap Calculation **Issue:** `totalSupply() + amount <= MAX_SUPPLY` could theoretically overflow with massive amounts\ **Risk:** Extremely unlikely in practice but mathematically possible\ **Recommendation:** Use `amount <= MAX_SUPPLY - totalSupply()`\ **Status:** ⚠️ LOW RISK (requires unrealistic amount values) #### 2. No Initial MINTER\_ROLE Assignment **Issue:** Constructor doesn't grant MINTER\_ROLE\ **Mitigation:** MINTER\_ROLE granted to vault via multisig\ **Status:** ✅ RESOLVED post-deployment ### Low Severity Issues #### 1. No burnFrom Function **Issue:** No delegated burning capability\ **Impact:** Design choice, not a security issue\ **Status:** ℹ️ INFORMATIONAL #### 2. Missing Emergency Pause **Issue:** No pause mechanism\ **Impact:** Cannot halt minting in emergencies\ **Status:** ℹ️ ACCEPTABLE (immutable supply cap provides protection) ### Security Features * **Supply Cap:** Immutable 100M token limit * **Access Control:** Role-based minting restrictions * **ERC20Permit:** Signature-based approvals * **View Helper:** `remainingMintableSupply()` for transparency ### Economic Security 1. **Hard Cap:** 100M maximum supply enforced at contract level 2. **Minting Control:** Only authorized contracts can mint 3. **Burn Capability:** Deflationary mechanism available 4. **No Admin Minting:** Even admin cannot bypass MINTER\_ROLE requirement ### Deployment Status * [x] Contract deployed and verified * [x] DEFAULT\_ADMIN\_ROLE held by multisig * [x] MINTER\_ROLE granted to PermalockVault * [x] Supply cap functioning correctly * [x] No unauthorized minting possible ### Conclusion The LIQToken contract implements a secure governance token with appropriate supply constraints and access controls. The minor calculation issue poses no practical risk given realistic usage patterns. **Risk Rating:** LOW\ **Recommendation:** APPROVED *** *Both token contracts demonstrate security-first design with minimal attack surface. The integration with PermalockVault has been properly configured with appropriate role assignments.* # Audit Rewards Harvester **Client:** iAero Protocol **Date:** 2025-09-05 **Artifact:** `RewardsHarvester.sol` (Solidity 0.8.24) **Standards/Libraries:** OpenZeppelin v5 (`Ownable`, `ReentrancyGuard`, `SafeERC20`) **External Dependencies:** * `IPermalockVault` (PermalockVault\_V5 with collector-aware sweepers) * Aerodrome `IVoter` (claimBribes / claimFees / claimRewards / claimRebase) * `IStakingDistributor` (notifyRewardAmount) * `ITreasuryDistributor` (distribute) *** ## 1) Executive Summary `RewardsHarvester` is a keeper/owner-gated operations contract that: 1. Claims bribes/fees/rewards via the vault-owned veNFT (using the vault’s `executeNFTAction`), 2. Sweeps reward assets **from the vault to itself**, and 3. Splits the sweep per policy: **10% protocol → TreasuryDistributor (or treasury fallback), 10% peg reserve, 80% to iAERO stakers** via `StakingDistributor`. Following your latest deployment of **PermalockVault\_V5** with the improved sweep authorization (collector may sweep to self; owner may not sweep AERO; iAERO/LIQ always blocked), the Harvester can operate without changes on its side. **Overall Risk:** **Low** (contract-level). Most residual risk is **operational** (correctly configuring the vault allowlists/roles and distributor addresses). The on-chain logic uses solid access control, reentrancy guards, and CEI discipline. *** ## 2) Scope * Full review of `RewardsHarvester.sol` as provided. * Integration assumptions with `PermalockVault_V5`: * Vault’s `rewardsCollector` is set to the deployed `RewardsHarvester` address. * Vault’s `sweepERC20/sweepETH` now authorize `rewardsCollector` to sweep **to itself**, block `iAERO`/`LIQ`, allow **AERO** only for the collector path. * Vault’s `executeNFTAction` allowlist includes relevant Aerodrome selectors (see §5.M-2). Out of scope: concrete Aerodrome voter/gauge contracts, distributor implementations, token contracts. *** ## 3) Methodology * Manual line-by-line review for access control, reentrancy, CEI, value-flow correctness, and external call surfaces. * Reasoning through integration paths with the vault and distributors (failure modes, revert behavior). * Consideration of fee-on-transfer tokens, ETH flows, and allowance hygiene. *** ## 4) Architecture & Roles * **Owner** — sets keepers, voter, distributors, pegDefender, etc. * **Keepers** — may call `claimAerodromeRewards`, `processAndDistribute`, `processAndDistributeETH`. * **Vault (PermalockVault\_V5)** — owns veNFT; enforces selector allowlists and collector-aware sweepers. * **Distributors** — receive protocol/peg funds; staking distributor receives 80% via `notifyRewardAmount`. All state-changing external functions are `nonReentrant`. *** ## 5) Findings Severity: **C**ritical / **H**igh / **M**edium / **L**ow / **I**nformational ### M-1 — Integration dependency: Vault sweep permissions & blocklist **Where:** `processAndDistribute()`, `processAndDistributeETH()` call `vault.sweepERC20/ETH`. **Risk:** If the vault isn’t configured exactly as deployed (collector-aware sweeps; AERO allowed for collector; iAERO/LIQ blocked), Harvester won’t receive rewards (ops failure, not an exploit). **Status:** **Resolved by your deployed PermalockVault\_V5 patch** (collector can sweep to self; AERO allowed only for collector; iAERO/LIQ always blocked). **Action:** Keep this invariant in runbooks; monitor sweeps with events. ### M-2 — Vault allowlist must include claim selectors **Where:** `claimAerodromeRewards` → `executeNFTAction(voter, data)` for: * `claimBribes(address[],address[][],uint256)` * `claimFees(address[],address[][],uint256)` * `claimRewards(address[])` (and optionally `claimRebase(uint256)` if used) **Risk:** If the vault’s allowlist is not seeded for these selectors, claims revert (ops failure). **Recommendation:** Ensure vault has: `setAuthorizedTarget(voter, true)` and `setAllowedSelector` for the above selectors. **Client Stance:** Accepted operational requirement. ### L-1 — External distributor calls (notify/distribute) are reentrancy surfaces (mitigated) **Where:** * `IStakingDistributor.notifyRewardAmount(token, amount)` (ERC-20 path uses `forceApprove` then resets to 0; ETH path uses payable call) * `ITreasuryDistributor.distribute(token)` after transferring funds **Risk:** Malicious distributors could attempt reentry. **Mitigation:** All entry points are `nonReentrant`; allowances reset to 0 immediately after use; ETH transfers check return values. **Action:** None required; keep distributors simple. ### L-2 — Fee-on-transfer tokens cause split skew **Where:** `processAndDistribute` splits by **pre-transfer balance**; if a token levies transfer fees on outbound legs, the receiving legs will be slightly off target. **Risk:** Minor accounting drift (not security). **Recommendation:** If precise ratios are critical, compute amounts from **post-transfer deltas** per leg; otherwise accept small skew. ### I-1 — Optional input hardening * `setVoter`: you may require `code.length > 0` to ensure a contract: `require(_voter.code.length > 0, "voter invalid");` * `setTreasuryDistributor`: if always a contract, also assert `code.length > 0`. *** ## 6) Positive Observations * **Access control:** clear separation of owner vs keeper; sensitive setters are owner-only. * **Reentrancy:** `nonReentrant` on all functions that move value; ETH sends use `.call` with success checks. * **Allowance hygiene:** `forceApprove` then reset to `0` avoids lingering approvals. * **Fee-on-transfer safety on intake:** not applicable (Harvester receives balances by sweep, then splits based on current balance). * **Events:** Good coverage for claimed rewards and distribution legs (consider adding sweep events in vault if not already). *** ## 7) Tests & Runbooks (recommended) **Unit/Integration tests** 1. **Vault integration happy path** * After claims, call `processAndDistribute([AERO, tokenX])`: Harvester receives sweeps; protocol/peg/staker splits match policy; allowances reset to 0. * ETH variant: `processAndDistributeETH()`, verify transfers and `notifyRewardAmount{value: ...}` success. 2. **Blocked tokens** * Ensure iAERO/LIQ never leave the vault via sweeps. 3. **Selector allowlist** * Remove one allowlist entry → `claimAerodromeRewards` reverts; add it → succeeds. 4. **Reentrancy guards** * Simulate malicious distributor attempting reentry → blocked by `nonReentrant`. 5. **Fee-on-transfer token** * Use a mock that burns a fee on transfer; verify minor skew is acceptable or adjust logic. **Ops / Runbooks** * After deploys: * Set `rewardsCollector = RewardsHarvester` in the vault (emit check). * Seed vault selector allowlist for voter claim functions. * Set `stakingDistributor`, `treasuryDistributor`, `pegDefender` as intended. * Monitoring: * Alert on failed sweep/notify/distribute transactions. * Track balances stuck in the vault for tokens intended to be harvested. *** ## 8) Compatibility * **Solidity 0.8.24** with OZ v5 — compatible. * **Ethers v6** — ABI surface is standard. * No assembly; straightforward to verify and instrument. *** ## 9) Conclusion `RewardsHarvester` is **production-ready** for your split policy (10% protocol, 10% peg, 80% stakers) given the now-deployed **PermalockVault\_V5** sweep authorization and vault allowlists. We found **no exploitable vulnerabilities** in the Harvester. Remaining risks are **operational** (configuration/permissions), which you’ve addressed. With the above test and monitoring recommendations, overall risk is **Low**. **Final Rating:** **Low Risk** (with operational dependencies documented). ## RewardsHarvesterV2 — Function Table **Purpose:** Claims Aerodrome rewards/fees/rebases to the Vault’s veNFT and routes all incoming rewards to **Protocol / Peg / Stakers** according to fixed BPS splits, delivering staker share to your Distributor. ### Key Constants / Addresses * `BPS = 10_000` * `PROTOCOL_BASE_BPS = 1_000` (10%) * `PEG_ACTION_BPS = 1_000` (10%) * `vault` *(immutable)*, `AERO`, `iAERO` (read from vault) * Configurable: `voter`, `stakingDistributor`, `treasuryDistributor`, `pegDefender` ### External/Public Functions | Function | Signature | Access | Guards | Notes | | --------------------------- | ------------------------------------------------------------------------------------------------------ | ---------------: | ---------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **constructor** | `(address _vault, address _voter, address _stakingDistributor)` | — | — | Sets immutables; reads `AERO/iAERO` from Vault. | | **setKeeper** | `(address who, bool allowed)` | **Owner** | — | Grants keeper rights for harvesting & distribution. | | **setVoter** | `(address _voter)` | **Owner** | — | Must be Aerodrome **Voter** address; also add as Vault `authorizedTarget`. | | **setStakingDistributor** | `(address dst)` | **Owner** | — | Must be a contract (`dst.code.length > 0`). | | **setTreasuryDistributor** | `(address _distributor)` | **Owner** | — | Optional; used to route protocol share and optionally split. | | **setPegDefender** | `(address _defender)` | **Owner** | — | Receiver of peg reserve share; falls back to Vault `treasury` if unset. | | **setRouter** | `(address _router)` | **Owner** | — | Reserved for future peg actions. | | **setPairConfig** | `(address _pair, bool _stable)` | **Owner** | — | Reserved for future peg actions. | | **setBuyThresholdBps** | `(uint256 _bps)` | **Owner** | — | Must be ≤ `BPS`. Reserved for future peg logic. | | **claimAerodromeRewards** | `(address[] bribes, address[][] bribeTokens, address[] fees, address[][] feeTokens, address[] gauges)` | **Keeper/Owner** | **nonReentrant** | Calls **Vault.executeNFTAction** on `voter` with the primary veNFT. Requires: Vault authorizes Harvester and `authorizedTarget(voter)=true`. | | **processAndDistribute** | `(address[] tokens)` | **Keeper/Owner** | **nonReentrant** | `Vault.sweepERC20(tokens, this)`; splits: Protocol / Peg / Stakers. Calls `Distributor.notifyRewardAmount` per token; on failure falls back to Treasury/TreasuryDistributor. | | **processAndDistributeETH** | `()` | **Keeper/Owner** | **nonReentrant** | `Vault.sweepETH(this)`; same split; attempts ETH notify on Distributor via `call`. | | **receive** | `()` | — | — | Accepts ETH. | ### Configuration Requirements * **Vault:** * `setRewardsCollector(Harvester)` (and optionally `setAuthorized(Harvester, true)`) * `setAuthorizedTarget(Voter, true)` * **Harvester:** * `setKeeper(, true)` * `setStakingDistributor()` * *(Optional)* `setTreasuryDistributor()` * *(Optional)* `setPegDefender(
)` ### Operational Notes * **Splits:** Protocol(10%) → `TreasuryDistributor` (if set) or `Vault.treasury`; Peg(10%) → `pegDefender` or `Vault.treasury`; Stakers(80%) → Distributor. * **Safety:** Uses `forceApprove` (reset to 0 after use). If Distributor reverts, staker share is **safely rerouted** to Treasury/TreasuryDistributor. *** # Audit LIQ Staking Distributor ### 📄 Official Security Audit (Completed & Actioned) **Project:** LIQStakingDistributor **Date:** September 2025 **Network:** Base **Auditor:** Independent Security Review #### Executive Summary * **Overall Risk:** **Low** (after fixes) * **Status:** ✅ **All identified issues addressed** and incorporated into the contract above. * The distributor implements a standard, robust **per‑share accumulator** for multi‑token rewards (ERC‑20 + ETH) and introduces appropriate **operational controls**: pausing, emergency withdrawal gating, and FOT‑safe funding. #### What Changed (Issues Fixed & Actioned) | ID | Finding | Severity | Resolution | | --- | ----------------------------------------------------------- | -------: | ------------------------------------------------------------------------------------------------------------------------- | | M‑1 | `emergencyWithdraw` bypassed lock without a circuit breaker | Medium | **Fixed**: added **Pausable**; `emergencyWithdraw` now **requires `whenPaused`**; clears stale `unlockTime` on full exit. | | M‑2 | Funding used **nominal amount**, not received (FOT) | Medium | **Fixed**: ERC‑20 reward notify now uses **balance‑delta** (`received = after - before`) and requires `received > 0`. | | L‑1 | No global pause for incidents | Low | **Fixed**: Integrated **Pausable**; applied `whenNotPaused` to stake/unstake/claim/notify. | | L‑2 | Stale `unlockTime` after full exit | Low | **Fixed**: Clear `unlockTime` when balance becomes 0 (exit, unstake‑to‑zero, emergency). | | L‑3 | Reward token list unbounded (gas) | Low | **Mitigated**: Added **`retireRewardToken`** with a `queued==0` guard; enumeration remains curated by ops. | | L‑4 | Redundant debt write in `claimReward` | Info | **Fixed**: rely on `_harvestOne` debt assignment; removed extra write. | | L‑5 | No rescue path for dust | Low | **Fixed**: `recoverERC20` with **LIQ exclusion**; ops policy required for usage. | #### Design Overview * **Stake LIQ** with a **7‑day lock**; lock extends on additional staking (never shortens). * **Rewards:** ETH (`address(0)`) and ERC‑20s; distributed pro‑rata via `accRewardPerShare`. * **Queued rewards**: If no stakers, added to `queuedRewards[token]`; once any stake exists, **flush** into the accumulator. * **Claims:** All tokens (`claimRewards`) or a single token (`claimReward(token)`); ETH via `.call{value:…}` with state updated before transfer. #### Access Control * **Owner:** `pause/unpause`, set reward notifiers, retire tokens, rescue ERC‑20 (not LIQ). * **Reward Notifiers:** Vault/Treasury/Owner (and any others the owner authorizes). * **Users:** Stake / Unstake (subject to lock) / Claim / Emergency withdraw (only when paused). #### Safety & Invariants * **Reentrancy:** All state‑mutating externals are `nonReentrant`; state changes precede ETH/token transfers. * **Accounting:** `Math.mulDiv` prevents overflow / precision loss; total user claims ≤ funded (minor rounding dust possible). * **FOT‑safe:** Notify uses **balance‑delta**. * **Operational:** Global pause halts stake/unstake/claim/notify; **emergencyWithdraw** only during pause. #### Test Checklist (passed assumptions) * Funding paths for ETH & ERC‑20 (incl. fee‑on‑transfer) distribute expected totals. * Lock enforcement; lock extension on top‑ups; unlock post 7 days; stale locks cleared at zero balance. * Accumulator math: Σ user claims ≤ Σ funded per token; rounding dust remains in contract. * Pause behavior: Stake/Unstake/Claim/Notify blocked; `emergencyWithdraw` allowed; unpause resumes operations. * Reentrancy: Malicious token/ETH claim reentrancy blocked by guards & order of operations. *** ### 📚 Smart Contracts Overview (Updated) Below is an expanded & up‑to‑date view of all core components and their roles in your **Base + Aerodrome** deployment. #### Core Protocol Contracts **`PermalockVault_V5.sol` (Vault)** * **Purpose:** Custodies and manages **veAERO** NFTs; mints **iAERO** & **LIQ** on deposits; gates all **veAERO** actions. * **Key Functions:** * `deposit()`: lock AERO into the **primary** veNFT; mints iAERO (user+treasury) & LIQ (user+treasury share). * `depositVeNFT()`: onboards an external veAERO NFT under management; may merge into primary. * `executeNFTAction()`: **strict selector allowlist** for `increaseAmount`, `increaseUnlockTime`, `merge` (transfers blocked). * `performMaintenance()`: merges additional NFTs and **rebases** (extends) primary to max where needed. * Sweeps: `sweepERC20/ETH` (Owner **or** `rewardsCollector`); AERO sweep restricted to collector only. * Break‑glass: **time‑locked** managed rescue to `rescueSafe` under `paused + emergencyPause`. * **Permissions:** * **Owner:** protocol multisig; authorizes `rewardsCollector` (Harvester) & `votingManager`; sets `authorizedTarget` (Aerodrome Voter). * **Authorized:** can call `executeNFTAction` to the Voter. * **Keeper:** can run `performMaintenance()`. **`iAEROToken.sol`** * **Purpose:** Liquid receipt token for deposited AERO. * **Features:** ERC‑20 + Permit; **minted by Vault** 1:1 (minus protocol fee share to treasury). **`LIQToken.sol`** * **Purpose:** Governance/incentive token with **emission halving** in the Vault. * **Features:** Max supply (e.g., 100M); ERC‑20 + Permit; minted by Vault; holders may burn. #### Staking & Rewards **`EpochStakingDistributor.sol`** * **Purpose:** Epoch‑based rewards for **iAERO** stakers. * **Mechanics:** Rewards bucketed by `(token, epoch)`; users can **claim N tokens for N epochs** (UI can source epoch/token lists via **RewardsSugar** or equivalent). * **stiAERO:** Receipt token is minted 1:1 on stake and burned on unstake (used as potential collateral externally). * **Security:** Pausable, balance‑delta for FOT tokens, hardened setter for `stiAERO`, optional freeze of receipt pointer. **`StiAERO.sol`** * **Purpose:** ERC‑20 receipt for iAERO stakers. * **Roles:** `MINTER_ROLE` / `BURNER_ROLE` granted to **EpochStakingDistributor**; admin on multisig. **`LIQStakingDistributor.sol` (this contract)** * **Purpose:** Rewards LIQ stakers (e.g., **TreasuryDistributor** flow = 80% of the 10% protocol share). * **Mechanics:** Per‑share accumulator; ETH + multi‑token support; **7‑day lock**; global **pause**; **emergencyWithdraw** only when paused; **FOT‑safe** notify; optional retire of tokens. #### Reward Collection & Splits **`RewardsHarvesterV2.sol`** * **Purpose:** Claims **Aerodrome** bribes/fees/emissions for the Vault’s veNFT and **routes** them by policy. * **Split:** * **80%** → iAERO stakers (**EpochStakingDistributor**) * **10%** → **TreasuryDistributor** (splits 80/20) * **10%** → **Peg reserve** (to `pegDefender` or `treasury`) * **Safety:** If Distributor notify fails, staker share **falls back** to Treasury/TreasuryDistributor; uses `forceApprove` with reset. **`TreasuryDistributor.sol`** * **Purpose:** Splits protocol’s **10%** share. * **Split:** * **80%** → LIQ stakers (**LIQStakingDistributor**) (**8% of total**) * **20%** → Treasury ops (**2% of total**) #### Voting & Bribe Management **`VotingManagerOptimised.sol`** * **Purpose:** Orchestrates **Aerodrome** voting via Vault’s veNFT, manages **bribe deposits** and **refunds**, performs **oracle‑weighted** allocation. * **Bribes:** ERC‑20 + ETH supported; per‑epoch slices with minimum **USD value** per epoch (via Chainlink feeds). * **Refunds:** If epoch not executed or pool not voted, **refundable** after a grace period. * **Treasury Claims:** Post‑vote, keeper collects bribe slices for pools that were actually voted. #### External / Data Helpers (Optional) * **RewardsSugar / LpSugar** (readers): Off‑chain or on‑chain dataset helpers you can use in UI/backend to **enumerate tokens & pools**, fetch **current epoch** expectations, and drive **claim batching** UX. *** #### System Interactions (Mermaid) ```mermaid graph TD User[User] -->|Deposit AERO| Vault[PermalockVault_V5] Vault -->|Mint iAERO| iAERO[iAERO Token] Vault -->|Mint LIQ| LIQ[LIQ Token] %% iAERO staking side User -->|Stake iAERO| ESD[EpochStakingDistributor] ESD -->|Mint 1:1| stiAERO[StiAERO Receipt] ESD -->|Burn on Unstake| stiAERO %% LIQ staking side User -->|Stake LIQ| LSD[LIQStakingDistributor] %% Harvester routes rewards RH[RewardsHarvesterV2] -->|80% Stakers| ESD RH -->|10%| TD[TreasuryDistributor] RH -->|10%| Peg[Peg Reserve / Defender] %% TreasuryDistributor splits 10% TD -->|80% of 10%| LSD TD -->|20% of 10%| Treasury[Treasury Ops] %% Voting management VM[VotingManagerOptimised] -->|Execute Votes| Vault Vault -->|executeNFTAction to Voter| Aerodrome[Aerodrome Voter] VM -->|Bribe Refunds & Treasury Claims| Treasury ``` *** #### Quick Function Index (high‑level) **Vault** * User: `deposit`, `depositVeNFT` * Ops: `performMaintenance` * Manager/Harvester: `executeNFTAction`, `sweepERC20/ETH` * Admin: `setRewardsCollector`, `setVotingManager`, `setAuthorizedTarget`, rescue suite **EpochStakingDistributor** * Funding: `notifyRewardAmount`, epoch variants/batch * Stake: `stake`, `stakeFor`, burn/mint **stiAERO** * Claim: `claim`, `claimMany`, `claimLatest` * Admin: `setReceiptToken`, `freezeReceiptToken`, `setAllowedFunder`, pause **LIQStakingDistributor** * Stake: `stake` (7d lock), `unstake`, `exit`, `emergencyWithdraw (paused only)` * Funding: `notifyRewardAmount` (ETH + ERC‑20 balance‑delta) * Claim: `claimRewards`, `claimReward` * Admin: `setRewardNotifier`, `retireRewardToken`, `recoverERC20`, pause **RewardsHarvesterV2** * `claimAerodromeRewards` (bribes/fees/emissions) * `processAndDistribute`, `processAndDistributeETH` (80/10/10 split with safe fallback) **VotingManagerOptimised** * Bribes: `depositBribe`, `depositETHBribe`, `refundMyBribes`, `claimTreasuryBribes` * Voting: `executeVotesAuto`, `executeVotesWithWeights` * Oracles: `setOracle`, `batchConfigureOracles` * Pools: `addPools`, `removePool` * Admin: `pause/unpause`, `emergencyWithdraw` (restricted) **TreasuryDistributor** * `distribute(token)`—routes 80/20 of protocol’s 10% share *** #### Operational Notes * Use **multisig** as `owner` / `DEFAULT_ADMIN_ROLE`. * Authorize only trusted **reward notifiers** (Vault, Harvester, Treasury). * Run keepers for **Harvester** (claim/split) and **VotingManager** (vote execution, bribe handling). * Configure **Chainlink oracles** for every bribe token (incl. **ETH/USD**). * Prefer a small curated set of reward tokens (retire seldom‑used tokens when `queued==0`). *** # Audits Epoch Staking Distributor & stiAERO **Auditor:** Independent Security Review **Date:** September 2025 **Network:** Base Mainnet *** ## Audit 1 — EpochStakingDistributor **Contract Address:** `0x781A80fA817b5a146C440F03EF8643f4aca6588A` ### Executive Summary **Risk rating:** **Low–Medium overall** The contract implements a **snapshot‑per‑epoch** reward distribution for iAERO stakers. It does **not** maintain or iterate any token list, which keeps `stake`/`unstake` gas predictable. Rewards are accounted by **(token, epoch)** and claimed by users directly. The contract follows safe interaction patterns (**checks‑effects‑interactions**, `nonReentrant`) and now includes **Pausable**, tighter **funding arithmetic**, and **safer receipt‑token linkage**. ### What changed / fixed * **Removed unchecked arithmetic** in ERC‑20 funding; now we compute `received = after − before` with explicit non‑regression and `> 0` checks. * **Added Pausable;** critical functions (`stake`, `unstake`, `exit`, `notify*`, `claim*`, `backfillReceipts`) are gated with `whenNotPaused`. * **Strengthened receipt‑token onboarding:** `setReceiptToken` now requires a code‑bearing contract, forbids setting to `iAERO`, and can be **frozen**. * **Wider checkpoint timestamps:** `uint64 ts` (from `uint48`) while keeping checkpoints to one slot (`uint64 ts | uint192 value`). * **Conservative ERC‑20 recovery:** owner can only recover **non‑iAERO** and **non‑receipt** tokens (with clear warning; see “Operations & Risks”). * **Internal claim path** for batch claims avoids nested `nonReentrant`. ### Scope & Methodology * **In‑scope files:** Epoch‑snapshot distributor contract provided in the last version you approved. * **Out‑of‑scope:** Vault, Harvester, Aerodrome Voter, token prices/oracles, third‑party protocols using `stiAERO` as collateral. * **Approach:** Manual line‑by‑line review, invariants & state‑machine reasoning, reentrancy/authorization analysis, economic checks for reward splits, edge‑case exploration (zero‑supply epochs, FOT tokens), gas & grief‑ing considerations. ### System Overview * **Stake/Unstake:** Users stake iAERO into the distributor; (optionally) a **receipt token** (`stiAERO`) is minted/burned 1:1 with staked iAERO. * **Epoch model:** Rewards are funded to **(token, epoch)** buckets. Payout shares are computed from **epoch‑start snapshots** of user balance and total supply. * **Funding:** `notifyRewardAmount(token, amount)` (current epoch) or `notifyRewardForEpoch(token, specificEpoch)`. ERC‑20 funding uses “pull” with **balance‑delta** to accommodate fee‑on‑transfer tokens; ETH uses `msg.value`. * **Claiming:** Users call `claim(token, epoch)` (or batched variants) to pull rewards. The distributor transfers directly to the user. * **No token enumeration:** The contract never stores an “active set” of reward tokens; all loops are bounded by the caller’s input (capped at 50 items per batch). ### Roles & Permissions * **Owner:** pause/unpause; set receipt token / freeze pointer; set allowed funders; perform conservative `recoverERC20`. * **Allowed funders:** call `notify*` functions. * **Anyone:** stake/unstake (user), claim personal rewards. ### Threat Model & Trust Assumptions * **Trusted:** Contract owner/multisig; allowed funders (e.g., your Harvester). * **Untrusted:** Users; arbitrary ERC‑20 tokens used as rewards; external protocols where `stiAERO` is used as collateral. * **Dependencies:** OpenZeppelin (v5) `Ownable`, `ReentrancyGuard`, `Pausable`, `SafeERC20`, `Math`. ### Findings #### Critical / High * **None observed.** #### Medium **M‑1: Zero‑supply epoch ⇒ permanent 0 claims for that epoch** * **Description:** If `totalSupplyAtEpochStart(epoch) == 0`, then `previewClaim` returns 0 for that epoch forever (even if users stake mid‑epoch). This is **by design** for snapshot fairness but leaves funds stranded in that epoch bucket. * **Impact:** Operational. Rewards for such epochs do not flow to users. * **Recommendation:** Handle at the **Harvester/ops** layer—if snapshot is 0 for intended epoch, fund the **next** epoch. Optionally add an owner‑only “roll‑forward” function to move untouched rewards to a later epoch. * **Status:** **Accepted by design.** Documented in runbook (see below). **M‑2: Admin / role mis‑configuration risk** * **Description:** If `stiAERO` roles (MINTER/BURNER) are not granted to the distributor, staking or unstaking will revert. If the distributor’s `owner` is an EOA, key risk increases. * **Recommendation:** Use a **multisig** for both `DEFAULT_ADMIN_ROLE` on `stiAERO` and `Ownable` owner on the distributor; wire roles first, then call `setReceiptToken`. Consider freezing pointer after validation. * **Status:** **Mitigated operationally** (deployment checklist provided). #### Low **L‑1: Conservative token recovery can withdraw reward tokens** * **Description:** `recoverERC20` is intentionally narrow (excludes iAERO & receipt token) but could still remove a token that has funded/claimable balances. * **Recommendation:** Use only for obvious dust. For a fully safe recovery, a richer liability check would be needed (not recommended due to gas/storage overhead). * **Status:** **Acknowledged**; keep as emergency escape with procedures. **L‑2: Batch sizes and user checkpoint growth** * **Description:** `claimMany`/`notifyBatch` accept up to 50 items; checkpoint arrays grow with user activity. * **Recommendation:** The caps and binary search are adequate; periodically test gas envelopes. * **Status:** **Accepted**. **L‑3: Pausing blocks claims** * **Description:** `whenNotPaused` protects claim functions as well. * **Recommendation:** If business preference is to **allow claims while paused**, remove `whenNotPaused` from claim functions. * **Status:** **Configuration choice**. ### Design Soundness & Invariants * **No token enumeration:** The distributor never loops “all tokens”; all loops depend on **caller input** (bounded/capped). * **Reentrancy:** All external state‑mutating functions are `nonReentrant`. Claims use internal `_claim` to avoid nested guards. Transfers occur **after** state updates. * **Funding correctness:** ERC‑20 path computes `received = after − before` and requires `after ≥ before` and `received > 0`. ETH path requires `msg.value == amount`. * **Snapshot math:** For user `u`, `payout = rewards[token][epoch] * bal_at_start(u) / supply_at_start`. The sum of payouts over all users ≤ funded amount (flooring/rounding may leave dust). * **Receipt alignment:** After `setReceiptToken`, staking mints `stiAERO` 1:1, unstaking burns 1:1. `exit` burns full balance. * **Ownership:** `Ownable(msg.sender)` in constructor; recommended to transfer to multisig post‑deploy. ### Operational Guidance (How to Use) #### Deployment (Base) 1. **Deploy** `EpochStakingDistributor(iAERO)`. 2. **Deploy** `StiAERO(admin=multisig)`. 3. From the **admin** (multisig), **grant roles** to the distributor: * `grantRole(MINTER_ROLE, )` * `grantRole(BURNER_ROLE, )` 4. On distributor, **set receipt token**: `setReceiptToken()`. (Optional: `freezeReceiptToken()`.) 5. **Allow funder:** `setAllowedFunder(, true)`. 6. **Transfer ownership** of distributor to multisig (recommended). 7. If there were existing stakes, use `backfillReceipts([users...])` in batches. #### Routine Operations * **Funding (Harvester):** * Normal: `notifyRewardAmount(token, amount)` → current epoch. * Specific epoch: `notifyRewardForEpoch(token, epoch, amount)` (current or previous only). * Batch: `notifyRewardAmountsBatch(tokens[], epochs[], amounts[])` (≤ 50 legs). * **Claiming (User/UI):** * Single: `claim(token, epoch)` * Many: `claimMany(tokens[], epochs[])` (n tokens for n epochs) * Weekly default: `claimLatest(tokens[])` (current + previous) * Preview: `previewClaim(user, token, epoch)` or `previewClaimsForEpoch`. * **Emergency:** * `pause()` → blocks stake/unstake/notify/claim/backfill. * `unpause()` restores. * `recoverERC20(token, to, amount)` only for non‑iAERO/non‑receipt dust. #### Monitoring & Playbooks * **Zero‑supply epoch:** If `supplySnapshotAtEpochStart[epoch] == 0`, fund **next epoch** instead. * **Unclaimed dust:** Due to rounding, small dust may remain. This is acceptable; do not sweep casually. * **Receipt invariants:** `stiAERO.totalSupply()` should equal the sum of `balanceOf` across users (not tracked on‑chain; verify off‑chain). ### Test Recommendations * **Property tests:** * Sum of `previewClaim` across users ≤ funded amount. * Receipt mint/burn matches delta in `balanceOf`. * Funding with FOT token yields `received > 0` and claims match `received`. * Epoch with zero supply produces zero claims; funding next epoch produces non‑zero claims. * **Reentrancy tests:** Attempt reentrancy via ERC‑777 style tokens or malicious receipt token; should be blocked by `nonReentrant` and call order. * **Pause tests:** Verify all protected functions revert when paused. *** ## Audit 2 — StiAERO (Receipt Token) **Contract Address:** `0x72C135B8eEBC57A3823f0920233e1A90FF4D683D` ### Executive Summary **Risk rating:** **Low** `StiAERO` is a standard transferable ERC‑20 with `ERC20Permit` and `AccessControl`. The staking distributor is granted `MINTER_ROLE` and `BURNER_ROLE` to mint/burn receipts 1:1 with staked balances. The security posture primarily depends on role governance and the distributor’s correctness. ### Scope & Methodology * **In‑scope:** `StiAERO` token contract. * **Approach:** Manual review for ERC‑20 correctness, role gating, and mint/burn semantics. ### System Overview * **Token:** *Staked iAERO* / `stiAERO` (18 decimals). * **Roles:** * `DEFAULT_ADMIN_ROLE`: manages roles; set to a **multisig** at deployment. * `MINTER_ROLE`: granted to distributor. * `BURNER_ROLE`: granted to distributor. * **Mint/Burn:** * `mint(to, amount)` only by MINTER. * `burn(from, amount)` only by BURNER (no allowance required; distributor burns directly during unstake/exit). ### Findings #### Critical / High * **None observed.** #### Medium **M‑1: Centralized roles** * **Description:** Admin can mint/burn if they grant roles to themselves or a compromised address. * **Recommendation:** Keep `DEFAULT_ADMIN_ROLE` on a **multisig**, avoid keeping MINTER/BURNER on EOAs beyond deployment. Revoke any temporary roles. #### Low **L‑1: External dependencies** * **Description:** Relies on OZ ERC‑20/Permit/AccessControl; well‑audited but requires correct linkage and compiler settings. * **Recommendation:** Pin OZ version in your build, run compilation with optimizer enabled and consistent settings across contracts. ### Operational Guidance (How to Use) * **Deployment:** `new StiAERO(admin=multisig)`; immediately grant MINTER/BURNER to distributor. * **After wiring:** Optionally revoke any roles from the deployer EOA; keep only multisig (admin) and distributor (minter/burner). * **Usage in UIs/protocols:** `stiAERO` is a regular ERC‑20 (transferable, `permit` supported). Users may deposit it as collateral elsewhere—but they must hold enough to burn when unstaking. ### Fixes & Closing Notes The combined system (Distributor + `stiAERO`) incorporated the following security improvements before this final audit: * ✔️ Removed `unchecked` arithmetic in ERC‑20 funding; added explicit post‑transfer checks. * ✔️ Added **Pausable** to all critical flows. * ✔️ Hardened `setReceiptToken` (code length check; forbid `iAERO`; optional freezing). * ✔️ Widened checkpoint timestamp to `uint64`. * ✔️ Added conservative `recoverERC20` with exclusions. * ✔️ Used internal `_claim` to avoid nesting `nonReentrant`. With these changes, the design is **sound and production‑ready** for Base, assuming operational best practices: * Run with **multisig** admin/owner. * Set `allowedFunders` to the Harvester only. * Handle **zero‑supply epochs** at the operations layer (fund next epoch or accept that bucket as 0). * Avoid using `recoverERC20` except for obvious dust; do not sweep active reward tokens. *** ## Appendix — Function Access Map (Distributor) | Function | Access | Pausable | Reentrancy | External calls | | --------------------------------------- | ------------------- | :------: | :--------: | ------------------------------------------------------ | | `stake`, `stakeFor` | public | Yes | Yes | ERC‑20 `transferFrom` (iAERO), optional `stiAERO.mint` | | `unstake`, `exit` | public | Yes | Yes | optional `stiAERO.burn`, ERC‑20 `transfer` (iAERO) | | `notifyRewardAmount` | owner/allowedFunder | Yes | Yes | ERC‑20 `transferFrom` (reward) | | `notifyRewardForEpoch` | owner/allowedFunder | Yes | Yes | ERC‑20 `transferFrom` (reward) | | `notifyRewardAmountsBatch` | owner/allowedFunder | Yes | Yes | ERC‑20 `transferFrom` (reward) | | `claim` | public | Yes | Yes | ETH transfer or ERC‑20 `transfer` (reward) | | `claimMany`, `claimLatest` | public | Yes | Yes | ETH / ERC‑20 transfers | | `setReceiptToken`, `freezeReceiptToken` | owner | n/a | n/a | sets receipt address | | `backfillReceipts` | owner | Yes | Yes | `stiAERO.mint` | | `setAllowedFunder` | owner | n/a | n/a | — | | `pause`, `unpause` | owner | n/a | n/a | — | | `recoverERC20` | owner | n/a | n/a | ERC‑20 `transfer` (non‑iAERO/non‑receipt) | # Troubleshooting ## Common Issues ### Transaction Failures **Problem**: "Wallet mutated or stripped calldata" **Solution**: * Disable transaction simulation in wallet * Try using MetaMask or Rabby * Use the Safe transaction builder for multisigs ### NFT Not Merging **Problem**: Deposited NFT shows "needsMerge: true" **Solution**: * Ensure auto-max lock is disabled * Call `performMaintenance()` manually * Wait for next deposit to trigger merge ### No Rewards Showing **Problem**: Staked iAERO but no rewards visible **Solution**: * Rewards are distributed weekly * Check if rewards have been harvested * Ensure you're staking in the correct contract ### Approval Issues **Problem**: Can't approve AERO/veNFT **Solution**: * Reset approval to 0 first * Try increasing gas limit * Check wallet has sufficient ETH ## Getting Help * Discord: [Join our community](https://discord.gg/RtGST592) * Twitter: @iAEROProtocol