PoC rate ratifier#841
Conversation
| /// @dev Computes the EIP-712 hash struct of a RateOffer (offer with `tick` replaced by `rate`). | ||
| function hashRateOffer(Offer memory offer, uint256 rate) internal pure returns (bytes32) { |
There was a problem hiding this comment.
We could also factorize with hashOffer
| bytes constant RATE_OFFER_TYPE = | ||
| "RateOffer(Obligation obligation,bool buy,address maker,uint256 start,uint256 expiry,uint256 rate,bytes32 group,bytes32 session,address callback,bytes callbackData,address receiverIfMakerIsSeller,address ratifier,bool reduceOnly,uint256 maxUnits,uint256 maxSellerAssets,uint256 maxBuyerAssets)"; | ||
| /// @dev keccak256(bytes.concat(RATE_OFFER_TYPE, COLLATERAL_PARAMS_TYPE, OBLIGATION_TYPE)) | ||
| bytes32 constant RATE_OFFER_TYPEHASH = 0x90e9f9e41e2cb91ddebe5f4e0924a3f0bc32d2c1048017a241339fabf364502c; |
There was a problem hiding this comment.
We could reuse OFFER_TYPEHASH and there would be no risk of collision, since EcrecoverRatifier always uses a Merkle tree. Also the current typehash doesn't correspond to a concrete struct.
Still prefer current code slightly, as it separates things even more explicitly. Minor benefit: a future ratifier could use a signature over a concrete Offer without risk of collision with this ratifier
There was a problem hiding this comment.
There is no collision anyway because EIP712 includes the contract address right?
There was a problem hiding this comment.
right, no collision in what is signed since the ratifiers are the verifyingContract as defined in EIP712
Still could be a bit confusing to have a tick field hold a rate
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Co-authored-by: Adrien Husson <adhusson@gmail.com> Signed-off-by: Quentin Garchery <garchery.quentin@gmail.com>
2 participants
Notes:
priceToTick)uint256type)