Core DAO's 255M CORE Reward Replay: When the Coinbase Account Learned to Answer Back

TL;DR

On August 28, 2026, two new addresses joined Core's block-producing set twelve seconds apart. Over the next three days they had block rewards credited to them more times than the protocol intended, and by the time Core halted the issuance on August 31 at 06:17 UTC, roughly 255M CORE of future emissions had been pulled into circulation early. Core's own post-mortem names the enabling condition plainly: an EIP-7702 delegation sitting on the coinbase account. The CoreRewardFix hardfork activated September 3 at 13:00 UTC at block 38,376,795, removed 186,153,491 CORE by direct state reduction, and now rejects any block whose coinbase carries a delegation. About 69M CORE, near $1.5M at current prices, had already been dispersed across external wallets. The 2.1B supply cap was never breached and no user or staker funds were lost. The lesson is narrower than "a chain got hacked." The coinbase used to be the one account in a block that could not do anything, and a protocol whose issuance path quietly relies on that is one upstream EIP away from a reentrancy bug in its monetary policy.

What Actually Happened on Core Between August 28 and August 31?

Core is a Bitcoin-aligned EVM Layer 1 running Satoshi Plus, a hybrid consensus that elects a validator set by a score blending delegated Bitcoin hash power, staked CORE, and self-custodied Bitcoin. Elected validators then produce blocks in a round-robin, one three-second slot each. Rewards settle at the end of each round rather than block by block.

Between August 28 and August 31, that settlement ran hot. Core's post-mortem says accelerated rewards were credited "across three daily settlement rounds," the last at 00:00 UTC on August 31, and roughly 255M CORE of future emission arrived early.

Disclosure lagged the exploit by three days. Core's first status note landed on August 31, saying a small number of validators were accruing rewards above the intended issuance and that user assets were safe. By September 1 it said the issue was contained and an emergency hardfork was being coordinated with the validator set, described from the start as a forward upgrade rather than a rollback. Exchanges did not wait for details. Coinbase paused CORE sends and receives at 04:41 UTC on August 31 while leaving trading open, and Bithumb, Coinone, Bitget and LBank followed.

For two days after that, the most important number in the story was one nobody had. Core would not say how much CORE was involved, how many validators, or for how long, and reporters said so directly: there was no full accounting of how many extra tokens entered circulation. Every figure below exists because Core finally published on September 5.

What Is a Coinbase Account, and Why Did EIP-7702 Change It?

The coinbase is the address a block credits its own rewards to, the fee recipient named in the block header. For the whole history of the EVM it has been an externally owned account: a balance, a nonce, no code. Crediting it was arithmetic. You added a number to a slot in the state database and the account had no way to notice, let alone respond.

EIP-7702 ends that. It lets an EOA sign an authorization that writes a delegation indicator into its own code slot, in the form 0xef0100 followed by a contract address. Any operation that executes code at that account, CALL, DELEGATECALL, STATICCALL, now follows the pointer and runs the delegate's code instead of finding nothing. The account still looks like an EOA on a block explorer. It behaves like a contract.

That is a fine feature for batching and sponsored transactions, which is what it was built for. It is also a change in a global assumption. Any code path that treated "send value to this account" as terminal and side-effect-free became, silently, a call into attacker-chosen code. When a non-reentrant routine ends up nested inside itself this way, the class has a name: CWE-1265, unintended reentrant invocation of non-reentrant code via nested calls.

Core built its reward-crediting path before that was possible. It kept running after it was.

The Root Cause: A Privileged Path That Could Be Entered Twice

Core's description of the bug is short and deliberately incomplete. Block rewards are distributed "through a privileged, protocol-internal path," and a flaw there meant that "under a specific and unusual account configuration, the reward crediting for a block could be repeated more than intended." Citing responsible disclosure, Core published no reproduction, and nobody else has either.

What is public is the fix, and a fix is a specification of the bug written backwards. Client release v1.0.26 carries three permanent defenses, each naming a link in the chain:

1. A per-block guard ensuring a block's reward can be credited at most once. So it was credited more than once, for the same block.
2. Rejection of blocks whose coinbase account carries an EIP-7702 delegation. So the coinbase had code, and that code was the "unusual account configuration."
3. Rejection of unexpected zero-gas transactions, described as an additional backstop. So the re-entry arrived as a transaction that paid nothing.

Read together the shape is legible. A validator proposes a block and sets the coinbase to an EOA it has delegated under EIP-7702, so that account executes code the validator wrote. Because the validator builds its own block, it can include transactions no mempool would relay, zero-gas ones among them. Something in that block reaches the privileged reward path a second time, and the guard that should have said "already paid" did not exist.

That reconstruction is inference. It is the only reading I can make the three defenses fit, but Core published no trace and no addresses, so treat the mechanism as reconstructed rather than confirmed. The defenses are confirmed; they are in the release.

One consequence explains the cleanup. The surplus moved through the ordinary reward-settlement process, so it landed in attacker addresses and, as Core puts it, "unintentionally, in the reward addresses of honest validators who simply received an inflated payout they did not cause." The bug paid everybody.

The Attack, Step by Step

The loop in steps 2 through 5 is the whole exploit, and it is the part a linear reading hides:

What the Chain Measurement Shows

The most useful independent work on this incident is a clock. CryptoTicker measured Core's block cadence across the window and published what changed: 21 distinct block-producing addresses on August 26 and 27, 23 on August 28, back to 21 on August 31. The two extra addresses entered production twelve seconds apart and exited twelve seconds apart, the first producing its last block at 38,281,994 at 05:49:56 UTC, the second at 38,281,998 at 05:50:08 UTC.

Four blocks. At Core's three-second slot, twelve seconds is exactly four positions in the round-robin, and the symmetry holds at both ends of the window: the two addresses held fixed seats four apart, entry to exit. Validators are ordered by hybrid score, so seats that close imply the two were backed at similar levels and elected in the same round. Core has not published who they were, what they staked, or what that cost. The absence matters, because cost-to-attack is what the rest of the industry needs to reason about repeat risk, and it is the one figure the post-mortem skips.

The same measurement found 181 blocks missing from the expected cadence across August 30 and 31, which it converts to 543 seconds. That is a check on itself: 181 times three seconds is 543, exactly what Core's documented slot length predicts. The chain never stalled, and the longest single gap was five seconds. The exploit cost about nine minutes of aggregate liveness.

Then the exit. Both addresses stopped producing at 05:50:08 UTC. Core's governance halted the inflation at 06:17 UTC, roughly 27 minutes later. That gap is arithmetic on two timestamps from two sources, so it is solid; the motive is not. It fits an attacker watching for a response and leaving early, and it fits a scheduled exit at a round boundary equally well.

Do the Numbers Reconcile?

Mostly, and the one place they wobble is worth naming.

On September 3 at 14:32 UTC, ninety minutes after the fork, Core said the upgrade had "burned 150M+ CORE of excess issuance". Two days later the post-mortem gave an exact figure: 186,153,491 CORE removed by direct state reduction, no transfer to any address. Both figures can stand, and they are still different claims. The first is an in-flight conservative floor; the second is final and, Core says, verifiable on-chain at block 38,376,795. Take the 186,153,491.

The rest closes cleanly. 255M accelerated, minus 186.153M removed, leaves 68.85M, the "approximately 69M" Core says was moved out of reach. No missing bucket, which many post-mortems cannot manage.

Nobody can follow that 69M. Core published no attacker addresses, so there is no public exit trail, no exchange deposit or bridge leg to point at, and no word on whether the two validators' stake was slashed or is still bonded. Recovery, Core says, sits with law enforcement.

The reconciliation is the best engineering in the response. Rather than zeroing every affected account, Core zeroed the attacker-controlled pools and reduced honest validators' reward addresses to a "fair-earnings floor," each validator's pre-incident balance plus three rounds of its own normal reward. Three rounds, because the exploit ran for three. Balances already at or below the floor were untouched.

On value, the framing matters more than the dollars. At $0.0267, CoinGecko's daily snapshot for CORE on August 28, 255M CORE was worth roughly $6.8M; by its August 31 snapshot the token was at $0.0212, about 20% down across the window, and the same tokens were worth $5.4M. Modest, by 2026 standards. The supply figure is not. Against a circulating supply CoinGecko now reports near 1.49B, 255M CORE is about 17% of everything in circulation and the ~69M that got away is about 4.6%. An unscheduled 17% of the money supply, issued by two seats in a round-robin over a long weekend.

Core has since had the reward paths reviewed independently by Halborn, and says it will simplify the related checks in a later release.

Why This Generalizes Past Core

An audit certifies the code you showed it, on the day you showed it, under the assumptions that held that day. This bug breaks all three clauses at once.

It did not live in a smart contract. It lived in the client, in a privileged path running below anything a Solidity reviewer is scoped to read. Plenty of chains commission thorough contract audits and treat the node implementation as infrastructure someone else already checked, usually because it began as a go-ethereum fork. The reward logic bolted on top is the part they wrote.

The assumption that broke was never written down. Nobody at Core decided the coinbase would never execute code; it was simply true, for years, everywhere, so it was never a check. EIP-7702 changed the meaning of an EOA across the whole EVM ecosystem, and every chain that pulled it in inherited a new capability for the one account every block is guaranteed to touch.

We have written up this shape before. Harmony's 4 billion ONE mint was a credit applied more than once through a receipt path. Ravencoin's KAWPOW consensus bypass was a client-level check that could be walked around. Maya Protocol's uncapped slash subsidy credited a pool with tokens the reserve never held. One family: an internal accounting path that pays out, trusted because it is privileged, unmonitored because it is internal.

Core's supply cap held perfectly through all of it. Everything the attackers took was CORE the protocol had already committed to issuing, just not for years. An invariant that only checks the endpoint says nothing about the rate.

What Should Operators Do About This?

1. Treat your issuance path as an audited invariant, not plumbing. Whatever code credits validators, stakers, or a reward pool is the most privileged write in your system. It creates money. It deserves the scrutiny you give a bridge, including the client-side portion nobody scoped.
2. Add an "at most once" guard before you need one. Core's first defense is a per-block idempotency check on the reward credit. If your settlement path has no such guard, the reason is probably that nobody thought a double-credit was reachable. That is the same reason it was reachable here.
3. Audit what EIP-7702 changed in your assumptions, not just your contracts. Find every place your node or contracts pay, call, or transfer to an address an untrusted party chose. Each is now a potential call into code, and the coinbase is unlikely to be the only one.
4. Alarm on validator-set composition, not just validator health. Most monitoring watches whether validators are up. Almost none watches whether the set changed shape. Two new producers in a 21-seat rotation is a one-line query, and it was the earliest visible sign here.
5. Check issuance against the schedule every round, in code. You publish an emission curve. Compare per-round issuance to it and page a human on divergence. A cap check passes right up until the cap is hit; a rate check fails on round one.
6. Publish the cost-to-attack. The industry learns more from what a validator seat cost the attacker than from the loss figure. Core has not, and repeat-risk assessment on every hybrid-consensus chain is worse for it.

A contract audit scoped to Core's reward contracts would most likely have missed this. The enabling condition sat in the client's block-processing path and rode in on an EIP inherited from upstream. Where this was genuinely catchable is in observation, and unusually, there was time to observe.

Most drains are atomic. This one ran for three daily settlement rounds. Five things were visible on-chain while it did, every one of them a figure already cited above: the block-producing set going from 21 addresses to 23 on August 28; a coinbase account carrying an EIP-7702 delegation, a single boolean per block that Core's own client now rejects; zero-gas transactions in produced blocks, which the client now also rejects; per-round issuance running far above the published emission curve; and 181 blocks missing from a chain whose longest normal gap is five seconds. Any one of them fires on August 28 and the second and third settlement rounds never happen. Runtime monitoring would not have stopped the first round and I will not claim otherwise. It had roughly 72 hours to stop the other two, and roughly 69M CORE left the reconciliation's reach inside that window. Compressing the clock between the first anomalous block and the first human who knows is the entire job of a monitoring layer like Tripwire, and here that clock ran for three days.

Frequently Asked Questions

How much did the Core DAO exploit cost? About 255M CORE of future emissions was issued early between August 28 and August 31, 2026, worth $5.4M to $6.8M depending on the day. Of that, 186,153,491 CORE was permanently removed at the CoreRewardFix hardfork; about 69M CORE, near $1.5M today, reached external wallets and remains outstanding. No user or staker funds were lost.

Was new CORE created beyond the supply cap? No. Core's post-mortem states the 2.1B maximum supply was never violated. The exploit pulled rewards forward from the existing pool, raising circulating supply faster than the emission schedule intended rather than minting past the ceiling.

What is the actual vulnerability? Core's privileged, protocol-internal reward-crediting path could run more than once for the same block when that block's coinbase account carried an EIP-7702 delegation, which gives an ordinarily code-free account executable code. Core has not published a reproduction, so the precise trigger sequence is unconfirmed. The fix in client v1.0.26 adds a per-block "credit at most once" guard, rejects blocks whose coinbase carries a delegation, and rejects unexpected zero-gas transactions.

Could this happen on other EVM chains? The specific bug is Core's, the precondition is not. EIP-7702 lets any EOA execute code, so any chain that adopted it should check whether its privileged paths assumed the payee was inert. The check is cheap. The assumption is usually undocumented.

Sources / References

• Core DAO, Post-Mortem: Reward Accounting Exploit & Network Upgrade, September 5, 2026
• Core DAO, "The v1.0.26 hardfork is now live on Core mainnet", September 3, 2026
• coredao-org/core-chain, Release v1.0.26
• CryptoTicker, Core DAO: Transfer Freeze and Emergency Hard Fork
• The Crypto Times, Core DAO Fixes Reward Exploit, Claws Back 186M CORE
• Cointelegraph, Core DAO Plans Hard Fork Over Excess Validator Rewards
• crypto.news, CORE transfers halted on exchanges as Core DAO prepares emergency fork
• Crypto Briefing, Core DAO plans emergency hard fork after validators draw excess rewards
• CryptoSlate, A validator reward failure on Core DAO triggers exchange transfer blocks and leaves token issuance in question
• Ethereum Improvement Proposals, EIP-7702: Set Code for EOAs
• MITRE, CWE-1265: Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls
• Core DAO Documentation, Core Validator Election
• CoinGecko, Core Price: CORE/USD Live Price Chart, Market Cap & News Today