Discussions for NEP5 tokens acceptance as network fees

[vncoelho]

Consensus nodes could also publish the tokens and rate they are accepting between that NEP5 token and GAS in order to accept them as network fee. The maximum value of all ratio could be used as well as a matter for paying network fee.

However, system fees should be kept in GAS in my opinion.

[igormcoelho]

I think this reduces the utility of GAS, so I dont think it's very good... its also challenging to.find a price that all CN agree (even taking Max, some may accept different tokens). The most complicated point is that, without Storage.Add() proposal (which was complicated and rejected) I dont see any other way to implement this. Gas control is natively handled, thats why it works on Verification. I dont know how user nep5 could do the same (without storage.add).

[vncoelho]

Reduces just a little bit because system fees are going to be kept in GAS, which are a principle of the Smart Economy.

However, I see network fees as more optional, consensus can pick based on that. The speaker is the one that receives the network_fees, yes? In this sense, we should pick based on the tokens proposes, if the ratio is enough to satisfy his criteria. That would be quite interesting...however, it do not need to be implemented now, it could be something for 1-2 years from now.

We could have a field for the hash of the NEP5. This would be the same hash that the CN published on the Native contract as willing to accept as network_fee at a given ratio.

[shargon]

I prefer only gas, as @igormcoelho said, this reduce the utility of GAS

[vncoelho]

@shargon, let's just discuss this a little bit more. I am also becoming in favor of this because of 2.3.

1.1. Utility of Gas is mostly designed for Generation -> Use -> SysFees Redistribution 1.2. In this sense, NetFees are like a consequent use for guiding choice of Consensus Nodes.

2.1. By allowing NEP5 tokens as NetFees, project could be more motivated to become a CN. Imagine NEX, SWTCH, among others? 2.2. NetFees are just a selection mechanisms that CN receives as incentives, they could use this for guiding their transaction selection. 2.3. On the other hand, this may cause unfair selection of transactions. Currently, anyone could audit the selection based on the state of mempool (not perfectly, because the node could justify that it was not aware of other txs.

In summary, I believe that even sysfees could be as NEP5 if the CN ensures the swap. In this sense, CN wallet should always have GAS for swapping the accepted token to sysfees...aheuaheuaea

Anyway, it was a discussion...I believe it is good to thing both because of possible feasible implementation but also for having a more clear idea about GAS utilities and needs.

[igormcoelho]

The point of 2.1 is really interesting, projects fighting to be CN, to increase utility of their own tokens :thinking: But still, I only see this happening if we have dozens of CN (which is impractical from the voting perspective... how to choose among 100?)

A much "easier" ( :smiling_imp:) way to implement this @vncoelho, is by simply "tipping" the wallets of CN :joy: You submit a tx that gives "a little-bit" of tokens directly to some specific CN addresses (on their own token kinds)... don't you think it would give you "some priority"? even failed tx would pass this way kkkkkkkk corrupt CN... let's not transform this into "regular" politics ;)

I think network fee based on GAS, with clear and simple rules, is much "fairer" from a protocol perspective, since it's not a hardware-stressing mining activity, but more like a "collaborative orchestration" activity.

[lock9]

Hello, I think we should use GAS only. I think that this is what GAS is meant for. Other tokens have different purposes.

[EdgeDLT]

In principle I like the idea of allowing fees to be paid using NEP-5 tokens because it could make life easier for token holders. But it is unnecessary complexity and reduced usage of GAS for a feature that can already be solved in the background by a service provider like a wallet or exchange.

[igormcoelho]

Some integrated nep5 <-> gas gateways may also solve the problem... I like @EDGEDLT description of the issue. We may have a NEP for "Integrated gateways for GAS", such that we validate those on tx transmission time. Nothing different from a regular DEX connected to the chain via a NEP... better partership with existing DEX for this.

On tx netfee verification time: user promises nep5 to dex -> dex promises gas for netfee -> tx goes.

It's like relaying a tx via a DEX.

It's interesting and challenging in.fact... user should partially sign the tx, without network fee and sender values (currently not possible), and DEX would send this tx together with filled it network fee value, so it goes. To do that, witness should be valid for specific Script (not whole tx), and Tx would need multiple scripts. DEX would only glue these scripts together and send tx...

[vncoelho]

I agree, the third layer could really cover this point in an efficient way. As discussed, for system fees it would be hard to accept other tokens, since it is a dynamic of the Ecosystem. Furthermore, CN make the swap would not be so efficient as a DEX in the way you are describing.

We would just be left with network_fee, which could really be accepted at any rate. However, it would open a wide margin for transactions selection in arbitrary order (according to CN wishes), which is easier to be detected as it is nowadays only with GAS.

[igormcoelho]

Let's keep this open, I guess more people still interested in the subject.

[vncoelho]

Agreed, brother.

[corck]

To jump into the discussion. I see the free transactions, or better said the lack of relying on an underlying currency one of the biggest advantages of NEO. Something I currently point out in talks to other people. "You just can walk into our store, buy our Gold backed, token, 15 seconds later you have it and can send it further to your nephew." No need to sell them ETH / GAS, even explain it to them. If that changes it might be a hurdle, I really want to avoid.

So ideally I'd like to cover the transaction costs using my NEP-5 token, or through another means. As a NEO holder myself, I think staying with GAS might be the best option otherwise it will get really complicated if there are 1000s of NEP-5s around and half of them are not really traded publicly as there's no need for it. Why should a Node accept a token it never heard of.

I like the NEP for "Integrated gateways for GAS" idea of @igormcoelho, in the simplest case, we as a company could have such a SC that we fill up with GAS and invoke on every transaction (and exchange the NEP-5 to GAS) to cover these costs. Thinking further, oracles could get the exchange rate of both tokens dynamically. I think we can't rely solely on DEXes here, as token might not be traded publicly (no need for it) or they might not be listed for other reasons. So a standalone SC should definitely be the way to go. Having that with oracles can really be a game changer in building autonomous, decentralized systems.

I was brainstorming on other ideas, like working on a loyalty system on a blockchain, but requiring people to have GAS/ETH/XYZ to send tokens is a showstopper currently on most of the ideas. In most cases I think having such a simple NEP-5 to GAS conversion could be the simple solution to it, until we have a layer-2 in place, which might solve it.

[igormcoelho]

You got a very strong point that I just forgot to highlight... DEX are exchanges afterall, so a dollar cent operation would be required to be reported, papers filled, perhaps tax paied, in countries like ours (Brazil is trying to register and control all possible tx in all blockchain platforms...). No one can do that for just a few cents.. other issue is that,as DEX are exhanges, its likely they require KYC for simple dollar cent operation. If we manage to.internalize such "bureacratic" requirement during a transparent GAS/NEP5 operation, it will be very valuable for platform users. Transforming GAS fee in equivalent NEP5 fee transparently would definitely simplify.much usage,so best thing is having these gateways as non-DEX,just utilities for tx transmission on Neo network.

[shargon]

Holders doesn't want other coin, they want Gas or neo, otherwise i can create a contract with infinite tokens, and pay with this

[igormcoelho]

As long as your contract backs up up its own user operations in GAS, you can do it. In some moment, it will run out of gas, if its not refilled somehow. In the proposal, external gates would only sign corresponding missing witness, as long as script is correct (and perhaps require holding some of user nep5, as guarantee).

[igormcoelho]

One practical modeling for GAS gateways: https://github.com/neo-project/proposals/issues/101