Layer 1 blockchain
Core ticker CORE
Summary
Satoshi Plus. A small elected validator set runs a go-ethereum client that borrows from BNB Smart Chain and takes turns producing a block every 3 seconds. Once a day validators are ranked by a hybrid score mixing three delegated inputs: votes Bitcoin miners write into their coinbase transactions (counted from Bitcoin blocks a week earlier), BTC that holders time-lock on Bitcoin with metadata naming a validator, and staked CORE. Governance sets the three weights; the reviewed docs give no numbers. Since the Hermes hard fork (25 November 2025) validators also sign BLS finality votes, and a block is final after about two blocks once at least two-thirds vote. Only validators' CORE deposits can be slashed; delegated BTC, CORE and hash power risk only rewards. 3581314182021
Design
- System
- Layer 1 blockchainCore (chain ID 1116) runs its own validator set, block production and finality, and its docs call it an EVM-compatible layer 1. It does not post its blocks, state or proofs to Bitcoin or Ethereum, so it is neither a rollup nor a Bitcoin layer 2, and it has no two-way peg that would make it a Bitcoin sidechain. Bitcoin feeds validator elections (miners' coinbase votes and BTC time-locked on Bitcoin, relayed into an on-chain Bitcoin light client); it is not Core's settlement layer. It is therefore classed as a layer 1.
- Settlement family
- Ethereum / EVM
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Economic finality
- Who makes blocks
- The top-ranked validators by hybrid score, each with a refundable 50,000 CORE deposit, rotate block production in 3-second slots. Core's pages disagree on the set size: the validator election page, architecture page, validator overview and whitepaper say 31, while the validator registration page says 27. Relayers carry Bitcoin block data into an on-chain Bitcoin light client, and verifiers can submit evidence that gets a validator slashed or jailed.
- Fork choice
- Core's client prefers the branch with the higher justified block from finality votes; when those are equal it prefers more accumulated difficulty, where an in-turn validator's block counts 2 and an out-of-turn block counts 1. Bitcoin's most-work chain plays no part in choosing Core's branch. By design, if fewer than two-thirds of validators vote, blocks keep coming without finality under the difficulty rule. The whitepaper also describes checkpoint hashes added to the client code against long-range attacks.
Qualifications
- Bitcoin security inheritance · Contested. Core's docs say the chain is secured by Bitcoin. What Bitcoin actually supplies is election weight: miners' coinbase votes and BTC time-locked on Bitcoin. Neither can be slashed, neither signs Core blocks, and Core writes nothing back to Bitcoin, so rewriting Core history needs control of Core's validators, not Bitcoin hash power. The added cost to an attacker depends on governance-set weights that were not published as numbers.
- Scarce resource · Contested. Filed as stake because elected validators bond CORE and produce blocks, and two of the three election inputs are locked assets (CORE and BTC). The third input is delegated Bitcoin hash power, a vote rather than work spent on Core, so neither a pure stake nor a pure work label fits.
- Finality · Partial. Since 25 November 2025 Core documents finality in about two blocks (roughly 6 seconds) once two-thirds of validators sign BLS votes, and conflicting votes are slashable in Core's contracts. If votes fall short, blocks continue without finality. The FAQ's older 12-block confirmation figure predates this change. The design was not independently tested for this profile.
- Decentralization · Partial. Anyone can delegate CORE, time-lock BTC or point hash power at a validator, but only 27 to 31 elected operators with a 50,000 CORE deposit sign blocks. In late August 2026 some of those block producers exploited a flaw in the reward contract to credit block rewards more than once; Core's fix, and by news reports a reconciliation that removed CORE from affected balances, came through a hard fork on 3 September 2026 that depended on the validators upgrading together. Operator identities and how concentrated the hybrid score is were not verified.
- Rollup security model · Not applicable. Core runs the same virtual machine, account format and tooling as Ethereum, but it posts no data to, and does not settle on, Ethereum or any other chain, so rollup security and data-availability models do not apply.
Tradeoffs
- Emphasizes
- Scalability and Security Contested
- Gives up
- Decentralization of block production: 27 to 31 elected validators, each posting a 50,000 CORE deposit, produce and finalize every block, and Core's full-node guidance calls for 32 GB of RAM and a fast 1 TB SSD. Finality depends on two-thirds of that small set voting honestly and on time.Core presents Bitcoin participation as a security gain, and that reading is disputed. Miners attach a vote to work they already do for Bitcoin, at no extra cost; time-locked BTC stays on Bitcoin and cannot be slashed; neither decides Core's fork choice. Only validators' CORE deposits are at risk for misbehavior. The weights of the three inputs are set by governance and are not published as numbers in the reviewed docs.
- Full node at home
- Demanding 10Core's docs list 4 CPU cores, 32 GB of RAM, 1 TB of free SSD space (gp3 class, 8k IOPS, 250 MB/s, read latency under 1 ms) and a 5 Mbps connection for a mainnet full node. The page is undated and gives no chain size or sync time; the example launch command sets an 8 GB cache.
- Throughput claims
- Theoretical peak: 700 tx/s 9Theoretical peak; not comparable across chains or with observed load.Core's FAQ answers 'How much TPS can the Core network withstand?' with about 700 transactions 'with an artificially low gas limit'.Undated FAQ answer; whether it predates the November 2025 Hermes hard fork is not statedVendor statement with no published method, transaction mix, hardware or measurement window; it reads as a ceiling set by the gas limit, not an observed rate. Ignores state growth, propagation across the node set and spam or decoy load; not comparable with other chains' figures.
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | Not yet assessed under the current definitions; a 2024 Core post describes hash time-locked swaps between Core and Bitcoin, which EVM contracts can implement as building blocks, but no live deployment or usage was verified for this profile. 40 |
| Authenticated data publication | Unknown | Not yet assessed under this row's current definition. |
| Light clients | Unknown | Not yet assessed under the current definitions; no light client for verifying Core itself was found. Core runs an on-chain light client of Bitcoin, which lets Core contracts check Bitcoin staking and miner votes; that verifies Bitcoin, not Core, and does not help a Core wallet verify Core. 6 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Core was found. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Core runs the EVM from a go-ethereum fork, so spend conditions are smart contracts; the Hermes hard fork added code on externally owned accounts. BTC staking uses Bitcoin Script timelocks on the Bitcoin chain, which is separate from Core's own execution. 6121718 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; the earlier review found no feature that lets users cancel, delay or recover payments on Core. The BTC staking lock is a Bitcoin timelock that only delays the owner's own spend. The 3 September 2026 hard fork that fixed a validator reward exploit also removed about 186 million CORE of early-issued rewards from affected addresses, per a news report citing Core; that was a one-off state change by Core and its validators, not a feature users can invoke. 2223 |
| Rollups | Unknown | No rollup anchored to Core was found or reviewed. Core itself is not a rollup on Bitcoin; see the class note. |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Established in the ecosystemMolten Finance, ArcherSwap, SushiSwap, IcecreamSwap | Core's April 2025 guide uses SushiSwap as its swap example, lists BitFLUX and Glyph among its exchanges and describes ArcherSwap as a hub for supplying, borrowing and leverage; DefiLlama files ArcherSwap as an exchange on Core. Core's July 2025 post says Molten Finance merged BitFLUX and Glyph into one exchange, and Molten's docs describe a concentrated-liquidity pool (Algebra Integral) and a stable-swap pool. DefiLlama's Core DEX overview also lists IcecreamSwap and others. Liquidity depth was not measured, and Molten's docs do not name the network their contracts run on. 28293031 |
| Issuer-native stablecoins | None found | Neither Tether's supported-protocols page nor Circle's USDC address list includes Core. The USDT and USDC contracts in Core's bridge docs are Core Bridge wrapped versions of tokens held on other chains. Here native means issued by the issuer on Core itself. 243233 |
| Algorithmic stablecoins | Unknown | Algorithmic or hybrid stablecoins on Core were not reviewed. |
| Bridges | First-partyCore Bridge (LayerZero), Chainlink CCIP | Core Bridge is Core's official bridge, built on LayerZero messaging, to Ethereum, BNB Smart Chain, Polygon, Optimism, Avalanche, Arbitrum and Base; Core's docs list wrapped WETH, USDC, USDT and WBTC contracts on Core. Core's docs also give mainnet settings for Chainlink CCIP. coreBTC, a collateralized BTC bridge announced in 2024, was not checked for current status. Risk: Bridged tokens on Core are claims on assets locked in bridge contracts on other chains. Their backing depends on those contracts, LayerZero's message verification settings and whoever can upgrade or configure them, none of which Core consensus checks. BTC time-locked for staking is not bridged and never moves to Core. 242526 |
| Block explorers | First-partyCore Scan | Core's docs name Core Scan (scan.coredao.org) as the mainnet explorer; they do not say who operates it or what software it runs, and other explorers were not reviewed. Explorer data is the operator's index, not consensus. 27 |
| Hardware wallets | ThinLedger, Trezor Safe 3, 5 and 7 through MetaMask or Rabby | See custody rows: Core documents Ledger paths through MetaMask for CORE and through a Core device app for BTC staking, and Ledger's own wallet code keeps Core behind a switch that is off by default, with no Ledger product page for Core found. Trezor's Core page lists MetaMask and Rabby, and Trezor Suite does not include Core. 34363739 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | PartialSame as native: Unknown | Can: Stake CORE on Core's staking website from MetaMask with a Ledger running the Ethereum app, with blind signing enabled, per Core's guide Can: Stake and redeem time-locked BTC with the Core device app, which shows amount, validator, fees and addresses on screen, through Core's staking website or Xverse Cannot: Redeem time-locked BTC with the standard Ledger Bitcoin app; Core warns this can cost access to the locked coins Cannot: Stake BTC from secondary or derived addresses or from addresses other than Native SegWit, per Core's Ledger guide Cannot: Add a Core account in Ledger's own wallet unless Ledger has switched the network on: current Ledger Wallet code includes Core but keeps it behind a feature switch that is off by defaultFirst-party support exists in Ledger's code but is limited: Ledger Wallet's source configuration lists Core (chain ID 1116) with a Ledger-run node, and the network sits behind a switch that is off by default, with no readable Ledger page confirming it is on. The paths Core documents run through MetaMask with Ledger's Ethereum app and through Core's staking website with a Core device app. 34353637 |
| Trezor | Through an intermediaryMetaMask or Rabby, listed on Trezor's Core pageSame as native: Unknown | Can: Keep the key for a Core address on a Trezor Safe 3, Safe 5 or Safe 7 and sign Core transactions through MetaMask or Rabby, which Trezor's Core page names for the Core network Cannot: Open Core accounts in Trezor Suite: Suite's list of EVM networks does not include chain ID 1116Trezor's Core page lists the Core network with only MetaMask and Rabby as apps, labels its screenshot as Core not supported in the Trezor Suite app, and describes Satoshi Plus consensus, which identifies it as this chain. Whether CORE staking or BTC staking on Core works with a Trezor through these apps was not tested, and the Core hardware-wallet guides reviewed cover only Ledger. 3839 |
Public data
iKnow Blockchain has no public-data lookups for Core yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
Emergency hard fork fixed a validator reward exploit on 3 September 2026
In late August 2026 some Core validators credited block rewards more than once through a system contract that had no per-block limit. On 1 September Core committed a contract fix and released client v1.0.24 scheduling a mainnet hard fork; v1.0.25 limited zero-fee transactions to system contracts and v1.0.26 moved activation to 13:00 UTC on 3 September. A news report citing Core says about 255 million CORE was released early, about 186 million was removed from affected addresses at the fork and about 69 million had already moved elsewhere.
- Implementation:system-contract fix committed; client releases v1.0.24 to v1.0.26 published
- Release:emergency mainnet hard-fork release
- Activation:scheduled for 2026-09-03 13:00 UTC; a news report says it activated at block 38,376,795; not checked on-chain
Sources: Core DAO (GitHub) — ValidatorSet per-block reward guard (core-genesis-contract commit fb35c941) (external site) · Core DAO (GitHub) — core-chain v1.0.24 (mainnet validator upgrade) (external site) · Core DAO (GitHub) — core-chain pull request 98: network upgrade v1.0.25 (external site) · GitHub — core-chain pull request 99 (v1.0.26) changed files (GitHub API) (external site) · Cointelegraph — Core DAO plans hard fork over excess validator rewards (external site) · The Crypto Times — Core DAO fixes reward exploit, claws back 186M CORE (external site)
-
Core published a 2026 roadmap
A Core post lists plans for 2026, including chain upgrades aimed at sub-second block times and finality, liquid staking tokens for BTC, markets that pair BTC and CORE stakers, and term-based staking. It also says current CORE emissions are about 2.5% of circulating supply a year and that the Hermes upgrade is complete.
- Proposal:announced roadmap
- Implementation:not observed
- Release:no dates given
- Activation:no listed item confirmed live as of this review
-
Hermes hard fork brought two-block finality votes to Core mainnet
Core scheduled the Hermes hard fork for mainnet at 08:00 UTC on 25 November 2025 with client v1.0.22. It adds BLS finality votes adapted from BNB Smart Chain's BEP-126, under which a block is final after about two blocks (around 6 seconds) once two-thirds of validators vote, plus validator maintenance mode, BLS12-381 operations, historical block-hash access and code on externally owned accounts.
- Proposal:BNB Smart Chain proposals adopted by Core (BEP-126 and others)
- Implementation:shipped in client v1.0.22
- Release:mandatory mainnet release
- Activation:scheduled 2025-11-25 08:00 UTC; Core's December 2025 post says it was delivered
Sources: Core DAO — Hermes hardfork on mainnet (external site) · Core DAO (GitHub) — core-chain v1.0.22 (Hermes mainnet) (external site) · Core DAO (GitHub) — Chain configuration source (params/config.go) (external site) · Core DAO — Hermes upgrade guidelines for validators and full node operators (external site) · Core DAO — The Core revenue roadmap (external site)
-
Governance proposal to double Dual Staking CORE-to-BTC ratios
Core published a governance proposal to double the CORE-to-BTC ratios that set Dual Staking reward tiers, from 34,000, 12,750 and 4,250 CORE per BTC to 68,000, 25,500 and 8,500, with a three-day vote from 5 to 8 November 2025 and implementation right after if approved.
- Proposal:governance proposal with a vote from 2025-11-05 to 2025-11-08
- Implementation:Core's docs show thresholds matching the proposed ratios; vote result not seen
- Release:parameter change; no client release involved
- Activation:not confirmed from a primary result notice
Sources: Core DAO — Governance proposal to adjust the Dual Staking CORE to BTC ratios (external site) · Core DAO Docs — Dual Staking overview (external site)
Topics your AI can explain
Your AI can explain these topics for Core through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Core's pages disagree on the elected validator count (31 on the validator election, architecture and validator overview pages and in the whitepaper, 27 on the validator registration page); the live count and how the hybrid score is spread across operators were not read on-chain.
- The governance-set weights for delegated hash power, staked CORE and time-locked BTC in the hybrid score are not stated as numbers in the reviewed docs or whitepaper.
- The share of Bitcoin hash power delegating to Core validators and the amount of BTC time-locked were not measured; Core's homepage counters did not load.
- The current penalty for conflicting finality votes was not read on-chain; the slashing contract's starting value is 1,000 CORE, and Core's slashing pages mention only missed blocks and double signing.
- Some docs look older than the upgrades: the FAQ's 12-block confirmation time and the contract guide's statement that Core matches the Shanghai EVM predate the Cancun-era (June 2025) and Hermes (November 2025) upgrades in the client configuration.
- Core's own post-mortem of the August 2026 validator reward exploit was posted on X and could not be read; the amounts (about 255 million CORE issued early, about 186 million removed at the fork, about 69 million moved out of reach) come from a news report citing Core, and the changed balances were not checked on-chain. The code fix and the 13:00 UTC activation on 3 September 2026 were read in Core's repositories.
- How gas prices are set and whether any part of fees is burned today was not verified beyond the governance page's statement that the fee-burn share is 0%.
- No light client for verifying Core, no payment or state channels and no rollups anchored to Core were found.
- Whether the hash time-locked swaps described in a 2024 Core post are live was not verified.
- coreBTC, lstBTC and other BTC-backed tokens on Core were not reviewed for custody model or current status.
- No Ledger product page for Core's chain was found; Ledger support rests on its wallet source code, where Core sits behind a switch that is off by default, and on Core's own guides. Ledger's switch settings for users could not be read, so whether Core has been switched on in Ledger's wallet was not confirmed.
- Trezor's Core page lists MetaMask and Rabby; which Core actions, including CORE and BTC staking, work with a Trezor through them was not tested.
- Liquidity depth on Core's exchanges was not measured, and Molten's docs do not name the network their contracts run on.
- Algorithmic stablecoins on Core were not reviewed.
- The operator of Core Scan, the Core Bridge's upgrade keys and its LayerZero verification settings were not identified.
- Chain data size, sync time and archive-node needs were not measured.
- The only throughput figure is Core's own undated FAQ claim; no observed rate was classified.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Core 101 (external site)
- Core Architecture (external site)
- Validator Election (Satoshi Plus) (external site)
- Validators overview (external site)
- Validator registration (external site)
- Bitcoin staking transaction design (external site)
- Slashing fees (external site)
- Delegator FAQs (external site)
- Core FAQs (external site)
- Full node configuration (external site)
- Governance (external site)
- core-chain repository (external site)
- Satoshi consensus engine source (satoshi.go) (external site)
- Fork choice source (forkchoice.go) (external site)
- Chain configuration source (params/config.go) (external site)
- SlashIndicator system contract (external site)
- core-chain release v1.0.22 (Hermes mainnet) (external site)
- Hermes hardfork on mainnet (external site)
- Core White Paper v1.0.7: Security (external site)
- Core White Paper v1.0.7: Delegated Proof of Work (external site)
- Core White Paper v1.0.7: Validator Election (external site)
- ValidatorSet per-block reward guard (core-genesis-contract commit fb35c941) (external site)
- Core DAO fixes reward exploit, claws back 186M CORE (external site)
- Core Bridge resources (external site)
- Bridging with LayerZero (external site)
- Chainlink CCIP cross-chain guide (external site)
- Core Explorer (external site)
- How to bridge, stake and explore Bitcoin DeFi on Core (external site)
- DEX overview for the CORE chain (API) (external site)
- Molten Finance: BTCfi DEX live on Core (external site)
- Molten documentation (external site)
- Supported protocols (external site)
- USDC contract addresses (external site)
- Ledger Wallet feature switch currencyCore (declared without an enabled value) (external site)
- Ledger Wallet EVM network configuration (config.ts) (external site)
- BTC staking with Ledger on Core mainnet (external site)
- Staking CORE with Ledger (external site)
- Trezor Suite Ethereum-family network configuration (external site)
- Core wallet (external site)
- Exploring BTCfi: Bitcoin staking, stCORE, coreBTC and HTLC atomic Bitcoin swaps (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding