Harmony presented its network as an open platform operated by a geographically broad community. Its introduction called that node community Pangaea and emphasized bringing people into validation who had not previously operated nodes. This was more than an argument about fast transactions: it connected ownership of infrastructure with participation in the project. The page also describes sharding across storage, transaction processing and networking. Its old four-shard and validator-count figures should be read as historical documentation, not a September 2026 census.

The enduring design question is whether distribution of technical work also distributes practical control. A network can divide its data among committees while still depending on a small group for upgrades, funding or emergency coordination.

Sahil Dewan announced the native ONE swap on January 23, 2020. The initial ERC-20 and BEP-2 representations were to exchange one for one into the coin used by Harmony itself. His account said the preparatory rolling upgrade had passed and described exchanges as distribution partners. Open staking was still a forthcoming step in that announcement. The distinction matters because the same ticker can survive a change of ledger without preserving every operational assumption. In 2020, the stated purpose was to give the independent network its own economic security and application currency.

That historical swap should not be confused with the different Ethereum migration accounting published in 2026 or treated as a current set of deposit instructions.

The sharding documentation separates each shard's block history and state database. Transactions name their source shard and, for cross-shard transfers, a destination. Committees normally communicate within their own shard, while cross-shard operations require messages between them. Crosslinks carry information about shard blocks and signatures to the beacon chain, which checks and records them. This architecture explains both the scaling ambition and an additional validation responsibility.

It is insufficient for one local database to contain a plausible balance change; the receiving system must authenticate what happened elsewhere. The documentation describes intended atomicity and canonical-history checks. Those design properties are requirements to implement and maintain, not grounds for dismissing a later defect in the code that performs them.

Harmony's Fast Byzantine Fault Tolerance documentation describes announce, prepare and commit phases. A leader proposes a block, validators check and sign, and aggregated BLS signatures reduce the communication required to demonstrate agreement. The relevant threshold is more than two thirds of committee voting power, rather than two thirds of every person who owns ONE. The view-change mechanism replaces a stalled leader and uses elapsed time from the last committed block.

The document explicitly depends on sufficiently accurate validator clocks and enough honest participants remaining online. These conditions make the performance claim intelligible. A fast successful round is not a guarantee that a network will continue producing blocks through arbitrary operator failures, clock drift or software disagreement.

Effective Proof-of-Stake bounds an elected BLS key's effective stake around the median bid. The documented range runs from eighty-five to one hundred fifteen percent of that median. A key outside the range receives the corresponding bounded effective value, which then influences its committee voting weight. The mechanism attempts to moderate concentration without simply giving every account an equal vote. It should not be mistaken for a one-person system: operators may control several keys, and delegations can remain economically concentrated.

Rewards are shared after the validator's commission. Understanding the distinction between keys, operators and delegators is therefore necessary before using a count of elected keys as evidence about independent control or comparing advertised staking returns.

The tokenomics documentation identifies ONE as the native transaction-fee and staking asset and gives it eighteen decimal places. Holders could operate validators or delegate to them, while elected signers received compensation for producing blocks. The economic design aimed to hold total rewards, including transaction fees, steady and let increasing fee income reduce fresh issuance. This was an intended relationship between usage and monetary policy, not a guarantee of zero inflation or rising market value. These were roles in the Harmony proof-of-stake network.

Replacement ERC-20 balances and validator-vault shares on Ethereum need their own explanation; preserving the name ONE does not automatically preserve the same gas function, consensus responsibilities or withdrawal process.

Harmony's developer guide offers familiar Ethereum tooling, JSON-RPC access and both hexadecimal and one-prefixed address representations. That compatibility reduced the amount of application infrastructure a Solidity team needed to relearn. It did not make Harmony an Ethereum rollup or make similarly displayed addresses interchangeable with every contract on another chain. The same guide records a significant limitation: cross-shard transfers supported native ONE, while contracts on separate shards could not freely interact. Its cross-shard contract roadmap still refers to 2023.

This is a useful warning against reading a surviving tutorial as a current service commitment. Code portability, application composability and operational continuity are different properties, and an archived development path can establish only what it actually documents.

The network-governance rules give proposal creation to elected validators and allow unelected validators to vote. They describe a seven-day pending period followed by fourteen days of voting, with stake-weighted participation and approval thresholds. Delegators influence the process through the validator they support and can redelegate when they disagree. This is mediated participation, rather than a direct ballot for every wallet on every protocol change. The document also separates proposal, voting and implementation.

A successful ballot does not itself install new software or ensure that maintainers will prioritize it. Later forum disagreements over tooling and execution are therefore relevant to the architecture of governance, not merely complaints outside an otherwise automatic decision system.

Matthew Barrett's incident account records the June 23, 2022 theft from the Horizon Ethereum bridge. The team estimated approximately one hundred million dollars in lost assets and subsequently attributed the unauthorized withdrawals to compromised signing keys. Its June 25 update described changing the Ethereum-side multisignature threshold to four of five. The account treated the bridge breach and the Harmony consensus layer as distinct. That distinction explains how a chain could continue processing transactions while representations of outside assets lost their backing.

A bridged balance is a claim dependent on the custody and release mechanism for its underlying asset. Working block production cannot, by itself, repair a shortfall in that external reserve.

The FBI publicly attributed the Horizon theft to the Lazarus Group, also identified as APT38, on January 23, 2023. Its February update identified additional wallets associated with the stolen assets. This provides a primary law-enforcement attribution, but it does not establish that victims were repaid or that every later recovery proposal succeeded. Those are separate economic and administrative questions. The distinction is important when a project's history moves from investigating an attacker to deciding who should fund restitution.

Identifying responsibility for a theft can coexist with disagreement among validators, token holders and bridge users about the distribution of its remaining cost.

Harmony's April 1 report described the previous month's v2026.0.0 mainnet release alongside Goldilocks trading strategies and cloud backtesting. The detailed report placed the sixty-blocks-per-minute experiment on localnet and devnet, even though its headline emphasized progress toward one-second finality. It also recorded fixes to a mainnet timestamp problem and peer recovery. These are distinct kinds of evidence: a reported mainnet software rollout, an experimental performance result and work on a separate trading product.

Treating all three as a single live-network improvement would overstate the record. The trading results also came from specified tests and configurations, so they are not a return promised to ONE holders or evidence that protocol fees funded those profits.

The August 2026 hardening pull request documents corrections to cross-shard receipt checks, staking, rewards and virtual-machine behavior. One important concern was validating incoming receipts along insertion paths, including spent status, destination shard, proofs and source signatures. The same description left the mainnet epoch for StrictStateValidationEpoch undecided. That explicit boundary prevents promoting every change in the patch into a verified active consensus rule.

Version 2026.1.3 was released on August 19, but release publication alone does not reveal which operators installed it or establish sustained network health. The code record is useful precisely when its scope is kept concrete: it identifies engineering work and outstanding activation conditions, rather than certifying an entire recovery.

Aaron Li's public progress log in the Harmony organization records chain-state investigation on August 11, rollback work during the following days and migration work throughout September. The later entries mention exchanges, validator follow-up, vaults and verification. This is first-person evidence of the team's work, not an independent audit of the resulting balances. It also helps establish the provenance of the separately published migration repository.

A reader should resist extracting more certainty from a work log than it supplies: time spent verifying a migration is not proof that every disputed account was resolved, that every exchange credited its customers or that an application's positions were recreated on another ledger.

The public migration repository sets a September 10, 2026 cutoff at 14:00 UTC and identifies the corresponding blocks on shards zero and one. Its initial eligibility calculation combines legitimate liquid balances, staking-related claims, supported pending transfers and WONE, with a one-thousand-ONE threshold and recent-activity condition. Active stake is represented separately through validator ERC-4626 vault shares. Crucially, the repository calls itself source code and methodology for independent review, not a distribution file.

It withholds calculated totals pending reproduction and requires stage-specific readiness checks. Eligibility, destination approval and actual delivery remain different records.

The migration FAQ says application contract code will not move automatically. It reserves reviewed multisignature, LayerZero-collateral and 1wallet allocations for a later stage, while SmartVault and other reviewed contract categories are not issued under the selected policy. Exchange entitlements follow confirmed destinations and manual delivery arrangements, leaving the exchange responsible for customer crediting. For ordinary holders, that means account classification can matter as much as the displayed balance.

A contract address that exists on Harmony is not automatically a safe destination on Ethereum. The FAQ also leaves the timing of smaller-wallet distribution unscheduled. These are the documented policy boundaries at review, not an endorsement of their fairness or a promise that later procedures cannot change.