-
Notifications
You must be signed in to change notification settings - Fork 6
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
Paymaster audit fixes #33
Changes from 13 commits
882313f
fa1eecd
5c3d321
29c20f5
c271037
bcd03b0
0af3cfa
b638f38
f489239
9a80d8b
ce78655
2ff989d
31db76c
ba11a61
e2086b2
55d4dae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,7 +5,6 @@ multiversx_sc::imports!(); | |
pub mod forward_call; | ||
const FEE_PAYMENT: usize = 0; | ||
|
||
/// An empty contract. To be used as a template when starting a new contract from scratch. | ||
#[multiversx_sc::contract] | ||
pub trait PaymasterContract: forward_call::ForwardCall { | ||
#[init] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can't add a comment on the unmodified code, but to have a safer approach regarding the fees in the forwardExecution endpoint, I would change the fee_payment nonce for the relayer_addr to fee_payment.token_nonce, instead of hardcoding the value 0, as the code would crash (without having a custom error) if the user would send an SFT. Now, if you want to allow only fungible tokens, do the check that the payment's nonce is 0. But still, I would keep the token_nonce approach. |
||
|
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.
Maybe rename to FEE_PAYMENT_INDEX for more clarity.