Adds PriceCappedApi3ReaderProxyV1 #14
Conversation
acenolaza
force-pushed
the
13-price-cap-stable-api3readerproxyv1
branch
from
9faf9c3 to
3127a39
Compare
WDYT of also checking lower/upper bounds in constructor to prevent setting values that might not make sense? We could even add a helper function like isCapped() that might come handy for external callers |
There was a problem hiding this comment.
WDYT of also checking lower/upper bounds in constructor to prevent setting values that might not make sense? We could even add a helper function like isCapped() that might come handy for external callers
Yeah, that makes sense. Add it please.
About the name
I'd call it PriceCappedApi3ReaderProxyV1. I dislike the aave-capo name (the "stable" part is poorly named imo).
acenolaza
force-pushed
the
13-price-cap-stable-api3readerproxyv1
branch
from
778c438 to
579ac4b
Compare
| /// @param proxy_ IApi3ReaderProxy contract address | ||
| /// @param lowerBound_ The minimum price (inclusive) this proxy will report | ||
| /// @param upperBound_ The maximum price (inclusive) this proxy will report | ||
| constructor(address proxy_, int224 lowerBound_, int224 upperBound_) { |
There was a problem hiding this comment.
I ended up not checking the bounds against the current proxy value for 2 reasons:
- we are already trusting the
deployerto provide a valid proxy value - the proxy value might be outside of the lower/upper range and we still want to deploy to be able to apply the cap and return the either of bounds values.
| revert LowerBoundMustBeNonNegative(); | ||
| } | ||
| if (upperBound_ <= lowerBound_) { | ||
| revert UpperBoundMustBeGreaterThanLowerBound(); |
There was a problem hiding this comment.
Should be UpperBoundMustBeGreaterOrEqualToLowerBound. But maybe just InvalidLowerBound and InvalidUpperBound so that it remains within 32 bytes.
There was a problem hiding this comment.
Are you suggesting that both can be equal meaning that the contract will thenenforce fixed price comparison (constant price configuration)?
There was a problem hiding this comment.
btw AFAIK there isn't a 32 bytes restriction on error names 🤔 (compiler internally uses the bytes4 selector)
There was a problem hiding this comment.
Are you suggesting that both can be equal meaning that the contract will thenenforce fixed price comparison (constant price configuration)?
Yeah, I think one might use this contract as a special case for a constant feed (although for that a more efficient version might make sense).
btw AFAIK there isn't a 32 bytes restriction on error names 🤔 (compiler internally uses the bytes4 selector)
I wasn't sure and remember this is the case with require errors. Feel free to leave as is.
acenolaza
changed the title
Based on https://github.com/bgd-labs/aave-capo/blob/main/src/contracts/PriceCapAdapterStable.sol