0.The thesis

Every blockchain you have used is a sequence. Transactions are lined up one after the other, and the line itself is the most valuable thing in the system: whoever decides the order decides who trades first, who gets sandwiched, whose liquidation fires before whose deposit lands. A decade of MEV research is a decade of fighting over a single totally-ordered list.

Abelian removes the list.

Inside an Abelian block there is no "before" and no "after". The state transition function is defined over a multiset of transactions and is provably independent of any ordering of them:

If the result cannot depend on the order, nobody can profit from the order. Front-running, sandwiching and priority-gas auctions are not mitigated: they are not expressible.

Abelian is a layer 3: a chain with its own validators, running on top of Robinhood Chain (itself an Arbitrum layer 2 of Ethereum). It settles to Robinhood Chain, uses Robinhood Chain assets (ETH and USDG at launch), and exits back to it as soon as a checkpoint lands. Nothing in it is specific to Robinhood Chain: a chain is one spec file, and a fork can settle to any EVM chain, L1, L2 or L3 (see fork).

1.Why Robinhood Chain needs this

Robinhood Chain brought tokenized equities on-chain, trading around the clock. It inherited the worst property of on-chain markets: execution quality depends on transaction order, and order is for sale. On a first-come-first-served sequencer it is a latency race; elsewhere it is an auction. Either way, the retail order is the one that gets ordered last.

Traditional exchanges solved a version of this decades ago with call auctions: at the opening and closing cross, every order in the batch executes at one uniform price. Nobody inside the batch is ahead of anybody else.

Abelian makes every block a call auction, for every market, every slot.

2.Commutative state

An operation commutes when applying it before or after any other operation gives the same result. Abelian's state is built so that everything a transaction can do is a commutative operation, and the few things that are not are resolved per block, as a set.

2.1 The overdraft rule

The one place order usually matters is overspending: Alice has 100, sends 80 to Bob and 80 to Carol. A sequential chain lets whichever comes first succeed. Abelian refuses to choose:

The rule depends only on the set of transactions, so it commutes. It is also the honest answer: the account asked for something it could not pay, and the chain does not pick a winner.

2.2 Nonces are not counters

Sequential nonces are an ordering. Abelian transactions carry a random 64-bit nonce and an expiry height instead. Replay protection is a set of seen transaction hashes within the expiry window. An account can submit any number of independent transactions to the same block.

2.3 Batch markets

Each market (for example ETH / USDG) clears once per block:

1. Collect resting orders and the block's new orders.
2. Find the price p* that maximizes executed volume. Ties go to the smallest imbalance, then to the price closest to the previous clearing price.
3. Every buy with limit ≥ p* and every sell with limit ≤ p* executes at p*.
4. The long side of the marginal price level is filled pro rata.
5. What does not execute rests in the book until it expires or is cancelled.

There is no time priority, because there is no time inside a block. Two orders at the same price in the same block are treated identically, whoever sent theirs "first".

2.4 Parallelism for free

A set has no dependencies between its elements. Validators can execute the debit sums, the deltas and each market's auction in parallel, on any number of cores, with no conflict detection and no optimistic re-execution. Commutativity is the strongest possible parallelism guarantee.

3.Validators and finality

Abelian runs its own validator set. Validators are staked on Robinhood Chain.

• Proposal: each height has a leader, chosen by rotation. The leader proposes a block: the set of transactions, the Robinhood Chain deposits it includes, the resulting state root.
• Voting: every validator re-executes the block and signs its header if the state root matches.
• Finality: a block is final when validators holding more than two thirds of the stake signed it. There are no forks to wait out: BFT finality is immediate.
• Liveness: if a leader does not produce a block in time, the next validator in the rotation proposes instead. A leader proposes as soon as there is a transaction, a deposit or a forced transaction to include; with nothing waiting, it makes an empty block once a minute (consensus.idleBlockMs), so the chain keeps time.
• Locks: a validator signs at most one header per height and writes that vote to disk before sending it, so even a crashed and restarted validator can never be slashed for equivocation.
• Slashing: a validator that signs two different blocks at the same height can be slashed on Robinhood Chain by anyone holding both signatures. The proof is two signed headers.

Because the leader cannot reorder anything, its only power is inclusion. Censorship is visible: a transaction that sits in every validator's mempool and is never included points at the leaders that skipped it, and users can force inclusion through Robinhood Chain (section 5).

4.Settlement on Robinhood Chain

Abelian posts checkpoints to its rollup contract on Robinhood Chain every few blocks:

Checkpoint {
  fromHeight, toHeight,
  stateRoot,        // Abelian state after toHeight
  withdrawalRoot,   // Merkle root of the withdrawals in the range
  batchHash,        // hash of the block data, posted alongside
  depositNonce,     // deposits credited so far
  forcedNonce       // forced transactions included so far
}

A checkpoint is accepted when signed by more than two thirds of the stake. The block data is posted with it (gzip of the headers and transactions), so anyone can re-execute Abelian from Robinhood Chain alone: rebuildFromSettlement() does exactly that, and validators use it to catch up before asking any peer. Checkpoints are posted when a withdrawal waits (after withdrawalDelaySeconds), when blocks pile up (maxBlocks), or when blocks have waited maxDelaySeconds; an idle chain posts nothing and costs nothing.

The state root commits to every balance and every resting order (with the funds it locks), the last clearing prices and the progress of the deposit and forced queues, as leaves the contract itself can verify: that is what makes exodus mode possible.

4.1 Instant exits

Optimistic rollups make you wait seven days to leave, because their state is only assumed correct until challenged. Abelian state is final the moment it is signed. A withdrawal is claimable on Robinhood Chain as soon as the checkpoint that contains it lands, which is seconds.

4.2 Deposits

Tokens listed in the chain's spec can be deposited into the portal: native ETH and USDG at launch, each under a cap on what the contract may hold of it. The contract credits what actually arrived (fee-on-transfer tokens included) and can never pay out more of a token than was deposited of it, a hard bound even against a signed checkpoint. Deposits are credits, so they commute with everything else; validators credit them in nonce order once the deposit's block is safe on Robinhood Chain, because a credit cannot be taken back if the settlement chain reorganizes.

5.Forced inclusion

A signed Abelian transaction can be posted to the portal contract on Robinhood Chain instead of to a validator. Forced transactions join the next block's set by reference, like deposits: the header commits to how far the forced queue has been included, and the checkpoint carries that number to the contract.

5.1 Exodus mode

If a deposit waits for a checkpoint longer than inclusionPeriod (a day at launch), or a forced transaction is not acknowledged by a checkpoint in that time, anyone can freeze the contract. Frozen is final: no more deposits, checkpoints or forced transactions. Then:

• every balance and every resting order of the last checkpointed state is withdrawable with a Merkle proof against its state root (escape), computed from Robinhood Chain data alone;
• every deposit no checkpoint credited is refunded to its sender (refundDeposit);
• withdrawals already checkpointed stay claimable.

Validators that disappear, or that censor, cannot keep anyone's funds. The end-to-end test runs this path and checks that the contract owes exactly zero afterwards.

6.Building on Abelian

Abelian programs are Δ-modules: modules whose effects are declared as deltas over commutative monoids (sums, sets, maxima) plus an optional per-block resolution step over the set of their inputs, like the overdraft rule or a batch auction.

The prototype ships two native modules, bank and exchange. The roadmap is a module language, Δ, with one compiler rule:

Δ will type-check that every state effect is a monoid operation and that every per-block step is a function of a set. The commutativity proof is the type check.

Until Δ exists, developers build on Abelian through its API and SDK (build): wallets, trading front-ends, market makers, bots, explorers, indexers. Every block is a published set with its clearing prices, which makes Abelian the easiest chain in existence to index: there is nothing to replay in order.

7.Security model

Be precise about what protects what.

• Safety of the state rests on the validators: more than two thirds of the stake signing a false state root could steal funds, because checkpoints are not yet proven, only signed. Re-execution fraud proofs are on the roadmap. At launch the four genesis validators are run by one operator, so Abelian is exactly as trustworthy as that operator, and its caps are set accordingly.
• Liveness and censorship do not rest on the validators: forced inclusion and exodus mode return every fund of the last checkpointed state without any validator's help.
• The owner of the contract lists tokens, sets caps, pauses new deposits and admits genesis validators. It cannot move, freeze or redirect user funds; claims and escapes are never paused. Ownership transfers in two steps, to a multisig as soon as there is one.
• Assets keep their own rules: USDG is issued by Paxos, which can freeze addresses.
• Spam is bounded, not priced: transactions carry no fee in v1, so validators rate-limit submissions per client and per account, and expiries are capped so the replay-protection set stays small. A fee market is a roadmap item.
• The code is unaudited. The launch is guarded by caps (1 ETH and 2,500 USDG) until it is.

8.What exists today

This repository has everything to run Abelian on Robinhood Chain mainnet:

• the node (TypeScript): orderless state transition, batch auctions, BFT voting with persisted locks, leader rotation, deposits, forced inclusion, checkpoints, rebuild from settlement data, HTTP + WebSocket API and a live explorer;
• AbelianRollup, the settlement contract: validator stake with unbonding and slashing, checkpoint verification, listed tokens with caps, native ETH, forced inclusion, exodus mode;
• the chain spec chains/abelian.json, an SDK and a CLI that deploys, launches and operates it;
• tests: permutation invariance and conservation of the state transition, the contract's suite, hash parity between the node and the contract, an end-to-end run from deposit to exodus, and a launch rehearsal against a local fork of Robinhood Chain mainnet.

9.Roadmap

1. Guarded mainnet (this repository): four genesis validators, capped deposits, ETH/USDG.
2. Independent validators, then a permissionless set with stake-weighted rotation.
3. Re-execution fraud proofs: anyone can prove on Robinhood Chain that a checkpoint's state root is wrong, by re-executing the block. The orderless state transition is simple enough to verify on-chain one market at a time.
4. Node in Rust, slots of 10 ms, incremental state tree.
5. Δ, the commutative module language.
6. Encrypted mempool: transactions encrypted to the validator set and decrypted together once the block is sealed. Combined with orderless execution, a validator learns nothing it can act on.

Order is an attack surface.

Abelian is described by one file, chains/abelian.json: chain id 44001 (0xABE1), settling to Robinhood Chain (chain id 4663), tokens ETH and USDG, market ETH/USDG. Every validator serves the API below and a live explorer at /.

pnpm abelian status             # height, leader, validators, last checkpoint
pnpm abelian book --market ETH/USDG

Transactions

Every transaction is an operation signed by a secp256k1 key with EIP-712:

domain  = { name: "Abelian", version: "1", chainId: 4663, verifyingContract: <AbelianRollup> }
Tx      = { from: address, nonce: uint64, expiry: uint64, op: string }

The domain is the settlement chain's id and the rollup contract, so any wallet connected to Robinhood Chain can sign Abelian transactions, and a signature for one Abelian chain (or fork) is worthless on any other. GET /status returns the domain to sign with.

• nonce is random, not a counter: blocks are sets, so an account's transactions have no order. A transaction hash can only be included once.
• expiry is the last Abelian height at which the transaction may be included.
• op is the canonical JSON (keys sorted, no whitespace) of one operation, with exactly the fields below, addresses in lowercase, amounts as decimal strings below 2¹²⁸.

price is quote base units per one whole base token: for ETH/USDG, "2500000000" is 2,500 USDG per ETH. Tokens are Robinhood Chain addresses; native ETH is the zero address.

The overdraft rule applies per account and token: if the debits an account requests in a block exceed its balance, all of them are rejected. Buy orders lock quote, sell orders lock base.

Transactions carry no fee. A validator accepts 20 submissions per second per client (bursts of 100), holds at most 64 pending transactions per account, and refuses an expiry more than 100,000 blocks ahead. ttl and expiry count blocks, not seconds: a block comes as soon as there is something to include, and at least once a minute otherwise.

HTTP API (every validator)

A block:

{
  "header": { "height": 812, "parentHash": "0x…", "stateRoot": "0x…", "txRoot": "0x…",
              "withdrawalRoot": "0x…", "depositNonce": 14, "forcedNonce": 2,
              "timestamp": 1792810000000, "proposer": "0x…" },
  "txs": [{ "hash": "0x…", "from": "0x…", "op": { "type": "order", … }, "result": { "ok": true } }],
  "clearings": [{ "market": "ETH/USDG", "price": "2450000000", "volume": "600000000000000000",
                  "buys": 2, "sells": 1, "fills": [ … ] }],
  "votes": ["0x…", "0x…", "0x…"]
}

txs is sorted by hash. The order carries no meaning: it is there so the list is canonical. A transaction that came through forced inclusion carries "forced": <nonce>.

SDK

import { AbelianClient, opOrder, opTransfer, deposit, claim } from "@abelian/abelian";

const abelian = new AbelianClient("https://www.abelianchain.com/api/v");
const { hash } = await abelian.send(account, opOrder("ETH/USDG", "buy", 2_450_000000n, 10n ** 17n, 50));
const { height, result } = await abelian.waitForTx(hash);

// On Robinhood Chain: deposits in, checkpointed withdrawals out.
await deposit(publicClient, walletClient, rollup, USDG, 100_000000n, account.address);
for (const w of await abelian.withdrawals(account.address)) if (w.proof) await claim(publicClient, walletClient, rollup, w);

Also exported: forceTransaction (post a signed transaction on Robinhood Chain), escape (exodus mode), rebuildFromSettlement (re-execute the whole chain from Robinhood Chain data, no validator needed), the state transition executeBlock, the hashing that matches the contract, and the node itself.

CLI

Keys come from .env: ABELIAN_KEY for a user.

pnpm abelian deposit  --token ETH --amount 0.01
pnpm abelian transfer --token USDG --to 0x… --amount 25
pnpm abelian order    --market ETH/USDG --side buy --price 2450 --amount 0.1
pnpm abelian account
pnpm abelian withdraw --token USDG --amount 100
pnpm abelian claim
pnpm abelian withdraw --token ETH --amount 0.01 --force   # through Robinhood Chain, no validator needed
pnpm abelian freeze | escape | refund                      # exodus mode

Create a token

Anyone creates a token in one transaction on Robinhood Chain: AbelianTokenFactory.createToken(name, symbol, description) makes it with a fixed supply of 1,000,000,000 and deposits all of it into its pool on Abelian, which opens once Robinhood Chain finalizes the block. Every buy and sell of a block clears at one price on the pool’s curve, so nobody buys before anyone else. It is a building block: a launchpad, a game or a community coin is an app on top of it (what people build; details in docs/abelian/tokens.md).

pnpm abelian create-token --name "Fair Coin" --symbol FAIR --description "Nobody buys first."
pnpm abelian swap --token 0x… --side buy --amount 0.01        # ETH to spend
pnpm abelian swap --token 0x… --side sell --amount 1000000    # tokens to sell
pnpm abelian tokens

A swap is the operation { "type": "swap", "token", "side", "amount", "limit" }: a buy spends amount of ETH at most at limit, a sell sells amount tokens at least at limit (wei per whole token). Its result says what it traded: price, spent, received. GET /tokens and GET /tokens/:address list the tokens with their pools, prices, holders and clearings.

Apps in the browser

The site serves the SDK for web apps as one ES module, with nothing to install: it reads the API and acts with the visitor’s own wallet (MetaMask, Rabby or any EIP-1193 provider), signing on Robinhood Chain.

import { Abelian, opSwap } from "https://www.abelianchain.com/assets/abelian-sdk.js";

const abelian = new Abelian();                       // the chain's public API
const tokens = await abelian.tokens();
await abelian.useSettlementChain(window.ethereum);
const { token } = await abelian.createToken(window.ethereum, { name: "Fair Coin", symbol: "FAIR" });
const { hash } = await abelian.send(window.ethereum, opSwap(token, "buy", 10n ** 16n));
const { result } = await abelian.waitForTx(hash);    // { ok, price, spent, received }

To work on an app without touching a real chain, pnpm devnet:abelian --activity runs Abelian on this machine with a token factory, three tokens and traders that keep them moving; point new Abelian("http://127.0.0.1:19101") at it.

Running a validator

Validators are listed in the chain spec and staked in its AbelianRollup contract. A validator signs block headers and checkpoints with its key; signing two different headers at the same height is slashable by anyone on Robinhood Chain (honest validators persist their votes, so a restart never causes it). See launch to operate one and fork to launch your own chain.

pnpm abelian validator --index 1      # key in ABELIAN_VALIDATOR_KEY_1, data in data/abelian/<address>

At launch the genesis set is four validators with equal stake, so a block needs three signatures to be final. The network page has a model of quorum, rotation and slashing.

What you need

• The deployer key in .env as DEPLOYER_KEY (or ABELIAN_DEPLOYER_KEY), holding about 0.015 ETH on Robinhood Chain: deployment and setup gas (well under 0.001 ETH at today's 0.02 gwei), plus 4 validators × (0.001 ETH stake + 0.002 ETH for checkpoint gas).
• Node 22+, pnpm and Foundry (forge, anvil).
• A machine that stays on for the validators: any small VPS with Docker, or this PC.

The launch

pnpm install
pnpm build:contracts

# 1. Rehearse: the whole launch on a local fork of Robinhood Chain mainnet (real USDG, real gas
#    price, your real deployer balance), then deposits, a batch, a withdrawal and its claim, a forced
#    transaction and a validator outage. Nothing is sent to the real chain.
pnpm abelian rehearse

# 2. Launch: creates 4 validator keys in .env (BACK UP .env), shows the plan and the cost, asks
#    for "yes", deploys AbelianRollup, lists ETH and USDG with their caps, admits and stakes the
#    validators, and writes the contract address into chains/abelian.json. If anything stops it
#    halfway, run it again: it resumes where it stopped.
pnpm abelian launch

# 3. Start the 4 validators (or one terminal each: pnpm abelian validator --index 1 … 4).
docker compose up -d --build

# 4. Check.
pnpm abelian status
pnpm abelian validators

The explorer is at http://127.0.0.1:7001/ on the operator's machine. Commit and push chains/abelian.json: it is the chain's genesis, and anyone who wants to verify, build on or fork Abelian starts from it.

Going public

Expose validator 1 only, behind TLS, and put its URL in the site and the SDK examples. With Caddy:

abelian.example.com {
  reverse_proxy 127.0.0.1:7001
}

The validators' peer URLs in chains/abelian.json stay on 127.0.0.1 while all four run on one machine. When an independent operator joins, their validator gets a public URL in the spec.

First transactions

# A user key (not the deployer, not a validator) in .env as ABELIAN_KEY.
pnpm abelian deposit --token ETH --amount 0.002     # credited once Robinhood Chain marks it safe (~10-15 min)
pnpm abelian account
pnpm abelian withdraw --token ETH --amount 0.001
pnpm abelian claim                                  # after the checkpoint, ~30 s later

Operating

Gas. The validator whose turn it is pays for each checkpoint (well under 0.0001 ETH at current prices). Checkpoints are only posted when something happened; the empty block made each idle minute is checkpointed every 500 of them, about three times a day. Top up any validator pnpm abelian validators flags as low.

Backups. .env holds the keys: losing it loses the validators (and the owner key if it is the deployer). The data volumes can be lost without losing the chain: a validator rebuilds from checkpoints on Robinhood Chain, then from its peers.

Ownership. The deployer owns the contract. Move it to a multisig when you have one: transferOwnership(newOwner) from the deployer, then acceptOwnership() from the new owner.

What protects users, and what does not

• Validators going down or censoring cannot keep anyone's funds. A user can post a transaction on Robinhood Chain (--force). If a deposit or forced transaction waits more than a day for a checkpoint, anyone runs pnpm abelian freeze, and every balance and order of the last checkpoint comes back with pnpm abelian escape, computed from Robinhood Chain data alone; uncredited deposits come back with pnpm abelian refund.
• Validators signing a false state could steal, as long as more than two thirds of the stake agree: checkpoints are signed, not yet proven. With four validators run by one person, Abelian is exactly as trustworthy as that person. The caps (1 ETH, 2,500 USDG) are there for that reason.
• The owner cannot touch funds: it lists tokens, sets caps, pauses deposits, admits genesis validators. Nothing else.
• USDG is Paxos's: the issuer can freeze addresses, including the contract's.
• The code is unaudited. Raise the caps after an audit, not before.
• Securities. Robinhood's stock tokens are tokenized securities with offering restrictions in many countries. The spec lists only ETH and USDG; listing more is the operator's legal call.

A chain is one JSON file, and it settles to whatever EVM chain you point it at. Abelian settles to Robinhood Chain, an L2, which makes it an L3. Point a fork at Ethereum and it is an L2; point it at Abelian's own settlement chain and it is another L3 beside it.

pnpm abelian new-chain --name Galois --chain-id 777001     # chains/galois.json, from chains/abelian.json
# edit chains/galois.json: settlement chain, tokens, markets, caps, timing
pnpm abelian rehearse --chain galois                       # the whole launch on a local fork, nothing sent
pnpm abelian launch --chain galois                         # keys, deploy, stake: your chain is live
pnpm abelian validator --chain galois --index 1            # … to 4

Every command takes --chain. Signatures are bound to the chain id and to the rollup contract, so transactions, votes and checkpoints of one chain are worthless on any other.

The spec

Abelian's own spec, with its values, is on the network page.

Changing the chain itself

The code is small on purpose. Where things live, in packages/abelian/src/:

Adding an operation

Say, stake or vote or a new market type:

1. add it to Op in types.ts and to validateOp in tx.ts;
2. give it a phase in executeBlock (stf.ts) that only uses commutative effects: credits, debits through the overdraft rule, set insertions, or a per-block resolution over the whole set (like the batch auction);
3. add it to randomBlock in stf.test.ts.

Step 3 is the real rule. The permutation test executes every random block in many orders and requires the same state root, results and withdrawals each time.

If the contract or the hashing changes, regenerate the parity vectors (pnpm --filter @abelian/abelian gen:vectors) and run pnpm test:contracts, then the end-to-end test (pnpm test:e2e:abelian).

Checklist before a fork goes live

• pnpm test:contracts && pnpm --filter @abelian/abelian test && pnpm test:e2e:abelian all pass;
• pnpm abelian rehearse --chain <yours> passes against your real settlement chain;
• caps are small, and stated on your site;
• .env is backed up somewhere safe;
• the spec, with its contract, is committed and public.