Read from the chain

APEX on Arc

There is no second APEX. A token exists on Arc only where the same amount was burned on X1 — the contract cannot mint beyond what X1 destroyed, and every mint names the burn it came from. Below is the pool as it stands right now, what a trade of your size would really cost in it, and where every USDC paid to us actually goes.

The machine-readable version Everything else we measured on Arc

Reading the chain…

What a trade costs here, honestly

This pool is small. That is not a complaint about it, it is a fact you should have before you trade: the numbers below are computed from the reserves above by constant product, including the 0.3% fee.

Where a payment goes

Every USDC paid to us on Arc lands in a split contract that can do exactly two things, and has no withdraw function:

  1. Half to the free claim pot. That is the money people claim three times a day, for nothing.
  2. Half buys APEX on the pool above and sends it to the drip vault, which releases 1% a week to the faucet, forever.

Being plain about what this does and does not do: the buy half moves the price, it does not add depth. Depth only grows when both sides are added to the pool. Nobody is promised a return here, nothing pays a yield, and APEX is not an investment — it is the token a faucet gives away.

The pot cannot be drained — and you do not have to take our word

Anyone can pay into the Arc claim pot: the contract has a payable receive(), so USDC sent to it simply becomes claims. What matters is the other direction. We read the deployed bytecode and walk it as opcodes, and this is what is in it:

Method, so you can repeat it: eth_getCode on the contract at any Arc RPC, then look for 0xff, 0xf4, 0xf2, 0xf0, 0xf5 as opcodes — skipping PUSH operands and the metadata trailer. Scanning raw bytes instead gives false positives; our own first attempt did exactly that and we threw it away. Machine-readable: arc-pot-proof.json.

If you are an agent

Addresses, so you can check all of it