Documentation.

eCash (ECX) is a Bitcoin hard fork from Paul Sztorc and LayerTwo Labs, built to activate Drivechains (BIP300 and BIP301) on a chain of its own. It is Bitcoin Core with that change: the same SHA-256d proof of work, the same address formats, and its own difficulty retargets after a one-time reset at the fork.

At mainnet block ~973,728 (estimated around October 31, 2026) every Bitcoin address receives ECX one-for-one: hold 1 BTC at the fork, own 1 ECX after it. From then on ECX is priced by its own market. The home page shows both numbers live: the fork ratio (1:1) and the market ratio between ECX and BTC.

That is why this launchpad fits: every coin here is mined with the same SHA-256 work, in the same 80-byte header format, with the same retarget and median-time rules. Not to be confused with eCash XEC, an unrelated coin, or with Chaumian “ecash” (Cashu, Fedimint).

Coins here trade against wrapped ECX (wECX), an SPL token issued by ecash.com that exchanges at par (1:1) for real ECX through the ecash team's bridge: deposit ECX and receive wECX on Solana, or send wECX back and receive ECX, minus a bridge fee. wECX has 8 decimals, so one raw unit is one satoshi of ECX.

Know the trust model. The bridge is custodial: the ecash team holds the ECX that backs wECX. Their own bridge README notes that per-window withdrawal caps and multisig payout authority are not built yet. Until mainnet, wECX is a claim on ECX that has not forked; expect volatility around the fork.

ePeg is a launchpad built on eCash's idea of money: proof of work. Every coin is a block in a small chain that follows the same SHA-256d rules as Bitcoin and ECX. Before a coin can launch, your browser has to find a nonce that makes its 80-byte block header hash below the network target. The server checks the proof and that it builds on the current tip, then builds the Meteora bonding-curve transaction that creates the coin, paired with wECX. The block hash rides along in that transaction as a memo, so the proof lives on Solana permanently.

Eight stages from a blank form to a graduating coin. Click a stage to pause on it.

Six fields, 80 bytes, identical to Bitcoin's layout. Integers are little-endian and hashes are stored byte-reversed, which is why Bitcoin hashes are displayed “backwards”.

A header is valid when sha256d(header), read as a little-endian 256-bit integer, is at or below the target. Hashes are uniformly random, so the only strategy is to try nonces until one lands. The miner precomputes the SHA-256 state of the first 64 header bytes (the midstate), which never change, so each attempt costs two compressions instead of three, the same trick every ASIC uses. Work is split across Web Workers, one slice of the nonce space per CPU thread.

The target is packed into 4 bytes: one exponent byte and a 3-byte mantissa. Difficulty is how many times harder the current target is than the easiest allowed one (powLimit).

powLimit   bits = 0x1e03ffff
           target = 0x000003ffff000000000000000000000000000000000000000000000000000000
difficulty = powLimit / target
expected   ≈ 2^256 / (target + 1)  hashes

Every 21 blocks the target is recomputed from how long the last period actually took, aiming for one launch every 10 minutes at peak demand. This is Bitcoin's (and eCash's) GetNextWorkRequired, including Satoshi's off-by-one: the span covers 20 gaps but is compared against 21.

expected = 21 × 600s
actual   = time(h−1) − time(h−21)
actual   = clamp(actual, expected/4, expected×4)
target'  = clamp(target × actual / expected, powLimit/64, powLimit)

Drag the demand slider. Low demand sinks to the floor; a rush pushes difficulty up, at most 4× per period.

Two of Bitcoin's timestamp rules apply: a block's time must be later than the median of the previous 11 blocks, and at most 2 hours ahead of the server clock.

The merkle root makes a launch tamper-proof once mined. Three leaves are hashed pairwise with SHA-256d, and the odd one pairs with itself, exactly like Bitcoin's transaction tree. The mint keypair is generated in your browser and never reaches the server; it signs the launch there.

L0 = sha256d(mint pubkey)
L1 = sha256d(creator pubkey)
L2 = sha256d(json[name, symbol, uri, firstBuySats])
root = H( H(L0‖L1) ‖ H(L2‖L2) )

In Bitcoin and eCash the coinbase is the miner's reward. Here it's the miner's right to the first buy, inside the launch transaction, before anyone else can trade. The cap starts at 5 ECX and halves every 210 blocks. You pay in SOL; a Jupiter swap buys the exact wECX amount at launch.

After launch, each coin trades on its own Meteora bonding curve against wECX. Progress toward the migration threshold is shown as Bitcoin confirmations: each sixth of the ECX the curve raises is one confirmation. At six the curve is complete, the block is final, and liquidity migrates to a DAMM v2 pool.

On a constant-product curve price rises faster than supply sells, so confirmations bunch up near the end: the first confirmation sells about a quarter of the curve's supply, the sixth only a few percent.

Two miners can find a block on the same tip. The database enforces a unique prev_hash, so appending is atomic: the first submit wins and the other becomes an orphan that re-mines on the new tip. If a launch fails on Solana after its block was appended, the block stays as an empty block: its proof of work was real, so history isn't rewritten.

A launch is at most two Solana transactions, signed together in one wallet approval. The swap only exists when your first buy needs wECX you don't already hold.

What enforces each rule, and how you can check it.

Every coin page has a “Verify in browser” button that recomputes the hash and merkle root from the stored fields. The same check in a few lines:

import { checkProofOfWork, merkleRoot } from "@/lib/chain";

const header = { version, prevHash, merkleRoot: root, time, bits, nonce };
checkProofOfWork(header).valid;                         // hash ≤ target
merkleRoot({ mint, creator, name, symbol, uri, firstBuySats }) === root;
// and the Solana launch tx carries the memo: epeg:block:<height>:<hash>