-
Notifications
You must be signed in to change notification settings - Fork 929
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
Allow compensation for relayed msg.value ETH #163
Comments
Hey, thanks for the proposal. Currently I would not make |
What's multisend? |
https://github.com/gnosis/safe-contracts/blob/development/contracts/libraries/MultiSend.sol (tests: https://github.com/gnosis/safe-contracts/blob/development/test/multiSend.js) This is a contract that can be used via a Adding this refund to the core contract is a little out of scope (in my opinion). Assuming the user wants to refund the ETH in DAI, then we need to somehow provide a conversion rate between ETH and DAI. Additionally we need to define what happens if the internal transaction (that should use the ETH send along) fails and therefore the ETH is left on the Safe (which is undesired if you have a DAI only Safe). So there are quite some edge cases which need to be properly defined. |
Hmm, we already have to convert between dai and Eth anytime a user pays someone’s gas, what’s different here? |
So the |
Will not be fixed as we plan to remove the payment logic in the next major version: #197 |
Update imports and docs
Context / issue
It would be very useful for the contracts (and the relayer) to support compensation for the tx sender sending the ETH specified by msg.value. This is particularly relevant for wallets where the intention is that they never hold ETH and compensate the tx sender entirely in DAI.
Proposed solution
An additional param provided to the
execTransaction
call specifying that the msg.value should be included in thehandlePayment
method. It would simply add the msg.value to the total value of ETH needing to be paid by the wallet to the refundReceiver.As a separate but related feature the relayer would also need to send along the msg.value in its TX when executing the safe tx.
The text was updated successfully, but these errors were encountered: