# Minimal Viable Auction for New Assets on Priority Ordered L2s

[Clanker](https://x.com/clankeronbase) is an EVM-based token launchpad with sustained sniping activity. We'd like to run auctions for the initial swaps of newly created tokens for the benefit of all users in the system. Recognizing that each chain has a different MEV and sequencing environment, this document lays out a design targeting Flashbot's [Rollup Boost](https://writings.flashbots.net/introducing-rollup-boost) architecture. Specifically we'd like to leverage new L2 sequencing features in the style of Dan Robinson's [MEV Tax](https://www.paradigm.xyz/2024/06/priority-is-all-you-need) work to run auctions for one-off, externally triggered opportunities.

The auction design laid out below requires a commitment to priority ordering by the sequencing environment and inherits the sequencing environment's censorship resistance properties. Nice-to-have sequencer features include: a bundle-like construct which allows transaction senders to specify a target block for a transaction to land in, and revert protections. The last two features would help maintain blockspace efficiency (by avoiding pointless gas consumption) for other users on the chain.

Clanker is currently on Base, but these sequencing features are only known to be planned for [Unichain](https://docs.unichain.org/whitepaper.pdf) (see section 3.2). Clanker has a preference of running an implementatin of this on Base, but is open to running these auctions wherever we are able to.

The rest of this document: gives background on our observed user behaviors that we'd like to interact with, presents the design we'd like to implement, and then compares the design to a fallback design for the sake of highlighting tradeoffs.

## Sniping Activity Background

Clanker has been live on Base since November 2024 and has seen a range of different sniping activity.

In early November, Clanker was the cause of a historic spike in reverting transactions on Base, as [documented by Doug Colkitt](https://x.com/0xdoug/status/1861662510023123030). Since then, Clanker has seen sustained sniping activity. Our v3 contracts (operational Jan 15 - March 18) had 16% of all tokens have a swap within the first 10 blocks of creation. Our current v3.1 contracts (operational March 18 - present) have seen 10% of all tokens have a swap within the first 10 blocks of creation. This is more meaningful when considering that only 20% of our tokens receive any swaps at all.

The data itself shows a healthy number of operational snipers, with spikes of activity when larger accounts are connected to the launch. Looking at March 13th of 2025, of the 14,000 coins created, 3,400 of them had a swap within the first 10 blocks. The data had this rough breakdown:

**Swap Size**

The total amount being purchased ranged from 0.00% to 23% of the supply, with an average of 0.76% and median of 0.1%. The distribution was:
| Range | Percentage |
|-------|------------|
| 0.001-0.01% | 9.43% |
| 0.01-0.1% | 43.95% |
| 0.1-0.5% | 19.66% |
| 0.5-1% | 11.56% |
| >1% | 15.40% |

**Block Timing**

There are people sniping in the same block as token creation, but rarely.
| Block | Count | Percentage |
|-------|-------|------------|
| 0 | 23 | 0.33% |
| 1 | 888 | 12.90% |
| 2 | 1535 | 22.30% |
| 3 | 1114 | 16.18% |
| 4 | 902 | 13.10% |
| 5 | 351 | 5.10% |
| 6 | 511 | 7.42% |
| 7 | 485 | 7.05% |
| 8 | 446 | 6.48% |
| 9 | 366 | 5.32% |
| 10 | 262 | 3.81% |
| **Total** | **6883** | **100.00%** |

**Coins with Multiple Snipers**

Of the 6883 snipes, there were 3,366 unique tokens. 1,411 tokens (42%) had multiple snipers. 256 tokens (7%) had 5 or more snipers swap it in the first 10 blocks.
The token 0x358e027616c0a8b7de9ebb5e0e06b1cd67083127 had 88 snipers swap it in the first 10 blocks. This is common for tokens assocaited with [non-junk identities](https://x.com/Boss0fBase/status/1899898023787843756).

## Auction Design

Clanker would like to implement an application-level auction to capture the value associated with the desire of snipers to be among the first purchasers of newly created tokens. We say _application level_ because historically on the EVM, the block building environment captures the value of contention for onchain opportunities (e.g., first swap in the block to capitalize on CEX-DEX arbitrage). Clanker is currently only on L2s, but if we were live on mainnet, a form of this auction would already be happening and value would be flowing, instead of to the participants of Clanker, to the entities involved in the block building environment.

Clanker has three main categories of users, all of whom would benefit from the auction:
- Coin creators: entities who initiate the creation of a token and receive the trading fees from the created pool.
- Snipers: non-creators who purchase the token within the first 10 blocks of the token's creation.
- Non-bot buyers: all other users who purchase the tokens after the initial 10 blocks (note: this definition is just for this paper, bots typically trade throughout a coin's lifetime).

We'd like to create an onchain auction where:
- Snipers have a clean way to express their willingness to pay to be the first swap on a token.
- The coin creator is the beneficiary of the auction's proceeds.

Indirectly, non-bot buyers would benefit from this by snipers having less capital to put towards their initial swap of the token.

The minimal auction design is as follows:
- Upon token and pool creation, the pool will be locked for 4 blocks. The base gas price of the launch block is recorded.
- In the 4th block, the first transaction in the block attempting to swap the token pays an amount based on the transaction's gas price in relation to the recorded previous base gas price. _Priority ordering is necessary for this to work_.
- Other swaps are allowed to proceed as normal after this first swap or in the 5th block if no swap in the 4th block was attempted.
- The sniper payment is given to the LPs in the token's pool.

Notes:
- The 4-block delay is to give snipers time to decide if they would like to purchase the token or not.
- The payment does not take into consideration the size of the swap for simplicity.
- The base gas price is recorded at the time of the launch block to allow the auction to operate under various gas price conditions.
- This is a proof-of-concept design; follow-up designs could experiment with multiple rounds of the auction if the initial one proves useful.
- This design assumes a neutral sequencing layer, which is the typical design assumption for centralized sequencers.
- The ability for snipers to specify the block they want to land their transaction in would help with onchain spam reduction.
- Revert protection increases the efficiency of the chain overall, as the reverted sniper bids would not need to be included in the block.
- If the underlying sequencing environment changes, Clanker has the ability to modify and switch out the auction as needed. Our code setup, currently in the audit process, is built to support this.

## Why this Design

We favor this design over designs which do not leverage the sequencing environment because of its simplicity and low friction for snipers.

An alternative version of this design, which does not require priority ordering but still relies on the sequencing environment's censorship resistance properties, is as follows:
- Upon pool creation, the pool is locked for 4 blocks.
- Snipers have 3 blocks to submit their bids and deposits to an auction contract.
- On the 4th block, the highest bid is deemed the winner and the next swap in the block triggers the sniper's swap as well as the next swap.
- Snipers' failed deposits are now able to be withdrawn and used for other purposes.

The downsides of the alternative design are:
- Increased onchain gas consumption: In the first design, only a single transaction needs to land on chain for the auction to be resolved. In the second design, snipers must submit and withdraw their bids, with the number of involved transactions increasing with the number of snipers. This creates non-constructive gas spend which negatively impacts all other users on the chain.
- Inefficient use of snipers' funds: The snipers' funds are locked for the duration of the auction. This is less efficient for the snipers, as they are not able to use these funds for other purposes. In the first design, it is expected that if a sniper does not have the funds to pay for their bid, their transaction would revert and not win the auction. There is no lockup of the funds.
- Sniper bids are public: In the first design, snipers' bids are not necessarily public. Depending on the qualities of the sequencer, transactions could be private before they land and reverting transactions could not be surfaced. This could facilitate less information leakage of sniping strategies.

Additionally, Clanker favors the initial lightweight design over other designs because it meets our snipers where they are today. We fully expect that our sniping community will be able to understand and utilize the auction. We plan to build out an SDK to help with this, with the goal of lowering the bar to compete in the auction.

## Clanker Team

Clanker's founding team [Jack](https://x.com/JackDishman), [Bryce](https://warpcast.com/btayengco), and [m00n](https://x.com/m00npapi), are skilled at quick production rollouts: Clanker is already on the 5th live contract iteration in roughly 6 months of existence. Clanker has generated 2.7 billion of volume on Uniswap v3 and has a large and active community building on top of our core product.

Clanker's head of protocol, [Lily](https://x.com/lobstermindset), has been researching and prototyping auction designs for DEXes and researching application MEV retention strategies since 2023.

Clanker would love to continue to innovate in production with an additional focus on auction mechanisms for the benefit of the wider onchain community. We think that our existing userbase would be excited to participate in (and benefit from) such activities.