Whack-A-Mole minting - Self-minting of tokens without circuit breakers

This is a variation of the previous approach with the following rules:

• Anyone can mint layer 1 tokens equivalent to a fraction of their address holdings (limited to the maximum flow rules).
• Freshly minted tokens, and the contents of the address they are minted into (the bond) are in quarantine for a while, a whack-time.
• Anyone can also whack freshly minted tokens in quarantine.
• Whacking freshly minted tokens is done by burning the equivalent to a fraction of the minted tokens.
• Whacking freshly minted tokens also burns the bond at the minting address.
• Whoever whacks an invalid minted token will get back their burned tokens + half of the burned bond at the minting address at layer 2.
• Optionally a subsidy to cover the transaction cost at layer 2 is given to the whacker, in which case the remains of the bond is saved in a rekt-fund which is used to cover such subsidies.

Analysis

Unbounded minting attack

An adversary can try to mint tokens until the layer 1 tokens available to the whackers is depleted. As whacking is quite profitable, an adversary would have to amass a significant number of the layer 1 tokens for this to work.

Another argument that the adversary will have to amass a significant number of layer 1 tokens is that profit maximising honest holders that see what is going on will want to basically burn their tokens before the peg is lost, i.e. convert to layer 2 tokens. So if it is more profitable for honest holders to whack than to just convert through burning, the adversary will need to amass a lot of tokens, or will go bankrupt.

We don't need flow control in the layer 1 to layer 2 direction, so market participants might flee from layer 1 by burning en masse. In this case the adversary will succeed in breaking the peg, but it will only be profitable for the adversary if there are more unconverted layer 1 tokens he can dilute than what he spent on the attack.

Also, the treating invalid minted tokens as a separate token approach can be used to protect unmoved tokens against dillution, so the only realistic target of an attack are liquidity pools.

The adversary can try to make it unprofitable to whack its own minted tokens by front-running whacking when detecting that someone else is whacking.

In order to avoid front-running, the protocol will reward all whackers equally, but if lots of whackers are appearing, decrease the fraction of holdings that can be minted from an address.

For example, if you initially need to keep a 1:1 between the bond and what you can mint, if 10 transactions are whacking like crazy one invalid minting, then later the protocol might require 10:1 between the bond and minting so that the bond is big enough to cover all the whackers.

If an adversary has more than 50% of the layer 1 tokens, then they should surely be able to break the peg between layer 2 and layer 1, but in this case they have wasted significant money on this, while those protecting layer 1 has lost nothing.

Layer 2 can create a new layer 1 token in this case as the adversary has depleted significant capital in this attack.

A situation where an adversary might be able to win is if there is a significant pool of tokens locked in liquidity pools in layer 1, and they are short the layer 1 token, and they can amass a sustained attack on the peg. However, as the flow is limited, the market would be able to react to this and it would be an extremely risky move by an adversary to do this in the open, burning capital over a prolonged time.

In order to handle the chicken-and-egg issue where the user does not have any initial funds on any address at layer 1, the user can sign a transaction delegating the initial minting to someone who has funds and is willing to do this, for a fee.

This does not require trusting the external party, but it requires the external party to sign the layer 1 transaction which means some sort of other party must be involved.

In general, the address keeping the bond, the recipient address, and the layer 2 address having funds to be converted need not be the same, but they all need to be involved in signing a transaction to get the job done. The simplest and most practical case is if someone converts their own funds and thus all signatures are the same.

DoS attack

In a DoS attack, the adversary will try to block legitime minting of tokens by wrongfully whacking them.

What is important when protecting against such an attack is that even if all the whacking might lower the flow or require higher bonds, whacking by burning X tokens should not invalidate more than X tokens from the bond.

If more than X tokens from the bond are also burned, then the whacking becomes an amplification attack where the attacker can increase his percentage control of the layer 1 tokens through whacking.

Multiple layer 1 tokens

It is possible to allow multiple instances of layer 1 tokens, all pegged to the same layer 2 token. The layer 1 tokens can have different mechanisms controlling minting of new tokens.

The different layer 1 tokens would be controlled by separate instances of layer 2 contracts, and when minting tokens at layer 1, the user would, in a compound transaction, move their layer 2 tokens into the layer 2 contract for the layer 1 token, and then move it from there into the layer 1 token through whatever means is used for controlling minting.

The core token contract for the layer 2 token does not need to know about the layer 1 tokens, but can treat them simply as normal layer 2 contracts that hold a balance.

One layer 1 contract for boundless whack-a-mole tokens

It should be possible to construct a layer 1 contract that can support an unbounded number of layer 1 tokens, so basically someone who wants to either create their own layer 2 token, or who wants to create a separate pegged layer 1 token alongside an existing layer 1 token for the same asset, can do so at will.

The ERC-1155 is such a standard where multiple tokens can be handled by the same contract. Because of the NFT popularity, more wallets will be able to support ERC-1155 tokens going forward.

Layer 1 batch swaps with layer 2

A way to save substantial gas fees at layer 1 could be to do batch moves of ERC-20 tokens. These batch transfers could be part of swaps for layer 2 tokens.

How this would work is that signed messages to move layer 2 tokens to layer 1 addresses would be put into one batch, and combined with batch layer 1 transfers.

No minting or burning of tokens would happen in this example, but the cost of entering and exiting the ERC-20 contract would be minimized.

Sequences of layer 1 tokens

Assuming a layer 1 token has been compromised, it could be reasonable to optimize the system for those that stop transacting.

Those that stop transacting should have the best outcome, while those that continue transacting will have a worse outcome. Maybe with the exception of burning to convert into layer 2 tokens.

A reasonable process could be to stop transacting at the point where invalid tokens are introduced and move to a new layer 1 token.

If a sequence of layer 1 tokens is built into the model, then moving into a new token could be already prepared.

One problem we face is how to move the state the layer 1 contract was at, at the point where invalid tokens were introduced, into a new contract.

Of course, we could initialize the new layer 1 contract using data extracted from layer 2, but this might be difficult to do in an atomic fashion if we want to take into consideration movements that continuously happen in the ERC-20 contract.

Thus an ERC-20 contract could be designed to simplify transfer of its full state, with some extra information indicating which addresses have been involved in transfers recently.

Sequence numbers associated with addresses

One way to make this easy is if the layer 1 token contract has a sequence number for each transfer. If this sequence number is associated with each address, then a new contract could airdrop into all addresses with sequence numbers before the invalid tokens were introduced, while those addresses with sequence numbers beyond the cutoff would have to share in the haircut. Unfortunately, this would allow an attacker to spread dust onto large account owners in order to bump their sequence number.

Exponential decay penalty per address

Another option is to associate an exponential decay value with each address. When moving funds into an address, an exponential value $v$ is computed based on blending the existing value with the incoming amount $d$:

v*n = \alpha*d + (1 - \alpha)_v_{n-1}

This can also take into consideration the age since the last transfer, at the cost of extra storage in the layer 1 contract.

The $v$ value or age can potentially be stored in the low bits of the amount, and the required dust to make room for this, burned during transfers.

A new layer 1 token contract or a burn to convert into layer 2 tokens could then use the exchange rate $1 - \frac{max(0, v_i-v_0)}{\sum_j{max(0, v_j-v_0)}}$ so the penalty is squeezed into the addresses for which $v > v_0$

Some last options - taxation to recoup losses

If permanent extra tokens have been minted, a last effort to recoup the losses could be taxation on transfers. In this case, a simple fee on transfers could be burned to cover the extra minted tokens.

If the taxation is on transfers, it would automatically apply for the most recent addresses, which is similar to some of the other approaches to assigning penalty weights.