Technology

Components

Reading chain values

The website reads total supply, disclosed wallet balances, and each address's balance, locked amount and frozen status directly from public BNB Smart Chain nodes. Values are refreshed every few minutes and shown with the time they were read. Transaction history links to the block explorer (BscScan).

How wallet linking works

Linking a wallet to an account means signing a message in the EIP-4361 (Sign-In with Ethereum) format.

• The message contains the site address, the account, the wallet address, the chain ID, a one-time value (nonce), and issue and expiry times (10 minutes).
• The server checks that the signature belongs to that wallet. Smart-contract wallets are verified with ERC-1271.
• One wallet can be linked to only one account, and a used message cannot be reused.

Reward payouts and verification

The following is the payout-tool workflow available on the NVEX website. Actual campaign rewards require the operator's reviewed results and previously announced payout conditions; the exchange and approval process will be set by partnership contracts and policies.

1. An NVEX administrator registers a reward confirmed for payout (member, amount, reason).
2. An authorized administrator signs the BHCT transfer from the treasury in their own wallet.
3. The website records the transaction hash and, once it is in a block, checks that the receipt's transfer record (sender, recipient, amount) matches what was registered.
4. A match is marked paid; a mismatch or failure is recorded as failed. Payouts are disclosed.

Proposed exchange of campaign results

The design maintains a boundary between reviewing source campaign evidence and verifying token payouts.

Exchange permissions, change and correction history, duplicate prevention and retention scope are items to agree with the operator. Personal and commercial source data would be handled within the scope needed for the work; public disclosures would distinguish information approved for payout and transaction reporting. This does not describe a currently operating automatic review or settlement integration.

Proposed service orders would also record order identifiers, catalog versions, fixed amounts, providers, receiving wallets, delivery, refunds and returns for reconciliation. The current token contract is not described as implementing order-specific escrow, automatic service settlement or automatic reward reallocation for this business. Managed-token transfers are separate from business ledgers and approval work.

Supply API

/api/supply (JSON), /api/supply/total and /api/supply/circulating (number only) are open to everyone. Values are read from the chain and cached for one minute. Responses include the calculation method, the excluded disclosed wallets and the time read.

Security principles

• The website's server holds no private keys and never asks users to send tokens or approve spending.
• The admin area is limited to admin accounts, and repeated failed logins are blocked.
• A published whitepaper version cannot be edited in the admin area, and published disclosures are protected against edits and deletion in the database. Changes are made through new versions or correction disclosures.