Fraxtal RPC: The OP Stack Chain That Doesn't Use ETH for Gas

Almost every OP Stack L2 shares one assumption: ETH is the gas token. Fraxtal breaks it. It's Frax Finance's Layer 2 — built on the OP Stack, aligned with the Optimism Superchain — but it runs on FRAX as the native gas asset, and it layers on a blockspace-incentive system (Flox) that pays contract developers for the gas their users spend. Underneath it's a standard EVM (chain ID 252, ordinary eth_*, viem/ethers/foundry unchanged), so the tooling is familiar. The two Frax-specific twists are what you actually need to design around. Here's the map.

The essentials

Fraxtal mainnet (live since February 2024) is chain ID 252, an OP Stack L2 with:

• FRAX as the native gas token (18 decimals) — not ETH, which is the headline difference from most OP Stack chains.
• ~2-second blocks — fast L2 confirmation.
• Optimistic rollup finality — soft confirmation is immediate on the L2; withdrawals to Ethereum follow the usual ~7-day challenge window.
• EVM-compatible — Solidity, ABIs, and standard tooling deploy without changes.

Connecting is standard EVM — the one thing to get right is the native currency:

import { createPublicClient, http, defineChain } from "viem";

const fraxtal = defineChain({
  id: 252,
  name: "Fraxtal",
  nativeCurrency: { name: "Frax", symbol: "FRAX", decimals: 18 },  // not ETH
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/fraxtal?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: fraxtal, transport: http() });
await client.getBlockNumber();   // just works

Twist #1: gas is FRAX, not ETH

The practical consequence lives in your fee handling. eth_estimateGas still returns gas units the same way it does everywhere (gas estimation basics), and EIP-1559 fields behave normally — but the value you multiply by, the balance a user needs to transact, and the token your relayer or funding wallet must hold are all FRAX, not ETH. Anywhere your code hard-codes "the native token is ETH" for display, funding, or balance checks, Fraxtal will surprise you.

If you've read the Celo fee-currency post, this is a cousin — Celo lets you pay gas in various fee currencies, while Fraxtal simply makes the native gas token FRAX end to end. Either way, the lesson is the same one that recurs across non-ETH chains: don't assume the gas asset. Read it from the chain config.

Twist #2: Flox — gas that pays developers back

This is the feature that has no equivalent on a vanilla OP Stack L2. Fraxtal runs Flox, a blockspace incentive system that distributes FXTL points based on gas activity — and crucially, it rewards both the user who spends the gas and the contract they interact with. In other words, if users transact against your deployed contract, you accrue FXTL for that usage.

For a developer choosing where to deploy, that flips the usual calculus. On most chains, the gas your users spend is pure cost that leaves the ecosystem; on Fraxtal, it partially cycles back to the builders driving the activity. It's conceptually adjacent to Astar's dApp Staking, where on-chain rewards flow to contracts by usage — but Flox ties it directly to gas spent, so the metric is raw blockspace consumption rather than a separate staking vote.

From the RPC's point of view, Flox is a protocol/accounting layer — it doesn't change how you call the chain. You deploy and interact with eth_sendRawTransaction / eth_call exactly as normal; the FXTL accrual happens off to the side based on the gas those transactions burn. It's a reason to build here, not an API you invoke. (Tokenomics around FRAX and the frxUSD stablecoin have evolved through Frax's later upgrades — check Frax's official docs for the current specifics before you design economics around FXTL.)

OP Stack mechanics carry over

Because Fraxtal is OP Stack, everything you know from other Superchain L2s applies — the same model we covered on Unichain and Zora:

• A sequencer orders transactions and gives near-instant soft confirmation; transaction data is posted to Ethereum L1.
• Two-tier finality: the L2 head is fast and practically reliable, but true settlement — and any withdrawal back to Ethereum — waits out the ~7-day optimistic challenge window. If your app moves value L2→L1, design for that delay; see soft vs. hard finality.
• Fee structure includes an L1 data component on top of L2 execution, so total cost tracks Ethereum's calldata pricing — just denominated in FRAX here.

What carries over unchanged

Aside from the FRAX gas token and Flox, treat Fraxtal as a standard EVM chain:

• eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally.
• Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
• 18-decimal native token; WebSocket subscriptions (newHeads, logs) work; at ~2s blocks, streaming beats tight polling.

The short version

Fraxtal (chain ID 252) is Frax Finance's OP Stack L2 with two departures from the standard Superchain playbook: gas is paid in FRAX, not ETH (so never assume the native asset — read it from the chain config), and its Flox system pays FXTL points to both users and the contracts they use, turning gas spend into a builder incentive. Everything else is standard OP Stack — fast sequencer soft-confirmation, an L1 data-fee component, and a ~7-day withdrawal challenge window — over an ordinary eth_* EVM that viem/ethers/foundry drive unchanged. Build it like any OP Stack chain; just get the gas token and the withdrawal delay right.

Building on Frax's ecosystem — frxUSD settlement, liquid staking, or Flox-incentivized dApps? A flat-rate Fraxtal RPC endpoint gives you chain 252 over HTTP and WebSocket alongside 75+ other chains under one key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/fraxtal?key=YOUR_API_KEY