-
Notifications
You must be signed in to change notification settings - Fork 75
feat(hubPool): Add sync method and liquidity utilization #26
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
Conversation
chrismaree
commented
Feb 8, 2022
- nit
- nit
- nit
- Update contracts/HubPool.sol
- review nit
- review nit
- feat(hubpool): Refactor hub pool to use 1D bitmap integer
- nit
- WIP
- review nit
- review nit
- nit
- nit
- nit
- nit
- nit
- nit
- WIP
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- WIP
- nit
- nit
- WIP
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- nit
- feat(slack-config): Add sync method and liquidity utilization
Co-authored-by: Matt Rice <matthewcrice32@gmail.com>
Signed-off-by: chrismaree <christopher.maree@gmail.com>
Signed-off-by: chrismaree <christopher.maree@gmail.com>
Signed-off-by: chrismaree <christopher.maree@gmail.com>
Signed-off-by: chrismaree <christopher.maree@gmail.com>
Signed-off-by: chrismaree <christopher.maree@gmail.com>
Signed-off-by: chrismaree <christopher.maree@gmail.com>
| struct PooledToken { | ||
| address lpToken; | ||
| bool isEnabled; | ||
| uint256 liquidReserves; |
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.
re-order for better packing.
| } | ||
|
|
||
| // Added to enable the BridgePool to receive ETH. used when unwrapping Weth. | ||
| function _sync(address l1Token) internal { |
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.
this is numerically identical to v1.
|
|
||
| emit WhitelistRoute(destinationChainId, originToken, destinationToken); | ||
|
|
||
| // TODO: Should relay message to L2 for destinationChainId and call setEnableRoute(originToken, destinationChainId, true) |
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 remove comment? is this TODO resolved?
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.
mistake in merging. added back.
|
|
||
| ExpandedIERC20(pooledTokens[l1Token].lpToken).burnFrom(msg.sender, lpTokenAmount); | ||
| // Note this method does not make any liquidity utilization checks before letting the LP redeem their LP tokens. | ||
| // If they try access more funds that available (i.e l1TokensToReturn > liquidReserves) this will underflow. |
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.
this underflow is expected + fine in this case right?
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.
yup! solidity 8 protects against underflows so this simply reverts.
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.
Is it possible for this to underflow, but the contract to have enough tokens to transfer out?
contracts/HubPool.sol
Outdated
| return _liquidityUtilizationPostRelay(l1Token, 0); | ||
| } | ||
|
|
||
| function liquidityUtilizationPostRelay(address l1Token, uint256 relayedAmount) public returns (uint256) { |
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.
nit make this nonReentrant also
nicholaspai
left a comment
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.
LGTM
mrice32
left a comment
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.
LGTM!
|
|
||
| ExpandedIERC20(pooledTokens[l1Token].lpToken).burnFrom(msg.sender, lpTokenAmount); | ||
| // Note this method does not make any liquidity utilization checks before letting the LP redeem their LP tokens. | ||
| // If they try access more funds that available (i.e l1TokensToReturn > liquidReserves) this will underflow. |
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.
Is it possible for this to underflow, but the contract to have enough tokens to transfer out?
This is another case of a variable being missed when the naming was changed. The data availability layer isn't bound to IPFS and will probably be something else anyway. This is within the scope of the UMIP, the contracts don't need to be specific about the underlying technology that is used.