Gas Sponsorship Eligibility Check increases the maxCounts of the policy.

[HatimPatwa]

Gas Sponsorship Eligibility Check API increases the maxCounts of the policy

According to my current wallet flow, when the user lands on transaction summary page where we show the amounts, gas fees etc.

Since we use smart accounts and have paymasters policies, on this page we do call the GasSponsorshipEligibily API to check for his eligibility and show on UI accordingly, and since he is on the summary page he can truthfully go back if he changes his mind about the transaction and can do so multiple times.

The issue is this API call increases the maxCountspersender cap of the policy, meaning even without actually proceeding with the transaction his eligibility gets depleted every time he visits the summary page only??

Is there a better way to check eligibility without having this side effect..

[avarobinson]

Hi @HatimPatwa,

Great callout. This is not the intended behavior for your use case. Circling back with the paymaster engineering team and will let you know if we can update this functionality or provide and alternative!

[avarobinson]

@HatimPatwa We are planning a fix for this for the v4 release of the SDK since this will include breaking changes. (See the new open issue)

In the meantime, I would recommend reducing the policy expiry time on the gas manager policy. As long as the paymaster signature is valid (which is defined by the policy expiry time), the signature will contribute to the policy limits. Once the signature expires, assuming it is not used to actually send the UO, the count per sender will go back down, not count against the limit, and the sender will be eligible again.

[HatimPatwa]

Hey Thanks for acknowledgement 👍🏻 ,

Yes, have tried the workaround already its good, but min. amount for signature expiry time is 2 min, will work for most cases but can be issue on certain cases where users maxCount is already low.

[avarobinson]

@HatimPatwa makes sense! Chatted with the team a bit more!

The best workaround would be to use buildUserOperation and cache the results rather than the check eligibility endpoint.

checkEligibilty runs the paymaster middleware and requests a paymaster signature. If we were to remove this functionality, the check would not be accurate. It's entirely possible that eligibility will become invalid because some other sponsorship will take place before it does.

Instead, you can use the result of buildUserOperation with error catching to check for eligibility and cache the UOStruct returned (if eligible) for the user so that it can be actually sent if the user decides to proceed from the "summary" page. This will avoid requesting sponsorship multiple times and potentially making the sender ineligible. If the buildUserOperation endpoint throws a 4XX, this means the sender is ineligible. If buildUserOperation returns a successful response, it will include a UserOperationStruct (unsigned UO), that you should cache and then use to sign and send if the user proceeds.

The v4 improvement will have checkEligibilty return a UOStruct or false directly, but will still need to contribute to policy limits in order to be an accurate on-chain check.

How does that solution sound?

[HatimPatwa]

@avarobinson, Yeah Makes sense, could be a good potential solution for various use cases,

Though i should point out more on the summary page requirements.

1. It shows Gas Fees (fetched from buildUserOpernation ).
2. Checks for Gas Sponsorship.

point 1 needs to be run whether or not he is eligible cuz user can ofcourse pay gas fees normally,
The solution you have provided (to run buildUserOperation) will result in an error if he is ineligible, and return basically no gas fees, rendering my summary page unusable.

Although a temporary solution for this would be that i run first buildUserOperation with gas policy id injected,
which will have two outcomes.

1. The user is eligible and we show on UI respectively, and display 0 gas fees.
2. The user is ineligible, buildUserOperation fails with 4XX. Now, I run buildUserOperation again without the gas policy ID injected, which will provide the necessary gas fees to be shown on the UI.

just a heads up, The point 2 will be time-consuming due to running 2 buildUserOperations.

What are your thoughts on this @avarobinson

[moldy530]

just a heads up, The point 2 will be time-consuming due to running 2 buildUserOperations.

I don't think the time cost of this is that high as building UOs is pretty quick. If speed is a concern here then I would actually do these 2 calls in parallel as:

const [sponsoredUo, nonSponsoredUo] = await Promise.all([
  sponsorshipClient.buildUserOperation(...).catch(() => null),
  nonSponsorshipClient.buildUserOperation(...),
]);