How PulseChain works: the fork, consensus and fees

Is PulseChain a copy of Ethereum?

Yes, openly. The execution client go-pulse is a fork of go-ethereum, and its mainnet configuration lists every Ethereum upgrade from Homestead to Gray Glacier at the same block numbers as Ethereum (params/pulse.go). Blocks below 17,233,000 are Ethereum mainnet blocks: for them the client still checks signatures with Ethereum’s chain ID 1 and uses Ethereum’s own Shanghai time. From block 17,233,000 on, PulseChain keeps its own ledger.

What happened in block 17,233,000?

Ethereum had already moved to Proof of Stake at that height. PulseChain therefore “un-merges” for exactly one block: 17,233,000 is produced as a single Proof-of-Work block with a deliberately tiny difficulty of 131,072. PulseChain’s terminal total difficulty is set to Ethereum’s last real value plus 131,072, so right after that block the chain merges again — this time with PulseChain’s own beacon chain. The header check in the client allows this one PoS → PoW → PoS transition and no other.

The block was read from the official RPC on 2026-10-17; its difficulty matches the constant in the code. You can repeat the reading with the calls in Verify it yourself.

What did the fork block change in the state?

Three things, all in the client’s pulse/ package (source):

1. Sacrifice credits. PLS balances for sacrifice participants are added from a binary file embedded in the client. The file is published and reproducible in the separate compressed-allocations repository (tag Mainnet, the tag the client’s code comment points to), which documents the format and ships a decoder. The inputs are three lists: the PulseChain sacrifice, the PulseX sacrifice and Ethereum beacon-chain depositors. Our reading of why the third list exists: those depositors’ ETH sits in Ethereum’s deposit contract, which is disabled on PulseChain, so their copy of that ETH would otherwise be unusable there.
2. No mainnet treasury. A “treasury” allocation exists only in the testnet configuration (params/pulse.go); the mainnet configuration has no treasury field, so that branch of the code never runs on mainnet.
3. A new deposit contract. Ethereum’s beacon deposit contract 0x00000000219ab540356cBB839Cbe05303d7705Fa is destroyed on PulseChain and replaced by an empty contract that rejects any value. PulseChain’s own deposit contract is written to 0x3693693693693693693693693693693693693693 with a fresh Merkle tree; its source is verified on PulseScan.

The credit file embedded in the client and the repository’s credits.bin have the same SHA-256 hash, 6a8b1890c13c65b2b08e8eb4af7d4707ac73b7bd5e5332c23992381493ba79e1, so anyone can check that the published data is what the chain applied.

What was copied unchanged?

Everything else. Every account balance, ERC-20 token, NFT and contract that existed on Ethereum at block 17,232,999 exists on PulseChain with the same address, code and storage. ETH balances became PLS balances one to one, because PLS is simply the native coin of the copied state. From the fork on, the two chains are independent: a copied token on PulseChain is not backed by the original on Ethereum. The difference between these copies and tokens bridged later is explained in System copies vs bridged tokens.

Why can one address mean two different contracts?

Deployer accounts and their transaction counters were copied too, and each chain continued counting on its own. A contract deployed after the fork can therefore land on an address that holds a different contract on the other chain.

Both collisions were read on-chain on 2026-10-17. Always name the chain together with an address.

How does PulseChain’s Proof of Stake differ from Ethereum’s?

The protocol is Ethereum’s beacon chain, run by forks of Lighthouse and Prysm. What differs are constants in the network configuration and preset, plus one change in the clients’ code — the reward burn:

Values from the lighthouse-pulse network configuration and preset, and the go-pulse configuration for Shanghai; the reward burn is code, explained below. How validators use all this is on Validators.

Why is the base reward factor 64,000?

Validator rewards grow with a validator’s effective balance times the base reward factor, divided by the square root of everything staked. PulseChain balances are a million times larger in units (32 million instead of 32), which makes that square root a thousand times larger. Multiplying the factor by 1,000 — from 64 to 64,000 — keeps the percentage reward rate in the same range as Ethereum’s. This is our reading of the formula; the number itself is in the code.

What is the validator reward burn?

Both PulseChain consensus clients change how rewards are credited. Before a reward is added to a validator’s balance, it is multiplied by the slot time divided by 12 — 10/12 on PulseChain — and then by 3/4; the code comments call the second step burning “an additional 25%” (lighthouse-pulse pulse.rs, prysm-pulse reward_burn.go). Together a validator receives 62.5 % of what the Ethereum formula would pay. The cut applies to attestation, sync-committee and block-proposer rewards; slashing-related rewards and deposits are credited in full, and penalties are not reduced. The burned part is never created, so it lowers the issuance of new PLS.

Our reading: PulseChain has 12/10 as many slots per year as Ethereum, so the first factor brings a validator’s yearly reward back to what the Ethereum formula gives, and the second lowers it by a quarter. The official Testnet V4 notes list this as “validator reward burning”.

Which Ethereum upgrades does PulseChain run?

Every Ethereum upgrade up to Shanghai / Capella, which went live on PulseChain at launch. Later Ethereum upgrades — Cancun (blobs), Prague/Pectra and Fusaka — are not activated. go-pulse v3.2.0 (2024-02-23) compiled Cancun support in without an activation time, and the v3.3.0 release note (2025-09-30) says the client supports newer Ethereum forks for compatibility while PulseChain remains on Shanghai + Capella. If PulseChain ever schedules one, it will appear as an activation time in params/pulse.go.

Where do transaction fees go?

• The base fee is burned. PulseChain inherited Ethereum’s EIP-1559 fee market (London is active). After each transaction only the priority tip — the gas price above the base fee — is credited to the block’s fee recipient; the base fee is credited to nobody, so it leaves the supply (state_transition.go).
• There is no block reward on the execution layer. After the merge, the client’s block finalisation only processes validator withdrawals and pays no block reward (consensus.go). New PLS comes from the consensus layer as validator rewards — after the reward burn — and reaches validators through those withdrawals.

So the net change in PLS supply equals validator rewards minus burned base fees. Whether that is positive or negative at a given time is a question for chain data, not for the code. The burn of a single block is its base fee times the gas used — Verify it yourself shows how to read it.

Where is this in the code?

The commits are the heads of the default branches checked on 2026-10-17: go-pulse a224d91967a31c2c3080a8f75784d8de13c80b7b, lighthouse-pulse e671e9dbf55f132e3189f618d2779a133f583086, prysm-pulse 992805a5f6edb4196ac7892bd6fbcdea8baa66d4. More repositories are listed on Source code.