[ARFC] Aave App Launch

1. Aave for Everyone Aave App is designed to meet the usability bar of leading fintech apps: the Fintech Test . It gives anyone, anywhere, a self-custodial way to access Aave Protocol’s lending infrastructure through an interface as simple as the apps they already use. Aave App allows anyone with a smartphone to use Aave’s institutional-grade lending infrastructure without setting up a digital asset wallet, managing gas, or understanding the complexities of DeFi. Users transfer fiat from their bank account via Aave Push’s regulated fiat-conversion rails and earn yield generated by Aave Protocol’s lending markets, with all net revenue directed to the DAO treasury. Aave Labs provides the user interface and the self-custodial infrastructure behind it, through Aave Accounts and ERC-6900 smart accounts. At launch, the Aave App will introduce four new innovations (Stable Vaults, Balance Protection, Aave App Accounts and Aave Push), with more product additions arriving through 2026 to increase revenue, lower costs, and expand the App’s user base. This proposal asks the DAO to approve the following: The initial vault allocation configuration for the Aave App, as specified in Section 5 The RPUR (Revenue Parameter Update Request) framework described in Section 7, under which the DAO may propose changes to Aave App’s core revenue parameters A launch campaign for the Aave App, as detailed in Section 8 The use of the entire Milestone 1 funding from the Aave Will Win proposal to fund the first-loss tranche of the Balance Protection captive structure The addition of Stable Vaults to the scope of the Aave App Stack bug bounty program, as described in the Aave Protocol Bug Bounty Programs Restructure ARFC and specified in Section 5 2. User & Balance Projections Aave App’s iOS waitlist comprises approximately 50,000 registered users, each of whom completed a multi-step onboarding process: app download, account setup, and profile completion with a subset of users also completing applicable KYC screening (only available to US users while on the waitlist). This required multi-step process filters for higher intent users relative to those present in email-only waitlists. The Android version of the Aave App is expected to be released in Q3 2026, expanding the non-US user base. By the end of the Aave App’s first 12 months, we estimate three scenarios for combined iOS and Android success metrics by varying three assumptions together for each case: conversion rate from waitlist to funded user (a user who has made an initial deposit), average balance per funded user, and month over month user growth: The above metrics are purely indicative, based on current waitlist numbers, assumed conversion rates, and projected month-over-month growth, and should not be taken as a guarantee of future performance. 3. Revenue Opportunities Aave App is projected to generate over $15M in annual revenue by the end of year two (indicative), across the four revenue streams outlined below, with additional streams under evaluation. Stream 1 (yield spread fees) and Stream 2 (reserve factor attribution) are expected to be active at launch. Streams 3 and 4 (card fees, swaps and FX), are expected to phase in throughout 2026, pending product availability and regulatory clearance. The $15M figure includes illustrative contributions from Streams 3 and 4; as these products have not yet been built or cleared for launch, their revenue contribution should not be treated as a projection the DAO is asked to rely on. YIELD SPREAD This fee is derived from the spread between the yield earned by the assets deployed in the vault and the yield payable to users. For example, total user deposits of $1B with a 0.2% yield spread could result in $2M in annual revenue within 24 months. RESERVE FACTOR ATTRIBUTION Because the Aave App uses Aave Protocol for earning on the vault’s balances, an increase in deposits via the app results in an increase in deposits into the protocol markets. Assuming unchanged protocol utilization rates and reserve factor, an increase in user balances would increase the reserve factor revenue for the DAO. Within 24 months, deposits of $1B flowing into Aave Protocol via the Aave App could generate approximately $4.5M in annual reserve factor revenue accruing to the DAO treasury at a 6% borrow rate , calculated as: $1B × 75% utilization × 6% borrow rate × 10% reserve factor = $4.5M The above calculation is a projection that assumes stable protocol utilization, borrow rates, and reserve factor allocation. The actual figure depends on protocol-wide activity, the stability of the above noted factors, and DAO governance. CARD FEES Card fees (including interchange, FX, network incentives, signing bonuses, etc) are expected to be a major revenue driver. The Aave App is expected to enable worldwide card issuance, letting users spend directly from their vault balances. This creates a high-margin, transaction-based revenue stream opportunity that can scale independently of yield or user balances. The table below includes projections assuming a 1.0% blended card fee. Savings-first users tend to have higher card spend because their vault balance functions as a spending account, similar to debit card behavior at neobanks. Card adoption rates are benchmarked against major fintechs. If Aave Cards launch, the calculation above illustrates how card revenue could scale with adoption; it is not a revenue target and is not part of what this proposal asks the DAO to approve. SWAP FEES Future additions to the Aave App could include volume-based fees on swaps between assets. Example use cases could include: Non-Stablecoin Deposits: Users that want to exit a crypto asset position and enter into stablecoins that pay a yield before they make their next move. Foreign Exchange Swaps: With the introduction of savings in additional fiat currencies as well as the ability to spend the Aave App balance internationally with the upcoming card, Aave App would be able to charge FX swap fees. The chart below is illustrative only. Swap fees depend on both the FX swap capability and the card product described above, neither of which currently exists, and the figures shown should not be treated as a projection the DAO is asked to rely on: 4. The Four Aave App Innovations At launch, Aave App will introduce four breakthrough innovations, each one necessary to pass the Fintech Test. STABLE VAULT Stable Vault is a vault tailor-made for retail consumer savings and provides a step-function improvement for stablecoin-powered savings applications. While being a DeFi innovation, it mirrors the user experience of traditional savings accounts while allowing for maximum cost and liquidity scalability. The core features that make this possible are: Per-user stable rate: Stable Vault depositors’ assets are placed in a yield bucket (for example, earning 5%, with the rates being influenced by underlying variable DeFi markets) from the vault’s allocation rather than guaranteed by any actor. This innovation allows for a smoother, more predictable yield experience. Certain users may be eligible to obtain yield boosts by completing in-app activities such as inviting friends or setting up automated deposits. Multi-strategy connectivity: Stable Vault is able to earn by supplying liquidity to protocols with any ERC-4626 compatible strategy, meaning Aave App can earn with Aave V3, V4 and sGHO. Multi-chain earning: Stable Vault is able to earn on any supported chain, enabling for the accounting (processing of deposits & withdrawals) to happen on a gas-efficient chain, while accessing the deepest pools of liquidity on Ethereum and capturing incentives on select other chains. Multi-stablecoin deposits: Stable Vault allows deposits & withdrawals in any number of whitelisted stablecoins, further allowing Aave App to abstract away individual stablecoin balances behind a reported dollar value. Stablecoins inside of the Stable Vault are rebalanced toward the target allocation automatically and uniformly across pooled balances, without discretionary per-user management. Stable Vault’s multi-chain IOU bridging functionality is guarded by an M-of-N bridge quorum. Rate limits are enforced on asset bridging globally and per lane (a route per asset, bridge provider and chain) to mitigate risk of bridge compromises or down time. Stable Vaults have been audited by Certora, Chain Security, Josselin, Stermi, and Recon. You can find the code and more information in the Stable Vault GitHub repository . Stable Vaults will be available to fintechs and partners as part of Aave Kit. BALANCE PROTECTION The Aave App will launch with a Balance Protection Program. Coverage is arranged with established third-party risk carriers, with a first loss tranche funded through a captive structure. The Program sets a new benchmark for user protection in DeFi-powered applications. Under the Program, eligible users may be reimbursed for the loss of protected stablecoin balances held through the Aave App where the loss results from: A security breach of the Aave App’s systems, including its smart contract infrastructure; A failure of the Aave App’s technology to perform as intended; or A prolonged inability to withdraw funds (more than 30 consecutive days) caused by the loss or inaccessibility of the cryptographic keys required to execute withdrawals. Balance Protection is provided subject to eligibility requirements (including a minimum protected balance, multi-factor authentication and activation of account protection features in the app), coverage limits, exclusions and claim deadlines. Program T&Cs apply. The entire funding from Milestone 1 for the Aave App public launch, detailed in the Aave Will Win proposal , will be used to fund the first-loss tranche in the Balance Protection captive structure. AAVE APP ACCOUNTS A significant limitation of non-custodial wallet software preventing mass adoption is the tension between allowing the user to stay in control over their assets, while providing an easy and intuitive user experience that rivals the best fintech apps today. Aave App is designed to be easy to use from the start, with the ability to sign up with either a phone number or an email address, in addition to a password. This is powered by Aave Accounts, an Aave Labs-incubated Ethereum EOA signer, which has undergone independent 3rd party audits by Zellic and Trail of Bits. Encrypted secret material, including a private key, requires a phone number and password to access, which reduces the risk of SIM-swap attacks compromising the account on their own. Aave Accounts act as the primary signer on an ERC-6900 smart account with custom modules allowing Aave App to offer a fintech-like experience by granting fine grained session key access without compromising self-custody. Among other features, after user authorization, funds may be swept into the vault upon receipt by the smart account, rather than requiring the user to perform an additional action to start earning yield, as well as adding account protection by requiring withdrawal destinations to be whitelisted by the user before funds are sent there. You can find the code and more information in the 6900 GitHub repository . In the event that a user loses access to their password, Aave App will launch with an opt-in account recovery feature, allowing users to regain access to their account by passing a biometric face scan, offered in partnership with CoinCover. You can learn more about this system here . AAVE PUSH Push by Aave Labs is responsible for, amongst other things, user identity verification; PEPs, sanctions and adverse media screening; fiat on-and-off ramping services; transaction monitoring; risk monitoring; compliance monitoring and testing; and financial crime oversight. Push holds a range of regulatory registrations and authorisations across key jurisdictions. In the UK, Push is authorised as an Electronic Money Institution (EMI) and registered as Cryptoasset Exchange Providers, enabling the delivery of integrated fiat and crypto services. In Ireland, Push is authorised as a Crypto-Asset Service Provider (CASP) by the Central Bank of Ireland (CBI). In the United States, Push is registered with FinCEN as a money services business, and is in the process of obtaining the necessary Money Transmitter Licences (MTLs) to support its operations. Push is an essential component of Aave App, and is designed to support Aave-powered interfaces more broadly, in the future. It allows products built on top of the Aave Protocol to offer low fee (or free) and scalable deposits and withdrawals to and from fiat currencies, and provides the foundation for exciting potential future products, which may include Aave-powered cards and regulated Aave stablecoins. 5. Stable Vault Launch Configuration The Stable Vault’s launch configuration is established by this proposal. This includes the initial target allocation, supported stablecoins, and the operating constraints under which the vault may rebalance over time. All of the App’s net revenue, including any difference between the yield generated by the underlying strategies and the rate paid to users, accrues to the DAO treasury. Whitelisted Stablecoins GHO USDC USDT Launch Target Allocation This proposal establishes the following target allocation for launch: 90% sGHO on Ethereum 5% aUSDC on Arbitrum 4% aUSDT on Arbitrum 1% GHO on Arbitrum The target allocation is intended to: prioritize yield generation; maintain sufficient redemption liquidity on the accounting chain; and reduce unnecessary swap activity by aligning liquidity with expected deposit and withdrawal patterns. Actual allocations may differ slightly from the target at any given time as assets are rebalanced to accommodate user deposits, withdrawals, bridge transfers and minimum execution sizes. The Stable Vault operates subject to the following constraints: rebalancing occurs only among DAO-approved assets and strategies; swaps execute on a 1:1 value basis, with any slippage covered through the Slippage Coverage Vault; bridge transfers are subject to configured rate limits; additional exposure to a stablecoin is prevented if oracle pricing indicates a material deviation from peg; assets or strategies may be excluded from future allocation if they are designated untrusted by the system configuration. Where market conditions or impairments prevent the target allocation from being maintained safely, the implementation prioritizes maintaining redeemability of user balances by increasing idle reserves and reducing exposure to affected strategies until governance determines an updated configuration. The Stable Vault contracts are public and have been audited by ChainSecurity, Certora, Recon and Josselin Feist. The Stable Vault is designed to operate according to the DAO-approved configuration described in this proposal. To support its day-to-day operation, the DAO may delegate certain operational functions to one or more Vault Stewards. These responsibilities are limited to the governance-defined operations of the Stable Vault and do not include authority to modify governance-approved parameters. At launch, this proposal designates Aave Labs as the initial Vault Steward. Additional DAO service providers may be further authorized to perform other supporting functions, and any designated Vault Steward may be replaced by Aave DAO governance at any time. Bug Bounty Coverage This proposal asks the DAO to approve the enrollment of the Stable Vault contracts in an ongoing bug bounty program at launch. Specifically, the Stable Vault contracts and their supporting infrastructure would be added to the scope of the Aave App Stack bug bounty program , operated on Sherlock, as established in the Aave Protocol Bug Bounty Programs Restructure ARFC . That ARFC already contemplates the Aave App Stack program covering Aave V3 App, Aave Pro, Aave Kit, and critical domains and web applications; this proposal makes the Stable Vault contracts an explicit part of that scope. Enrollment would cover the Stable Vault core contracts. Consistent with the Aave App Stack program, the primary focus is vulnerabilities that could directly lead to loss of user funds. Stable Vault submissions would follow the Aave App Stack severity and payout framework proposed in the Bug Bounty Programs Restructure ARFC: Severity Min Max Critical $50,000 $100,000 High $10,000 $25,000 Medium $5,000 $10,000 Low $1,000 $5,000 Funding and payout execution follow the unified DAO-level payout flow described in the Bug Bounty Programs Restructure ARFC, with the Aave App Stack program falling under Aave DAO funding responsibility. If the Bug Bounty Programs Restructure ARFC has not yet passed Snapshot at the time this proposal is implemented, Stable Vault coverage would be added to the existing DAO bug bounty program under equivalent terms until the restructured programs take effect. 6. Launch Timeline The Aave App is expected to follow a phased rollout, progressively granting waitlisted users access to use the App in cohorts based on referral activity as part of a public beta. A phased approach allows the system to scale the user base in a controlled manner, so that system stability, balance protection coverage, and customer support can keep pace at each stage of the rollout. Regional Buckets Waitlist users are segmented into regional buckets reflecting the availability of identity verification and fiat rails (provided through Push and its licensed partners) at launch: US: full fiat on and off-ramp and KYC (except NY). EU (8 countries for initial rollout): full fiat on/off-ramp in the initial supported set. Additional EU countries will be added throughout 2026 as infrastructure expands. UK: To be added in July. The initial rollout of EU countries will be: Portugal, Spain, Ireland, France, Italy, Germany, Poland and The Netherlands. Rest of World (RoW): stablecoin-only deposits and withdrawals at launch, with fiat support to follow as regional partnerships mature. At each phase, onboarding is pulled roughly equally from all active buckets and ordered within each bucket by referral count. This supports balanced regional growth and prevents any single market from saturating launch capacity ahead of others. Launch Phases Phase 1 — Founding Users (Weeks 1–3) The first 1,000 users will be onboarded from the top of the waitlist, pulled roughly equally across the US, EU, and RoW (rest of the world) buckets and prioritized within each bucket by referral count. This cohort will serve as the initial validation cohort for end-to-end flows including KYC (where applicable), bank deposits or stablecoin deposits, vault allocation, and withdrawals. User cap: 1,000 users Primary objective: Validate the full deposit-to-withdrawal lifecycle under real-world load across all three initial regional buckets, as well as collect data on the main cost drivers to help prioritize product cost optimization. Phase 2 — Early Access (Weeks 4–7) Access expands to the next 9,000 waitlist users, again pulled roughly equally across the US, EU, and RoW buckets and ordered within each bucket by referral count. During this phase, the referral mechanism becomes the primary lever for queue advancement: each successful referral moves a user forward in their bucket’s queue. The UK bucket is expected to come online during this phase as KYC and bank deposit infrastructure becomes available, at which point onboarding shifts to pulling roughly equally across all four buckets. User cap: 10,000 cumulative users Primary objective: Stress-test the Stable Vault rebalancing logic across sGHO and accounting-chain allocations under realistic deposit and withdrawal volumes, and UK onboarding once enabled Phase 3 — Open Waitlist (Weeks 8–16) The remaining iOS waitlist users are onboarded in weekly cohorts, continuing the equal-pull model across active buckets. New signups continue to be queued, with referrals remaining the primary acceleration mechanism. User cap: 50,000 Primary objective: Reach full waitlist conversion and validate cross-region operational flows including EUR-denominated and GBP-denominated USDC deposits and withdrawals. Phase 4 — General Availability (Week 17 onward) The waitlist is removed and the iOS app becomes openly available in all supported jurisdictions. The Android version is targeted for release during Q3 2026, expanding access to the broader non-US user base. Waitlist: removed User base scaling toward the 12-month projection described in Section 2. Phase Progression Criteria Advancement between phases is conditional on the following criteria being met: Operational stability: no major incidents in the trailing 7 days, and all systems operating as intended. Vault health: Stable Vault allocation within ±5% of the target configuration specified in Section 6, and instant redemption liquidity sufficient to service projected daily withdrawal volume at a 3x safety margin. Support capacity: customer support response times don’t routinely exceed 24-48 hours across all supported channels and active regional buckets. If any criterion is not met, the active phase is extended and new user onboarding paused until remediation is complete. Communications Aave Labs publishes a phase status dashboard tracking onboarded users per bucket, aggregate balances, and progression criteria health. Material changes to the launch plan, including phase extensions, scope adjustments, regional bucket additions, or user cap modifications, are posted to the Aave governance forum. These changes reflect good-faith operational implementation of the Phase Progression Criteria and regional rollout parameters already approved by the DAO in this proposal, and do not constitute a new grant of authority to Aave Labs. 7. Revenue Parameter Update and Feature Requests This section gives the DAO a standing, structured mechanism to adjust the Aave App’s core revenue parameters and Stable Vault configuration as the product matures and real usage data replaces projections. Scope of Adjustable Parameters A Revenue Parameter Update Request (RPUR) may propose changes to the following core revenue parameters, in addition to any new revenue streams added in the future: Some inputs are set outside the DAO’s control, such as the raw interchange rate set by card networks or the market yields produced by the underlying DeFi markets. An RPUR may adjust the DAO’s share of revenue, not those externally determined rates. 8. Launch Campaign This proposal asks the DAO to approve a $500,000 launch campaign budget for the bootstrapping of Aave App. The budget will be deployed solely across two purposes: Yield Incentivisation: Boosting Stable Vault yields for early users to accelerate first-deposit conversion and balance growth from the waitlist cohort. Vault rebalancing cost coverage: Subsidizing swap and bridge costs incurred by the Stable Vault during the launch period, while the rebalancing infrastructure matures and optimizes toward steady-state cost efficiency. After the initial bootstrapping period, fees will be added throughout the app to make it sustainable for the long term. The fees and additional revenue-driving products are outlined in Section 3 of this ARFC. Campaign Duration The campaign will run for approximately 180 days from the start of Phase 1, calculated as: ~90 days to clear the waitlist through Phases 1–3, during which users are lifted off in cohorts per the equal-bucket pull model described in Section 6. 90 days of post-onboarding yield incentivisation for each cohort, ensuring that users onboarded later in the waitlist clearance receive comparable incentive exposure to those onboarded on day 1. The total campaign window therefore spans approximately the launch date through ~180 days post-launch. The exact campaign end date will track the actual pace of waitlist clearance. Incentives are distributed linearly, so users onboarded earlier hold a higher base rate through the incentivization period before the program moves into a period of sustainability. Once the incentive budget is exhausted, the base rate is lowered to make the system more sustainable, or additional incentives are requested. Customer Acquisition Economics The current waitlist of ~50,000 users provides the campaign’s initial conversion base. For modeling purposes, taking a blended user 12 month projection from Section 2 (90,000 users) against the $500,000 campaign budget yields: Average user acquisition cost (CAC) from yield incentives: ~$5.55 per user Average balance per user (per Section 2 blended projection): ~$2,222 Cost to acquire $1 of user balance: ~$0.0025 (i.e., ~25 bps) Aside from yield incentivization, the full cost (weighted by jurisdiction, KYC type, etc) of onboarding a user and servicing them for 12 months is roughly $35.60. This includes, among other things: KYC checks for customers Free (subsidized) bank deposits and withdrawals The balance protection program The account recovery program with CoinCover Subsidizing gas fees Once Aave App is live and we are able to track conversions from different funnels, Aave Labs will post updated Customer Acquisition Costs in the Governance forums. It’s important to note that many of these costs are front loaded for the initial onboarding of a user and don’t appear on an ongoing month to month servicing basis. Examples of costs that are front loaded during initial onboarding include, for example: IDV & risk assessment for a KYCd user The account deployment gas fees Registration with PSP and BAAS providers Linking of an initial bank account and funding an initial bank deposit Without the initial front-loading, the month to month servicing costs average roughly $1.9, or $22.8 per year. Notably, the cost of onboarding and servicing a non-KYC’d user is roughly 70% of that of a KYC’d user. For reference, comparable consumer fintechs typically report CAC in the range of $20–$200+ per user, depending on segment and channel mix. The Aave App’s projected CAC is well below this range, driven by: A pre-qualified waitlist cohort with high signup intent (email, phone, password, country, name, and avatar already provided). Organic referral-driven queue progression as described in Section 6. Yield incentivisation as the primary acquisition lever, rather than competing with brand or paid acquisition spend. Budget Allocation The $500,000 budget is expected to be allocated across the two purposes as follows: This proposal requests the $500,000 campaign budget be funded from the DAO treasury in the following composition: 300,000 GHO, 100,000 USDC, and 100,000 USDT. This mix is denominated to align with the Stable Vault’s whitelisted stablecoins and its sGHO-weighted target allocation, minimizing swaps when incentives and rebalancing subsidies are deployed. Reporting Aave Labs, in line with building and operating in public principles, will publish a campaign performance dashboard tracking: Users onboarded per regional bucket. Balances onboarded per regional bucket. Realized CAC and cost-per-dollar-acquired against the projections above. Campaign spend against the $450K / $50K allocation split. A final campaign report will be published on the governance forum within 30 days of campaign conclusion, including any recommendations for follow-on campaigns based on observed conversion and retention metrics. 9. Next Steps Gather community feedback on this ARFC during forum discussion period. Escalate the proposal to an ARFC Snapshot for off-chain vote. Following a successful Snapshot, submit an AIP for an onchain vote through the Aave Governance Portal. The AIP will implement all approvals requested in this proposal. Copyright Copyright and related rights waived via CC0 . Disclaimer : This proposal contains forward-looking statements, projections and illustrative examples based on current expectations and assumptions. Actual outcomes may differ materially due to a range of factors, including market conditions, user adoption, regulatory developments, technical considerations and DAO governance decisions. Nothing in this proposal constitutes a guarantee, commitment or promise of future performance or product availability. The Aave App Terms and Conditions, as amended from time to time, govern the use of the product and constitute the entire agreement between the user and the relevant service providers. In the event of any inconsistency between this proposal and the applicable Terms and Conditions, the Terms and Conditions shall prevail. 1 post - 1 participant Read full topic