You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the reasons why PullPayment is useful is that by using _asyncTransfer, the 'payment' is decoupled from any possible recipient contract logic, and any code executed on an Ether transfer (e.g. a fallback function) will only run once withdrawPayments is called.
However, said function calls Escrow.withdraw, which does a transfer to the recipient. This means only 2300 gas is forwarded, which is only enough to e.g. log an event. This severely limits the usefulness of PullPayment (and Escrow): we should change this transfer for a call, along with the required checks (e.g. make sure the call actually succeeded, etc.).
The text was updated successfully, but these errors were encountered:
We've been discussing this a bit, and it's not entirely clear whether or not this could inadvertently create unsafe reentrant scenarios, so we're pausing development on this one until we have a clearer idea of the consequences of our decision.
One of the reasons why
PullPayment
is useful is that by using_asyncTransfer
, the 'payment' is decoupled from any possible recipient contract logic, and any code executed on an Ether transfer (e.g. a fallback function) will only run oncewithdrawPayments
is called.However, said function calls
Escrow.withdraw
, which does atransfer
to the recipient. This means only 2300 gas is forwarded, which is only enough to e.g. log an event. This severely limits the usefulness ofPullPayment
(andEscrow
): we should change thistransfer
for acall
, along with the required checks (e.g. make sure the call actually succeeded, etc.).The text was updated successfully, but these errors were encountered: