BHCT Whitepaper · Contents6/19
- Version
- v1.8
- Issued
- November 5, 2026
- Issuer
- NVEX Foundation
- Download PDF · 676KB
Chapter 06
Tokenomics
This chapter describes the current on-chain state and a proposed allocation. Current values are exactly as read from the chain; the proposed allocation will be disclosed and this chapter replaced in a new version once the foundation confirms it. How supply is distributed, used and recovered is described in Token economy.
Supply
| Item | Details |
|---|---|
| Initial supply | 1,000,000,000 BHCT (minted once to the treasury wallet at issuance) |
| Further minting | None. The contract has no mint function. |
| Burning | Holders can burn their own tokens; total supply falls by the amount burned. |
| Admin recovery | Mints nothing; it only moves tokens to the fixed treasury wallet. |
Current allocation
| Treasury wallet (unallocated) | 100% | As of November 5, 2026, the entire supply is in the treasury wallet, and the allocation plan in the whitepaper is a proposal that has not been confirmed. Any tokens leaving the treasury appear in circ |
Allocation plan (proposed)
Allocation categories and shares, and lockup/vesting schedules, have not been confirmed. Below is a proposal aligned with the token economy design; once the foundation confirms it, it will be reflected together with a disclosure. The shares used in the ecosystem (contribution rewards, services, market expansion) are set at 65%, so most of the supply flows to contribution rewards and ecosystem use.
| Pool | Proposed share | Amount (BHCT) | Purpose | Spending · lock (proposed) |
|---|---|---|---|---|
| Ecosystem contribution rewards | 40% | 400,000,000 | Reviewed creator and community rewards; designated bonuses count when actually paid to creators | Quarterly budgets and annual total reward payout cap (10% of reference balance), without resetting it for returns |
| Ecosystem services · partners | 15% | 150,000,000 | Specified contribution rewards under public programs, not a substitute for cash supply costs | Record the source on transfer to rewards; same-nature rewards count toward the common annual total reward payout cap |
| Market expansion | 10% | 100,000,000 |
Lockup · vesting
No lockup or vesting is currently set on-chain. Nothing has been allocated, so there is no release schedule.
The proposal locks the team/contributor share for 12 months and then releases it monthly over 36 months, and locks the foundation reserve for 12 months. The contract's balance lock is an admin function that blocks transfers until a set time, so each release tranche would be locked with its amount and time and disclosed. The nature and risks of this permission are described as they are in Contract and permissions. The proposed reward pool is unlocked, with spending governed by the annual total reward payout cap, quarterly budgets and all-pool outflow plans. This proposal is separate from the current absence of on-chain locks.
Circulating supply
Circulating supply = current on-chain total supply − balances of disclosed wallets
The only disclosed wallet today is the treasury wallet. This website reads both values from BNB Smart Chain every few minutes and serves the same values through the supply API.
Reward payout principles
- Rewards are sent directly from the treasury wallet to the wallet a member linked to their account.
- Every payout records its transaction hash and is marked complete only after the on-chain transfer (sender, recipient, amount) is verified.
- Payouts are disclosed every month.
Proposed token flow and reallocation
The flow is approved quarterly reward budget → reviewed payout → voluntary creator order → direct NVEX ecosystem receipt → confirmed delivery and refund/dispute closure → eligible base-model reallocation. Direct-receipt exceptions count only contractual returns actually received.
| Step | Proposed handling | Verification records |
|---|---|---|
| Budget approval | Check service-specific capacity and secured cash within the annual total reward payout cap covering same-nature rewards from every pool | Approver, budget, period, recipients, remaining cap and availability by service |
| Review · payout | Confirm contribution reward conditions separately from contractual compensation | Campaign, review, recipient account and wallet, amount and transaction hash |
| Voluntary use | Creator selects a catalog service or decides not to spend | Agreed order, price, capacity and deadline |
| Service receipt | Receive order payments at the ecosystem receiving wallet published in the catalog; providers receive the cash price of secured slots | Order-level receipt, delivery, cancellation and refund status |
| Confirmation |
Separate cash flow and service costs
These are proposed fund flows once agreements and funding are secured, not a statement of confirmed brand revenue or cash support today.
| Cash flow | Proposed purpose and separation |
|---|---|
| Actual brand payments → contractual payouts and business costs | Contractual creator compensation, production and operating costs, and any service budget agreed by contract; settled separately from additional BHCT rewards |
| Separately agreed foundation · operator · sponsor budgets → service supply | Cash costs of available services, provider payments and cost reserves |
| Agreed cost budget → gas · refund handling | Agree in advance who funds and handles network costs for payouts, returns and refunds |
Returning service tokens to the foundation does not create cash for staff, facilities, editing or localization. Token receipts and reallocation would not be presented as new market demand or cash revenue. Additional rewards would not be expanded before service costs, refund budgets and capacity are secured.
Decisions required for allocation and payout caps
These are the items to settle before confirming the proposed allocation above and starting the first distribution. It does not change current allocation or lockup facts; approved quantities and schedules would be reflected after separate decisions and disclosure.
| Decision | Items to set before starting |
|---|---|
| Reward budget · period | Total approved limit from existing treasury, spending period, approvers and unused-budget treatment |
| Campaign · recipient caps | Campaign limit, eligibility and amount rules, and duplicate-payout prevention |
| Service capacity | Fixed catalog BHCT amounts, secured slots, supply costs and existing booking obligations |
| Cash · refund funding | Funding commitments and receipt verification, costs, gas, refunds and dispute reserves |
| Wallets · reconciliation | Treasury, reward pool, ecosystem receiving and refund wallets and responsible parties, disclosure scope and monthly approval |
| Allocation · release policy | Confirm the proposed shares and lock periods, separate pool wallets and register them as disclosed wallets; the current absence of locks remains until confirmed |
Approve new payouts only within the smallest permitted range of remaining total and common annual total reward payout allowance, campaign/personal limits, service-specific demand and supply, and secured cash. First account for accepted bookings, anticipated use of previous unused rewards and refund reserves; other services' slots cannot substitute. Verify prices and costs by service without treating token appreciation as funding.
This whitepaper is for information only and is not investment advice. Plans and figures may change; material changes are posted on the disclosure board. Read the full risk notice · Disclosure board