Wyre Forwarding Tool

[e18r]

No description provided.

[MikeD123]

Hey @e18r , thanks for putting this one in! Apologies for the delays in getting the dialogue started (it'll be back and forth from here on, fyi!).

Looks aligned with the spec, given the minimal context I'd say you got the gist of it. Nice work.
Gas costs and overall chain bloat are the main issues that you mentioned, agreed.

How would you think about storing/reusing to avoid duplicate forwarding contracts. I.e

• Would Wyre assume that checks are done on the partners side before receiving a request? Would you think that the dapp dev would know that prior to the request with Wyre?
• Would you think that Wyre should store that server side, and issue a response to the developer that no deployment is required, etc...

What happens in the following scenario?

• Partner uses forwarding tool and selects function from address.
• Contract is deployed, confirmations pending.
• Users request can't be completed due to (insert error. Payment failed, Wyre's API is down, users computer lost connection, etc....)
• Dapp developer has now paid to deploy in advance

Thanks so much @e18r

Kind regards,

Michael.

[e18r]

Hello @MikeD123, thank you for taking the time to review my work. I'll address your questions soon. Have a nice weekend!

[e18r]

Hi @MikeD123, here are my answers to your comments and questions:

Gas costs and overall chain bloat are the main issues that you mentioned, agreed.

To me, the end user's inability to use Wyre to send specific data to smart contracts is the main issue. Gas costs are a secondary issue; they are critical during congestion peaks, but rather irrelevant otherwise. However, partners should be able to customize them in Wyre's API.

• Would Wyre assume that checks are done on the partners side before receiving a request? Would you think that the dapp dev would know that prior to the request with Wyre?

Yes and yes. My proposal is that, although this is a tool developed by Wyre, it's a dapp with no (traditional) back-end that partners use to overcome some of Wyre's limitations related to interacting with smart contracts. The tool should instruct partners to make sure they introduced the right address and provide them with a UI to interact with the newly created forwarding contract to make sure everything works fine before updating the receiving address in Wyre's API.

• Would you think that Wyre should store that server side, and issue a response to the developer that no deployment is required, etc...

I think that, ultimately, this is indeed the right way. An internal development would ease the development burden on the partner's side, and also would allow end users to send specific data to smart contracts, thus solving the main shortcoming of this approach. But as I mention in the final remarks, this is a further step; it will probably take a lot more development effort on Wyre's side and more responsibility if something goes wrong. It might make sense to develop the forwarding tool first, gather feedback, make sure it is really worth it, and then undertake the development server-side.

What happens in the following scenario?

• Partner uses forwarding tool and selects function from address.
• Contract is deployed, confirmations pending.
• Users request can't be completed due to (insert error. Payment failed, Wyre's API is down, users computer lost connection, etc....)
• Dapp developer has now paid to deploy in advance

So in your scenario the partner deploys a forwarding contract and then an end user is unable to make a payment. The partner has now paid to deploy in advance? Sure, but she paid only a regular transaction fee to deploy a forwarding contract that can be reused whenever a new (or the same) end user tries to pay again. I don't see any problem here.

[e18r]

Hello @MikeD123, how are you? Do you have any other comments or suggestions? If not, please don't forget to mark the issue as "done" in Gitcoin. Have a nice day!

[alexvotofuture]

@e18r reached out to the team - will have them review and respond with any additional feedback shortly. Thanks!

[e18r]

Hello @alexvotofuture, @MikeD123, please don't forget to have the team review this. Thank you.