[ARFC] Onboard syrupUSDC to Aave V3 Core Instance

[ARFC] Onboard syrupUSDC to Aave V3 Core Instance

Author: ACI

Date: 2025-06-27

ARFC updated 2025-07-16 with new parameters from Risk Service Providers.


Summary

This proposal seeks to onboard syrupUSDC — a USDC-based yield-bearing token issued by Maple Finance — as a collateral asset on Aave V3 Core Instance. syrupUSDC is built on top of Maple’s infrastructure and offers access to overcollateralized, fixed-rate institutional loans, providing high and consistent yields to DeFi users.

Maple, launched in 2021, is an on-chain Asset Manager with decades of traditional finance and crypto experience. As of June 2025, Maple has $2.3b in AUM. Maple combines deep capital markets expertise with DeFi innovation to offer digital asset lending and yield products.

Motivation

Onboarding syrupUSDC to Aave V3 Core Instance provides:

  • New Token Type: A new collateral option backed by real yield from fixed-rate institutional lending strategies
  • AAVE TVL: Maple has a large network of institutional capital allocators, ready to allocate $500M+ USDC/USDT into syrupUSDC if it is available on Aave as collateral to loop it and get to their hurdle rates.
  • Higher Rates and Utilization: Increases USDC rates and utilization due to strong expected borrower demand.
  • Growth Incentives: Maple has $250k of incentives available to bootstrap the growth for Aave users.

The Aave and Maple partnership will enable:

  • New Yield Opportunities: Commercial alignment with Maple’s large institutional network, unlocking additional yield generation opportunities for Aave.
  • GHO Adoption: Maple can help with growing other strategic priorities for Aave, including GHO adoption. Eg GHO lending to institutions.
  • Future Collaboration: Future asset listings, including the Maple liquid yielding Bitcoin asset.

Specification

ARFC updated 2025-07-16 with new parameters from Risk Service Providers.

Parameter Value
Isolation Mode No
Borrowable No
Collateral Enabled Yes
Supply Cap 50,000,000
Borrow Cap -
Debt Ceiling -
LTV 73%
LT 78%
Liquidation Bonus 6%
Liquidation Protocol Fee 10%
Variable Base -
Variable Slope1 -
Variable Slope2 -
Uoptimal -
Reserve Factor -

E-Mode

Parameter Value Value Value Value
Asset syrupUSDC USDC USDT USDS
Collateral Yes No No No
Borrowable No Yes Yes Yes
Max LTV 90.00% - - -
Liquidation Threshold 92.00% - - -
Liquidation Bonus 4.00% - - -
Ticker: syrupUSC

CAPO

maxYearlyRatioGrowthPercent ratioReferenceTime MINIMUM_SNAPSHOT_DELAY
19.94% monthly 7

Yield bearing token.

It’s a USDC based, yield bearing token whose principal and yield are backed by the secured lending strategy of Maple. (More details below).

Technical details: ERC-4626 token standard built on top of the Maple’s smart contracts.
High Yield. Maple has a track record of generating consistent high underlying yield of 7-15% net APY.

Loans are fully collateralised by digital assets ensuring lending positions are protected, even if borrowers default or asset prices fall. More on: Maple Finance.

Risk Parameters will be provided by Risk Services Providers at the earliest possible on ARFC stage and ARFC will be updated with that feedback.

Useful links:

Website: https://maple.finance/
App: Maple Finance

Disclosure

ACI (Aave Chan Initiative) is not affiliated with Maple Finance and has not received compensation for creating this proposal.

Next Steps

  1. Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage.
  2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.

Copyright

Copyright and related rights waived via CC0.

2 Likes

where is the link of standard ARFC?
needs to follow up, thx

Was there a Temp Check vote for this ARFC?

See it here [TEMP CHECK] Onboard syrupUSDC to Aave V3 Core Instance

Summary

LlamaRisk supports the onboarding of syrupUSDC to Aave V3. We recommend its addition as a collateral-only asset, with the primary use case foreseen being leveraged yield strategies through stablecoin looping. syrupUSDC is an ERC-4626 token representing a share in a revolving portfolio of over-collateralized loans to institutional borrowers. Its yield is generated from a dedicated loan book collateralized primarily by Bitcoin (~75%), Solana, and Ether.

Lenders have two primary exit mechanisms: instant on-chain redemption from a liquid stablecoin buffer of over $ 250M at writing, or a first-in-first-out (FIFO) queue serviced as underlying loans mature. This secondary market liquidity is the most critical factor for Aave’s risk management. The on-chain redemption buffer, while substantial, could be rapidly depleted during a broad market downturn or in the event of expected losses within the loan portfolio. In such a stressed scenario, redemptions would be queued, making secondary markets on DEXs the only viable path for immediate liquidation. Therefore, we strongly recommend that supply caps for syrupUSDC on Aave be sized conservatively, based on the available depth of this secondary market liquidity (combined ~$20M on Uniswap V4 and Balancer).

From a risk perspective, credit underwriting is now centralized under Maple’s in-house “Maple Direct” team. While this concentrates credit selection risk, no defaults have occurred under this new framework, which replaced the previous third-party delegate model. Lender protection is reinforced by a legal structure where assets are held in a Cayman Islands Segregated Portfolio Company (SPC), legally ring-fencing the syrupUSDC pool.

Key technological and governance risks remain. The protocol utilizes a fixed 1 USD price feed for USDC for its internal liquidations, which could lead to mispricings if USDC were to depeg. Furthermore, a powerful 4-of-7 multisig “Governor” holds broad administrative authority, including upgrading contracts without a mandatory timelock delay, representing a significant centralization risk.

See full analysis below

1. Asset Fundamental Characteristics

1.1 Asset

syrupUSDC functions economically as a tokenised note backed by a revolving, fully collateralised loan book. Holders have a pro-rata claim on a segregated pool of USDC receivables plus the excess digital-asset collateral that Maple underwriters require from borrowers, giving the instrument the character of a secured, pass-through credit product rather than a pure stable-coin wrapper. Yield is fixed-rate for each underlying loan but variable for the pool and is paid respectively in USDC or USDT; it accrues to the token’s share price, so lenders retain liquidity and can exit either by on-chain redemption (subject to a two-business-day processing window) or by swapping into spot USDC on supported AMMs. There is approximately $263M in recallable stablecoin liquidity. These balances constitute the liquid buffer. They are the first funds Maple draws on when lenders request on-chain redemptions, so “instant liquidity” is strictly capped by the buffer’s size. Once the buffer is exhausted, further withdrawal requests queue and are serviced gradually, in line with the cash-flow of the underlying loan portfolio (average tenor 30–90 days).


Source: Maple Finance, July 3rd, 2025

syrupUSDC sources its yield from a dedicated loan book with independent borrowers, entirely separate from Maple’s Blue-Chip Secured and High-Yield Secured pools. Over the past six months, this segregated exposure has generated a net annualised return in the 6–9% range, rather than the previously targeted 15%. Borrowers are subject to a stringent underwriting process that includes cash-flow analysis, collateral testing, and market-depth assessments. Borrowers pass a stringent underwriting process that screens cash-flow quality, tests collateral for market depth, price stability, and smart-contract soundness, and then sets terms calibrated to the borrower’s risk profile. About three-quarters of the collateral now posted is Bitcoin—split between native BTC and Liquid-wrapped BTC—while Solana contributes another 10 %. The balance comprises smaller allocations to Ether, liquid-staking tETH, LP_USR liquidity tokens, and USR stablecoins, giving the pool measured diversification without
sacrificing liquidity for potential liquidations.


Source: Maple Finance, June 20th, 2025

None of Aave’s existing listings exposes lenders to a ring-fenced, over-collateralised institutional loan book. syrupUSDC would therefore be the protocol’s first credit-backed asset whose collateral is segregated and custodied by regulated third parties. Its admission would set the technical and procedural benchmark for subsequent products such as syrupUSDT and the broader class of tokenised loan-portfolio tokens.

1.2 Architecture

When a lender deposits USDC through the front end, they call deposit() on the syrupUSDC Pool, which inherits ERC-4626 and therefore mints vault shares at the current price per share. The pool transfers fresh cash to its PoolManager, the cross-contract hub that sets liquidity caps, funds or refinances loans, and, where enabled, allocates idle balances to approved DeFi strategies. Each funded loan spins up a dedicated MapleLoan contract; accounting flows through a LoanManager that aggregates interest, service fees, and collateral ratios across the book.

Collateral that backs syrupUSDC is monitored 24 / 7 by an internal alert engine that pulls three independent price feeds. A fall to the pre-agreed Margin-Call Level triggers an automated top-up request; the borrower has 24 hours to restore the Initial Collateral Level. Any intraday slide to the Liquidation Level allows Maple to seize and liquidate immediately, preferentially through OTC desks to avoid slippage.

Exit involves a two-step queue. A lender submits a request that lands in the WithdrawalManager, which services requests strictly FIFO as cash returns to the pool; interest continues to accrue until settlement, and Maple reports that most queues clear in under 24 hours, although the docs warn it can take up to 30 days in a stressed scenario.

The collateral is kept in segregated wallets at regulated, institution-grade custodians such as Anchorage Digital, BitGo, and Zodia Custody; lenders can verify every wallet address on-chain.

Maple may employ the collateral to earn additional yield—staking liquid staking tokens that can be sold instantly, or native staking through specialized providers where unbonding periods apply—yet concentration limits and real-time dashboards show exactly how much of each asset is staked and under which provider, so lenders always know how quickly the position can be unwound if a margin event occurs.


Source: Maple Finance, July 2nd, 2025

The Maple’s app details tab offers a real-time, loan-level view of every syrupUSDC exposure—principal outstanding, fixed interest rate, collateral type, and current collateral ratio. Borrower admissibility follows the credit playbook outlined in Maple’s July 2024 paper “Yield Generation, Underwriting & Risk Management.” Each applicant undergoes KYB/AML screening, balance-sheet and cash-flow analysis, management interviews, and asset-specific collateral tests that assess market depth, historical volatility, and smart-contract risk. Maple’s risk team retains the resulting diligence files internally, and they are not published; only the headline loan terms and live collateral metrics are surfaced in the UI.

Loss Reflection in syrupUSDC

Losses in syrupUSDC are reflected directly in the token’s price via the internal exchange rate. If a borrower defaults and the loan cannot be fully recovered, the totalAssets decline, causing the syrupUSDC exchange rate to drop, effectively socializing the loss across all holders. No tranching or insurance fund exists, so all lenders bear equal exposure.

The protocol uses an unrealizedLosses accounting variable to prevent abuse during known loss events and maintains dual exchange rates when unrealized losses exist.

This prevents new depositors from exploiting “paper losses” by minting excess shares and profiting once the impairment is reversed. However, this also prevents LPs from withdrawing during default events due to a lowered exchange rate being used, effectively forcing the LP to wait until the defaults are covered and the original exchange rate is restored.

Risk mitigation includes overcollateralized loans, with immediate liquidation rights to lenders in default events. Additional recovery can be pursued via legal arbitration in the Cayman Islands, with the Maple Foundation acting as the enforcement agent. Also, Maple employs real-time price monitoring and automated margin calls. Collateral can be liquidated across DEXs, CEXs, or via market makers. The staked/locked assets have pre-arranged forward contracts for liquidity during forced sales.

1.3 Tokenomics

syrupUSDC has no fixed cap; the supply expands when USDC/USDT is deposited and contracts when redeemed and burned. Therefore, Economic value accrues through the vault’s share-price appreciation rather than scarcity. Because interest is paid in the base asset, syrupUSDC should converge toward a redemption value of one USDC/USDT plus accrued interest, subject to loan performance.

ERC-4626 vault funnels deposits into one or more “DeFi Strategies”. Each strategy pays a performance fee to the Maple Treasury every time its assets grow. strategyFeeRate is not hard-coded to a particular figure; Maple governance can change it through an admin call.

Since Origination, Service, and Management fees are skimmed before cash is recognised as “total assets” in the vault, syrupUSDC holders never sign or pay a separate fee transaction. Depositors face only normal network gas costs on deposit or withdrawal. The published net APY is therefore after:
• the strategy-layer performance fee,
• the pool-level management fee,
• all borrower-side origination and service fees, and
• Maple’s automatic provisioning of delegate cover and reserve buffers.

Maple charges no deposit, withdrawal, or spread fee; if a lender opts to exit by swapping syrupUSDC for USDC on a DEX, any price impact is purely market-driven, not a protocol fee.

On a separate note, the Drips programme distributes SYRUP tokens pro rata to syrupUSDC depositors (at a base rate of 1 Drip per 1 USDC per day). Rewards accrue continuously but unlock quarterly; unclaimed tokens revert to the treasury. Locking a deposit for up to six months grants a reward multiplier.

1.3.1 Token Holder Concentration


Source: syrupUSDC Top 100 Holders, Etherscan, June 30, 2025

The top 5 holders of syrupUSDC are:

Most syrupUSDC on Ethereum is actively utilized across various DeFi applications, indicating healthy protocol integration. Beyond these DeFi use cases, the top 10 holders collectively account for just 6% of the total supply, suggesting low concentration and reduced centralization risk.

2. Market Risk

2.1 Liquidity

Source: syrupUSDC/USDC Swap Liquidity, DeFiLlama, June 30, 2025

Users can swap 10.28M syrupUSDC worth up to $11.41M for USDC within a price impact of 7.5%.

2.1.1 Liquidity Venue Concentration

All syrupUSDC liquidity on Ethereum is concentrated on Uniswap V4 (via Arrakis vault) and Balancer.

Source: Uniswap, July 3rd, 2025

Source: Balancer, July 3rd, 2025

2.1.2 DEX LP Concentration

The primary Ethereum liquidity pool resides in a single Uniswap V4 pair seeded chiefly by a Maple-controlled wallet, creating venue and LP-concentration risk. Additional liquidity of $5M has been deployed in a Balancer V3 pool, but concentration risks remain significant.

2.2 Volatility

Source: syrupUSDC Market Price vs. Internal Exchange Rate, LlamaRisk, June 30, 2025

The internal exchange rate of syrupUSDC for withdrawals can be calculated as follows by the functions exposed by the contract.
image

The secondary market rate, i.e., the syrupUSDC-to-USDC conversion rate on the Uniswap V4 pool, closely tracks this internal rate under normal conditions. The largest deviation, approximately 0.61%, occurred on June 19, 2025. It is worth noting that the liquidity pool is only one month old, limiting the ability to perform a long-term trend analysis.

2.3 Exchanges

syrupUSDC is exclusively traded on DEXs and is not currently listed on any centralized exchange.

2.4 Growth

Source: syrupUSDC Ethereum Supply, Dune, June 30, 2025

syrupUSDC’s supply on Ethereum has increased by 1,300% YTD, rising from roughly 54M to 760M. Of this, 589M syrupUSDC is actively used in DeFi applications, reflecting a high utility rate of 78.74%.

3. Technological Risk

3.1 Smart Contract Risk

Twelve independent audit reports spanning five release cycles, carried out by four firms (Trail of Bits, Spearbit/Cantina, Three Sigma, and 0xMacro). Every critical or high-severity finding recorded in those reports was resolved before the relevant code went live, per Maple’s security page.

The most recent ones are:

3.2 Bug Bounty Program

There is a live bug bounty programme hosted on Immunefi with rewards up to USD 500,000 (10 % of affected funds) for critical smart-contract bugs.

All Maple V2 contracts—including Syrup-specific modules like SyrupRouter, SyrupRateProvider, pool proxies, and oracle wrappers are in scope.

3.3 Price Feed Risk

In the Maple protocol, most asset prices are sourced via oracle wrappers that relay getLatestPrice() from underlying Chainlink AggregatorV3 feeds. These wrappers also expose a gated setManualPrice() function, which the Security Admin multisig can invoke in case of a Chainlink outage.

Price oracle sets have been configured for three assets, with manual override functionality enabled only for USDC. However, for USDC, Maple uses a fixed price oracle hardcoded to 1 USD for on-chain collateral liquidations, rather than referencing a live market feed. This static pricing assumption introduces significant risk, particularly during depegging events.

While the team clarified that the fixed 1 USD price is used solely for liquidation, the risk remains material, particularly in recursive borrowing scenarios. In the event of a USDC depeg, relying on a static price during liquidation could result in mispriced auctions and potential bad debt. A live market feed like Chainlink’s USDC/USD oracle would offer a more robust and accurate mechanism.

Asset Price Oracle Max Delay Manual Override Price
WETH Chainlink ETH/USD 4 hrs N/A
WBTC Chainlink BTC/USD 4 hrs N/A
USDC UsdOracle, fixed 1 USD 0 hrs 1 USD

These oracle feeds are used in functions like getExpectedAmount() within the LoanManager, where accurate pricing is critical for determining auction parameters during collateral liquidations.

To price syrupUSDC for the Aave Ethereum market, Chainlink’s USDC/USD price feed can serve as the base, while the syrupUSDC internal exchange rate calculated as (totalAssets - unrealizedLosses)/totalSupply can be sourced directly from the token’s ERC20 contract.

3.4 Dependency Risk

Yield Sources

Maple Direct, the lending arm of Maple Finance, is responsible for underwriting, structuring, and managing loans originated through Maple pools accessed by Syrup. All loans generating yield for syrupUSDC and syrupUSDT are extended to creditworthy, crypto-native institutions that post liquid digital assets as collateral. Protocols such as Aave, Uniswap, Kamino, and SKY are also utilized as yield sources, making the security and reliability of these systems critical dependencies.

Loan Collateral

Beyond blue-chip assets like BTC and ETH, Maple has approved a broader range of assets as loan collateral. This selection undergoes a rigorous approval based on liquidity, historical volatility, and technical risk assessments. Maple’s team conducts thorough due diligence during this evaluation. However, the legitimacy and stability of the underlying project behind each asset remain key dependencies. While loans are overcollateralized and can be liquidated to protect lenders’ principal, collateral asset quality still plays a vital role in mitigating default risk.

Underwriting

Since 2024, Maple has retired the third-party “Pool Delegate” model and consolidated all origination under Maple Direct, an internal credit desk that conducts KYB, due diligence, collateral analysis, and loan negotiation in-house. Centralising underwriting removes the variability that previously existed between external delegates and has, to date, produced a clean track record—no credit losses or defaults have occurred on the over-collateralised loans originated by the Maple team. The earlier defaults at Orthogonal Trading ($36M) and Auros ($18M) were booked under legacy delegate pools and are not indicative of the current risk-management framework. While this shift improves underwriting consistency, it also concentrates credit-selection risk in a single organisational unit, making ongoing transparency into Maple’s internal credit process essential.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

The Maple Finance ecosystem involves several entities:

  • Maple Labs Pty Ltd operates the main platform interface and publishes the primary ToS for basic usage, wallets, and interface interactions.
  • Syrup Ltd, a separate offshore affiliate, issues and administers syrupUSDC and syrupUSDT products and their specific ToS.
  • Maple International Operations SPC (Cayman Islands Segregated Portfolio Company) is the legal counterparty for loan arrangements, pool administration, and prize draw campaigns.

Maple’s entities primarily provide software interfaces that facilitate decentralized, peer-to-pool lending by parties over the Maple Protocol. They act as the administrators of the web interface, not as direct custodians or intermediaries of funds.

All users (lenders and borrowers) must pass rigorous KYC checks. Lenders must be accredited investors under applicable rules. Borrowers must sign a Master Lending Agreement (MLA) before disbursing funds. The counterpart to the MLA from the Maple side is typically Maple International Operations SPC or another specified affiliated entity responsible for loan origination.

A Cayman Islands SPC allows a single legal entity to create multiple segregated portfolios (“SPs”), sometimes called “cells”. Each SP is legally distinct for purposes of assets and liabilities, but does not create separately registered companies. At Maple, each product or pool exists as a separate portfolio within Maple International Operations SPC. The assets, liabilities, and obligations of each portfolio are legally ring-fenced. Creditors of one portfolio (e.g., syrupUSDC) have no claim on the assets of another (e.g., syrupUSDT), nor do they have recourse against the general assets of the SPC beyond the relevant portfolio. This satisfies legal/regulatory requirements for isolating risks and assets between products and participant groups.

The Maple team has provided detailed responses to our due diligence questions, summarized as follows.

  1. MLA Key Legal Terms: MLA is designed to offer robust credit protection to lenders. It grants immediate collateral liquidation rights, full recourse to the borrower’s general assets for deficiencies, and streamlined enforcement through a dedicated Security Agent (Maple Foundation). Default triggers include payment failures, breaches of collateral requirements, failure to cure margin calls, covenant breaches, insolvency, and prohibited activities. Enforcement rights allow immediate loan acceleration, collateral liquidation without notice, and pursuit of deficiency claims via arbitration or litigation. The MLA is governed by Cayman Islands law and features comprehensive covenants and cross-default provisions.
    Using collateral to generate yield involves additional rehypothecation and counterparty risks, as protocol staking mechanisms or institutional staking providers temporarily control the collateral. In this regard, we gathered extra information on:
  2. Legal Title to Staked Collateral: Under the MLA, lenders receive legal title and a first-priority security interest in all collateral, including assets deployed for yield generation. Borrowers retain equitable title and are entitled to the return of the original collateral (in identical form) upon loan repayment. This structure enables lenders to utilize collateral in staking or yield strategies while safeguarding the borrower’s right to reclaim their assets at maturity.
  3. Rights and Recovery in Counterparty Failure: In the event of default, lenders have immediate rights to accelerate the loan, seize and liquidate collateral, and apply default interest. Lenders maintain a first-priority security interest, and each portfolio is ring-fenced from others. Recovery mechanisms include immediate collateral liquidation and full recourse to the borrower’s general assets, with enforcement managed by a Security Agent.
  4. Margin Calls & Liquidations: Maple employs a proprietary monitoring system for real-time price feeds and automated margin calls. Multiple liquidation channels are available, including market makers, centralized, and decentralized exchanges. Collateral is assessed for liquidity prior to acceptance, and for staked or locked assets, forward arrangements with trading desks are used to provide immediate liquidity and protect lender capital.

4.2 Access Control Risk

The Maple protocol is governed by a 4/7 multisig Governor contract controlled by the Maple team, its affiliates, and advisors, which holds broad administrative authority via the Governor role. This includes upgrading core contracts (e.g., Globals, Liquidator, Withdrawal Manager), managing global parameters, overseeing the MapleTreasury, and executing administrative functions on Pools and Loans. A secondary Operational Admin (a 3/5 Safe multisig) handles routine protocol actions with limited scope. Additionally, an Emergency Pause function called by the Governor or Security Admin (a 3/6 Safe multisig) allows the protocol to halt operations during critical incidents. These permissioned controls introduce centralized governance risk, as improper use or compromise of the multisig could impact protocol integrity, asset safety, or user access.

4.2.1 Contract Modification Options

syrupUSDC inherits Maple’s V2 architecture: every on-chain object (the token itself, its pool, the loan, withdrawal-manager, etc.) is a proxy that points to an implementation registered in a single MapleProxyFactory.

The Governor can:

  • upgrade any registered implementation (Globals, WithdrawalManager, Liquidator, etc.);
  • set or revoke global fee rates (platformManagementFeeRate, platformOriginationFeeRate, platformServiceFeeRate) —changes flow straight through to syrupUSDC pools;
  • list or delist valid collateral assets, pool assets, and price oracles;
  • alter the default timelock parameters (duration and “execution window”) that apply to every scheduled call;
  • pause or unpause individual contracts or functions, or trigger the protocol-wide emergency pause;

Because syrupUSDC is a proxy deployed by MapleProxyFactory, its implementation can also be swapped out by the Governor, subject to timelock restrictions.

Pool Delegates may:

  • schedule an upgrade() on their PoolManager, LoanManager, or WithdrawalManager;
  • schedule parameter changes (e.g., interest-rate slippage or min-ratio) that affect only their pool;

None of those calls can be executed until the timelock has fully elapsed.

All syrupUSDC instances are NonTransparentProxy contracts created by MapleProxyFactory. Thus benefiting from cheaper deploys, centrally version-controlled implementations and upgrades emitting an Upgrade event from the same factory address.

A new syrupUSDC version becomes usable only after Governor registers the implementation and sets it as the factory’s “default version”. Delegates may upgrade an individual pool’s syrupUSDC proxy only along an approved upgrade path whitelisted by the Governor.

4.2.2 Timelock Duration and Function

globalsV301 introduces no delay at defaultTimelockParameters.

4.2.3 Multisig Threshold / Signer Identity

Governor (0xd6d4Bcde6c816F17889f1Dd3000aF0261B03a196) is managed by a 4/7 multisig with the following signers:

  • 0x690A5aCa4E6c2f0c9880e582c2AA9913586e12BF;
  • 0x0f4430f1cEc6b976a9358EFfa95399EE8fc8BD40;
  • 0xF4b33586ee31DC6db89DA7Fb64b853E99F984B7F;
  • 0xd9c66fc2b01Bb6d72e8884d2AA1e2DDA2995ecD6;
  • 0x96481CB0fCd7673254eBccC42DcE9B92da10ea04;
  • 0x04eBB8201BC767BD96932D33b12BD2EaA661E918;
  • 0x588C6eb6E68F3Cb03243835c1c67864C84dF85bD]]

Maple indicates that a minority of the signers are employees/Maple team affiliates; the majority are long-standing external advisors and investors who have held their seats for over two years.

Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Aave V3 Specific Parameters

Will be presented jointly with @ChaosLabs.

Price feed Recommendation

We recommend pricing syrupUSDC on Aave using Maple’s syrupUSDC/USDC internal exchange rate defined as (totalAssets - unrealizedLosses)/totalSupply in combination with Chainlink’s USDC/USD feed and CAPO adapter. The configuration details will be shared in coordination with @ChaosLabs.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

2 Likes

Overview

Chaos Labs supports listing syrupUSDC on Aave V3’s Ethereum Core instance. Below is our analysis and risk parameter recommendations for the initial listing.

Protocol Overview

SyrupUSDC is Maple Finance’s liquid yielding dollar, a yield‑bearing stablecoin representing USDC deposits in Maple’s lending protocol. Depositors mint syrupUSDC by supplying USDC into Maple’s Syrup pool and receive an amount of syrupUSDC tokens according to the asset’s exchange rate. These tokens continuously accrue interest generated from Maple’s fixed‑rate, over‑collateralized loans to institutional borrowers. SyrupUSDC functions as an ERC‑4626 vault token representing a claim on the pool’s underlying USDC plus earned yield.

A delegate‑level management fee and a protocol fee are extracted from interest, and the pool can enforce a liquidity cap. There are no direct mint or redeem fees, and the pool is open access.

Maple Direct is the lending arm of Maple Finance, which conducts financial due diligence and agrees to terms with borrowers off chain. Maple Direct also manages the loan book, with a variety of alert and monitoring systems in place to promptly conduct margin calls and liquidations, discussed in more detail below.

Technical Implementation

The syrupUSDC token is implemented by an immutable MaplePool contract which stores the underlying asset address and a reference to a dedicated PoolManager. The PoolManager deploys liquidity into loans via LoanManager modules and coordinates withdrawals through a WithdrawalManager queue. MaplePool grants the manager an unlimited USDC allowance so that loan funding and withdrawal processing can transfer funds without additional approvals. Access control for every external call runs through the manager’s canCall hook, centralizing permission logic (liquidity cap checks, pause states, allowlist controls). All state‑mutating functions in MaplePool are made non‑reentrant.

Total pool value is tracked by the PoolManager as cash plus loan receivables minus unrealized losses. MaplePool’s totalAssets() simply forwards this value. Yield accrues by increasing the exchange rate between shares and assets; token balances themselves do not rebase. Two conversion rates exist: one for deposits (ignores unrealized losses) and one for withdrawals (deducts unrealized losses), preventing timing games around defaults. There are no unrealized losses in the pool, and thus the two values are currently equal. Interest payments arriving from loans first route delegate and protocol fees to their recipients, with the remainder raising totalAssets.

Additionally, when depositing, users are given the option to deposit USDC with no time commitment, a 3-month lockup (earning 1.5x Drips, Maple’s incentives), or a 6-month lockup (earning 3x Drips).

Mint and Redeem Mechanics

Minting

  1. A user calls either deposit(assets, receiver) or mint(shares, receiver).
  2. The manager confirms deposits are allowed, the liquidity cap is respected, and the pool is not paused.
  3. MaplePool calculates the shares to mint from the current deposit exchange rate, performs the bootstrap‑mint safeguard if the pool was empty, mints the shares, and transfers in USDC from the sender.
  4. The user receives syrupUSDC immediately; no lockup or fee applies.

Queued withdrawal

  1. The user callsrequestRedeem(shares, owner) to enter the queue.
  2. The specified shares move to the WithdrawalManager escrow while continuing to earn yield.
  3. The PoolManager services queued requests FIFO whenever liquidity becomes available from loan repayments and new deposits, or uses liquidity from strategies like Aave or Sky, calling redeem on behalf of the escrow to deliver USDC to the user.
  4. Users may cancel a pending request via removeShares(shares, owner) if it has not been processed.

There is no fixed cooldown beyond the queue wait time; users can also trade syrupUSDC on secondary markets for immediate liquidity.

In practice, the vast majority of redemptions are completed in under one hour, as the chart below illustrates. The blue line indicates the aggregate value of redemptions that have been completed as hours elapsed increases, while the color of the individual redemptions indicates when they were processed — red indicates it was early in syrupUSDC’s history, green indicates it was a recent redemption.

Displayed another way, with average redemption time (weighted by size of redemption) plotted over time, it is clear that syrupUSDC’s redemption time has improved significantly in recent weeks.

This faster redemption time has coincided with rapid new deposits, leading to a lower overall utilization of the pool, providing significantly more liquidity available for rapid withdrawals.

Security Features

The pool’s loans are over‑collateralized, and a PoolDelegateCover theoretically supplies a first‑loss buffer. However, as stated in the documentation, the PoolDelegateCover is currently unused, as Maple Direct manages most pools and ensures collateralization levels.

MaplePool itself is immutable; PoolManager and supporting modules are upgradeable through time-locked, governed proxies. MapleDAO can invoke emergency pauses or parameter changes, while Pool Delegates manage individual pools under protocol‑level limits. Reentrancy guards, hardened token‑transfer helpers, and a one‑time bootstrap mint mitigate common smart‑contract attacks; the design has undergone multiple third‑party audits.

Underlying Assets

Collateral backing USDC and USDT loans on Maple currently total $957M, with $596M of stablecoins borrowed; this results in an overall collateralization ratio of 160% ($957M collateral supply/$596M borrowed). BTC represents the vast majority of collateral assets within the pool. Maple’s dashboard provides details on the loans provided and collateral wallets.


app.maple.finance/earn/details

Overall, BTC represents the vast majority of collateral on the book, followed by SOL. As expected, the average collateralization ratio for each collateral asset differs, with SOL’s slightly higher than BTC’s, while stablecoins have the lowest.

There is an additional $307M deposited across DeFi protocols, primarily SKY ($267M USDC), with additional deposits in liquidity pools and $2.67M USDT supplied on Aave.

Loan Contracts

Maple loans are instantiated as minimal proxy contracts created through the FixedTermLoanFactory or OpenTermLoanFactory (at this time there are only open term loans for syrupUSDC). Fixed Term loans, would set a defined date by which the loan must be repaid, whereas Open Term loans can be maintained in perpetuity.

At origination, the borrower provides core terms, including principal amount, interest rate, payment interval, and fee rates, which the factory records and then deploys a new proxy.

Funding occurs when the LoanManager calls fundLoan (fixed‑term) or fund (open‑term); this pulls USDC from the MaplePool into the loan contract and immediately transfers the proceeds to the borrower’s wallet via drawdownFunds. Once funded, the loan tracks state variables such as principal, interestRate, paymentInterval, andnextPaymentDueDate .

Repayments are made through makePayment: the borrower supplies USDC equal to scheduled principal plus interest. The function allocates the payment across principal, interest, and fees, updates principal and paymentsRemaining, and emits accounting events. If the borrower pays late, lateFeeRate and lateInterestPremiumRate automatically increase the owed amount from the original due date until payment.

Both fixed‑ and open‑term variants permit refinancing via proposeNewTerms/acceptNewTerms, enabling updated rates or schedules without deploying a new contract. Each loan proxy can be upgraded through migrate if Maple governance approves a new implementation, but critical economic parameters remain immutable after funding to protect both parties.

Liquidations and Principal Calls

When a loan fails to meet the designated payment due date, the borrower is notified and has a predetermined amount of time (referred to as the “grace period”, plotted below), generally 48 hours, to perform the payment, together with an incurred late payment fee. In the case in which the borrower does not meet the late payment within the grace period, and Maple Direct holds the belief that the borrower is insolvent, the Pool Delegate can liquidate the underlying collateral and repay the loan. In the unlikely case in which the collateral is not sufficient to cover the entirety of the debt, the Pool Delegate will call impairLoan (fixed‑term) or impair (open‑term) to initiate a default and the unrealizedLosses variable would be updated to reflect the lack of collateral.

Additionally, every loan agreement defines a margin call and a liquidation level. At the reach of the first level, the delegate will issue a margin call to the borrowers, requiring them to provide additional collateral or repay the loan within 12-24 hours from the notice.

Critically, suppose price moves cause LTV to reach the liquidation level. In that case, the delegate has the contractual right to bypass notice times and initiate an off-chain liquidation through market-maker agreements. In the case in which the collateral recovered is not sufficient to cover the entire debt, the Pool Delegate will once more use the proceeds to partially repay the loans and initiate an impairment on the remaining shortfalls, which would be reflected in unrealizedLosses.

This immediate liquidation provides an important backstop and prevents a scenario in which large price declines over 12-24 hours cause a position to accrue bad debt following a margin call.

Only one partial liquidation has been performed as of today of a BTC-backed loan; however, there have been no losses to syrupUSDC. The team has occasionally published reports after high volatility events, providing details on margin calls and liquidations; after mass liquidations on February 2, 2025, 35% of loans in the Syrup pool received margin calls and all margin-called borrowers supplied additional collateral to avoid liquidation.

Additionally, open‑term loans support callPrincipal, letting the delegate demand partial repayment by a notice deadline. The amount of time a borrower has to repay their position after a call is dictated by the “notice period”; this value is set to 30 days or longer, however, it can be set to be as short as 2 days.

Unrealized Losses

As long as a loan is current and not impaired, the manager records no unrealized loss. When an impairment event occurs, either because a repayment deadline is missed after its grace period or because a margin call triggers liquidation, Maple first liquidates the posted collateral and applies the sale proceeds directly to the outstanding balance. Only the residual principal (including any accrued interest) that remains after this partial repayment is recognised as a shortfall and booked to unrealizedLosses. In other words, unrealizedLosses equals the difference between the original debt and the realised collateral proceeds, not the full notional of the loan.

After impairment, Maple seeks voluntary repayment from the borrower. If the borrower covers the shortfall unrealizedLosses is reversed in full, and the two exchange-rate paths (convertToAssets and convertToExitAssets) reconverge.

Failing swift settlement, Maple initiates formal legal recovery, a process that can span several months. In this instance the losses get realized and the two exchanges align to the lowest value between the two. Any recovery obtained later is injected back into the pool and offset the realised loss retroactively.

Because unrealizedLosses is calculated only on the net deficit after collateral realisation, it provides a close approximation of potentially unbacked exposure to the borrower. Nevertheless, during the legal-recovery phase, the variable can still overstate final losses if subsequent recoveries are expected, so its inclusion in external risk metrics such as Aave’s convertToExitAssets versus convertToAssets still warrants caution.

Comparison to Aave

The chart below displays USDC borrow rates on Aave V3 Ethereum Core, with dots overlayed representing newly initialized loans on Maple (size corresponds to principal amount).

The fixed rate dynamic of Maple carries with it a relatively significant premium, in which borrowers are routinely paying roughly double USDC’s borrow on Aave. This premium is likely caused by a combination of the borrower’s legal bounds, which impair them from accessing DeFi lending markets such as Aave, or the inability to wrap native assets. The collateralization levels of loans are similar to Aave; the lowest BTC-collateralized loan on Maple currently stands at an LTV of just under 77%, below Aave’s LT of 78%.

Market Cap and Liquidity

syrupUSDC’s supply has surged in recent months and is currently approaching 800M. There is an additional 58M on Solana.

The asset’s on-chain liquidity has been somewhat limited and volatile, though it recently improved significantly with the funding of a new Uniswap V4 pool.

The asset’s on-chain liquidity is sufficient to support a listing, especially when considering its rapid redemption time. This timeliness has also helped support the asset’s on-chain market price, which has displayed no significant and persistent depegs from the asset’s exchange rate.

Risks

The primary economic risk associated with syrupUSDC is that redemptions in a short period of time exceed the amount of relatively liquid assets held as underlying (such as deposits in Aave and Sky), currently just under $300M when excluding DEX liquidity pools containing syrupUSDC and USDC. In this event, Maple would be required to facilitate redemptions by calling principal, in essence notifying borrowers that their otherwise healthy positions will be closed. In this hypothetical event, Maple would have access to significant liquidity after 30 days, and likely much sooner, when borrowers either repay their position or are closed out.

Parameter Recommendations

Liquidation Threshold and Bonus

The asset’s strong peg, robust controls, and over-collateralization indicate that it is appropriate to list the asset with a relatively high LT. However, taking into account that it yield-bearing stablecoin, and thus will primarily be used as collateral for other stablecoins, we recommend limiting its general LT, while selectively creating E-Modes that allow for this use case. Outside of E-Mode, we recommend a 78% LT and 6% LB.

E-Mode

We recommend listing the asset in an E-Mode with major stablecoins, allowing for users to efficiently leverage the asset and generate yield. The parameters for this E-Mode are provided below and are determined using syrupUSDC’s observed deviations from its exchange rate.

Supply and Borrow Cap

Taking into account the on-chain distribution of syrupUSDC liquidity, we recommend listing with an initial supply cap of 50M. Additionally, given the asset’s characteristics, we do not recommend allowing the asset to be borrowed.

Oracle Implementation

We recommend utilizing the USDC/USD oracle, augmented with the convertToExitAssets value in syrupUSDC’s contract. In the event of any practical deficit observed within any of the debt positions on Maple post-liquidation, this exchange rate will be altered to account for the underlying shortfall. This will additionally be protected using CAPO, with parameters provided below.

However, while convertToExitAssets does accurately represent the deficit of the syrupUSDC pool, the liquidation process may lead the market price of syrupUSDC to effectively anticipate the loss. This could lead to users speculating on the future loss by taking loans against syrupUSDC collateral prior to the exchange rate update. While an unlikely situation, given the distribution of collateral assets within Maple’s protocol, this poses a risk of bad debt.

Hence, moving forward, we aim to work in parallel with Maple in an effort to obtain relevant information about the state of the collateralized debt positions residing on the balance sheet and react accordingly in the context of risk parameterization.

Specification

Parameter Value
Isolation Mode No
Borrowable No
Collateral Enabled Yes
Supply Cap 50,000,000
Borrow Cap -
Debt Ceiling -
LTV 73%
LT 78%
Liquidation Bonus 6%
Liquidation Protocol Fee 10%
Variable Base -
Variable Slope1 -
Variable Slope2 -
Uoptimal -
Reserve Factor -

E-Mode

Parameter Value Value Value Value
Asset syrupUSDC USDC USDT USDS
Collateral Yes No No No
Borrowable No Yes Yes Yes
Max LTV 90.00% - - -
Liquidation Threshold 92.00% - - -
Liquidation Bonus 4.00% - - -

CAPO

maxYearlyRatioGrowthPercent ratioReferenceTime MINIMUM_SNAPSHOT_DELAY
19.94% monthly 7

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this recommendation.

Copyright

Copyright and related rights waived via CC0

2 Likes

For visibility, we believe the case of syrupUSDC is precisely the type of asset whose category/type should be evaluated and included in an allowlist before proceeding with a full analysis for onboarding by all service providers.


To be more precise in what concerns the technical and security analysis, to be up to our standards of quality, analysing syrupUSDC for onboarding is equivalent to analysing the whole Maple protocol behind the asset, together with the strategies of re-supplying collateral (whenever applicable) into other protocols (e.g. SKY, which factually is considered up to standards on Aave, but others simply not evaluated like Kamino).

Even if we are willing to do that if the community decides to include the category in the allowlist, this will have very major consequences (delay) on all of our other areas of contribution: the resources spent to evaluate fully another lending protocol, together with setting up ad-hoc internal procedures, not only for us, but for all other service providers involved, like risk.

Finally, we think that adding this type of asset will create a very major precedent on assets partially based on hypotecation being onboarded to Aave, consequently adding tail risk to the Aave protocol. So high-level, we will be against adding this asset category to the allowlist.

Given that the AAcA (Aave Asset class Allowlist) is currently a work-in-progress and the interest of the community in getting our technical analysis on the asset, we present it to the community.


syrupUSDC technical analysis


Summary


This is a technical analysis of all the smart contracts of the syrupUSDC asset and its main dependencies.


Disclosure: This is not an exhaustive security review of the asset, as performed by the Maple Team, but rather an analysis from an Aave technical service provider on various aspects we consider critical to review before a new type of listing.
Consequently, like with any security review, this is not an absolute statement about whether the asset is flawless/not. Only our opinion in what concerns problems with is integration with Aave and/or additional technical risks.



Analysis

The syrupUSDC is a yield-bearing, strategy-based asset that primarily generates yield through the allocation of funds to the Maple Lending Protocol. Additionally, it earns variable yields by deploying funds across various DeFi protocols. Users can deposit USDC to receive syrupUSDC, which accrues a fixed yield from these strategies. Institutional loans can access liquidity after passing Maple’s KYC requirements.


For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

  • Mechanism to update the exchange rate of the asset for the underlying, in this case, USDC.
  • A recommendation of pricing strategy to be used in the integration asset <> Aave.
  • Any miscellaneous aspect of the code we can consider important.
  • Analysis of the access control (ownerships, admin roles) and the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:

Criticality Description
CRITICAL Usually super-admin functionality: it can compromise the system by completely changing its fundamentals, leading to loss of funds if misused or exploited. E.g. proxy admin, default admin
HIGH It can control several parts of the system with some risk of losing funds. E.g., general owners or admin roles involved in the flow of funds
MEDIUM It can cause malfunction and/or minor financial losses if misused or exploited. E.g., fee setter, fee recipient addresses
LOW It can cause system malfunctions but on non-critical parts without meaningful/direct financial losses. E.g., updating descriptions or certain non-critical parameters.

Risk Description
:green_circle: The role is controlled via a mechanism we consider safe, such as on-chain governance, a timelock contract, or setups involving multi-sigs under certain circumstances.
:yellow_circle: The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
:red_circle: The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

  • The system is divided into upgradable and non-upgradable contracts.
  • For proxies, the system uses the Proxy standard from the MapleProxyFactory.
  • The MapleProxyFactory is governed by the Maple Governor, a 4-of-7 multisig held by founders and partners of the protocol.

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with syrupUSDC.


syrupUSDC

The so-called syrupUSDC is the system’s core contract, implementing the ERC4626 standard that allows users to exchange USDC for the yield-bearing syrupUSDC token. It is a non-upgradable contract that has all permission operations controlled by the PoolManager.

  • Access Control
    • All functions in syrupUSDC are validated against the PoolManager.canCall() method, which evaluates whether the operations can be performed.
  • Deposits and Redemptions
    • Users can deposit USDC and receive syrupUSDC by calling the deposit(assets) function. Internally it calculates the amount of shares via previewDeposit(assets) getter. Alternatively, users can call the mint(shares) or use the depositWithPermit and mintWithPermit.
    • Users can initiate a redemption via the requestRedeem(shares) function. The shares will then be moved to the WithdrawalManagerQueue contract by the PoolManager via the WithdrawalManagerQueue.addShares(shares, owner) that creates the request into a FIFO queue.
    • After creating the request and the conditions are met (e.g, enough time has passed for users who locked their shares), the user can call the redeem(shares), which will invoke the Pool Manager and WithdrawalManagerQueue to calculate the amount of assets via the internal _calculateRedemption() method in the WithdrawalManagerQueue.
    • Users can cancel the request via the removeShares(amount) function and reclaim their syrupUSDC shares.
  • Exchange Rate
    • The system utilizes two distinct exchange rates: one for processing new deposits and the other for finalizing redemptions.
      • The deposit exchange rate relies on the previewDeposit(assets), which is calculated using the standard pattern of ERC4626 shares * totalSupply() / totalAssets(). The totalAssets() is fetched from PoolManager.totalAssets(), which returns the number of USDC held by the pool via USDC.balanceOf(syrupUSDC) plus the sum of USDC managed by all syrupUSDC strategies.
      • The redemption exchange rate is calculated in the internal _calculateRedemption(sharesToRedeem) getter of the WithdrawalManagerQueue contract using the formula totalAssetsWithLosses * sharesToRedeem / totalSupply(). The totalAssetsWithLosses variable is the totalAssets() minus the sum of unrealized losses by all syrupUSDC strategies.
      • The _calculateRedemption() also also verifies the availableLiquidity in the pool via USDC.balanceOf(syrupUSDC) , and if not enough liquidity, the final redemption amount will be adjusted and calculated as availableLiquidity * sharesToRedeem / totalSupply().
      • It is important to mention that the system utilizes asset.balanceOf(pool) as part of its accounting, which may result in donations of USDC to the system, potentially manipulating the exchange rate.

PoolManager

The Pool Manager is a master contract and core admin of the system. It holds the assets’ accounting of the pool and the admin functions to configure the system. It is an upgradable Proxy contract.

Permission Owner functions Criticality Risk
PoolDelegate - MPC (call time-locked) upgrade CRITICAL :green_circle:
SecurityAdmin - Safe 3-of-6 upgrade CRITICAL :yellow_circle:
factory (time-locked) setImplementation, migrate CRITICAL :green_circle:
ProtocolAdmins: Governor, PoolDelegate, OperationalAdmin (Safe 3-of-5) setPendingPoolDelegate, setIsStrategy, finishCollateralLiquidation, triggerDefault, addStrategy, setDelegateManagementFeeRate, setLiquidityCap, setPoolPermissionManager CRITICAL :yellow_circle:
PoolDelegate - MPC: Syrup Deployer withdrawCover HIGH :green_circle:
syrupUSDC requestRedeem, processRedeem, removeShares, HIGH :green_circle:
Strategies requestFunds HIGH :green_circle:

  • Access Control
    • ProtocolAdmins
      • A New pool delegate (which is a strategy manager and funds allocator of the system) can be set in a two-step process via the setPendingPoolDelegate(address) function. To finalize, the new delegate must confirm the transfer by calling the acceptPoolDelegate() function.
      • The pool permission manager contract can be set via the setPoolPermissionManager(address). Internally, it verifies if the contract is an of Maple’s contracts.
      • A strategy can be created via the addStrategy(address strategyFactory, bytes extraDeploymentData) function. It verifies if the strategyFactory is an instance of Maple contracts and calls strategyFactory.createInstance(extraDeploymentData), which deploys the new strategy contract. It finishes by enabling the isStrategy mapping and adding to the strategyList.
      • Strategies can be toggled as valid via the setIsStrategy(strategy, isStrategy) function It requires that the strategy address was previously included in the StrategyList.
      • Liquidations can be executed against the borrower’s collateral in the event of non-compliance with payment obligations within the specified period via the triggerDefault(address loan, address liquidatorFactory)method.
        Internally, it gets the lender contract via the loan address and calls the lender.triggerDefault(loan, liquidatorFactory) which returns whether the liquidation is finalized, the total losses, and the platform fees. If the liquidation is finalized, it triggers the internal handleCover(losses, fees) function, which calculates the amount that the PoolDelegateCover can pay as fees to the treasury and the losses to the pool. Otherwise, the Admin or delegate must call finishCollateralLiquidation(address loan).
        It is important to note that liquidations are only applied to strategies that allocate funds to the Maple Lending Protocol, not to DeFi strategies.
      • A liquidation that is not finalized can be terminated by calling the function finishCollateralLiquidation(address loan). Internally, it gets the lender contract via the loan address and calls lender.finishCollateralLiquidation(loan) which returns the total losses and the platform fees. It finishes by calling the internal handleCover(losses, fees).
      • The liquidity cap is configured via the setLiquidityCap(amount) method.
      • The delegate fee management can be set via the setDelegateManagementFeeRate(fee) method.
    • PoolDelegate
      • The funds from a liquidation (known as the cover amount ) can be withdrawn from the PoolDelegateCover and sent to an arbitrary address via the withdrawCover(amount, recipient) function. It invokes the PoolDelegateCover.moveFunds(amount, recipient) and ensures the PoolDelegateCover balance doesn’t fall below the minimum set for the PoolManager contract. Currently, the minimum is set to zero.
      • It is important to highlight that The Pool Delegate Cover is not actively in use across the protocol.
    • Pool
      • The requestRedeem(), processRedeem(), and removeShares() functions are initiated by users via the syrupUSDC Pool and forwarded to the WithdrawalManagerQueue.
  • Fund Strategies
    • Strategies can request funds from the pool via the requestFunds(address destination, amount) function. The call must be initiated by a valid strategy instance of Maple contracts and registered in the Pool Manager. This function also ensures, internally, that the pool balance doesn’t fall below the liquidity reserved for withdrawals.

PoolDelegateCover

The PoolDelegateCover is a contract that facilitates funds transfer and is the recipient of funds from liquidations. It’s a non-upgradable contract.

It is important to mention that the team has confirmed that the Pool Delegate Cover is not actively in use across the protocol. Maple previously supported external Pool Delegates to align economically with lenders.

  • Access Control
    • The PoolManager can transfer funds from this contract to any address via the moveFunds(amount, recipient) function.

WithdrawalManagerQueue

This contract allows users to submit withdrawal requests and holds custody of their shares until the request is processed. Once the withdrawal request is processed the shares in custody will be exchanged for assets using the current exchange rate and then transferred to the owner of the shares.

Permission Owner functions Criticality Risk
PoolDelegate - MPC (call time-locked) upgrade CRITICAL :green_circle:
SecurityAdmin - Safe 3-of-6 upgrade CRITICAL :yellow_circle:
factory setImplementation, migrate CRITICAL :yellow_circle:
Redeemers: PoolDelegate, Governor, OperationalAdmin (Safe 3-of-5) processRedemptions HIGH :green_circle:
ProtocolAdmins: PoolDelegate, Governor, OperationalAdmin (Safe 3-of-5) removeRequest, setManualWithdrawal HIGH :yellow_circle:
PoolManager addShares, processExit, removeShares HIGH :green_circle:

  • Access Control
    • Redeemers
      • The processRedemptions(shares) function finalizes the max number of redemption requests possible given the amount of shares. It calls the internal calculateRedemption(shares) function to obtain the redeemable shares amount and iterates through the maximum requests that the redeemable shares can support. Every request is processed via the internal _processRequest(requestId, amount) function, which checks whether the user opted to manually withdraw later via the redeem() function in the Pool contract or to automatically receive the underlying asset.
    • ProtocolAdmins or PoolDelegate
      • A redemption request from any user can be cancelled via the removeRequest(user) function. The shares are sent back to the user, and the request is deleted.
      • The manual withdrawal can be toggled from any user request via the setManualWithdrawal(user, isManual) function.
    • PoolManager
      • During the redemption request by a user in the Pool, the PoolManager takes the user shares and transfers them to the WithdrawalManager contract via the addShares(shares, owner) method, which creates the request in the queue.
      • When the user finalizes the redemption in the Pool, the PoolManager calls the processExit(shares, owner) to calculate the correct amount of shares that the user will receive.
      • If a user cancels their redemption request in the Pool, the PoolManager forwards it by calling the removeShares(amount, owner) function, which decreases the shares or deletes the request completely, depending on the amount. Then, it finalizes by transferring the syrupUSDC shares back to the owner.

Strategies

SyrupUSDC employs various strategies to generate yield for its lenders. There are two main strategies:

  • Loan Managers, who act as the principal yield source for the protocol, operate with fixed and open terms.
  • DeFi Strategies (for example, Aave and Sky) serve as a secondary yield source for the protocol, used to park funds that will be later utilized by Loan Managers or to fulfill withdrawal requests.

LoanManagers

The Loan Managers (Open and Fixed) are responsible for interacting with and managing their specific loan types on behalf of the Pool Manager, meaning they handle the flow of funds and, most importantly, provide the total assets under management to the Pool Manager’s account. They’re upgradable Proxy contracts.

Permission Owner functions Criticality Risk
PoolDelegate - MPC (call time-locked) upgrade CRITICAL :green_circle:
SecurityAdmin - Safe 3-of-6 upgrade CRITICAL :yellow_circle:
factory setImplementation, migrate CRITICAL :yellow_circle:
PoolDelegate - MPC: Syrup Deployer fund, proposeNewTerms, rejectNewTerms, acceptNewTerms HIGH :yellow_circle:*
PoolDelegate or Governor setAllowedSlippage, impairLoan HIGH :yellow_circle:
Governor removeLoanImpairment HIGH :yellow_circle:
PoolManager triggerDefault, finishCollateralLiquidation HIGH :green_circle:

  • It is outside of the scope of this analysis to evaluate the lending protocol/overcollateralization dynamics (e.g., lending terms), so there can be additional risk.
  • Access Control
    • Pool Delegate
      • Assets are borrowed from the pool via the fund(address loan). This function gets the funds via poolManager.requestFunds(loanManager, amount) and for Open-Term loans are pulled by the loan contract via the loan.fund() method, while for the Fixed-term, the assets are transferred directly to the loan contract.
      • New terms between the Borrower and Lender can be changed via the proposeNewTerms() function. This function allows to change the principal amount borrowed, periods, interest rate, and collateral required. For Open-Term loans, the new terms are proposed by the Lender and accepted via the claim() method. For Fixed-term loans, they are proposed by the borrower and accepted by the Lender (PoolDelegate) via the acceptNewTerms() method, and later the borrower can call the claim() method.
      • For the Fixed-Term loans, the new terms can be rejected by the Lender via the rejectNewTerms() function.
    • PoolDelegate or Governor
      • For Fixed-Term loans, the maximum slippage to liquidate the collateral asset can be set via the setAllowedSlippage(slippage) function.
      • When the borrower is unable to repay the loan, the PoolDelegate or the Governor can call the impairLoan() function, which allows the totalAssets() to account for the assetsUnderManagement() as unrealizedLosses() . This has a direct effect on the exchange rate syrupUSDC.
      • Only the Governor can remove a loan from an impaired state by calling the removeLoanImpairment() function.
    • PoolManager
      • When borrowers fail to repay their loans on the defined date, following a grace period, the PoolManager can liquidate the collateral via the triggerDefault() method. The totalAssets() will be adjusted accordingly to reflect the recovered assets from the liquidation.

DeFi Strategies

Inheriting the base functionality from the MapleAbstractStrategyContract, each strategy contains the logic to interact with a specific DeFi protocol. The strategy has 3 different states: Active, Inactive and Impaired (when it’s not possible to withdraw funds from the DeFi protocol). It’s an upgradable Proxy contract.

Permission Owner functions Criticality Risk
PoolDelegate - MPC (call time-locked) upgrade CRITICAL :green_circle:
SecurityAdmin - Safe 3-of-6 upgrade CRITICAL :yellow_circle:
factory setImplementation, migrate CRITICAL :yellow_circle:
StrategyManager: PoolDelegate - MPC: Syrup Deployer fundStrategy, withdrawFromStrategy HIGH :yellow_circle:*
ProtocolAdmins: PoolDelegate - MPC: Syrup Deployer, Governor, OperationalAdmin (Safe 3-of-5) deactivateStrategy, impairStrategy, reactivateStrategy, setStrategyFeeRate HIGH :red_circle:

  • It is outside of the scope of this analysis to evaluate the lending protocol/overcollateralization dynamics (e.g., lending terms), so there can be additional risk.

  • Access Control
    • StrategyManager
      • Assets are deposited into the specific DeFi Strategy via the fundStrategy(amount) method. This function gets funds via the poolManager.requestFunds(strategy, amount) and then interacts with the DeFi protocol by depositing funds (e.g, supply on Aave).
      • Later, assets can be withdrawn via the withdrawFromStrategy(amount) function. A fee is charged on the yield accrued during the period the strategy was active and sent to the treasury. The amount is then sent directly to the pool.
    • ProtocolAdmins
      • A fee Rate can be set via the setStrategyFeeRate(fee) method.
      • The strategy’s state via the deactivateStrategy(), reactivateStrategy(), and impairStrategy() methods. It is important to mention that the strategy’s state directly affects the totalAssets() used for redemptions, where:
        • Active state increases totalAssets() with the strategy’s assetsUnderManagement().
        • Impaired state decreases totalAssets() with the strategy’s assetsUnderManagement() as unrealizedLosses()
        • Inactive state returns zero;

MapleProxyFactory

The MapleProxyFactory is a generic Beacon Proxy Factory contract that handles the deployment of the system’s upgradable contracts, such as PoolManager, Strategies, and WithdrawalManagerQueue. Since the factory is contract-specific, it holds a default implementation that is used by the new proxy when no implementation is provided. Upgrades are triggered in the instance by the SecurityAdmin or PoolDelegate. It is a non-upgradable contract controlled by the Governor’s multisig.


Permission Owner functions Criticality Risk
Governor createInstance, enableUpgradePath, disableUpgradePath, registerImplementation, setDefaultVersion CRITICAL :yellow_circle:

  • Access Control
    • New Proxy contracts can be deployed via the createInstance(bytes arguments, bytes32 salt). Internally, it deploys the Proxy using create2, validates the implementation version, and finalizes by initializing the contract with the input arguments.
    • Upgrades are made in a 3-step process:
      • First, the implementation contract and its version and its initializer contract must be registered in the factory storage via the registerImplementation(uint256 version, address implementation, address initializer).
      • The Governor must authorize the upgrade from the current version to the new version and whether needs a migrator contract via the enableUpgradePath(uint256 fromVersion, uint256 toVersion, address migrator). It can also be cancelled via the disableUpgradePath(uint256 fromVersion, uint256 toVersion).
      • Finally, it is upgraded via the upgradeInstance(uint256 toVersion, bytes calldata arguments), which is called from the instance contract by the Pool Delegate (scheduled calls) or by the SecurityAdmin (instant upgrade). Internally, it verifies whether the upgrade was authorized and queries the toVersion implementation. Then, it calls proxy.setImplementation(implementation), and it migrates whether the migrator and arguments were provided via the proxy.migrate(migrator, arguments).
      • For upgrades invoked by the PoolDelegate, an additional timelock validation is checked in the proxy.setImplementation(implementation) function, which checks if the upgrade was previously scheduled using the globals.isValidScheduledCall() function. In contrast, when the upgrade is initiated by the SecurityAdmin, the timelock validation is bypassed.
      • The default implementation version for the factory’s proxies can be set via the setDefaultVersion(version).

Maple Globals

Globals is a central Maple contract for storing Maple system parameters. It includes a pauser and a timelock for upgrades for certain core contracts of the system. It’s an upgradable NonTransparentProxy contract owned by the Maple Governor.

Permission Owner functions Criticality Risk
Upgradable Admin: Governor setImplementation CRITICAL :red_circle:
Governor setPendingGovernor, setDefaultTimelockParameters, setTimelockWindows, unscheduleCall, setMapleTreasury, setMigrationAdmin, setOperationalAdmin, setSecurityAdmin, setPriceOracle, setValidCollateralAsset, setValidPoolAsset, setValidPoolDeployer, setManualOverridePrice CRITICAL :red_circle:
Governor or OperationalAdmin - Safe 3-of-5 activatePoolManager, setBootstrapMint, setCanDeployFrom, setValidBorrower, setValidInstanceOf, setValidPoolDelegate, setMaxCoverLiquidationPercent, setMinCoverAmount, setPlatformManagementFeeRate, setPlatformOriginationFeeRate, setPlatformServiceFeeRate HIGH :red_circle:
Governor or SecurityAdmin - Safe 3-of-6 setContractPause, setFunctionUnpause, setProtocolPause HIGH :green_circle:

  • Access Control
    • Governor
      • The default timelock delay period and its maximum duration to be executed after the delay period can be set by calling the setDefaultTimelockParameters(delay, duration) method. Currently, the default delay for scheduled calls is 7 days with a maximum execution-window duration of 2 days.
      • The delay period to scheduling calls for specific contract actions (e.g, upgradeability) can be set through the setTimelockWindow(contract, bytes32 functionId, delay, duration). It is important to mention that this function can bypass the default 7-day delay by entering a shorter period.
      • The scheduleCall(contract, functionId, calldata) function is permissionless, but e.g, upgrades must be called by the PoolDelegate or SecurityAdmin.
      • The Governor can remove scheduled calls through the unscheduleCall(caller, contract, functionId, callData) function.
      • The addresses of the access control admins, treasury, collateral assets and oracles can be set by the Governor.
    • Governor or OperationalAdmin
      • Different service fees can be set for a specific poolManager through the setPlatformManagementFeeRate(poolManager, fee), setPlatformOriginationFeeRate(poolManager, fee), setPlatformServiceFeeRate(poolManager, fee) methods.
      • New contracts into the system are registered, validated and activated by the Governor or OperationalAdmin.
    • Governor or SecurityAdmin
      • Specific contracts can be paused/unpaused via the setContractPause(address, bool).
      • The system can be paused/unpaused via the setProtocolPause(bool) function.
      • Specific functions can be unpaused by calling setFunctionUnpause(address) function.

Pricing strategy

SyrupUSDC can be characterized as a Lending Protocol, which means a new category of asset being onboarded to Aave. We agree that even if the more straightforward solution to price syrupUSDC with Capo adapter + CL USDC/USD Price feed, as suggested by the risk service provides, we still see this asset as a complex set of pricing, given that the collateral is not only USDC but also composed of n different abstract strategies, some of which can be straightforward to price, while at the same time, others require a more complex evaluation to reach a conclusion.

It’s also important to highlight that the exchange rate can be manipulated in both directions by increasing it through direct USDC donations to the pool or strategies, and decreasing it by impairing or disabling strategies.
Given this fragility of the rate, we highly recommend that if the DAO chooses to list syrupUSDC, it must not be borrowable.

Miscellaneous

  • The system has undergone several security reviews by Trail of Bits, Spearbit (Cantina), Three Sigma, and 0xMacro. They can be found in the Maple documentation here.
  • SyrupUSDC requires several trust assumptions, given that the entities that control the administrative functions, such as the Governor, Pool Delegate, Operational and Security Admins, are controlled by the Maple Team. The Team has provided a list of Assumptions, which highlights that all roles mentioned above are KYC-processed actors and are incentivized to act in the best interest of the protocol.
  • The Maple Team has confirmed that the address managing the Pool Delegate role is an MPC wallet.
  • Even taking those into account, it is important to highlight that the system has multiple moving parts with its custom strategies that will directly affect Aave.

Conclusion

We believe syrupUSDC does not face any infrastructural barriers to listing; however, we identify technical blockers that directly affect the security users’ funds on the Aave Protocol as follows:

  • The Globals singleton contract upgrades that are not time-locked have enough rights to modify critical parts of the system in a scenario where the upgradable admin (currently controlled by the Governor) has its signers’ keys exploited by a malicious actor.
  • The Governor + SecurityAdmin pattern can bypass the timelock, which is only enforced when the Pool Delegate initiates the upgradable calls of critical contracts within the system. This could break the system, similar to the scenario above, if a malicious actor gains complete control.
  • The impairment/disabling strategies action is not time-locked, which could lead to a rapid rate drop, resulting in multiple liquidations and potential bad debt on Aave. A similar scenario could occur if a malicious actor gains control over one of the addresses responsible for this role. We have recommended the Maple team to re-evaluate this flow, to be more defensive, even if keeping the impairment/disabling levers required for the protocol to work.

We discussed the previous points with the Maple Team, and they agreed to evaluate improvements, which, if applied, would remove the blockers from our side (after we re-check the system).

Additionally, it is outside of our scope to evaluate in depth each of the underlying strategies of the asset (both lending systems and DeFi allocation), each one of them involving additional risk, and dependency on the for example, the underlying venues where the funds are allocated.

3 Likes

First of all, we thank BGD for their thorough analysis and are pleased to note their overall positive feedback on the Maple protocol.

At Maple, we operate to the highest institutional, technical, and security standards. We welcome constructive feedback, and we are proactively taking BGD’s recommendations onboard. The Maple team is already working to address these points and implement the solutions outlined below.

Maple will address the three identified recommendations as follows:

Governor Multisig Timelock

BGD recommendation (1): The Globals singleton contract upgrades that are not time-locked have enough rights to modify critical parts of the system in a scenario where the upgradable admin (currently controlled by the Governor) has its signers’ keys exploited by a malicious actor.

BGD recommendation (2): The Governor + SecurityAdmin pattern can bypass the timelock, which is only enforced when the Pool Delegate initiates the upgradable calls of critical contracts within the system. This could break the system, similar to the scenario above, if a malicious actor gains complete control.

Maple’s Response: To address Recommendations (1) and (2), Maple will update the Governor Multisig to include a 24-hour timelock for all function calls and on-chain actions across the Maple protocol. The Governor Multisig will interact with an immutable smart contract enforcing this timelock for every call, ensuring that even if the multisig is compromised, no changes can be executed instantly.

Maple will make sure to involve BGD in the implementation process to ensure it meets all requirements. Once completed, Maple will request a final review from BGD before jointly updating the Aave community on the forum and being ready for the vote.

Impairment Function - Security Update

BGD recommendation (3): The impairment/disabling strategies action is not time-locked, which could lead to a rapid rate drop, resulting in multiple liquidations and potential bad debt on Aave. A similar scenario could occur if a malicious actor gains control over one of the addresses responsible for this role. We have recommended the Maple team to re-evaluate this flow, to be more defensive, even if keeping the impairment/disabling levers required for the protocol to work.

Maple’s Response: To address Recommendation (3), Maple reaffirms its commitment to the institutional security practices and operational procedures expected of the largest on-chain asset manager. In addition, we will further strengthen the multisig signing policy for impairment and disabling actions.

Finally, Maple will publish a detailed, transparent procedure outlining the process for impairing or defaulting a loan, including the specific steps and conditions required.

Conclusion

With these implementations, Maple is confident that BGD’s concerns are fully addressed. We remain committed to collaborating closely with BGD to ensure the solutions meet their standards and those of the Aave ecosystem and community.

5 Likes