Hedera's current documentation is explicit: this is a public, open-source, proof-of-stake distributed ledger built on hashgraph consensus, and it should not be labeled a blockchain. The distinction is not a marketing ornament. Hashgraph orders transactions through gossip about gossip and virtual voting, rather than through miners competing to publish a block.

The same pages describe native services for accounts, tokens, and consensus messages, plus smart contracts for people who want an Ethereum-style interface. HBAR is the unit that meters those services. Holding HBAR is not a share in the Hedera Council, and a council member's ordinary business is not a Hedera product.

The hashgraph write-up argues that no single leader assigns a transaction's consensus time. Nodes gossip events, and the consensus timestamp is derived from when a supermajority effectively saw the transaction. The whitepaper and the docs present this as fairer ordering than a miner who can sequence transactions inside a block.

Those are design claims with stated assumptions, including an honest supermajority and clocks that are not wildly wrong. They are not an independent benchmark of today's production throughput, and they are not a promise that every application on Hedera inherits the same fairness. An application can still order its own work badly above the consensus layer.

Hedera Council is a known set of organizations that governs the network, rather than an open race in which anyone can anonymously become a consensus node. The project treats that structure as a way to put identifiable institutions in charge of upgrades and node operation. Critics treat the same fact as evidence that the network is permissioned at the layer that matters.

Both descriptions can be true at once. Identifiable governors can be an advantage for some enterprise buyers and a disadvantage for people who want anyone to be able to validate. The council page is the primary record of the model. A list of famous members is not a measurement of how much those members use the ledger.

Hedera documents first-class accounts and a token service, so issuing a fungible or non-fungible token does not require deploying a bespoke contract for every asset. That is a real product difference from a chain where the token standard lives only in application code. It also concentrates behavior in network services that the council's software releases can change.

A token created on Hedera is still an issuer's instrument. The network can record supply and transfers according to the keys that control the token. It cannot make an off-ledger reserve exist, and it cannot force a marketplace to list the asset. Readers should look up the token's own keys and treasury before treating the Hedera logo as a warranty.

Hashgraph's documentation says throughput is limited mainly by bandwidth and illustrates that claim with card-network scale. That sentence is an argument about the algorithm's overhead, written by the people who designed it. It is not a published audit that Hedera mainnet has cleared a named volume of production payments on a named day.

The honest use of the passage is to understand what the designers believe the consensus layer does not waste. Capacity for an application still depends on fees, topic or contract limits, client software, and the transactions people actually submit. A diagram of maximum gossip is not a usage report.

HBAR is spent on services and can be staked under the network's proof-of-stake rules. That creates a possible link between activity and the token. The link is not automatic demand from every council member's customers. A firm can sit on a council, or even submit transactions, without its shareholders, depositors, or users holding HBAR.

Hedera's fee calculator explains the pricing mechanism: fees are set in US dollars and converted to HBAR at transaction time. A dollar-denominated fee therefore does not require a constant number of HBAR. Assessing the token economy requires service volume, fee schedules, and the HBAR conversion, rather than assuming every new enterprise customer creates the same token demand.

Hedera's openness story has distinct stages. The January 2022 council decision concerned buying hashgraph intellectual property and committing to an Apache 2.0 release. In September 2024, the whole codebase became the Hiero project at LF Decentralized Trust. The latter announcement explicitly separates governance of the source code from operation of the Hedera network, which remained with the council. Contributing to Hiero and becoming a mainnet consensus operator therefore describe different forms of participation.

The 2022 Reddit discussion about open sourcing is more revealing than a generic claim that every HBAR holder welcomes enterprise adoption. Participants asked whether another network could copy the algorithm and whether existing network effects would protect Hedera. The thread records both enthusiasm and competitive anxiety. It does not measure how common either view was across holders, and it cannot establish that a council member intended to launch a competing ledger.

Operational control became tangible during the March 2023 precompile exploit. The official postmortem describes disabling proxies to limit further theft, then coordinating a fix and removal of attacker privileges. This is a case for examining both benefits and costs of intervention: incident containment helped protect users, while the ability to restrict access shows who could act during an emergency. Calling the ledger public does not answer that governance question.

Hedera's current node requirements explicitly describe a permissioned mainnet operated by Council members. The guide sets hardware, network and installation requirements for those operators and states that it does not cover a transition to permissionless consensus. This is a more precise account of present admission than a general statement that anyone can run a node. The word node covers different responsibilities, and publicly accessible software does not by itself authorize a machine to join the consensus set.

For an enterprise builder, a specified operating environment may be attractive because it makes infrastructure expectations concrete. For someone evaluating decentralization, that same admission boundary remains a material constraint rather than a detail erased by the project's future roadmap.

Native HBAR staking is different from a bonded position on many other proof-of-stake networks. The documentation says the balance remains liquid, with no bonding lock or slashing, while contributing to the selected node's consensus weight. Rewards depend on eligibility and the reward account's funding, not a promise of a fixed investment return. The guide also identifies an operational edge case: when a node leaves the address book, accounts staked to it stop accruing rewards and can lose access to unclaimed rewards associated with that node.

A tracked software issue is not proof the behavior has already changed. Native staking should therefore be evaluated on its own mechanics, separately from any application or exchange advertising a yield on HBAR.

The Token Service offers operations that an application would otherwise have to implement in a contract. Its documentation lists separate roles for supply, freezing, KYC, wiping balances, pausing transfers, adjusting fees and updating metadata. These are capabilities that an issuer may configure, not a reason to assume every Hedera token has identical controls. They can support a regulated issuer's workflow while also creating powers a holder needs to understand. An asset's transfer history does not tell the entire custody story if a relevant key can later restrict its use.

Nor does the presence of a KYC feature establish that an issuer has satisfied every legal obligation. The technical role and the legal claim require separate evidence.

Custom token fees are also distinct from the network's transaction fee. The current guide describes fixed, fractional and royalty arrangements, whose recipients and payment assets depend on the token's configuration. The underlying transaction still requires a network fee in HBAR. That distinction prevents an issuer's revenue from being automatically counted as revenue received by all HBAR holders. The royalty documentation also acknowledges an enforcement limit: splitting an exchange across separate transactions can avoid the intended automatic collection.

A feature can simplify a standard transaction path without controlling every economically equivalent action outside it. Creators and marketplace builders therefore need to understand which transfer pattern the fee rules actually cover.

Ty Smith's September explanation describes the Consensus Service as an ordered event log, not a general-purpose database. HCS can establish sequence and timestamps, while an application must interpret those events and reconstruct its own state. Indexers, projections and external storage provide searches and queries that the consensus log does not supply directly. This distinction gives builders a concrete reason to use HCS without attributing capabilities it lacks.

It also limits claims made about recorded real-world events: ordering a submitted statement is different from independently verifying the truth of that statement. The same article records the January 2026 increase in the base message-submission fee, so older cost examples need to be dated rather than treated as permanent pricing.

Hedera's mirror-node tutorial distinguishes short-lived confirmations available from consensus nodes from longer-term history retrieved through mirror infrastructure. It demonstrates both REST queries and subscriptions to topic messages, rather than treating every data request as a fresh consensus transaction. This separation matters to an explorer, a wallet and an accounting system: each needs a way to retrieve and interpret historical results after the initial submission. Choosing a mirror endpoint also introduces an operational dependency on that provider's availability and coverage.

The tutorial permits a community-operated or self-hosted mirror, which creates options for infrastructure independence without changing who participates in consensus. A responsive historical API and a healthy consensus network remain different things to monitor.

The December 2025 block-node announcement reported a private preview deployed during November across the network environments. It was explicit about its limitations: the preview ran alongside the existing record-file system and did not yet provide the completed threshold-signature capability. Its ambitions included streaming access, historical retrieval and later state services. This is useful evidence of staged engineering, not proof that every promised feature was available to every operator at that point.

In particular, a new data-distribution node should not be silently described as an open consensus validator. The preview addressed how network output could be stored and delivered, while the admission rules for producing consensus remained a separate issue.

The current cutover notice distinguishes July's wrapped-record streaming from the full transition scheduled for November 2026. It tells mirror operators to use a compatible release and continue upgrading, while preserving historical record files in the legacy storage location. As reviewed in September, the November transition is still a schedule. The article's earlier publication date does not turn its updated future instructions into a completed event.

For applications using the standard APIs, the main work is assigned to infrastructure operators; for direct record-file consumers, the format change is operationally significant. The migration is therefore best understood as a change in data production and ingestion, with a staged compatibility window and specific verification responsibilities.

The September atomic-batch notice reports a concrete restriction: a batch can contain at most one smart-contract call, placed last. It schedules removal of contract calls from that batch mechanism for March 2027 while preserving native-service batches and standalone contract calls. The stated reason is a mismatch between batch semantics and EVM execution. This is a useful counterexample to assuming that every added capability remains unchanged indefinitely. Developers combining independently signed native operations with contract execution must review the precise composition boundary.

Moving a sequence into one contract and submitting separate transactions are different alternatives, with different atomicity properties; a migration should not hide that distinction from the application relying on it.

The older smart-contract rent article demonstrates another reason to inspect current notices on historical documentation. Its current warning says contract expiry and auto-renewal charges are disabled, while the body retains a proposed storage-rent model and an obsolete rollout schedule. The design rationale still explains a real engineering concern: indefinitely maintaining arbitrary state consumes finite resources. It does not establish that the described recurring charges are currently collected. A builder can study the proposed model while checking the operative configuration separately.

Likewise, an investor should not count a planned rent mechanism as realized protocol revenue. Preserving the date and the corrective warning produces a more useful history than either deleting the proposal or reporting it as fully activated.