Arc Trading on Launch Day: Which Launchpads Led?

Arc is Circle's blockchain, with network fees paid in USDC. During the roughly eight hours we studied on launch day, its token markets recorded 160.12 million USDC in trading volume. New tokens drew buyers, and launchpads competed for their trades. Arc's launch post sets out the earlier private phase; Arc's USDC guide explains the fee model.

Trading volume, also called turnover, adds the USDC side of each swap. The same funds can trade many times. A large total does not tell us how much money traders brought to Arc, or how much they made.

Minara led the launchpads we could identify. Even without trades in its most-traded token, it stayed ahead of o1's full total. Yet most new Minara tokens we could follow for a full hour had no trades in our data near its end. That gap between a busy launchpad and a quiet token matters to anyone buying a fresh launch.

The headline counts token trades priced in USDC. It leaves out swaps that show USDC on both sides. The broader totals below include those swaps; their trade and address counts also include trades priced in other assets.

economic-usdc-overview CSV · trading-overview CSV · same-denomination-swaps CSV

Launchpad results · Trader behavior · Chain use and fees · Full research and data

When we measured trading

We studied trading on Arc's launch date. Our data starts with the first trade we captured, which does not tell us when public trading began.

Bitquery's trading data supplies the swap figures. We used Arc's chain records to check trades and measure network use. The Arc API page explains what the data covers. To query the chain yourself, start with the Arc mainnet docs.

Trading eased while address counts held steady

Trading volume peaked before the swap count did. In the next hour, there were more swaps but less USDC traded. The average swap was smaller.

In the final hour, both volume and swap count fell. The number of active addresses barely moved. They made fewer swaps on average, while the average swap grew larger. The slowdown did not come with a broad drop in that active group.

hourly-trading CSV

Addresses active in both of the final two hours traded less in the last hour. Those seen only in that last hour added volume. But they did not fully replace the earlier volume from addresses that stopped trading.

hour-change CSV

An address seen only in the later hour may still have used Arc before. These trades cannot tell us why someone changed pace.

Most swaps were small. The median, the middle value when trades are sorted by size, was well below the average. Tiny swaps made up a large share of the count but little of the volume. Larger trades carried much more of it.

trade-size CSV · transaction-routing CSV · trading-overview CSV

A single trade can pass through several pools, each holding assets for swaps. We count each pool swap in the volume total. That is why swap count can be much higher than the number of trade transactions. A DEX data feed lets you track both.

Most swaps used Uniswap V4 pools

Most swaps in our data used the Uniswap V4 format. Many apps can use the same pool design. This does not identify the website where someone traded or the launchpad that created a token.

protocols CSV · trading-overview CSV

The busiest tokens help explain where the volume went. The table ranks them by trading volume against USDC. Some may have launched before the hours we studied.

top-token-display CSV

One heavily traded token calls itself "USDC," but its address differs from Arc's verified USDC address, 0x3600000000000000000000000000000000000000. Token names such as ARGUS and TOLLY need the same care. Anyone can copy a name. The address tells you which token you are buying.

The same check matters for launchpad rankings. A familiar token name alone cannot prove where it launched.

Which launchpads drew the most trading?

A launchpad helps create tokens and their first markets. We linked tokens to the contracts that created them, then measured trading in those tokens. This includes trades in pools beyond the launchpad itself.

We checked more names than appear in the ranking. Some could not be linked to a contract. We left NebulaPad out because a token check failed. This is a data gap and says nothing about the project's honesty. The methods give the details.

origin-turnover CSV

Minara had the most volume among the launchpads we identified, followed by o1. Much of Arc's trading still could not be tied to a named launchpad.

Tokens from one unknown factory, a contract that creates tokens, had more volume than Minara's. Its address is 0xb021be536808f551b31789422fd28a6c9c6e97da. We could not confirm the platform behind it. Much more trading involved tokens we could not link to a launch record. Together, the named launchpads account for only a minority of total USDC volume.

Our data may also miss trades handled by some launchpads' own contracts, such as Flipt, Sharc and Warp. Archemist's figures cover an older contract version, and some older tokens are missing. A small total here does not prove low use across a whole platform.

Does Minara rely on one hit?

Minara's most-traded token supplied about half its volume. We counted again without swaps in that token. Minara still had more volume than o1's full total.

origin-turnover CSV · largest-token-exclusion CSV · origin-wallet-stress CSV

The same test changes the order below them. Aka loses much more volume when its top token is left out, putting Tolly ahead. We also ran a separate test that excludes all trades by each platform's ten top addresses by volume. Minara kept its lead among the named launchpads.

Minara's tokens kept trading after launch. Almost all volume in its new tokens came after the block in which they launched. Some trades also took place in other pools.

launch-phase-trading CSV

original-pool-trading CSV

A trade in another pool alone cannot prove that a token has migrated, the step when a launchpad moves it to a new trading pool. The Pons launchpad study tracks that process on another chain. Its figures cover another market and period.

A busy launchpad can have quiet tokens

One hit can make a launchpad look busy. For a trader choosing a fresh token, the more useful question is how the rest of its launches fared.

Most token addresses we linked to launch records came from unnamed factories. The table counts those recorded launches. We could not confirm the full number of tokens created on Arc.

launches-common CSV · launch-cohort-summary CSV

To compare their first hour, we kept only tokens launched early enough to have a full hour of data. Tokens with no trades in our data still count. This gives each token the same time to find buyers.

Minara's median first-hour volume was much higher than Tolly's or RadarDEX's. Yet only a minority of its tokens reached five buyer addresses besides the known creator.

launch-cohort-summary CSV

In that full-hour group, most Minara tokens had no trades in our data during the final fifteen minutes. A small group still traded heavily. A busy launchpad was no promise of steady trading in each token.

launch-cohort-summary CSV

Leaving out the known creator address helps, though the creator may control other wallets. Aka had a higher first-hour median across a much smaller group of tokens. o1 also had a higher median than Minara. Its creator addresses are unknown, so we cannot count its buyers apart from creators.

Launch time matters too. Tokens released into a busy market may draw more trades than later launches. The detailed results compare launch times and shorter periods. Also, zero USDC volume can mean a token traded against another asset. That happened in the Long and Ellipse groups.

Many addresses came back quickly

The token figures raise another question: did buyers stick around? We followed the addresses that sent trade transactions. One person can use several wallets, so these counts cannot tell us how many people traded.

trader-summary CSV · trading-overview CSV

The median address made a handful of trade transactions and traded few tokens. Some made only one trade transaction. To check who returned within an hour, we included only addresses whose first recorded trade left a full hour before the data ended.

returns-summary CSV

Most of those addresses traded again within an hour, often quite soon. We also counted who traded during minutes thirty to sixty after their first recorded trade. That rate was lower. It leaves out addresses whose repeat trades all happened in the first half-hour.

returns-summary CSV

Many came back to trade the same token. Others tried another one or traded several in a single transaction. These returns show activity within the hours we studied. They cannot tell us how many new users Arc gained or whether those users stayed for days.

Fast repeats carry much of the value

One address, 0xf70da97812cb96acdf810712aa562db8dfa3dbef, led by volume and traded hundreds of tokens. We could not identify its owner or strategy.

Many addresses sent a trade transaction within a second of their last one. One total below counts only those quick follow-up trades. A separate test excludes every trade by the same group, even their slower trades. That removes much more volume.

fast-repeat-summary CSV

We repeated the test with gaps of five and thirty seconds, and with trades in the same block. Fast repeats can fit bots or arbitrage. Speed alone cannot identify a bot's owner or prove wash trading, where trades give a false sense of demand. A live trading feed can track the pace; intent needs more evidence.

Launchpad audiences shared wallets

Traders did not keep to one launchpad. A large share of addresses trading Tolly tokens also traded Minara tokens. Minara and o1 shared many addresses too. Adding each launchpad's count would count some addresses twice.

launchpad-audience-overlap CSV

After an address first traded tokens linked to Tolly, we checked which other identified launchpad's tokens it traded next. We allowed a full hour to make the move. o1 and Minara were common next stops.

platform-path-summary CSV

Many made no such move within the hour. They could still have traded tokens from launchpads we could not identify. Trading on another launchpad also does not tell us why someone moved.

The detailed results also track trading volume after these moves. Some periods overlap, so those amounts should not be added into a chain total.

Later selling was common

Did buyers hold, or sell soon after buying? We checked each address separately for each token it bought. One address buying two tokens counts twice. Among cases with a full hour of data after the first recorded buy, most showed a later sale of that token. For those that sold, the wait was often short.

observed-exits-summary CSV

For Minara, buyers first seen near launch were more likely to sell within the next half-hour than buyers first seen much later. Each group held its own mix of tokens. This does not prove that buying earlier paid off.

entry-summary CSV

An address may already have held tokens or received them from another wallet. A later sale cannot tell us whether the buyer sold the tokens from that purchase, closed the full position or made a profit.

The Minara creator addresses we identified received more USDC from token sales than they spent on token buys after launch.

creator-cash-flow CSV

That cash-flow gap leaves out token transfers, launch costs and fee income. It cannot show profit. The same need for a full wallet history applies to crypto tax work.

Prices add another reason for care. Even the busiest token could leave a late buyer facing a sharp fall.

The leading Minara token rose sharply and fell hard

Minara's most-traded token, 0xa163d7624da3b5d9182c50eab5b8cd247ae861bb, drove much of its volume. In its original pool, the price rose sharply and then fell from its peak.

The final five-minute average price was far above the first. But a buyer who entered at a peak could have faced a steep fall before that final point.

selected-pool-price-summary CSV · selected-pool-price-paths CSV · selected-pool-trade-gaps CSV

Each point shows the average trade price during five minutes. Trades of more tokens carry more weight. The first point covers less than five minutes because the pool had only just started trading.

These are prices at which trades took place. A large sell could have received a much worse price. The price API and pool-price guide explain why the chosen market matters.

High volume does not ensure deep liquidity: enough funds in the pool to handle a large sell without a steep price drop. We have not measured how much a holder could sell at a given price.

How much did users pay in network fees?

All those swaps also put load on Arc. Trading made up a large share of chain transactions and an even larger share of gas use, the work needed to process them.

chain-common CSV

chain-activity-mix CSV

Some transactions failed. We do not know what all of them tried to do, so this failure rate cannot tell us how often traders were unable to sell.

Users pay network fees each time they send a transaction. The median fee was small, but fees added up across millions of them. The median fee for a trade was higher than the median across all chain use.

chain-common CSV · network-fee-distribution CSV · network-trade-cost-summary CSV

Pool trading fees are separate and are not included here. We also compared network fees in a busy hour with a quieter hour. The busy hour had a higher median fee, but the mix of uses had changed too. We cannot claim that more activity alone caused the higher fee. The exact hours and results are in the methods below.

How many new contracts were created?

We counted records of contract creation, but some lack the new contract's address. That prevents a checked count of unique new contracts.

The token launch counts above cover the launchpads and factories we could track. They cannot fill this chain-wide gap. Contract creation records and their limits remain in the full research results.

Transfers reuse the same funds

USDC moved around Arc far more than the trading total alone suggests. But the same funds can move many times, and some transfers appear in more than one type of record.

transfer-common CSV · transfer-key-check CSV

Arc records USDC movements both as native transfers and through its ERC-20 token interface. Some records can describe the same transfer. Adding these totals would risk counting the same money twice.

Neither total tells us how much new money entered Arc or how much stayed there. That needs a separate check of funds moving into and out of the chain. The cross-chain API can help trace those flows.

Minara led volume. Did the rush last?

Minara led volume among the launchpads we identified, even after the separate tests excluding its top token or top traders. Aka had a higher median first-hour volume across a much smaller group of tokens. Tolly relied less on one hit than Aka did. The answer changes with what a trader wants to measure.

The unknown factory had more volume than Minara, and some launchpad trades are missing. Naming the platform behind that factory and filling those gaps could change the ranking.

The rush lasted longer for some tokens than others. Many addresses traded again within an hour. Yet most new Minara tokens with a full hour of data had no trades near its end. For anyone holding one of those tokens, fresh buyers and enough liquidity to sell matter more than the launchpad's total volume. Whether buyers would stay beyond these first measured hours remains open.

Full research, methods and data

Download the result tables and methods to check the figures. The files keep values before rounding. Larger tables are compressed, and the field guide explains how to read them.

• Read the full research appendix: every finding from the corrected report, with the original detail tables.
• Methods and definitions, audit and open differences, and CSV field guide.
• File hashes and export manifest, question-to-result map, and full coverage map.

Six small value checks remain unresolved in the source research; the trade counts agree. The amounts and all other data limits are listed below and in the linked audit. Profit, win rate and net inflows remain unknown. We also have not measured how much a trader could sell at a stated price.

Methods, checks and known data gaps

Time and trading totals

The trading period is 11:49:10–19:30 IST. The wider raw-chain data starts at 04:20:06 UTC. The official launch event listed a 15:30 UTC pre-show and 18:00 UTC main stage, both after the cutoff. Neither is treated as the chain's activation time.

Trade figures use Bitquery's Trading.Trades cube. The headline excludes swaps between native USDC and its ERC-20 view. Both refer to the same unit. Broader USDC totals retain those rows; broader trade and address counts also include trades priced in other assets. Price-based USD estimates stay separate from USDC amounts.

The base token is the asset being priced; the quote asset is the unit used to price it. Token counts refer to base tokens. Assets seen only on the quote side fall outside that count. The price chart weights trades by base-token quantity and leaves out records missing that quantity.

Launchpad and trader checks

The launchpad links passed receipt and code checks on the first and last token sampled for each group. Those samples do not prove complete token history or contract safety. NebulaPad was excluded because a sample failed to confirm which token a launch record referred to. Similar code and event signatures do not establish who owns an unknown factory.

We counted Trader.Address, which matched the raw chain sender across the saved trades. A different sender field often held another address role. The highest-volume address had no deployed code at cutoff; its owner remains unknown.

After a trader moved between launchpads, the volume comparison counts only pool trades in tokens linked to each launchpad. Other trades in the same route stay out. Some time ranges overlap. The correction history below records changes to those values.

Fees, contracts and liquidity

The fee comparison uses 09:00–10:00 and 07:00–08:00 UTC. The results are in busy-quiet-fees CSV. Pool and hook fees have not been traced to each recipient. Testing the size of a possible sell would need the pool's state, fees and hook rules at the relevant block.

Internal creation traces count records, not unique new contracts. Some lack the created address. A broader creation flag also catches ordinary calls. The full appendix retains the counts for both the trading period and the wider chain-data period. The transfer files preserve each record type's decimal rules and duplicate checks.

Source audit

Report version 2 · the original data audit and later corrections were checked separately.

Check	Result and limit
Original final audit	103 of 109 checks passed. Six value comparisons remain open; counts agree.
Value differences	Three last-hour reference-USD comparisons differ by about 9.18 USD in total. Three USDC checks each differ by less than 0.002 USDC. Saved-row sums supply this article.
Corrected post-move values	1,035 of 9,057 comparisons changed, including 87 sign changes. All 19 targeted correction checks passed; path counts and cohorts stayed the same.
Buyer breadth	342,483 buyer address/base-token pairs span all quotes; 329,608 are USDC-only. Value fields use USDC quotes. These denominators must stay separate.
Rolling source	235 accepted trade slices. The live floor moved from 06:19:10 to 06:25:23 UTC after 13,677 earlier rows had been saved. Retained-overlap counts match.
Missing base quantity	226 rows keep valid quote quantities and counts. Quantity-based price claims leave them out. Missing values remain unknown.
Raw/cube sample	13:00–13:01 UTC: 3,405 successful raw DEX rows versus 3,395 cube rows. No raw rows were added to the trade measures.
Sender checks	Trader.Address agrees with the raw sender across the saved trades; 68 saved RPC receipt senders also agree. TransactionHeader.Sender matches on only 15 rows.
Block record	54,509 consecutive common-window blocks. The wider raw view has 227 missing heights before this window. Three boundary blocks were checked through public RPC.
Source independence	Raw tables and API records may share upstream data. RPC receipt samples check only those records.

The study cannot establish holder growth or identify bots from timing alone. The raw capture and private database are not part of the website download.