With this operation, a deployed contract may inform user, aka "sender", its willingness to sponsor some GAS during execution time for the intended operation methodName.
Example:
Some NEP-17 implements this NEP and provides that "transfer" gives extra 0.5 GAS for the user. This check can be done during test time (as a "const" operation), and then, User Wallet then should be able to estimate how much GAS it needs to reach the point of method invocation, including sponsorValue GAS cost. On the other hand, contract that implements this NEP, should use sponsorValue as the first operation in the method, and should throw exception if not willing to provide GAS (so, "transfer" tests, such as balance check, could be put inside sponsorValue, thus being paid by the user together with network/tx fees).
Now that we have Refuel mechanism, I propose that we discuss some NEP for Sponsored Operations, with the following operation:
sponsorValue(string methodName, object[] args, Hash160 sender) -> BigInteger "GAS"With this operation, a deployed contract may inform user, aka "sender", its willingness to sponsor some GAS during execution time for the intended operation
methodName.Example: Some NEP-17 implements this NEP and provides that "transfer" gives extra 0.5 GAS for the user. This check can be done during test time (as a "const" operation), and then, User Wallet then should be able to estimate how much GAS it needs to reach the point of method invocation, including
sponsorValueGAS cost. On the other hand, contract that implements this NEP, should usesponsorValueas the first operation in the method, and should throw exception if not willing to provide GAS (so, "transfer" tests, such as balance check, could be put insidesponsorValue, thus being paid by the user together with network/tx fees).