Skip to main content

System specifications

Introduction​

This article is the reference specification of Hathor system. It is intended to be consulted by anyone getting to know the technology, or already implementing and using it in their business and systems.

Overview​

Hathor is an affordable, scalable and easy-to-use general-purpose layer-one blockchain platform that addresses the problem of scalability without weakening security and decentralization, by embedding a chain of mined blocks within a DAG of transactions.

Network​

  • Name: Hathor Network
  • Official instances: mainnet and testnet
  • Mainnet release date: January 3, 2020
  • Throughput in transactions per second (TPS): protocol does not impose a theoretical throughput limit.

Protocol​

White paper:

Hathor: An alternative towards a scalable cryptocurrency, Brogliato, 2019

Consensus​

  • Consensus algorithm: proof of work
  • Consensus mechanism: Nakamoto consensus1 , i.e., PoW + best blockchain (most accumulated work) — same as Bitcoin.
  • Average time between blocks: 30 s
  • Average difficulty adjustment interval: 134 blocks

Ledger (blockchain)​

  • Data structure: directed acyclic graph (DAG) + chain of blocks (blockchain). Transactions are not placed inside blocks; Instead, each transaction and each block is a vertex of the DAG. Each transaction points to 2 previous ones, and each block points to 2 transactions and the previous block, forming the chain of blocks. DAG + blockchain ensures the combination of scalability with strong security.
  • State model2: ledger bookkeeping follows a hybrid model:
    • For wallet balances: UTXO
    • For contract states: account-based with global state
  • Identifiers: the following entities are identified by 32-byte UUIDs:
    • Vertices (transactions and blocks)
    • Tokens
    • Blueprints
    • Contracts

Transactions​

  • Finality3: probabilistic — same as Bitcoin
  • Average confirmation time for a transaction: for low-value transfers, 1 block confirmation is typically sufficient. For higher values, users should define how many blocks to wait. After 6 blocks, blockchain reorganizations become virtually impossible.
  • Supported script standards:
    • P2PKH
    • P2SH (for multi-signature)
    • DataScript (to store a data point in an output)
  • Scripts source code: python-hathorlib/hathorlib/scripts.py
  • Serialization: differently than Bitcoin. To serialize and deserialize transactions, you can use one of Hathor's parsers: in Python in Python Hathor lib, or in Node.JS in Hathor wallet lib.

For more on this, see Anatomy of a transaction.

Wallets​

  • Digital signatures: ECDSA with curve secp256k1 — same as Bitcoin
  • Addresses: 25 bytes encoded in Base58check
  • Address generation algorithm: RIPEMD160(SHA256)
  • Addresses are formed by [version][pubkey_hash][checksum] — same as Bitcoin, only changing the version byte:
    • pubkey_hash = ripemd160(sha256(compressed_pubkey))
    • checksum = sha256(sha256(pubkey_hash))[:4]
  • Network + script address prefixes:
NetworkScriptAddress prefix
MainnetP2PKHH
MainnetP2SHh
TestnetP2PKHW
TestnetP2SHw

Mining​

Every vertex (blocks and transactions) must be mined to be validated by the full node and added to the ledger.

  • Mining algorithm: SHA-256d — same as Bitcoin
  • Transaction mining: used as an anti-spam mechanism, allowing zero transaction fees. It requires a small PoW and provides no economic incentive.
  • Block mining: economically incentivized via "coinbase transaction"4. Blocks are mined through merged-mining with the Bitcoin Network — that is, mining pools can use the same computational power to secure both networks simultaneously. This increases miner profitability, provides Hathor with a high level of security, and optimizes the use of cryptocurrency mining resources.

Tokenomics​

HTR is the native utility token used to consume services on Hathor Network.

  • Base unit: 2 decimals; i.e., the smallest fraction of HTR is 0.01. All custom fungible tokens follow this same standard.

  • Supply:

    • Pre-mine: genesis block defined an initial supply of 1B HTR in a wallet controlled by Hathor Labs, to be progressively released into circulation with the goal of bootstrapping initial technology development and fostering the ecosystem. For the release schedule, see Token economics report.
    • Mining rewards: 8 HTR per mined block (at the moment), without further halvings.

  • Demand: HTR is required for paying fees for the following network services:

    • Token creation and minting
    • On-chain data storage
    • Contract creation and execution

  • Fees:

Network serviceFeeFunds destination
Fund transferZero (no fee); i.e., there is no transaction cost to move any tokens between wallets and contracts-
On-chain data storage0.01 HTR per data output; each data output accepts a data point of up to ≈ 30–31 KiBBurned
Fungible token creation and minting0.01 HTR per minted unitHTR is redeemable if tokens are melted 5
NFT creation and minting0.01 HTR per minted unitHTR is redeemable if tokens are melted 5
Contract creation and executionGas fee table to be defined in the future70% burned, 30% for blueprint developers

For more on contract's fees destination see Nano contracts economics.

Programmability​

It supports smart contracts (AKA nano contracts):

  • Turing completeness: yes
  • Execution machine: native (AKA Hathor engine)
  • Programming language: Python 3
  • Floating point: not supported

System components​

Considering only the codebase developed and supported by Hathor Labs, Hathor system comprises the following components:

  • Hathor core (full node)
  • Wallets
  • Transaction mining service (proxy miner)
  • Explorer

The following subsections describe each of these components.

Hathor core (full node)​

Hathor core is the official and reference:

  • implementation of Hathor protocol; and
  • client for operating a full node in the network.

As with Bitcoin core, Hathor core is the reference specification of the protocol. When running Hathor core, the computer becomes a full node in the network.

Hathor core does not include a built-in wallet or miner. Wallets and miners are separate components that connect to a full node via HTTP and WebSocket APIs, and must trust it.

For more on it, see Core (full node) pathway

Wallets​

Hathor codebase provides the Hathor wallet library, a JavaScript library for implementing Hathor wallets. It serves as the foundation for the three official wallet applications:

  • Desktop
  • Mobile
  • Headless
info

All three official wallet applications (desktop, mobile, and desktop) are thin clients, just like Metamask, Exodus, and TrustWallet. That is, they need to connect to and trust a full node to obtain the state of the blockchain.

The library can also be used to implement Hathor wallets in external systems and to add support for Hathor in multi-chain wallet applications.

  • Keys generation: hierarchical deterministic wallets (HDW), following BIP-39 and BIP-44 standards.
  • Balance calculation: default gap limit value of 20 addresses; configurable in headless.
  • Hardware wallets support: Ledger Nano S/X (June 17, 2025).

Lastly, there is also the Wallet service, the official backend for all wallet applications. It is not essential for wallet operation but significantly improves the user experience. It indexes the ledger (blockchain), which speeds up initialization and balance loading. It does not store user keys and cannot sign transactions. Transactions are still created and signed on the user’s device, but the wallet application must trust the balances view provided by the service (it would already need to trust the full node anyway).

Transaction mining service (proxy miner)​

Transaction mining service is a proxy miner that intermediates the connection between full node, wallet application, and miners. As the name suggests, its main function is to provide a transaction mining service for wallet applications. Additionally, it can also be used for block mining in localnets (development environment) and side chains.

Explorer​

Hathor system has an official explorer composed of two main components:

  • A client-side web application
  • A backend service that exposes an HTTP API

Currently, Hathor Labs provides the explorer for both network instances (testnet and mainnet).

Footnotes​

  1. Bashir, Imran, Mastering Blockchain: Distributed ledger technology, decentralization, and smart contracts explained. 2nd Edition, Packt Publishing, 2018, p. 144. ↩

  2. F. E. Alzhrani, K. A. Saeedi, and L. Zhao, A Taxonomy for Characterizing Blockchain Systems, IEEE Access, vol. 10, pp. 110568–110589, 2022, doi: 10.1109/access.2022.3214837, p. 110573. ↩

  3. Bashir, Imran, Mastering Blockchain: Distributed ledger technology, decentralization, and smart contracts explained. 2nd Edition, Packt Publishing, 2018, p. 155. ↩

  4. Bashir, Imran, Mastering Blockchain: Distributed ledger technology, decentralization, and smart contracts explained. 2nd Edition, Packt Publishing, 2018, p. 164. ↩

  5. Regarding token melt: it is necessary to have melt authority over a token to perform a melt operation. For each 1.0 custom token melted, 0.01 HTR is redeemed. Attempting to redeem fractions of a custom token (e.g., 0.8) results in an implicit burn. ↩ ↩2