-
Notifications
You must be signed in to change notification settings - Fork 495
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
Position descriptor #353
Position descriptor #353
Conversation
|
||
int256 constant DENOMINATOR_MOST = -300; | ||
int256 constant DENOMINATOR_MORE = -200; | ||
int256 constant DENOMINATOR_2 = -150; |
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.
why cant WETH just use DENOMINATOR
as well? I feel like ETH/WETH pools are going to be very unusual, and the pricing of them probably shouldnt matter?
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 made them different because the native currency might not always be ETH
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.
would it make sense to pass in something like wrappedNative
instead of WETH? that way for CELO, Polygon, and zksync (if we ever deploy to them) we would be able to cover both addresses?
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.
and then that way wrappedNative and native have the same priority.
we would then not care about WETH priority on those chains.
so on those chains it could be possible to display price like WETH/CELO
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.
mm thats true ok. I just hate the name DENOMINATOR_2
😂 please can you rename it? then we can keep it hahah
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.
oh i was thinking we could just remove it altogether
buffer[params.sigfigIndex--] = "."; | ||
} | ||
buffer[params.sigfigIndex] = bytes1(uint8(48 + (params.sigfigs % 10))); | ||
// can overflow when sigfigIndex = 0 |
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.
why is overflow desirable?
src/PositionDescriptor.sol
Outdated
tokenId: tokenId, | ||
quoteCurrency: quoteCurrency, | ||
baseCurrency: baseCurrency, | ||
quoteCurrencySymbol: quoteCurrency.isAddressZero() |
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 id rather this logic was inside the namer. Like SafeCurrencyNamer and then in there check .isAddressZero()
to abstract away from this contract
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.
so have the isAddressZero check inside of the namer? that's not directly related to name though. Plus, the isAddressZero check is also used for decimals
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 guess I'm wondering if SafeERC20Namer
should be called like SafeCurrencyMetadata
or something?
and then it can include
- logic for checking for isAddressZero and returning information for native
- try-catching decimals (from other comment) and returning 0 if not
src/PositionDescriptor.sol
Outdated
: SafeERC20Namer.tokenSymbol(Currency.unwrap(baseCurrency)), | ||
quoteCurrencyDecimals: quoteCurrency.isAddressZero() | ||
? 18 | ||
: IERC20Metadata(Currency.unwrap(quoteCurrency)).decimals(), |
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.
why is safe decimal fetching not needed?
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.
not sure because for name we check to see if its returned in bytes and then convert it to string.
i guess we could do something similar for uint8?
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.
not sure how likely that decimals will be in bytes tho
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.
but what if the token doesnt have a decimals function? they dont have to. I think you have to default it to 0
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.
if you look at the spec the function is optional. So you can do a try-catch and default to 0 or something
src/libraries/SafeERC20Metadata.sol
Outdated
/// @title SafeERC20Metadata | ||
/// @notice can produce symbols and decimals from inconsistent or absent ERC20 implementations | ||
/// @dev Reference: https://github.com/Uniswap/solidity-lib/blob/master/contracts/libraries/SafeERC20Namer.sol | ||
library SafeERC20Metadata { |
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.
Just a tiny nit to rename it SafeCurrencyMetadata
now that it includes native?
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.
okay nice!
WIP