-
Notifications
You must be signed in to change notification settings - Fork 82
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
Engine method call
has no way to attach ETH
#309
Comments
We can have a custom borsh deserialiser that reads the first two fields, and if there is some extra data in the end it reads it as the value (attached eth), this way we preserve backwards compatibility. |
Finally find a way to overcome orphaning rules difficulties and made a PR. Here's the feature branches: Hope everything will work fine in current CI configuration ('cause not sure about this, due to toolkit update). This is my first PR, I was doing my best, so don't hit me hard. =) Anyway, I rely on your advises and support guys! |
I was radically change and simplify logic (following KISS & DRY), using more straightforward and explicit way with relying on generic borsh deserialization ( Seems like now it works more reliable, rather than when using |
The method
call
is supposed to be equivalent to the methodsubmit
, except allows interacting with the EVM from a NEAR account as opposed to an Aurora account. Howevercall
does not have any way to attach an ETH balance to the transaction which greatly limits its usefulness.I propose we add a
value
field toFunctionCallArgs
struct to address this issue.Note: to preserve backwards compatibility we may wish to accept both a version of
FunctionCallArgs
with and without the new field; in the case it is not given it defaults to 0 (the current behaviour). This may or may not be possible since borsh is not a self-describing format. If there are currently no mainnet usages ofcall
then maybe the breaking change is fine.The text was updated successfully, but these errors were encountered: