Abstract
NHBCoin is a live Layer 1 blockchain built around a two-token model: NHB, a settlement and fee currency the protocol treats as fixed at $1.00 rather than letting it float on a market, and ZNHB, a fixed-supply asset — 1,000,000,000 units, minted once at genesis and never again — behind staking, governance, and treasury economics. The network reaches finality through a round-based Byzantine fault-tolerant consensus among a small, currently growing set of staked validators, whose voting power combines bonded ZNHB with a real-time engagement score (POTSO) rather than stake alone. Native, consensus-level modules handle point-of-sale payments, escrow, ZNHB-collateralized lending, and a governed pipeline for minting NHB against custodied stablecoin deposits and redeeming it back out. This document describes what is actually implemented and running today, and says so plainly where something is instead still in development.
Protocol Pillars
NHBCoin's design rests on a small set of commitments that show up consistently across its consensus layer, its token model, and its native modules, rather than on a single headline feature.
These commitments guide how the protocol is extended: a new module is expected to fit the same pattern as the ones already live, not introduce a parallel, less-scrutinized way of moving value.
- A settlement currency (NHB) with a protocol-fixed $1.00 unit value, rather than a token whose price the network has to defend.
- A fixed-supply asset (ZNHB) that carries staking, governance, and treasury functions separately from day-to-day payments, with no protocol path to mint more of it after genesis.
- Commerce primitives — point-of-sale payments, escrow, lending, a peer-to-peer market — implemented as native, consensus-level transaction types rather than smart contracts layered on top.
- Three deliberately separate prices for ZNHB (a treasury sale curve, a signed reference price, and peer-to-peer market trades) so that treasury inventory pricing can never be mistaken for, or manipulated into, a market price.
Consensus & Validator Incentives
NHBCoin's consensus engine is a round-based Byzantine fault-tolerant protocol: a proposer is selected each round, validators broadcast prevotes and then precommits, and a block commits once precommits representing more than two-thirds of total voting power have been collected. Every committed block carries a quorum certificate — the aggregated precommit signatures that reached that two-thirds threshold — which any peer can independently verify against the historical validator set.
Voting power is not stake alone. A validator's weight in proposer selection and rewards combines its bonded ZNHB with a continuously updated engagement score, so uptime and participation matter, not just capital at stake. As of this writing the network runs with a small validator set consistent with its early stage; additional validators join through the same on-chain process described below, not through a hand-edited configuration.
Engagement Weighting (POTSO)
POTSO — Proof of Time Spent Online — is the engagement engine behind that weighting. It tracks heartbeat submissions, uptime, and abuse signals per validator, and the resulting score is combined with bonded stake when the protocol computes proposer-selection odds and reward shares, so an operator earns more by staying online and participating, not simply by holding more ZNHB.
Validator Lifecycle
A validator candidate registers on-chain, bonds ZNHB as stake, and must submit regular heartbeat transactions to remain eligible. Voting power is derived from a validator's own bonded stake, not stake delegated to it, and validator and staking rewards are paid from a dedicated Reward Pool on a fixed halving emission schedule — 200 ZNHB per epoch initially, halving roughly every four years — rather than through open-ended inflation.
Token Model: NHB & ZNHB
NHB and ZNHB serve deliberately different, non-overlapping purposes: NHB is the operational currency used for payments and network fees, and ZNHB is the fixed-supply asset behind staking, governance weight, and the network's own treasury economics. The protocol keeps their pricing mechanisms structurally separate rather than letting one stand in for the other.
NHB: The Settlement & Fee Currency
NHB has no fixed supply cap. It is minted on deposit and burned on redemption: a user acquires NHB by depositing a supported cryptocurrency through the network's swap-in pipeline, which settles into custodied USDT or USDC balances, and the network mints the equivalent NHB 1:1 once that settlement confirms.
The protocol treats NHB as fixed at $1.00 rather than as a floating, market-discovered price. NHB has no public exchange listing and no external price oracle prices it — its dollar value is a protocol design constant, matching the fact that every NHB in circulation corresponds to custodied stablecoin value rather than to speculative demand.
NHB can be redeemed back out: a holder burns NHB on-chain, and an authorized attestor confirms the resulting off-chain USDT (ERC-20 or TRC-20) or USDC payout once it settles, closing the loop under a governance-adjustable risk cap that bounds redemption volume independently of the mint side.
ZNHB: The Fixed-Supply Network Asset
ZNHB's genesis supply is fixed at 1,000,000,000 units, split once at genesis into two pools that never mix: an 800,000,000-unit Sale Pool sold to buyers over time, and a 200,000,000-unit Reward Pool that funds validator and staking rewards on a halving schedule. The schedule pays 200 ZNHB per epoch (each epoch spanning 100 blocks) for the first 500,000 epochs, then halves every 500,000-epoch era after that — roughly four years per era at the network's target block time, longer if real block production runs slower — so the cumulative payout converges toward the Reward Pool's 200,000,000-unit ceiling without ever reaching or exceeding it. ZNHB cannot be minted after genesis, by anyone, for any reason — a hard protocol invariant, not an operational policy.
The Sale Pool is priced by a bonding curve, not a flat rate: 16,000 tranches of 50,000 ZNHB each, priced from $0.05 at the first tranche toward $1.00 asymptotically at the last, computed in exact rational arithmetic so a purchase's cost depends only on how much of the pool has already sold, never on how that purchase is split across transactions. This curve describes only what the treasury itself charges for its own remaining inventory — the protocol never uses it, and this document never claims it, as ZNHB's market price.
ZNHB's actual reference price — the figure used to value ZNHB posted as loan collateral, and to cap what the treasury's buyback engine will pay when repurchasing ZNHB from willing sellers — comes from a separate, independent mechanism: a permanently non-governable quorum of signers submits a signed price once per epoch. A share of NHB transaction-fee revenue automatically funds that buyback engine; whatever ZNHB it repurchases is recycled back into the Sale Pool, never burned and never re-minted.
A third figure exists alongside the sale curve and the reference price: the price ZNHB actually trades at, peer-to-peer, on the network's own marketplace, where holders list and fill ZNHB-for-NHB trades directly against each other subject to a flat, governance-adjustable listing fee. That marketplace, not the treasury curve, is where ZNHB's market price is genuinely discovered once it leaves the treasury.
- Validator Bonding: validators stake ZNHB as bonded collateral that anchors their voting power and can be slashed for provable misbehavior.
- Loan Collateral: borrowers post ZNHB as collateral for NHB loans, valued against the signed reference price above, never the treasury sale curve.
- Governance Weight: ZNHB holders vote on protocol governance proposals, which are quorum-gated and timelocked before taking effect.
- Paymaster Funding: merchants pre-fund ZNHB paymaster pools that reimburse customer network fees and fund loyalty-program rewards, subject to on-chain reserve and issuance caps.
Identity & Claimable Payments
NHBCoin includes an on-chain alias registry: any address can claim a short, human-readable username and have it resolve to that address for payments, replacing long hex or bech32 strings with something a counterparty can actually remember and verify.
The chain also supports claimable transfers: a payer can lock funds under a hash-lock and a deadline, addressed to a recipient who does not yet need a wallet or private key at send time. The recipient claims the funds by revealing the pre-image before the deadline, or the payer recovers them automatically once it passes — the primitive behind, for example, paying someone by phone number or email before they have onboarded to the network.
Both mechanisms are native transaction types rather than off-chain conveniences: alias resolution and claim settlement happen on-chain, so a wallet or a merchant integration can verify an alias or a pending claim directly against chain state rather than trusting a centralized lookup service.
Native Escrow
NHBCoin's escrow module locks NHB on-chain between two parties until agreed conditions are met, then releases it — without a third-party smart-contract platform or an off-chain custodian holding the funds in between.
Each escrow can be configured with an arbitration policy: a single designated arbitrator, or a committee that resolves disputes once a configurable signature threshold is met. A disputed escrow is resolved through that configured path rather than defaulting automatically to either party.
Because escrow is a native transaction type rather than a bolted-on contract, every open, released, or disputed escrow is directly queryable from chain state — useful for marketplaces, freelance platforms, and merchant tooling built on top of NHBCoin.
Point-of-Sale Payments
NHBCoin implements point-of-sale payments as a native, three-step on-chain lifecycle — authorize, capture, and void — the same shape a card network uses, settled directly in NHB rather than through a separate card-rail intermediary.
A merchant's terminal or app authorizes a payment against a customer's wallet, captures it once the sale is confirmed, or voids it if the sale falls through. Because authorization, capture, and void are each independent, authenticated on-chain transactions, a merchant integration can query a payment's real state directly from the chain rather than trusting a webhook or a database row that could drift from what actually settled.
An optional merchant fee — a fixed basis-point rate on the transaction, separate from the network's ordinary transfer fee — can be configured per merchant address, giving payment processors a predictable, on-chain-enforced revenue model instead of a privately negotiated off-chain one.
Loyalty & Paymaster
Businesses can run on-chain loyalty programs that reward customers in ZNHB for spending NHB, with per-transaction, per-user-daily, program-daily, epoch, and lifetime-per-user issuance caps enforced directly by the protocol rather than by an off-chain script that could silently misbehave.
Loyalty rewards are funded from a paymaster pool that a business pre-funds in ZNHB. The same paymaster mechanism can reimburse a customer's network fee on a qualifying transaction, so a checkout can feel fee-free to the end user even though the fee is still genuinely paid — by the merchant's paymaster balance, not the customer's wallet.
Reserve enforcement is non-fatal by design: if a paymaster pool is running low, the engine throttles or skips the reward rather than failing the underlying payment, and emits an on-chain warning once the pool's headroom drops within a configurable margin of its reserve minimum, so a business can top up before rewards actually stop.
Collateralized Lending
NHBCoin's lending module lets a borrower post ZNHB as collateral and draw NHB against it from an on-chain liquidity pool funded by NHB suppliers, who earn interest accrued through a supply/borrow index rather than a fixed rate.
Collateral is valued against the same independently signed reference price described in the token model above — never against the treasury's own sale curve, which would let a buyer inflate the price they borrow against simply by buying more of their own collateral asset. Loans are subject to a governance-set maximum loan-to-value ratio and a staleness and deviation guard on the reference price: if no sufficiently fresh, sufficiently consistent price has been submitted for a market, new borrowing, under-collateralized withdrawals, and liquidations against that market are blocked outright rather than falling back to a guessed value.
A share of accrued interest can be routed to a developer or pool-operator fee, and risk parameters — loan-to-value caps, oracle staleness and deviation bounds — are adjustable through the same on-chain governance process used elsewhere in the protocol, not hardcoded per deployment.
Settlement & Redemption
Getting value into NHBCoin and back out both run through a regulated payments processor as the custodial rail, rather than NHBCoin operating its own multi-chain custody. On the way in, a user deposits a supported cryptocurrency; once it settles into custodied USDT or USDC, the network mints the equivalent NHB 1:1 to the user.
On the way out, a user burns NHB on-chain; an authorized attestor address confirms the resulting off-chain USDT (ERC-20 or TRC-20) or USDC payout once it settles, and reports that outcome back on-chain so the burn and the payout stay reconciled. The redemption path runs under its own governance-adjustable risk cap, tracked separately from the mint-side risk engine so mint and redeem activity for the same address are never measured against a shared counter, and can be paused independently without blocking payouts already in flight.
ZNHB moves through a different pipeline entirely: sales out of the Sale Pool follow the bonding curve described in the token model, and the treasury's buyback engine can repurchase ZNHB from willing sellers once per epoch, at a price capped by the lesser of a discounted curve price and a margined signed reference price, recycling whatever it buys back into the Sale Pool rather than burning or re-minting it.
Governance
ZNHB holders propose and vote on protocol parameters directly on-chain, across proposal kinds spanning fee-rate changes, slashing policy, price-signer registration, lending risk parameters, and treasury buyback parameters, among others. Voting power is the same engagement-adjusted weighting used for consensus, so passive stake alone does not dominate a vote.
Every proposal kind goes through the same quorum-and-timelock gate: a proposal needs enough participating voting power to be valid, needs to clear its approval threshold, and — even once it passes — sits behind a timelock before it actually takes effect. A parameter change is never instantaneous.
Governance's reach is deliberately bounded. ZNHB's genesis supply split, the Sale Pool curve's own parameters, and the validator/staking halving schedule are fixed at genesis and are not reachable by any proposal kind that exists today, so a fixed-supply asset's core guarantees cannot be voted away by whoever shows up to a given proposal.
Security & Operations
NHBCoin runs a public bug bounty program covering the core node implementation, official SDKs, and reference wallets. Rewards are tiered by severity, from informational hardening reports up to critical findings such as remote code execution or a consensus failure.
Reports are acknowledged and triaged on a fixed schedule, and reporters are asked to observe a coordinated-disclosure embargo before going public, so a fix can ship before the details behind it do.
Bug Bounty at a Glance
- Critical (remote code execution, consensus failure): $10,000–$25,000
- High (privilege escalation, theft of locked funds): $4,000–$10,000
- Medium and low (double-spend vectors, denial-of-service, information disclosure): $250–$4,000
- Acknowledged within 24 hours, triaged within 5 business days, reported to [email protected]
Roadmap
The items below are planned or in-progress work — not yet part of the live network described above. They are listed for transparency about direction, not as commitments to a specific date.
- Validator set growth: onboarding additional validators beyond the network's current launch-stage set through the standard stake-and-heartbeat process, broadening decentralization over time.
- Fixed-term, locked-rate NHB borrowing alongside the existing variable-rate lending pools, for borrowers who want a fixed period and rate instead of one that moves with pool utilization.
- A dedicated security review of wallet key-recovery flows, an area flagged internally as needing hardening beyond its current design.
- Expanded self-service governance tooling for parameters that are already adjustable on-chain today but still require direct proposal submission rather than a purpose-built admin interface.
Conclusion
NHBCoin combines a protocol-pegged payments currency, a fixed-supply governance and security asset, and a set of native commerce modules — escrow, point-of-sale payments, lending, a peer-to-peer market, and a governed fiat on/off-ramp — into a single Layer 1 network. Every mechanism described above as live is running in production today; where a capability is still in development, this document says so directly rather than presenting it as already shipped.