Charge extra gas not deduct coins from account

[ethanfrey]

Alternate solution to #10

After modelling some contracts using the new tokenfactory interface, I think charging fees will mess up composability, the same way Terra transfer tax caused all kinds of headaches for contract devs. Let me explain:

If I as an external user create a token, it deducts a fee from my account. If I don't have the tokens in my account, it fails. That makes sense.

If I instantiate a contract that creates a token (eg AMM that uses tokenfactory for the LP token as this is a clear example), it will charge the contracts. Thus, for any action that will create a token, the contract must query the price and ensure that I sent at least that price (along with any other charges it wants to ask for).

Now, let's look at an AMM Factory contract. It has a message "CreatePool", that will instantiate the AMM. Now, it must pay the AMM as part of that to cover the token cost. So, this message (which doesn't directly create a token), must be aware of the internals of the other, and ensure the user pays the proper amount to the Factory, so the factory can pass that along to the Pool as part of the initialisation. Getting a bit tougher.

But let's get worse... Imagine I implement cw20-ics20 so that the remote side issues native tokens (via token factory) not cw20 tokens when it receives my packet. That means that the first time a given token is transferred over a given channel, a CreateDenom message will be triggered. Which will charge... who? The contract itself, from the locked funds of other? The relayer account??? This is another level of complexity beyond the AMM Factory and I have no idea how to properly account for it here.

---

My solution: do not charge a fixed fee (deducted from caller account), but rather charge a rather large gas fee (say 2 to 20 million gas). This should be a sufficient cost to prevent spam (and more expensive than creating a token via ibctransfer packet). It also ensures that the tx signer pays the fee and we don't need to account for this in every level of every contract that interacts with someone who now creates a token. It just shows up in Keplr as an extra cost to the user signing the transaction. Maybe an unexpectedly high gas fee, but not hidden.

And finally, a relayer can detect this. Currently IBC relayers simulate gas usage and can skip high-gas packets. This doesn't require any knowledge of the implementation of the protocol, simply the gas detection logic already done. Also ICS29 fee payments are implemented and could be used to pay the relayer (okay, if you pay me X tokens, I will cover your 20 million gas transaction).

Given this, I think using a denom_creation_gas field in params is better than the existing denom_creation_fee. I'd love to hear opinions from @ValarDragon or anyone else who worked on the tokenfactory in Osmosis.

[GNaD13]

But let's get worse... Imagine I implement cw20-ics20 so that the remote side issues native tokens (via token factory) not cw20 tokens when it receives my packet. That means that the first time a given token is transferred over a given channel, a CreateDenom message will be triggered. Which will charge... who? The contract itself, from the locked funds of other? The relayer account??? This is another level of complexity beyond the AMM Factory and I have no idea how to properly account for it here.

I don't really get it. Hmmm, why do we need token factory in this situation? What I'm thinking here is that the ibctranfer already handle the mint of ibc token via bank module.

[ValarDragon]

I think this makes sense to do!

Originally this was created when there were known functionality liveness threats with many denoms being available. (Tokenfactory is not unique in offering this capability, e.g. IBC offers it as well) And there was slight concern over there being more, with noone having looked for them.

The known threats were patched on osmosis and communicated for (> 1 year now) to other chains active at the time. I haven't tracked whether other chains resolved said problems, I believe the answer was no.

I'm happy to remove the token creation fee, and re-communicate the issue to anyone who is concerned.