There is common problem of Web3 applications in need of getting somewhere money for even initial chain interactions, but workaround exists and appears as somebody's else gas and fee expenses.
Possible Solution
Smart contract solution
Create some program that will represent some "gas station" allowing usage of reserved gas for specified users.
+ Fully on-chain
- Requires a lot of interactions
- Requires user to pay fee and minimal gas limit to interact the program (Doesn't totally solve initial problem)
Extrinsic solution
Create some extrinsic that will be signed and send from user A and accept user B identifier and call that he wants to execute on-chain by accepting it's encoded and signed (for verification of call) data.
+ Properly solves funds management problem
+ More flexible and wide solution
+ Doesn't require excess program calls: so will be executed faster due to absence of second queue waiting
+ - May be a bit unusual for substrate-around developers and users
+ - Requires a lot of documentation and considers about who should receive unused funds (mostly about just implementation)
Fund-related solution
Allow on the protocol level delegate ability to use some funds as it realised for fungible tokens to avoid just granting for fees.
techraed
commented
11 months ago
Problem to Solve
There is common problem of Web3 applications in need of getting somewhere money for even initial chain interactions, but workaround exists and appears as somebody's else gas and fee expenses.
Possible Solution
Smart contract solution
Create some program that will represent some "gas station" allowing usage of reserved gas for specified users.
+Fully on-chain-Requires a lot of interactions-Requires user to pay fee and minimal gas limit to interact the program (Doesn't totally solve initial problem)Extrinsic solution
Create some extrinsic that will be signed and send from user A and accept user B identifier and call that he wants to execute on-chain by accepting it's encoded and signed (for verification of call) data.
+Properly solves funds management problem+More flexible and wide solution+Doesn't require excess program calls: so will be executed faster due to absence of second queue waiting+ -May be a bit unusual for substrate-around developers and users+ -Requires a lot of documentation and considers about who should receive unused funds (mostly about just implementation)Fund-related solution
Allow on the protocol level delegate ability to use some funds as it realised for fungible tokens to avoid just granting for fees.