• Authored by: larry0x and ChatGPT
• Commonwealth discussion

Background

In Cosmos ecosystem there are two prevailing fungible token standards, the native token and the CW20. Osmosis is equipped with a “tokenfactory” module which allows anyone (human users or smart contracts) to mint native tokens. This is a much desired feature, as native token is superior than CW20 for many reasons which I will not cover here.

Given that Osmosis currently has a very low gas price, tokenfactory needs a mechanism to deter spamming. This means an attacker creating a massive amount of new tokens that take up nodes’ storage space. It does this by charging a fee, currently set at 10 OSMO, whenever a new token is created. This is known as the

in the code.

The problem

It turns out, that this fee approach makes it harder for smart contracts to integrate with tokenfactory, especially ones that need to repeatedly create new tokens. For example,

• A lending protocol that issues tokens representing collateral or debt positions, needs to pay the fee each time a new collateral or debt asset is added.

• A cross-chain transfer protocol that issues voucher tokens, needs to pay the fee the first time a token is transferred.

Such contracts need to allocate a fee pool for these payments and program relevant payment logics, which in many cases is a non-trivial task.

Note that this complexity has nothing to do with how big the fee is. It is there as long as the fee is non-zero.

An alternatie solution

Ethan Frey proposed an alternative spam-prevention approach in this Github issue. It suggests that, instead of charging a fee, charge a large amount of gas instead.

From the perspective of the user who creates a new token, there is no difference from the current approach – they pay the same fee, the only difference being whether it’s a

or a gas fee. However, it makes it much easier for smart contract developers.

This approach has been implemented by Juno and is expected to be included in its v15 upgrade.

This proposal

I proposed that Osmosis does the following:

• Introduce the same spam-prevention mechanism, in consistency with Juno’s implementation (most importantly, keep the same protobuf message/query API);

• Set

  denom_creation_fee
  to zero in the UpgradeHandler of the next chain upgrade.