Frontend: support subsidized transfers #2031
Conversation
There was a problem hiding this comment.
One issue regarding the decoding from local storage. Other than that, the implementation looks perfect. Just a few more things that came to my mind...
Did we ever think of showing the paid fees in the transfer history?
Imo, before going live, we should definitely be able to switch to use the request manager when the FeeSub contract is drained. I don't mind whether we provide a check on contract-level or on the frontend.
Ah and we should check why the build fails in the CI before merging.
GabrielBuragev
force-pushed
the
frontend/support-subsidized-transfers
branch
from
2093b4d
to
5e17fda
Compare
GabrielBuragev
changed the title
|
Additionally, tests for the |
Good that you asked that. Today I wanted to see exactly that (the fees) in my transfer history. :-) |
|
Here you go: #2042 |
bilbeyt
force-pushed
the
frontend/support-subsidized-transfers
branch
from
ab063af
to
4663f47
Compare
GabrielBuragev
force-pushed
the
frontend/support-subsidized-transfers
branch
2 times, most recently
from
7c3c266
to
19a991b
Compare
Previously, we only needed to generate typings for the @beamer-bridge/deployments npm package. That changed with the new `FeeSub` contract. The decision was to not keep this contract as a part of our deployments folder/npm package so we have to copy/paste the ABI for this contract whenever it changes. Due to this reason, we had to extend the `generate-types` npm command to detect and use this folder as well. In order to keep the output folder structure of this command simple, i used the `typechain` command twice so it doesn't try to come up with a complex folder structure for the outputted contracts which breaks the module import resolution in our codebase.
In order to be able to easily determine if a transfer can be subsidized, we implement a view function that enables us to do exactly that.
GabrielBuragev
force-pushed
the
frontend/support-subsidized-transfers
branch
from
19a991b
to
a339140
Compare
Closes #2026
In order to test it, you need to add a
feeSubAddressin theconfig/chains/421613.jsonchain config file.The
feeSubAddressproperty inside the config file will be used as a toggle point for this feature on the frontend.If the
feeSubAddressis not defined in the chain config file, then the app resumes with normal operation (doesn't do any checks agains theFeeSubcontract).I used to test with the following FeeSub contract deployed on Arbitrum: https://goerli.arbiscan.io/address/0xda8015d66c30d6a3d4dd112fd175a9ee3ff38c74
One thing worries me, which was ignored in order to speed up the development process of this feature:
When the
FeeSubcontract is defined in a chain config file, but it has not enough funds to subsidize a transfer, the transfers created on the frontend will continuously fail until one of the following was done:FeeSubproperty was removed from the specific chain config file and the frontend is re-deployedFeeSubcontract on the specific chain so it can continue subsidizing transfersWe cannot easily prevent this on the frontend since:
We could do these checks on our end, but i do believe that this should be done on contract level instead.