Allowing network fees to be paid for by a third party

Support
#1

I wanted bring up a topic I believe to be important, and this board seemed like the right place for it.
First I will run through why I believe it to be important, and then I will detail 2 different methods which I believe can achieve that goal.

‘Gasless’ Transactions

With this, I refer to not cheap transactions, but transactions that can be executed without holding the chain coin, in this case ICX, at all. This seems to be even more important with BTP and the interoperatability goals of ICX. On Ethereum, the concept is implemented via the approve method and basically allowing a 3rd party to submit ‘transfer’ transactions on your behalf. This may also be accompanied by the same ‘approve’ method allowing the 3rd party to be renumerated in some other token.

‘True’ interopterability

This heading may merely be a headline, but I believe the raw elegence of parties being able to transact via ICX while paying gas fees in the chain coin they are used to and comfortable with, and even moreso, to contrast the fees they are paying now in their current chain coin, with the fees via ICX+BTP again in their current chain coin, to be very alluring.

Creation of a service sub-industry

To actually service these gasless transactions would require services, potentially run by P-Reps or other parties that actually submit these transactions on chain.

Allow dApps to partially or fully subsidise tranctions

dApps can also choose to subsidise transactions, only in their platform token. The permutations are endless.

Method 1: Addition of an analogue to approve to the officially supported IRC token standard

Approve

The approve method comes with flaws, most notably, the initial approve requires an on-chain transaction and the limit for transfers is traditionally set to a functionally infinite value. Alternatively setting the correct limits requires a on-chain transaction each time. However it appears that there are some EIPs that may serve as references addressing this exact issue.

Strictly from a cryptographical view, there should be no difference to a message submitted to the chain from the owner of the tokens, versus a 3rd party that comes bearing a signed message from that owner.

Core developer support

I believe this functionality would greatly benefit from core developer support. This is where my lack of familiarity of the inner workings comes up so I would love any corrections here. I believe such a cryptographic operation could be fairly heavy, or even if not, trusting every token creator to implement it correctly seems risky.

Core Developer base implementation

I believe a core developer 1st party supplied implementation of that function can greatly increase adoption and trustworthiness of this method.

Static analysis

As an addition to the previous point, with such an implementation, it will be possible to test for the bare minimum in token contracts via static analysis, and this can potentially be marked in the explorer, automatically.

Method 2: Decouple submission of transactions entirely from the party submitting them to the chain

This leads on from the previous idea, and is an even more radical, but (to my untrained eye), incredibly powerful tool. With just the addition of some sort of timeout block field, to me there is no cryptographic reason that we cannot fully decouple the contents of the transaction with the person submitting it. This would allow, at a base level, all methods ever, past, present and future, to be called by submitting the signed transaction payload on behalf of someone else.
No modifications to contracts or logic would be required.
This is a superset of what is required for gasless transactions, and I cannot personally grasp the extent of its applications.

Some of the things that just come to mind

  • Order book style methods stored offchain ( I believe some dApps tried this on Ethereum?)
  • Time delayed off-chain execution of methods, without the off-chain source having access to private keys.Potentially suitable for hot-cold wallet links, similar to contract wallets.
  • Conditional execution of methods with explicit exclusions. It should be possible to sign 2 or more transactions, where only 1 of the many can succeed.

Why not just build them into contracts

I believe many of the above usecases or functionality are not unique or fresh, and have been tried by building such fuctionality into the contract itself. The raw difference in power from being able to do this natively I think is very desireable, and this automatically gives the functionality the same security confidence as the security of the underlying system itself, as it will be the system itself at that time.

Discussion

I think this capability will be extremely beneficial when the explosion of tokens comes about due to BTP. It can also allow the best possible onboarding experience, no onboarding at all. I hope this can be taken on by the experienced folk here and improved to be viable.

#2

I agree something like this would be very beneficial. ICON has fee sharing (contract operator can cover up to 100% of the transaction fee), but I believe the catch is the first transaction to register for the fee sharing would still need ICX. I like Method #1 but not sure if there any technical limitations regarding implementation on ICON. Will sit back and let some more technical people chime in – @2infiniti, @Spl3en, etc.

#3

Hey @arch good to see you here.

ICON has something called “Fee Sharing” enabled. It still requires the wallet to have some ICX in it, but through other 3rd party services, some ICX can be given to the account in order to be able to send the transaction to the network. Bridgepay.money uses this for USDS transfers I believe, which enables end-users to not need to worry about transaction fees.

I believe this would need to be offered by a 3rd party service unless we really got into the core of ICON and allowed some sort of whitelisting of assets that can be used to pay fees. But this gets really tough when calculating gas/step costs I’d think.

In theory this is possible. Balanced can offer fee sharing, cover 100% of the fees, then sell BALN when we’re out of ICX to refill it

I could totally be missing something, but I believe this feature is primarily used in Uniswap and other AMMs when supplying liquidity. It’s also used most places that users send tokens. It’s because what happens is that the user gives permission for Uniswap to take tokens from their wallet given certain conditions, rather than the wallet giving a signature to transfer the tokens to uniswap.

Though as I’m typing, I could see how this could be helpful in allowing users to pay fees in other assets. Essentially, Balanced would pull the fee-token from the users wallet, sell it for ICX, then pay the fee. However, all these operations need ICX to execute, so Balanced would need to pay for that as well.

This one I’m also not so sure about from a technical standpoint.

Overall, I agree with the importance of this, though I think there are other priorities to focus on from a core development standpoint. For now, there are “good enough” solutions that apps and services can use to abstract away the blockchain component and I’d rather see ICON core devs focus solely on BTP development for 2022.

#4

As I alluded to but maybe didn’t explicitly state under

Creation of service sub industry

Both methods merely allow 3rd parties to provide this service, not the chain itself. I also think of the creation of this sub industry to be another explicit benefit.

I have read up on fee sharing, but the issue is not the ‘amount’ of fees which fee sharing addresses, but needing any amount at all. Approve also does not address this, so what I am proposing is something beyond that, potentially incoporating features from those un-adopted EIPs linked initially.

This is the implementation I was inspired by on ETH, by doing it on a smart contract basis. But that is a a more generalised form from my suggested Method 1, which is transfer specific. I believe it is important for some level of core support because I believe if implemented via contracts, it should be in every BTP sourced token. Again, a bit of a non technical benefit beyond the ease of adoption, the ability for someone transfering their ‘home’ token, and continuing to pay gas with it, is very eye catching. Additionally, the gains in ease of adoption are magnified for ICX. Realistically, almost every CEX in existence will let someone onboard ETH to the ETH chain, but ICX does not enjoy that same status at all. Letting someone fully onboard via any BTP chain I believe will open doors quicker and faster than any other method (like direct onboarding via fiat).
In that sense, to me, regardless of the first or second method, it is a natural progression and extension of BTP.

With regards to Method 2, without putting words into anyones mouth, I was told previously that it might not be as heavy as it sounds, so I am cautiously optimistic there.

1 Like