> For the complete documentation index, see [llms.txt](https://docs.blinklabs.xyz/blink/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blinklabs.xyz/blink/arc/how-it-works.md).

# How it works

Arc is Circle's EVM-compatible Layer 1 for stablecoin finance. Circle runs Arc on a permissioned validator set using Malachite BFT consensus. A new block is produced roughly every half second, and each block is final the moment it is committed.

When a transaction is sent via Blink, we submit it to the Arc network and share it with our trusted searcher network. Searchers may submit backrun transactions to capture arbitrage opportunities. For transactions that successfully land on-chain and are backrun, Blink may return a portion of that value to the transaction originator.

Transactions that revert, fail, or are not included on-chain are not eligible for refunds or value sharing.

### Flow Overview

1. Transaction Submission
   * Users submit transactions through Blink's Arc endpoint
   * Transactions are immediately submitted to the Arc network
2. Searcher Integration
   * Vetted searchers receive transaction details
   * Searchers analyze for profitable backrun opportunities
   * Execution happens within the same block when possible
3. Profit Distribution
   * Searchers capture arbitrage value through backrun transactions
   * Automated profit-sharing mechanism returns value to original transaction senders
   * Transparent tracking ensures fair distribution

### Differences with Ethereum

#### 1. USDC is the gas token

Arc has no ETH. Gas is paid in USDC, so fees stay predictable in dollar terms. At Arc's 20 gwei base fee a simple transfer (21,000 gas) costs about $0.0004, and a 500,000 gas contract call costs about $0.01.

USDC has two interfaces on Arc that share one balance:

* **Native** (gas, `msg.value`, `eth_getBalance`, fee fields): **18 decimals**
* **ERC-20** (transfers, approvals, allowances): **6 decimals**, at `0x3600000000000000000000000000000000000000`

{% hint style="warning" %}
Never mix raw values from the two interfaces without converting. A native amount divided by 10¹² is the same amount in ERC-20 units, but the division truncates: up to 10¹² wei of a native balance is invisible to the ERC-20 interface.
{% endhint %}

#### 2. Instant, deterministic finality

Arc blocks are final on inclusion, with no reorganizations, so a single confirmation is enough to act on a transaction. Transactions are typically included within about a second of submission.

Block timestamps have one-second granularity. Up to three blocks can share the same timestamp, so order transactions by block number rather than by timestamp.

#### 3. A stable fee market

Arc specifies EIP-1559 with an exponentially smoothed base fee, bounded by a 20 gwei floor and a 20,000 gwei ceiling. In practice the base fee has stayed at the 20 gwei floor. It is paid to the block proposer rather than burned. There is no minimum priority fee.

Set `maxFeePerGas` to at least 20 gwei. Unlike Ethereum clients, which reject an underpriced transaction immediately, Arc accepts a transaction priced below the base fee and returns its hash, but never includes it.

#### 4. Ordering by priority fee, no builders

There is no builder market on Arc. Validators take turns proposing blocks, and within a block transactions are ordered by priority fee, highest first. Transactions paying the same fee usually, but not always, keep their arrival order.

Transactions from the same sender always execute in nonce order. A low-fee pending transaction therefore holds back every higher-fee transaction queued behind it from that address.

#### 5. No public mempool

Arc RPC nodes do not expose pending transactions, and pending transactions are not gossiped between independent node operators. Third parties cannot watch for your transaction before it is included, so classic sandwiching by outside bots is not currently possible.

This is not a guarantee of fair ordering: the node you submit to and the block proposer still see your transaction before inclusion. Please reach out to us if you're interested in more details.

#### 6. No "Bundles"

Arc's JSON-RPC has no bundle method. This means it's harder to attribute value recovered from the searcher.

Despite there being no bundles, Blink has a number of approaches to attribute recoveries for originator transactions that are successfully included on-chain and pass that back to the originator of the transaction.

#### 7. No blob transactions

Arc supports legacy (type 0), access list (type 1), EIP-1559 (type 2) and EIP-7702 (type 4) transactions. Blob transactions (EIP-4844, type 3) are rejected.