-
Notifications
You must be signed in to change notification settings - Fork 11
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
feat(lazer): Update EVM example to attach fee for verification #39
Conversation
lazer/evm/test/ExampleReceiver.t.sol
Outdated
receiver.updatePrice(update); | ||
vm.deal(consumer, 1 ether); | ||
vm.prank(consumer); | ||
receiver.updatePrice{value: pythLazer.verification_fee()}(update); |
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 I attach more fee and call verifyUpdate{value: msg.value}()
the refund fails and I get the following error:
If I instead call verifyUpdate{value: 1 wei}()
, then all calls succeed but the ending balances are all wrong.
If I attach more fee and then comment out the refund in updatePrice
, the final assert fails saying that consumer has the full amount of ether. Yet, pythLazer was still paid, and now the receiver contract got paid the 9 wei difference. So, money was made out of thin air.
I think I might be missing something simple, but not sure what it is...
Things I can think of which might matter are: Payable vs non-payable addresses and contracts with receive/fallback functions.
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.
@Riateche helped me out. The issue was that when I called vm.prank() before calling the updatePrice function, I was calling pythLazer.verification_fee() to get the fee to attach. This consumed the prank and led to some other default address making the call for verifyUpdate(). This default address doesn't have the receive/fallback functions so it fails. But storing the fee as a uint256 and making sure prank correctly targets the actual call, the test succeeds.
No description provided.