Mass Token Minting

Minting and distributing tokens to a large number of users is a fairly common pattern, especially for community-driven applications and rewards or reputation points. Generally, tokens of this form are distributed in a permissioned manner by a central party, as un-gameable global reputation is non-trivial. However, once the tokens have been distributed they cannot be reclaimed by the issuer.

While it is certainly possible to do this relatively inexpensively by using one-to-many transactions (as Fuel supports up to eight inputs and eight outputs per transactions), we can do even better!

First, let us consider how one would make distributing such tokens cheaper on Ethereum today. There are two easy, concrete methods:

  1. The issuer pre-signs an authorization to mint a certain number of tokens for a particular user. She then sends the user the pre-signed authorization, which the user can redeem to the token contract for tokens. In this case, the issuer does not pay anything to distribute the token, as gas costs are covered by the user.
  2. The issuer posts a commitment (e.g. a Merkle root) of new coin balances to the token contract, which is an O(1)-cost operation. Users can then withdraw their tokens with a Merkle inclusion proof. In this case, the issuer pays a constant cost to distribute tokens, regardless of the number of tokens or users.

These schemes do not work on Fuel v1, as generic smart contracts are not supported. But what if we combined some of the aspects of the two approaches?

Token minting
Pre-signed transaction tree.

The scheme is actually quite simple:

  1. The issuer mints all the tokens at once on Ethereum, as a batch.
  2. The tokens are deposited to Fuel.
  3. The issuer now has a single UTXO (or rather, a deposit) with exactly the number of tokens they want to distribute.
  4. The issuer recursively pre-signs transactions that split this UTXO into eight outputs that are returned to the same address. This forms a tree of pre-signed transactions, as shown in the diagram above.
  5. Once the leaves are reached, each output is sent to the appropriate user's address. Users are then given the Merkle branch of pre-signed transactions to the transaction that would send them tokens.
  6. A user that wishes to redeem their tokens broadcasts the branch of pre-signed transactions to Fuel (or, more specifically, the transactions that haven't yet been included on Fuel from potential previous users that do the same), then spends the appropriate output with a new (potentially fee-paying) transaction.

Note: The issuer does not send the pre-signed transactions to Fuel. Indeed, the pre-signed transactions do not pay any fees and so would not be included barring out-of-bounds negotiation. Rather, the user pays fees for an entire branch of pre-signed transactions using Child-Pays-For-Parent (CPFP).

Readers familiar with Bitcoin's CTV (BIP-119) proposal should find this scheme very similar. However, rather than being enforced with on-chain rules, the commitment to a tree of transactions is simply an off-chain promise.

Note: The threat model for distributing tokens in this manner is not necessarily weaker than that of using a contract on Ethereum to enforce some rules. In this mass token minting scheme, the issuer could double-spend their pre-signed transactions. Notice however that the issuer in any case could simply just not issue the tokens in the first place, as distribution is permissioned, to the same effect.

Note: Equivalent functionality to CTV (BIP-119) is on the roadmap as a future addition with covenants.