Skip to content
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

Yield Fi yUSD Rate Providers #252

Merged
merged 11 commits into from
Feb 6, 2025
50 changes: 50 additions & 0 deletions rate-providers/registry.json
Original file line number Diff line number Diff line change
Expand Up @@ -605,6 +605,20 @@
"warnings": [],
"factory": "0x26dEc0e6a4249F28e0f16A1a79808bF9ba308310",
"upgradeableComponents": []
},
"0xb1D5c23DbfCb36864f32bc704AE4205BB9720C33": {
"asset": "0x895e15020C3f52ddD4D8e9514eB83C39F53B1579",
"name": "YieldFi yUSD Rate Provider",
"summary": "safe",
"review": "./yUSDRateProviderArbitrum.md",
"warnings": [""],
"factory": "",
"upgradeableComponents": [
{
"entrypoint": "0xE88DA976479461080072D6461128fd401B6D4Dcb",
"implementationReviewed": "0xfeae389573e64b4ada95a494090f2399415c8b20"
}
]
}
},
"avalanche": {
Expand Down Expand Up @@ -997,6 +1011,20 @@
"implementationReviewed": "0x4e7991e5C547ce825BdEb665EE14a3274f9F61e0"
}
]
},
"0xD47c15CDD7c734db321F07CB9AB1f852aE9A0b83": {
"asset": "0x895e15020C3f52ddD4D8e9514eB83C39F53B1579",
"name": "YieldFi yUSD Rate Provider",
"summary": "safe",
"review": "./yUSDRateProviderBase.md",
"warnings": [""],
"factory": "",
"upgradeableComponents": [
{
"entrypoint": "0xE88DA976479461080072D6461128fd401B6D4Dcb",
"implementationReviewed": "0xfeae389573e64b4ada95a494090f2399415c8b20"
}
]
}
},
"ethereum": {
Expand Down Expand Up @@ -2447,6 +2475,28 @@
"implementationReviewed": "0xe2D2E90122cb203CF1565a37ef90a256843A825A"
}
]
},
"0xa65ffBa1CD05414df3fD24Bf5dc319B47450Fbf4": {
"asset": "0x1CE7D9942ff78c328A4181b9F3826fEE6D845A97",
"name": "YieldFi yUSD Rate Provider",
"summary": "safe",
"review": "./yUSDRateProvider.md",
"warnings": [""],
"factory": "",
"upgradeableComponents": [
{
"entrypoint": "0x1CE7D9942ff78c328A4181b9F3826fEE6D845A97",
"implementationReviewed": "0x79E243f6504615497c1374Ea0B6365Dd1Ef82C8d"
},
{
"entrypoint": "0x9305a0cc13293b69deE0B9d281D21144b029BdFf",
"implementationReviewed": "0xf2De8048f002b70202D05249810E72914651Aa26"
},
{
"entrypoint": "0xf4eF3ba63593dfD0967577B2bb3C9ba51D78427b",
"implementationReviewed": "0xa52BC229C750b35C10d54F23aD3cb6E8155df01a"
}
]
}
},
"fantom": {
Expand Down
6 changes: 2 additions & 4 deletions rate-providers/template.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,23 +23,21 @@ Each of the items below represents an absolute requirement for the Rate Provider
## Review Checklist: Common Findings
Each of the items below represents a common red flag found in Rate Provider contracts.

If none of these is checked, then this might be a pretty great Rate Provider! If any of these is checked, we must thoroughly elaborate on the conditions that lead to the potential issue. Decision points are not binary; a Rate Provider can be safe despite these boxes being checked. A check simply indicates that thorough vetting is required in a specific area, and this vetting should be used to inform a holistic analysis of the Rate Provider.
If none of these is checked, then this might be a pretty great Rate Provider! If any of these is checked, we must thoroughly elaborate on the conditions that lead to the potential issue. Decision points are not binary; a Rate Provider can be usable despite these boxes being checked. A check simply indicates that thorough vetting is required in a specific area, and this vetting should be used to inform a holistic analysis of the Rate Provider.

### Administrative Privileges
- [ ] The Rate Provider is upgradeable (e.g., via a proxy architecture or an `onlyOwner` function that updates the price source address). \<Delete this hint: If unchecked, delete all of the bullets below.\>
- admin address: [\<network:address\>](\<link to contract block explorer\>)
- admin type: \<EOA/multisig\> \<Delete this hint: If EOA, delete the whole sub-section below.\>
- multisig threshold/signers: \<X/Y\>
- multisig timelock? \<YES: minimum duration/NO\>
- trustworthy signers? \<YES/NO\> \<Delete this hint: Are the signers known entities such as Vitalik, Hudson, samczsun, or Fernando? Or are they random addresses?\>

- [ ] Some other portion of the price pipeline is upgradeable (e.g., the token itself, an oracle, or some piece of a larger system that tracks the price). \<Delete this hint: If unchecked, delete all of the bullets below.\>
- upgradeable component: `\<contract name\>` ([\<network:address\>](\<link to contract block explorer\>))
- admin address: [\<network:address\>](\<link to contract block explorer\>)
- admin type: \<EOA/multisig\> \<Delete this hint: If EOA, delete the whole sub-section below.\>
- multisig threshold/signers: \<X/Y\>
- multisig timelock? \<YES: minimum duration/NO\>
- trustworthy signers? \<YES: whom/NO\> \<Delete this hint: Are the signers known entities such as Vitalik, Hudson, samczsun, or Fernando? Or are they random addresses?\>

### Oracles
- [ ] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes). \<Delete this hint: If unchecked, delete all of the bullets below.\>
Expand Down Expand Up @@ -67,4 +65,4 @@ To save time, we do not bother pointing out low-severity/informational issues or
## Conclusion
**Summary judgment: \<USABLE/UNUSABLE\>**

\<Delete this hint: Formulate a nuanced conclusion here. Remember, it's okay if some of the boxes above are checked as long as reasonable protections are in place. If the Rate Provider is very obviously safe, say so. If it's very obviously not, say so: what specifically needs to change before it can be considered safe? If the conclusion is hazy, explain why, and leave the final determination up to the reader. Examples of completely unacceptable conditions include, but are not limited to: EOA admins, EOA price sources, market prices (instead of deposit/redemption prices).\>
\<Delete this hint: Formulate a nuanced conclusion here. Remember, it's okay if some of the boxes above are checked as long as reasonable protections are in place. If the Rate Provider is very obviously usable, say so. If it's very obviously not, say so: what specifically needs to change before it can be considered usable? If the conclusion is hazy, explain why, and leave the final determination up to the reader. Examples of completely unacceptable conditions include, but are not limited to: EOA admins, EOA price sources, market prices (instead of deposit/redemption prices).\>
59 changes: 59 additions & 0 deletions rate-providers/yUSDRateProvider.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# Rate Provider: ERC4626RateProvider

## Details
- Reviewed by: @brunoguerios
- Checked by: @mkflow27
- Deployed at:
- [ethereum:0xa65ffBa1CD05414df3fD24Bf5dc319B47450Fbf4](https://etherscan.io/address/0xa65ffBa1CD05414df3fD24Bf5dc319B47450Fbf4)
- Audit report(s):
- [Protocol Audits](https://docs.yield.fi/resources/audits)

## Context
This rate provider works with a standard approach of `totalAssets/totalSupply`.

## Review Checklist: Bare Minimum Compatibility
Each of the items below represents an absolute requirement for the Rate Provider. If any of these is unchecked, the Rate Provider is unfit to use.

- [x] Implements the [`IRateProvider`](https://github.com/balancer/balancer-v2-monorepo/blob/bc3b3fee6e13e01d2efe610ed8118fdb74dfc1f2/pkg/interfaces/contracts/pool-utils/IRateProvider.sol) interface.
- [x] `getRate` returns an 18-decimal fixed point number (i.e., 1 == 1e18) regardless of underlying token decimals.

## Review Checklist: Common Findings
Each of the items below represents a common red flag found in Rate Provider contracts.

If none of these is checked, then this might be a pretty great Rate Provider! If any of these is checked, we must thoroughly elaborate on the conditions that lead to the potential issue. Decision points are not binary; a Rate Provider can be usable despite these boxes being checked. A check simply indicates that thorough vetting is required in a specific area, and this vetting should be used to inform a holistic analysis of the Rate Provider.

### Administrative Privileges
- [ ] The Rate Provider is upgradeable (e.g., via a proxy architecture or an `onlyOwner` function that updates the price source address).

- [x] Some other portion of the price pipeline is upgradeable (e.g., the token itself, an oracle, or some piece of a larger system that tracks the price).

- upgradeable component: `YToken` ([ethereum:0x1CE7D9942ff78c328A4181b9F3826fEE6D845A97](https://etherscan.io/address/0x1CE7D9942ff78c328A4181b9F3826fEE6D845A97#code))
- admin address: [ethereum:0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001](https://etherscan.io/address/0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001)
- multisig threshold/signers: 2/4
---
- upgradeable component: `Administrator` ([ethereum:0x9305a0cc13293b69deE0B9d281D21144b029BdFf](https://etherscan.io/address/0x9305a0cc13293b69deE0B9d281D21144b029BdFf#code))
- admin address: [ethereum:0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001](https://etherscan.io/address/0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001)
- multisig threshold/signers: 2/4
---
- upgradeable component: `Yield` ([ethereum:0xf4eF3ba63593dfD0967577B2bb3C9ba51D78427b](https://etherscan.io/address/0xf4eF3ba63593dfD0967577B2bb3C9ba51D78427b#code))
- admin address: [ethereum:0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001](https://etherscan.io/address/0x7c2c44a988E0B74bcaE644fC8cD1200fcF727001)
- multisig threshold/signers: 2/4


### Oracles
- [ ] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes).

- [ ] Price data is expected to be volatile (e.g., because it represents an open market price instead of a (mostly) monotonically increasing price).

### Common Manipulation Vectors
- [ ] The Rate Provider is susceptible to donation attacks.

## Additional Findings
To save time, we do not bother pointing out low-severity/informational issues or gas optimizations (unless the gas usage is particularly egregious). Instead, we focus only on high- and medium-severity findings which materially impact the contract's functionality and could harm users.

No additional findings.

## Conclusion
**Summary judgment: USABLE**

Rate provider is a standard ERC4626RateProvider that relies on totalAssets/totalSupply. All other contracts in the pipeline that are upgradeable and can directly influence the rate are managed by multisigs.
52 changes: 52 additions & 0 deletions rate-providers/yUSDRateProviderArbitrum.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Rate Provider: `ChainlinkRateProvider`

## Details
- Reviewed by: @brunoguerios
- Checked by: @mkflow27
- Deployed at:
- [arbitrum:0xb1D5c23DbfCb36864f32bc704AE4205BB9720C33](https://arbiscan.io/address/0xb1D5c23DbfCb36864f32bc704AE4205BB9720C33)
- Audit report(s):
- [Protocol Audits](https://docs.yield.fi/resources/audits)

## Context
This RateProvider is updated via the API3 product. It reports the exchangeRate of yUSD/USD on mainnet. It is read on mainnet and available as an Oracle on arbitrum.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must say I'm not able to fully grasp this API3 data source, but I'm assuming it's a standard and I replicated the findings registered on the ezETH rate provider review.
Can you guys please confirm this is indeed the case?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Bruno. Gerally speaking whenever we first took a look at a new oracle rate provider, they were reviewed as part of the review. After that if the rate is a "direct" result of a oracle price provider, we have marked it as usable. This includes oracle such as:

  • API3
  • Chainlink
  • Redstone
  • Chronicle

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In cases like this, you can refer to the review already being done at review


## Review Checklist: Bare Minimum Compatibility
Each of the items below represents an absolute requirement for the Rate Provider. If any of these is unchecked, the Rate Provider is unfit to use.

- [x] Implements the [`IRateProvider`](https://github.com/balancer/balancer-v2-monorepo/blob/bc3b3fee6e13e01d2efe610ed8118fdb74dfc1f2/pkg/interfaces/contracts/pool-utils/IRateProvider.sol) interface.
- [x] `getRate` returns an 18-decimal fixed point number (i.e., 1 == 1e18) regardless of underlying token decimals.

## Review Checklist: Common Findings
Each of the items below represents a common red flag found in Rate Provider contracts.

If none of these is checked, then this might be a pretty great Rate Provider! If any of these is checked, we must thoroughly elaborate on the conditions that lead to the potential issue. Decision points are not binary; a Rate Provider can be usable despite these boxes being checked. A check simply indicates that thorough vetting is required in a specific area, and this vetting should be used to inform a holistic analysis of the Rate Provider.

### Administrative Privileges
- [ ] The Rate Provider is upgradeable (e.g., via a proxy architecture or an `onlyOwner` function that updates the price source address).

- [x] Some other portion of the price pipeline is upgradeable (e.g., the token itself, an oracle, or some piece of a larger system that tracks the price).
- upgradeable component: `Api3ReaderProxyV1` ([arbitrum:0xE88DA976479461080072D6461128fd401B6D4Dcb](https://arbiscan.io/address/0xE88DA976479461080072D6461128fd401B6D4Dcb#readProxyContract))
- admin address: [arbitrum:0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8](https://arbiscan.io/address/0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8)
- admin type: multisig
- multisig threshold/signers: 4/8
- multisig timelock? NO
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't find timelocks in the implementation, but if it's too relevant, it would be nice if you could double check.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not every system has them. They are helpful for the reader to have but not a requirement.


### Oracles
- [x] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes).
- source: API3.
- source address: The data is sourced from multiple so called "beacons" which are a set of nodes which provide the rate data to be aggregated by the `Api3ServerV1` [base:0x709944a48cAf83535e43471680fDA4905FB3920a](https://arbiscan.io/address/0x709944a48cAf83535e43471680fDA4905FB3920a)
- any protections? The rate is calculated as the median of all the rate data "fetched" from beacons. For more information about more protections see [api3 docs](https://docs.api3.org/reference/dapis/understand/deviations.html) and consult the `updateBeaconSetWithBeacons` & `updateOevProxyDataFeedWithSignedData` functions.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here about not fully grasping API3 and replicating ezETH findings. Please confirm 🙏

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine to leave it like this.


- [ ] Price data is expected to be volatile (e.g., because it represents an open market price instead of a (mostly) monotonically increasing price).

### Common Manipulation Vectors
- [ ] The Rate Provider is susceptible to donation attacks.

## Additional Findings
To save time, we do not bother pointing out low-severity/informational issues or gas optimizations (unless the gas usage is particularly egregious). Instead, we focus only on high- and medium-severity findings which materially impact the contract's functionality and could harm users.

## Conclusion
**Summary judgment: USABLE**

This rate provider should work well with Balancer pools. API3 updates the rate on arbitrum regularly and has various protections in place to ensure the correct values are bridged accurately.
52 changes: 52 additions & 0 deletions rate-providers/yUSDRateProviderBase.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Rate Provider: `ChainlinkRateProvider`

## Details
- Reviewed by: @brunoguerios
- Checked by: @mkflow27
- Deployed at:
- [base:0xD47c15CDD7c734db321F07CB9AB1f852aE9A0b83](https://basescan.org/address/0xD47c15CDD7c734db321F07CB9AB1f852aE9A0b83)
- Audit report(s):
- [Protocol Audits](https://docs.yield.fi/resources/audits)

## Context
This RateProvider is updated via the API3 product. It reports the exchangeRate of yUSD/USD on mainnet. It is read on mainnet and available as an Oracle on base.

## Review Checklist: Bare Minimum Compatibility
Each of the items below represents an absolute requirement for the Rate Provider. If any of these is unchecked, the Rate Provider is unfit to use.

- [x] Implements the [`IRateProvider`](https://github.com/balancer/balancer-v2-monorepo/blob/bc3b3fee6e13e01d2efe610ed8118fdb74dfc1f2/pkg/interfaces/contracts/pool-utils/IRateProvider.sol) interface.
- [x] `getRate` returns an 18-decimal fixed point number (i.e., 1 == 1e18) regardless of underlying token decimals.

## Review Checklist: Common Findings
Each of the items below represents a common red flag found in Rate Provider contracts.

If none of these is checked, then this might be a pretty great Rate Provider! If any of these is checked, we must thoroughly elaborate on the conditions that lead to the potential issue. Decision points are not binary; a Rate Provider can be usable despite these boxes being checked. A check simply indicates that thorough vetting is required in a specific area, and this vetting should be used to inform a holistic analysis of the Rate Provider.

### Administrative Privileges
- [ ] The Rate Provider is upgradeable (e.g., via a proxy architecture or an `onlyOwner` function that updates the price source address).

- [x] Some other portion of the price pipeline is upgradeable (e.g., the token itself, an oracle, or some piece of a larger system that tracks the price).
- upgradeable component: `Api3ReaderProxyV1` ([base:0xE88DA976479461080072D6461128fd401B6D4Dcb](https://basescan.org/address/0xE88DA976479461080072D6461128fd401B6D4Dcb#code))
- admin address: [base:0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8](https://basescan.org/address/0x2AAE699ed04BBbD068f67a5b3C813eBB35f2c9E8)
- admin type: multisig
- multisig threshold/signers: 4/8
- multisig timelock? NO

### Oracles
- [x] Price data is provided by an off-chain source (e.g., a Chainlink oracle, a multisig, or a network of nodes).
- source: API3.
- source address: The data is sourced from multiple so called "beacons" which are a set of nodes which provide the rate data to be aggregated by the `Api3ServerV1` [base:0x709944a48cAf83535e43471680fDA4905FB3920a](https://basescan.org/address/0x709944a48cAf83535e43471680fDA4905FB3920a#code)
- any protections? The rate is calculated as the median of all the rate data "fetched" from beacons. For more information about more protections see [api3 docs](https://docs.api3.org/reference/dapis/understand/deviations.html) and consult the `updateBeaconSetWithBeacons` & `updateOevProxyDataFeedWithSignedData` functions.

- [ ] Price data is expected to be volatile (e.g., because it represents an open market price instead of a (mostly) monotonically increasing price).

### Common Manipulation Vectors
- [ ] The Rate Provider is susceptible to donation attacks.

## Additional Findings
To save time, we do not bother pointing out low-severity/informational issues or gas optimizations (unless the gas usage is particularly egregious). Instead, we focus only on high- and medium-severity findings which materially impact the contract's functionality and could harm users.

## Conclusion
**Summary judgment: USABLE**

This rate provider should work well with Balancer pools. API3 updates the rate on base regularly and has various protections in place to ensure the correct values are bridged accurately.