# Arc research: methods and limits

## Scope

The main trading window is **16 September 2026, 06:19:10–14:00:00 UTC**, ending just before 14:00. This is **11:49:10–19:30:00 IST**, a span of 7 hours, 40 minutes and 50 seconds. The requested local date began at 18:30 UTC on 15 September. Available sources do not cover that whole date.

The wider raw-chain view begins at 04:20:06 UTC. It is kept separate. Its block table has 227 absent heights before the trading window. Some transaction records exist for heights absent from that block table. The common trading window has no missing heights in the saved block set; every saved block's transaction count reconciles with the transaction export. This checks the records available here, without establishing that the source caught every possible protocol.

Arc's own announcement sets public launch for 16 September and describes an earlier private mainnet. The official event schedule starts after this report's cutoff. Neither an event time nor our first retained block establishes the moment of public network activation. The report therefore uses the measured date and hours. [Arc announcement](https://www.arc.io/blog/arc-mainnet-goes-live-on-september-16-2026), [official event schedule](https://community.arc.io/public/events/arc-mainnet-launch-livestream).

## Sources and snapshot

All trade-derived measures come from authenticated **Trading.Trades**, filtered to `bid:arc` and the Uniswap and Aerodrome families. The initial all-protocol check also returned Seaport NFT fills. Those fills are outside the DEX comparison.

The full export has 235 accepted time slices. A slice that reached the row limit was split. Every returned timestamp was checked against its slice; accepted slices join without overlap or gaps. Each slice retains its query, capture times, full response and hashes. `copies` preserves the number of source rows sharing the selected fields. It is not a rule for deleting repeats.

The earliest live Trading row moved from 06:19:10 to 06:25:23 during the research. Counts in the retained overlap agree exactly. Earlier rows were already saved and remain in the fixed snapshot. They are supported by the initial aggregate check, but cannot be re-queried from the later live floor. No fixed retention duration is inferred from this observation.

Raw ClickHouse blocks, transactions, calls, events and transfers provide checks and non-trading facts. They never replace the Trading cube for a trading measure. API and raw-table agreement may share upstream ingestion; it is not proof from independent sources. Receipt, code and block checks use Arc's public RPC, chain ID 5042.

## Event identity and order

- Transaction identity: chain and transaction hash, with block hash checked for conflicts.
- Launch event identity: block hash, transaction hash and `LogHeader_Index`. The shorter `Log_Index` resets within a transaction and failed the uniqueness test.
- Transfer occurrence: block hash, transaction hash, call index, log index, transfer index and transfer type. Indexes alone without their call context undercounted valid movements.
- Creation trace: block hash, transaction hash and call index. The broad creation flag also includes ordinary top-level calls. Only successful, non-reverted internal CREATE/CREATE2 records support the reported creation-trace measure.
- Trading groups: saved response, row position and preserved multiplicity. Both repeated groups found in the full export have separate swap events in their receipts. Identical amounts do not imply an ingestion duplicate.

Transaction order comes from verified block height and position within the block. Timestamps measure elapsed time at one-second resolution. They do not decide order among transactions sharing a timestamp. Several swaps by one trader in one transaction count as one visit. Within-transaction trade order is unavailable from this cube, so inventory cycles requiring it are not claimed.

## Amounts and addresses

USDC turnover adds the cube's quote quantity once per pool execution. Native USDC and its ERC-20 interface are the same denomination; a row has only one selected quote side. Other quote assets do not enter this USDC total. The main token-market headline excludes 2,709 records worth 213,615.85 USDC where both assets are native/verified-interface USDC. Full-cube supporting tables retain this set and are labelled accordingly. The cube's reference-USD amount is separate. Amounts are returned as floating-point values, so value totals are rounded for publication; event counts are integers. In the final-hour repeat, three strict USDC quantity comparisons differ by less than 0.002 USDC each, and three reference-USD comparisons differ by about 9.18 USD in total. Their causes are unresolved. The saved-row sums are used consistently; those six comparisons remain open in the audit.

Missing base quantities remain null. They prevent quantity-based price and inventory calculations for those rows; valid quote amounts and row counts are retained. Zero is never substituted for an unknown quantity.

The trader is the cube's `Trader.Address`. It matches the raw chain transaction sender on every saved swap. The cube's `TransactionHeader.Sender` matches that chain sender on only 15 swap rows, so it must not be interpreted as the same field for this snapshot. A separate set of 68 saved RPC receipts agrees with the raw sender. No address count is a count of people. Buy and sell refer to the named base asset in the cube, not a reconstructed full-wallet intent.

Native USDC accounting uses 18 decimals; the ERC-20 interface uses six. The latter was checked by a historical read. Gross ERC-20 and native transfer views are reported separately because they can describe the same movement. They are not added into a combined capital-flow number. [Arc's USDC model](https://docs.arc.io/arc/concepts/stablecoin-native-model), [Arc's decimal guidance](https://www.arc.io/blog/usdc-for-every-action-how-arc-simplifies-building-onchain).

## Launchpad attribution

The search screened 55 names and retained 49 mainnet research candidates. A site mention, shared event signature or shared PoolManager never proves a brand. Contract addresses come from first-party material where found; exact emitter and event fields bind tokens to a launch source. Receipt checks inspect the first and last token for each mapped brand/emitter, including mint events and code at the launch block and preceding block. This validates samples and field mappings, not every contract's security or full history.

The ranking covers the saved, mapped token sets, including launches observed before the trading window. It is not whole-platform market share: older token history and some contract versions are missing. Unknown factories stay separate. NebulaPad's first sample failed the token/mint check, so its cohort is excluded from trading ranks. Newly found Archemist V4 events remain separate from the verified V2 token set until their full binding is established.

Token creation and execution venue are separate. A swap touching two different mapped brands belongs to a cross-brand group in additive totals. Token tables can overlap and must not be summed into a chain total. A named platform's missing curve-trade decoder is not evidence of no trading.

## Cohorts and comparisons

First-hour outcomes require a launch within the common window and at least 60 minutes before cutoff. Quiet tokens remain in eligible cohorts as zero *observed cube activity*. Unknown creator addresses stay outside non-creator denominators. A pool can be supported by a launch field or an observed matched pool execution. Funnel stages are nested.

Return rates anchor at the first observed trader transaction, and require the complete 15-, 30-, 60- or 120-minute horizon. A return is a different transaction. Observed selling after buying is not proof that the sold tokens came from the measured purchase. Entry-time groups are fixed before comparing outcomes: 0–1, 1–5, 5–15 and 15+ minutes after launch.

Version 2 corrects post-move value assignment. The first unambiguous named-source visit and next different named-source visit use the same rules as before. From the move transaction through the next 30 minutes, each source receives only turnover from executions assigned to its mapped token set. Unknown and unattributed executions in the same transaction do not count toward that source. Transactions touching several named sources remain outside the paired value sums. Different source/address pairs can have overlapping time windows and must not be added into a chain total.

Buyer/seller breadth counts cover all captured quote assets per base token. Buy, sell and repeated-buy USDC values include USDC quotes only. Repeat status means more than one buy transaction across all quotes; repeated-buy USDC starts after the first buy transaction, even if that first buy used a different quote. The directional ratio uses USDC values only and stays null when their sum is zero. Do not treat the all-quote address count as a USDC-only buyer denominator. [Field definitions](/investigations/arc-blockchain-launch-trading/data/analysis/buyer-seller-breadth-scope.csv).

The adjacent-hour turnover split is exact accounting: continuing-address change, plus addresses present only in the later hour, minus addresses present only in the earlier hour. The intensity identity uses distinct address–transaction pairs, rather than chain transactions: `V = W × (A/W) × (S/A) × (V/S)`. Means make this identity work; medians are reported separately.

Concentration tests remove the same whole-window top token or top addresses and recount the remaining audience. The concentration-equivalent count is `1 / sum(share²)` over exclusive groups. It measures concentration, not a human-user count.

Fast-repeat flags use successive trader transactions in the same block or within 1, 5 and 30 seconds. These sets overlap. They can include routing, arbitrage and other uses; they are not confirmed bots or proof of wash trading.

## Unavailable results

No full-wallet profit, win rate, net bridge inflow, inventory retention, holder count, guaranteed exit size or historical slippage is inferred from turnover. Those claims need opening balances, transfers, costs, boundary labels or historical pool state that have not passed the needed checks. Internal creation records do not expose every resulting address, so a count of unique new contracts and a full contract-use conversion rate are not supplied.

The 61-measure status sheet and final audit state which findings are measured, partial or unavailable. The public evidence package contains frozen result tables. The authenticated raw capture is retained privately.