Hashora Roadmap

Establish the project direction, investigate SHA-256 proof of work and difficulty adjustment options, and prepare a buildable development environment.

• Hashora’s initial design direction: SHA-256d proof of work and a 10-minute target block interval.
• ASERT reference implementation compiled, with its calculation, difficulty and activation-anchor tests passing.
• Dedicated hashora-dev worktree created from the Bitcoin Core v32.0 source tag.
• Upstream baseline compiled with wallet support and test executable enabled.

Completed evidence: successful build output and ASERT reference test results. These verify the reference code and build, not a working Hashora blockchain.

Turn the initial concept into precise, testable rules that every Hashora node must enforce identically.

• Define network identifiers, message magic, ports and address prefixes.
• Specify the genesis block and verify its hash and proof-of-work parameters.
• Calculate exact subsidy issuance and total supply using integer arithmetic and rounding rules.
• Integrate SHA-256d and ASERT, including anchor selection, timestamp constraints, target limits and activation behaviour.
• Add Hashora-specific unit tests and consensus edge-case tests.

The initial 50 HORA reward, 210,000-block halving interval, eight decimal places and two-day ASERT half-life remain proposed parameters until adopted in the specification and tests.

Run a private test network to prove that the configured chain starts, produces valid blocks and follows its own consensus rules.

• Start a node using Hashora’s genesis configuration.
• Mine and validate test blocks locally.
• Check subsidy, halving boundaries, block acceptance and rejection of invalid blocks.
• Restart nodes and verify chainstate and database recovery.
• Test competing chains, reorganisations and peer connectivity.

Test coins have no promised monetary value and will be kept separate from any future mainnet assets.

Validate the user-facing path, from creating keys to sending a transaction that independent nodes agree is valid.

• Generate wallets and addresses and safely back up keys.
• Send transactions between test wallets and verify balances and confirmations.
• Test transaction fees, mempool policy, double-spend rejection and restart recovery.
• Document wallet security, node RPC access and safe operating practices.

Investigate compatible mining workflows and test how the network behaves as hash rate changes.

• Evaluate SHA-256d miner compatibility and the required mining interfaces.
• Test CPU and suitable SHA-256 devices where practical.
• Assess solo-mining and pool compatibility without implying profitability.
• Test low-hash-rate conditions, miner arrival and departure, and ASERT response.
• Publish clear setup instructions and known limitations.

Small devices can participate, but their chance of finding a block depends on total network hash rate, difficulty and luck. No earnings are guaranteed.

Open a separate public test network only after the private network and basic wallet flows work reliably.

• Publish testnet binaries, source, instructions and known issues.
• Invite node operators, developers and miners to test independently.
• Collect reproducible bug reports and resolve consensus disagreements.
• Test backups, monitoring, abuse controls and operational recovery.

A mainnet launch is a separate decision, not an automatic result of a successful testnet.

• Arrange independent review of consensus code and economic rules.
• Complete security testing, release reproducibility and dependency review.
• Document threat assumptions, centralisation risks and incident response.
• Confirm legal, operational, infrastructure and community readiness.
• Publish final parameters and launch procedures before any mainnet launch decision.