Summary
Add gauge for the sreUSD-long LlamaLend market to the gauge controller.
This proposal includes an overview of sreUSD and rationale for the LlamaLend market configuration.
Abstract
The sreUSD-long market has been configured similar to previously deployed stablecoin markets, allowing for high leverage looping while accounting for direct redemption from the protocol for a redemption fee. The sreUSD-long market utilizes a custom oracle contract deployed by Resupply that prices reUSD/USD from the reUSD/scrvUSD with the aggregated price of crvUSD and a minimum price bound at 0.99. It applies the sreUSD vault rate, a fork of sfrxUSD that has been deployed very recently.
sreUSD Overview
Stablecoin Design
Resupply mints reUSD against CDPs collateralized by other stablecoins (initially crvUSD, frxUSD) that are deposited into external lending markets (initially LlamaLend and FraxLend) to earn yield. The target market is selected by the borrower. Given the non-volatile property of this CDP market design, LTVs tend to be very high - typically 95% - allowing borrowers to achieve up to 20x leverage. This “refinancing” of stablecoins lets user capture leveraged exposure to external lending APRs while the protocol earns fees on minted reUSD.
Borrow-Rate Policy
reUSD’s borrow APR is set to the max of:
- ½ of the lending rate reUSD collateral is earning,
- ½ of a “risk-free” proxy (e.g., sfrxUSD), or
- 2%,
whichever is higher—so protocol income scales with market yields and avoids zero-rate regimes. This also strives to protect the collateralization of the borrow position, as the borrow position should typically be earning more yield than Resupply charges as a fee, except when lend market rates are very low.
Peg Mechanics
Resupply allows anyone to permissionlessly redeem reUSD against CDPs for a dynamic fee. Redemptions burn reUSD and deliver a basket of collateral to redeemers, establishing a floor near $1 minus the redemption fee. The base fee, configurable by the DAO, is set at 1%. This essentially creates a reUSD floor price at 0.99 relative to the underlying stablecoins (crvUSD & frxUSD). The mechanism is designed to restore the peg by shrinking borrower debt while transferring collateral to redeemers.
The system tolerates upward peg deviations. This is considered tolerable because it makes minting reUSD more profitable, therefore creating organic downward pressure on the peg toward $1 as reUSD minting accelerates.
Insurance Pool
A dedicated, user-funded pool (earning a share of protocol revenue and RSUP) is used to cover bad debt and to buy collateral during CDP liquidations. Its capacity and refilling cadence are central to systemic resilience. Withdrawals from the pool involve a 7-day cooldown. In case use of Insurance Pool reserves becomes necessary, the DAO can control the allocation of funds through an onchain vote. It can also change parameters relevant to the pool, such as the cooldown time.
Savings reUSD (sreUSD)
sreUSD is a new addition to the Resupply system in an effort to create additional demand for the reUSD stablcoin. It is an ERC-4626 vault that streams weekly protocol revenue to depositors. It is growth-oriented (not the insurance backstop) and receives (a) a baseline split of protocol revenue and (b) extra “off-peg” fees when reUSD trades below peg (via a priceWeight mechanism that charges 50–60% of underlying yields as fees, routing the incremental portion to sreUSD first). This dynamic fee is intended to create additional incentives for holding reUSD and disincentives for shorting reUSD during periods of peg instability.
The sreUSD is based on sfrxUSD with native support for LayerZero cross-chain support with OFT compliance. Like sfrxUSD, there is no token lockup or penalties, it can always be redeemed for the pro-rata share of underlying reUSD in the vault. There are no additional token emissions- all yield in the vault comes from protocol revenue. See more information about sreUSD in the proposal.
Governance & Access Control
Governance is managed through an on-chain DAO of staked RSUP tokenholders via a dedicated Voter contract (unstaking involves a 14-day cooldown). The contract is explicitly documented in source as “primary ownership contract for all protocol contracts,” executing arbitrary function calls only after sufficient staked-weight approval. Key mechanics visible in code:
- Stake-weighted voting via
IGovStaker: quorum and proposal thresholds are computed from total voting weight at a fixed epoch, using anEpochTrackerto prevent last-minute stake swings. - Thresholds & Timers (defaults in code):
minCreateProposalPctandquorumPctare stored in basis points (MAX_PCT=10,000); timing safeguards includeminTimeBetweenProposals= 1 day,votingPeriod= 3 days,executionDelay= 6 hours, and anEXECUTION_DEADLINE= 3 weeks (includes the voting period). These create a lightweight timelock and ensure proposals have sufficient time before execution. Admin setters exist to adjust these values via governance. - Execution model: proposals carry a batch of {target, data} actions; once quorum is reached and delay has passed, anyone can call
executeProposalwithin the deadline. The contract inheritsCoreOwnableandDelegatedOps, signaling that “Core” treats the Voter as the system owner/executor under DAO control.
This is a standard, credible on-chain architecture: transparent, stake-weighted, epoch-locked voting with bounded timings. The main risks to watch are (i) parameter mis-tuning of quorumPct/thresholds and (ii) concentrated staker power; both are at least visible and adjustable on-chain.
Security Posture
The team has published audits from yAudit and ChainSecurity prior to protocol launch. The team offers a self-hosted bug bounty program with policies and contact information provided in the protocol docs.
Despite sound security precautions, there was an exploit on June 26 that resulted in $10m bad debt to the protocol. The exploit, detailed in the official post-mortem, involved a donation attack to a newly deployed wstUSR market. All bad debt from the incident has since been paid off through a combination of Insurance Pool funds, donations, and a loan from Yearn’s treasury. Resupply has since undergone additional audits to ensure the exploit vector has been removed.
Risk Considerations
Stacked dependencies: reUSD solvency depends on the health of external lending venues and the constituent markets (LlamaLend, Fraxlend), the collateral stables (crvUSD, frxUSD), and the yield-boosting platform (Convex). A venue-side shortfall or depeg propagates into reUSD and therefore into sreUSD.
Insurance capacity: Liquidations are intended to be a rare circumstance, and are funded by the Insurance Pool. If losses exceed the reserve capacity, the protocol assumes the extra bad debt (effectively socializing losses / policy risk). Note that liquidations are most likely to be necessary due to contagion from a failed lend market, but may also be necessary if a position’s borrow cost puts it at risk of undercollateralization.
Soft Peg: The redemption mechanism enforces a price floor near $1 minus the redemption fee; it doesn’t prevent upward depegs (which is considered acceptable). The redemption mechanism is dynamic and involves several factors such as a base fee, pair usage weight, and reUSD price premium. These factors adjust the cost to redeem depending on how frequently redemption is done through a specific market and based on the price of reUSD. These parameters and dependencies are settable by the contract owner and can change assumptions about the strength of the soft peg.
Governance: The Core contract authorizes privileged roles and can execute on protocol and non-protocol assets. The Voter is assigned to the smart contract described above. Although an onchain DAO, governance risk may arise from stakeholder concentration, especially given the relatively low staking period required to participate in governance (14 days).
Privileged Roles: There’s also a Guardian multisig managed by the Resupply team that can pause/cancel onchain proposals. Signers consist of reputable Convex and Yearn devs. This mitigates the governance attack vector described above but also represents a multisig trust assumption over DAO operations.
Bridging / OFT (LayerZero): sreUSD has native support for LayerZero’s OFT standard. OFT relies on LayerZero for message delivery and verification. Mis-config (e.g., DVN settings) or endpoint issues can stall or misroute transfers.
Specification:
Market Parameters
| Parameter | Value |
|---|---|
| A | 200 |
| fee | 0.002 |
| liq_discount | 1.5% |
| loan_discount | 2.0% |
Parameter Optimization Methodology
We aim to parameterise a sreUSD → crvUSD LLAMMA market before sreUSD has launched. Given the absence of live sreUSD data, we construct a synthetic price series that approximates the stability characteristics of the intended market.
Data Selection and Preparation
Base Dataset Selection: We use the REUSD/SCRVUSD (0xc522A6606BBA746d7960404F22a3DB936B6F4F50) Curve pool as the base series, as it mirroring the structure of the future sreUSD/crvUSD market by capturing:
- REUSD’s stability properties.
- SCRVUSD’s yield-bearing behaviour, while accounting for underlying crvUSD dynamics.
These properties make it a natural fit.
Proxy Pair Identification: To extend the dataset beyond REUSD’s launch in April, we identify a yield-bearing stable → non-yield bearing pool (ideally paired crvUSD/scrvUSD) with at least 12 months of price history to capture crvUSD price dynamics. Through the Curve UI we identified the following pools as possible candidates by scanning for pools with > 1m TVL:
| Pair | Pool Address | Deployment Date |
|---|---|---|
| sUSDe/crvUSD | 0x57064F49Ad7123C92560882a45518374ad982e85 |
Jun-01-2024 |
| FRAX/sDAI | 0xcE6431D21E3fb1036CE9973a3312368ED96F5CE7 |
Dec-16-2023 |
Candidate proxies of the underlying are ranked against REUSD/scrvUSD primarily based on volatility profile.
The closest statistical match was the crvUSD/sDAI pair constructed from the from following pairs CRVUSD_USDC * FRAX_SDAI / FRAX_USDC.
Synthetic History Construction: Extract returns from the selected proxy series and rescale to match the volatility profile of REUSD/SCRVUSD. Merge the scaled proxy history with the REUSD/SCRVUSD data to produce a continuous ≥ 12-month series.
Simulation Preparation: Ensure price direction is consistent with LLAMMA requirements (collateral per debt unit).Produce both:
- Raw short-history dataset (REUSD/SCRVUSD only).
- Extended merged dataset (proxy + REUSD/SCRVUSD).
These datasets will be run through the LLAMMA simulator, with parameter selection favouring configurations that perform safely on both.
The synthetic price path can be used for simulation can be observed below:
Note: The price path start at 0.92 due to scaling of the sDAI series. As we more interested in the volatility profile rather absolute price level it is acceptable for the purpose of the analysis.
Simulations
Fee-Tier Stress Test
Objective: Estimate how base AMM fee (in bps) affects tail loss for the LLAMMA simulator under 1-day liquidation horizons—isolating base-fee effects from dynamic/oracle fees.
AMM & Market Settings
- Preprocessing: none (no time reversal).
- Daily timeframe
- AMM geometry:
A=200,range_size=4 - Oracle smoothing:
Texp=600seconds (≈10-min EMA) - External venue cost:
ext_fee=5e-4(5 bps) - Dynamic/Oracle fees: disabled to isolate base fee
dynamic_fee_multiplier=0use_po_fee=0po_fee_delayignored
Rationale: hold market microstructure and liquidity ladder constant while measuring sensitivity to the base trading fee only.
Stress Definition
- Horizon:
1.0day (overnight risk proxy). - Sampling scheme: with replacement, random start times, no reversal (
add_reverse=False). - Window integrity: draw start positions on [0,1-\text{size}] so each sample is a full 1-day window (no truncation at dataset end).
Tail Metric & Sampling Budget
- Samples:
samples = 10_000 - Tail: P95 Expected Shortfall
n_top_samples = int(0.05 * samples) = 500
Estimator: mean of the 500 worst losses from the 10,000 sampled windows.
Rationale: P95 ES captures heavy-tail behavior without the brittleness of “single worst window.”
Execution Snippet
from libsimulate import scan_param, plot_losses
import random
if __name__ == '__main__':
import random
samples = 10_000
tail = 0.05 # 5% tail (P95 ES)
n_top = max(1, int(samples * tail))
fees_bps = [1, 2, 3, 4, 5, 7, 10, 15, 20, 30]
fee = [b/1e4 for b in fees_bps]
results = scan_param(
filename='./data/sreUSD-crvUSD/crvusd_sreusd_synth.json',
ext_fee=5e-4,
A=200,
range_size=4,
fee=fee,
min_loan_duration=1.0,
max_loan_duration=1.0,
add_reverse=False, # realistic for yield-bearing pair
Texp=600, # 10-min half-life EMA
samples=samples,
n_top_samples=n_top,
other=dict(
dynamic_fee_multiplier=0, # isolate base-fee effect
use_po_fee=0, # oracle-move fee OFF for this experiment
po_fee_delay=2 # harmless here; keep >=1 if you ever turn use_po_fee on
)
)
plot_losses('fee', results, outfile='./example_reusd/1_fee.png')
A-Factor Stress Test
Objective: Quantify how the amplification factor A (band density / tick width) impacts tail loss in the LLAMMA simulator over a 1-day liquidation horizon, under realistic trading frictions and oracle-driven dynamic fees.
AMM & Market Settings
- Preprocessing: none (no time reversal), i.e.,
add_reverse=Falsefor yield-bearing pairs. - Horizon:
1.0day windows. - AMM geometry: sweep
A, holdrange_size=4fixed.
(Interpretation: higherA⇒ narrower bands (more concentrated liquidity) while the number of bands stays constant.) - Oracle smoothing:
Texp=600seconds (≈ 10-min EMA). - External venue cost:
ext_fee=5e-4(5 bps). - Fees (realistic): include LLAMMA’s oracle/distance fees.
fee=0.002(20 bps base fee held constant during the A sweep)use_po_fee=1(oracle-movement fee enabled)po_fee_delay=2(matches 120s decay at 60s bar granularity)dynamic_fee_multiplier=0.5(distance-from-band fee; ≈¼ coefficient analogous to sUSDe LLAMMA)
Rationale: We want the shape of tail risk vs. band density in conditions closer to production. Holding fee constant isolates the effect of A while still letting dynamic fees respond to moves.
Sampling Design
- Scheme: random with replacement, uniform start times; full-window enforcement by sampling start on [0, 1-\text{size}].
- Dataset direction: no reversal (
add_reverse=False).
Tail Metric & Sampling Budget
- Samples:
samples = 10_000 - Tail: P95 Expected Shortfall
n_top_samples = int(0.05 * samples) = 500
Estimator: mean of the 500 worst losses from the 10,000 sampled windows.
Rationale: P95 ES captures heavy-tail behavior without the brittleness of “single worst window.”
Execution Snippet (P95, 10k samples)
from numpy import logspace, log10
from libsimulate import scan_param, plot_losses
if __name__ == '__main__':
import random
samples = 10_000
tail = 0.05 # 5% tail (P95 ES)
n_top = max(1, int(samples * tail))
results = scan_param(
filename='./data/sreUSD-crvUSD/crvusd_sreusd_synth.json',
ext_fee=5e-4,
A=sorted(set(int(a) for a in logspace(log10(100), log10(1000), 20))),
range_size=4,
fee=0.002, # 0.002 - 20bps
min_loan_duration=1.0,
max_loan_duration=1.0,
add_reverse=False, # realistic for yield-bearing pair
Texp=600, # 10-min half-life EMA
samples=samples,
n_top_samples=n_top,
other = dict(
dynamic_fee_multiplier = 0.5, # matches sUSDe LLAMMA contract (0x6505aeC799AC3b16a79cb1Ae2A61884889b54C1b) get_dynamic_fee coefficient (≈ 1/4)
use_po_fee = 1, # LLAMMA always applies oracle-move fee
po_fee_delay = 2 # 120s contract decay ÷ 60s per bar
)
)
plot_losses('A', results, outfile='./example_reusd/2_A.png')
Results
We inform the fee empirically by setting it on par with the competing pair, allowing the swapping of reUSD/crvUSD.
Fee
We see two candidates for the fee parameter, which minimize loss at a fee tier of 4bps and 20bps. Naturally, the higher fee tier is more favourable for the borrower. The borrower effectively acts as a liquidity provider in the LLAMMA. Consequently, a higher fee tier translates to more rebates to the borrower paid by arbitrageurs.
Amplification Factor
We select an A ≈ 200 (specifically A=206 from our grid). It sits on the Pareto frontier, delivering low tail loss (~1.08%) while keeping the liquidity discount (~2.04%) close to its practical minimum; higher A reduces haircut but raises the loss.
Liquidation Discount
Given that we estimate 95 ES and using a synthetic dataset, we very conservatively round up the liquidation discount from 1.08% to 1.5%.
Loan Discount
The purpose of the Loan discount is to avoid immediate liquidation when a loan is configured. Given that we are working with a stable asset, we add a 0.5% policy buffer as margin. This is in line with previous experiments conducted on sUSDe.
\text{loan_discount} = \text{liquidation_discount} + \text{policy_buffer}
The resulting loan discount is 2\% \text{~} (1.5 + 0.5).
Monetary Policy
| Parameter | Value |
|---|---|
| Min Rate | 0.1% |
| Max Rate | 30% |
The market uses Semilog Monetary Policy, the current standard for LlamaLend Markets. This policy uses a polynomial curve based on the market utilization and the min/max rates set by governance. The parameter config has been set with a max rate that is expected to exceed the yield on the underlying.
We plan to quickly replace this monetary policy with the EMAMonetaryPolicy used in the sfrxUSD market. This will allow the market to dynamically assign rates based on changes to the sreUSD yield.
Oracle
Proxy: https://etherscan.io/address/0x8535a120f6166959b124e156467d8caf41ca2887
Implementation: https://etherscan.io/address/0xc5BA754C3DadA47E32710eBC17361Ed16e52C954
In line with the deployment of recent LlamaLend markets, the implementation of an oracle proxy allows the Curve DAO to set a new oracle implementation without requiring a market migration. The implementation SreusdFromOracleVault is a custom implementation that uses Resupply’s own oracle contract to price reUSD in USD using the Curve reUSD/scrvUSD liquidity hub, the aggregated price of crvUSD, and imposes a 0.99 minimum bound on the returned price.
The underlying pools and contracts used in the oracle include:
- reUSD/scrvUSD: $58.4m TVL
- sreUSD Vault
- Resupply Oracle Contract
The TVL history for each of the pools used in the oracle implementation are shown:
reUSD/scrvUSD
Source: CurveMon
Vote Actions
GAUGE_CONTROLLER = "0x2F50D538606Fa9EDD2B11E2446BEb18C9D5846bB"
ACTIONS = [
# Add sreUSD-long to gauge controller
(GAUGE_CONTROLLER, "add_gauge", "0x29E9975561fAD3A7988CA96361AB5c5317CB32Af", 0, 0)
]
