-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add USDA plugin and scripts #1215
base: master
Are you sure you want to change the base?
Conversation
test/plugins/individual-collateral/angle/USDAFiatCollateral.test.ts
Outdated
Show resolved
Hide resolved
{ | ||
require(config.defaultThreshold != 0, "defaultThreshold zero"); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking at the stUSDA ERC4626 contract, and there seems to be an internal accrual happening on any deposit or withdrawal. since this accrual affects the pricePerShare() rate, we should make sure this gets updated on any call to collateral.refresh()
(refresh() ensures that all state variables affecting price are updated so that the most accurate, up-to-date price can be calculated).
the best way to do this is probably to copy over the refresh call from the AppreciatingFiatCollateral
and add a call to deposit(0, address(this))
at the top of the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, but wondering if this is really needed for stUSD
. View functions like totalAssets
or convertToAssets
already includes accruals (see https://github.com/AngleProtocol/angle-transmuter/blob/main/contracts/savings/Savings.sol#L109). So it is possible to compute up-to-date prices without having to trigger a state update, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes but there are state updates performed in the collateral plugin, so we should match that with any necessary state updates in the collateral itself.
[ | ||
{ | ||
priceTimeout: PRICE_TIMEOUT.toString(), | ||
chainlinkFeed: networkConfig[chainId].chainlinkFeeds.USDC, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
USDA
collateral = <USDAFiatCollateral>await USDAFiatCollateralFactory.connect(deployer).deploy( | ||
{ | ||
priceTimeout: PRICE_TIMEOUT.toString(), | ||
chainlinkFeed: networkConfig[chainId].chainlinkFeeds.USDC, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
USDA
// Mainnet Addresses | ||
export const USDA = networkConfig['31337'].tokens.USDA as string | ||
export const StUSD = networkConfig['31337'].tokens.stUSD as string | ||
export const USDA_USD_PRICE_FEED = networkConfig['31337'].chainlinkFeeds.USDC as string // we use USDC feed as USDA/USD is not available in chainlink, and USDA/USDC is always 1 through the transmuter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok this is a critical piece of the pricing puzzle so i think its worth justifying this with a more in-depth explanation.
can you link the transmuter docs and code?
is USDC ALWAYS instantly and atomically exchangeable 1:1 for USDA?
are there any failure modes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please find here the Transmuter code and docs.
USDA is in the current settings exchangeable 1:1 instantly and atomically with USDC.
As you point out, there are some failure modes (and this is where the value of the Transmuter lies), especially if USDC was to depeg. Transmuter was designed to incorporate anti-depeg mechanisms, and automatically fallback into a preservation mode if one of the assets in its backing was to depeg. As currently all assets for which this monitoring is activated are USDC derivatives (namely USDC and steakUSDC on Morpho) then, only a USDC depeg could cause the 1:1 exchangeability to break between the 2 assets.
There are some cases where the protocol could have its liquidity buffer in USDC depleted, but in this case, the system supports a permissionless rebalancing feature allowing anyone to refill the USDC reserves of the protocol and enable 1:1 USDA->USDC conversion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think having the liquidity buffer depleted is a concern. there's really no guarantees on when it would be refilled, right? and at that point, users would need to go to the market to exchange?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current setup with the public harvester contract, and the liquidity of the collateral assets, there is in fact a guarantee that this liquidity buffer will be refilled.
While we mentioned the liquidity buffer in USDC, with the transmuter, users can burn their USDA for any of the other assets in the backing (which is not the case by the way with the majority of other stablecoin protocols), and so before selling on the market, they can burn for like steakUSDC and USDM. They may also choose to redeem their USDA for a portion of all the assets in the backing depending on the proportion that they represent.
In any case, users are never locked in Angle and can always exit using the system's primary minting mechanism
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok so its even more complex than just USDA => USDC, which means using the USDC oracle doesnt really hold in all cases. let's chat through this on a call.
leaving this pr open for now. need an stUSDA oracle in order to complete the plugin. |
No description provided.