Resupply USD (REUSD)

Resupply USD: How reUSD Turns Lending-Market Yield Into a Borrowable Stablecoin

Resupply is a decentralized stablecoin protocol built around collateral from external lending markets. Its reUSD token is minted as debt against yield-bearing positions, while redemption rules, insurance mechanisms, and RSUP-based governance shape how the system manages liquidity and risk.

What Resupply is designed to do

Resupply is a collateralized stablecoin protocol that uses yield-bearing positions from external lending markets. Its documentation describes a model in which users supply assets associated with crvUSD and frxUSD markets, borrow reUSD against those positions, and retain exposure to the underlying lending yield. The protocol says revenue is directed to several groups, including stakers, savers, and the insurance pool. This makes Resupply closer to a debt-and-yield system than to a fiat-backed stablecoin issuer: reUSD depends on on-chain collateral, market liquidity, pricing contracts, and the rules of the lending venues it integrates.

The intended users are therefore DeFi participants who want to borrow a stablecoin without fully giving up a yield-bearing collateral position. The design can also serve users seeking exposure to Resupply’s savings or insurance mechanisms, although those products introduce separate smart-contract and liquidity dependencies. The project’s own description is a statement of intended function, not independent evidence that every supported market remains liquid or that the strategy is suitable for every user.

How the collateral structure works

At the contract level, Resupply organizes borrowing through registered pair contracts. The protocol’s redemption code retrieves a pair’s total debt, collateral vault, exchange-rate information, and underlying asset before calculating how much collateral can be returned for redeemed reUSD. This structure means reUSD is not backed by one universal reserve account. Its effective backing is distributed across approved collateral markets, each with its own utilization, oracle, exchange-rate, and liquidation characteristics.

The documentation names Curve Lend, Curve Lend v2, and Fraxlend as relevant lending venues. That integration can make the system capital-efficient because collateral may continue generating lending yield while supporting reUSD debt. It also creates layered exposure: a reUSD user is indirectly exposed not only to Resupply’s contracts, but also to the selected lending market, its collateral vault, its oracle, and the stability of the asset deposited there.

What reUSD does inside the protocol

reUSD is the protocol’s debt token. Users mint it by borrowing against approved collateral positions, and the redemption contract burns the reUSD returned by a user when collateral is withdrawn. In practical terms, the token’s main utility is access to liquidity against collateral rather than a claim on a bank-held dollar reserve. The system’s economics therefore depend on keeping debt limits, collateral valuations, interest, and redemption conditions aligned across the supported pairs.

Redemption is not necessarily a fixed one-to-one exchange with a single reserve asset. The contract calculates a redemption fee, converts the amount through the relevant collateral oracle and vault exchange rate, and can return either collateral shares or underlying assets. This gives the protocol a defined exit mechanism, but the amount and form of collateral depend on the selected pair and its available liquidity.

Fees, guards, and peg management

The redemption handler uses several controls that affect exits. Its code includes a base redemption fee, usage-based discounts, additional fees when redemption activity becomes concentrated, and an oracle-related surcharge when the underlying collateral is priced above the reference level. Usage weights decay over time, which is intended to avoid treating old redemption activity as permanently congested. These are protocol rules visible in the code, but their effectiveness depends on parameter settings, oracle quality, and the liquidity available in each pair.

The same contract includes a redemption guard. When the guard is enabled, permissionless redemptions can be restricted unless the reUSD oracle price is below a configured threshold or the caller is the designated redemption operator. This is a meaningful operational dependency: a mechanism intended to protect against value leakage or disorderly exits can also make redemption availability depend on privileged roles and governance-controlled settings.

Governance and upgrade control

Resupply’s Voter contract is described in the code as the primary ownership contract for protocol contracts. It allows arbitrary function calls to be executed after the required voting conditions are met. The published constants specify a one-week voting period, a one-day execution delay, and a three-week execution deadline, while quorum and proposal-creation thresholds are stored as configurable state variables. This gives governance meaningful authority over protocol parameters and contract actions rather than limiting it to advisory signaling.

The governance forum records proposals involving market onboarding, borrow limits, redemption fees, security guardrails, and insurance-pool operations. That history shows that supported collateral and risk settings are expected to change through governance. Users should therefore treat the approved-market list, limits, fees, and operator permissions as changeable system parameters rather than permanent characteristics of reUSD.

Known failure history and practical limitations

Resupply’s governance forum documented a June 2025 exploit that produced approximately 10 million reUSD of bad debt. The recovery proposal described a combination of treasury payments, an insurance-pool reduction of 6 million reUSD, and a remaining amount to be addressed through future protocol revenue or governance-directed measures. The proposal also outlined RSUP incentives for affected insurance-pool depositors. This is a material part of the project’s operating history because it demonstrates that losses can be allocated through governance and insurance mechanisms rather than absorbed only by a separate external guarantor.

The central unresolved questions are therefore practical rather than purely conceptual: how much liquidity is available for a given redemption, how quickly governance can respond to a market or oracle problem, how privileged operators are controlled, and how future losses would be distributed. ReUSD’s architecture offers capital efficiency by combining stablecoin debt with yield-bearing collateral, but it also compounds dependencies across Resupply, external lending markets, oracles, governance, and insurance resources.

Key takeaways

• reUSD is minted as collateralized debt, not issued as a direct claim on bank-held dollars.
• The system relies on external lending markets whose collateral, liquidity, oracles, and contract behavior affect reUSD users.
• Redemptions use pair-specific collateral conversions and variable fee logic rather than a single universal reserve asset.
• Governance can influence markets, parameters, operator permissions, and protocol contracts through the Voter system.
• The June 2025 exploit and recovery process show that insurance-pool participants and governance may bear losses after a protocol failure.

Risks and open questions

• External lending-market, collateral-vault, oracle, and exchange-rate failures could affect the value or liquidity available to reUSD holders.
• Redemption guards, designated operators, and configurable parameters create dependence on privileged controls and governance decisions.
• Variable redemption fees and pair-specific liquidity may make exits differ materially across collateral markets.
• The June 2025 exploit created substantial reUSD bad debt and required an insurance-pool and governance-led recovery process.
• The available sources do not establish that all current collateral markets, contracts, audits, or governance safeguards remain equally active or effective.