Implement Fallback to User Balance for Transactions When Relayer Fails #223
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Pessina
requested review from
benmalcom and
hcho112
and removed request for
benmalcom
|
While I was looking at the code, it comes to my mind that, would it be nicer if:
TDLR, I don't think just assume that user wants to transaction with their account balance is a good thing. It is possible that either they may not want this feature nor not being aware of this will happen. (Some user may even think this is a scam because they may expect using fast-auth + relayer would pay the gas but it ends up using user's balance) Ideally, we should implement both where:
and need to rebase and fix yarn lock file |
|
@hcho112 Good point! For the developer part, I agree with you, and it would be beneficial to allow developers to configure whether they want users to pay for the transaction in case the relayer refuses the transaction. We can bring this up for discussion. The issue here is that we would need to change the wallet interface. From what I understand, this requires a NEP, right? I propose we handle this later as a separate ticket. However, for the user part, I believe they are already aware of the fees as it's already stated on the iFrame of the fast-auth-signer. 
As you can see, the total already includes the fees. Users assume they will pay the gas, but sometimes they won't. It's a positive surprise in that case. What do you think? |
|
@hcho112 regarding the multi-chain, this PR doesn't touched multi-chain code, it's only for the |
|
@Pessina In terms of making change on |
|
Agree that it's great to have a fallback mechanism instead of just having the transaction fail. If we don't know beforehand, maybe we could add a checkbox (default ON) that says something like "Use my balance for this transaction if sponsoring is not available". Similar to this toggle on iOS that tries to send your text via SMS when iMessage isn't available:
What do you think @nall-near? |
|
I think the context of why the transaction fails is important. For example, in the case of un-allowed actions, or non-whitelisted receiver ID, these hurdles could be intentional to protect the user from carelessly signing transactions. Similar to Dio's question above,
Regardless, I agree with @diogoortega that we need to inform the user if something is different/unexpected about signing, and try to be as explicit as possible. Let me know if I'm overthinking this, we don't need unique messaging for each use case, but I do want to alert the user with some caution if they are trying to do something outside the allowed context of the relayer as well as when they may need to pay for the fees themselves. I also like Dio's suggestion to have a toggle within the dapp context settings that allows users to confirm automatically. |
|
We could use something like this for the signer app, it could also be a little less scary if that makes sense to y'all. |
|
@diogoortega and @nall-near, thank you for all the input. Let me try to answer your questions, and please let me know if anything is unclear.
We will only know if the transaction will be "sponsored" after sending it via the relayer and checking the response. Regarding the custom error messages: yes, it's possible. The relayer returns a custom message with some clues about why it failed. I can double-check the messages so we can customize them accordingly.
No, we only find out after calling the relayer. We can set up a call with the relayer team to discuss approaches for obtaining this information before calling the send transaction endpoint on the relayer. However, I would advise doing this in a separate PR as it may take time.
Note: User confirmation is only possible when the transaction requires the FullAccess Key. For the FunctionCall Key, the dApp holds the key and can sign transactions on behalf of the user without confirmation. Currently, we do not have a UI for the FunctionCall Key. We can develop one, but the dApp would still be able to bypass this confirmation if desired. Let me provide more details about the flow: 1 - FullAccess Key:
2 - FunctionCall Key:
The main difference is that with the FullAccess Key, we display the iFrame for user confirmation. In the second scenario, we do not have a UI to ask the user to confirm if they want to use their own balance as the dApp holds the FunctionCall Key and can sign transaction on behalf of the user without asking. |
|
I just had a chat with @DavidM-D about this issue, and he came up with a nice suggestion that we think may simplify the The dApp probably knows if the transaction can or cannot be relayed, so we could expose two endpoints for the transaction signature:
By doing this, we can create two distinct user interfaces to communicate the transaction details to the user, rather than having a single interface that attempts to handle both scenarios with a toggle box or by prompting the iFrame twice for confirmation. What are your thoughts on this approach? Also, I asked him how hard it would be to implement the feature to check if the relayer will accept/refuse the transaction before sending it. He said it will be complicated to do that, so it would be better if we avoid this path. |
packages/near-fast-auth-signer/src/components/Sign/Sign.styles.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
@Pessina I have tested them according to your recommendation but I couldn't get any of them working properly. Maybe perhaps we should try to test this together? meanwhile can you share with us video recording of working version if you can get this working locally?
|
@hcho112 I believe the error you are facing it's because you didn't linked the local In order to do that you need to run Those are the recordings: Screen.Recording.2024-06-11.at.11.27.01.movScreen.Recording.2024-06-11.at.11.24.59.movIf you still face issues, please let me know and we can work on this together. |
This PR introduces a fallback mechanism for transactions when the relayer service fails to relay them due to specific issues such as actions not being allowed or the sender/receiver not being whitelisted. In such cases, the transaction will be retried using the user's own balance, ensuring that the transaction can still be processed without dependency on the relayer's current state or configuration.