Current public docs now cover node rewards, snapshot bootstrap, wallet, faucet, and service boundaries. Read the Node Rewards page

Technical Docs

Technical docs for Chipcoin's live public testnet.

This page summarizes the current public services, the reward-node flow, snapshot bootstrap, and the service boundaries of the live public testnet.

Protocol page

Use the protocol page for the high-level explanation, then come back here for the current live testnet details.

Node Rewards

The Node Rewards page explains the reward-node lifecycle, epoch settlement, and why Chipcoin differs from a miner-only PoW model.

Brief Whitepaper

A concise public paper covering the monetary model, the live testnet stack, and the role of Node Rewards.

Architecture and live stats

Architecture notes and the live testnet page make the current public stack easier to inspect without internal operator context.

What These Docs Cover

The docs page is the technical reference layer for the live public testnet.

It is not a generic whitepaper or a promise page. It should describe the current public services at a high level, how the reward-node loop works, and the boundaries between roles.

Current public scope

  • Reward-node lifecycle, epoch settlement, and payout visibility.
  • Snapshot bootstrap for faster node startup and recovery.
  • Wallet path and browser wallet installation guidance.
  • Testnet faucet access and explorer verification.

How to use this page

  • Read Protocol first if you need project context.
  • Read Node Rewards if you want the core incentive model first.
  • Read Whitepaper if you want the shortest public summary.
  • Read Architecture if you want the component map.
  • Read Live Testnet if you want current public chain signals.
  • Read Wallet if you need the user flow.
  • Read Faucet if you need testing rules and the claim form.
  • Use this page when you want the technical summary of the visible public services.

Current Testnet Stack

The live public testnet already includes more than the web surface.

The public website should reflect the actual running stack: full node, external miner, browser wallet, snapshot bootstrap, explorer access, and the reward-node system.

Full node

The public testnet uses a SQLite-backed full node with P2P, persistent peerbook, headers-first sync, and HTTP API surfaces.

External miner

The miner operates from node-issued block templates over HTTP rather than as an in-process consensus shortcut.

Reward-node automation

Reward-node renewal, attestation, and settlement automation are already operating on the public testnet.

Snapshot bootstrap

Trusted snapshot import is part of the practical startup path for new nodes and operational recovery.

Explorer

The explorer remains a separate public service used for external verification after wallet, faucet, or reward-node activity.

Website and docs

The website is static and should document the live public stack without inventing unsupported claims.

Live testnet stats

The website can also show current public signals such as node count, recent blocks, and recent settled reward epochs via the public API.

Node Rewards

The reward-node system is deterministic, on-chain, and operating on public testnet.

Chipcoin's reward-node system is integer-only, part of programmed emission rather than extra inflation, and visible to consensus through epoch settlement and coinbase payouts.

Lifecycle

  1. Acquire CHC for registration and renewal fees.
  2. Register the reward node on-chain.
  3. Complete the warmup period.
  4. Renew on time every epoch.
  5. Participate in the verifier-attestation system.
  6. Receive settlement at epoch close if qualified.

Important properties

  • Registration is persistent on-chain.
  • Eligibility is not persistent and depends on timely renewal.
  • Offline nodes do not lose registration automatically.
  • Missed epochs are not recovered retroactively.

Epoch Verification and Settlement

Reward-node payouts are finalized through attestation bundles and one epoch settlement.

Each epoch determines the active set, assigns deterministic verification windows, collects signed attestations, aggregates them into bundles, and settles payouts into the closing block coinbase.

Verification windows

Assigned verifiers check nodes in deterministic windows and sign the resulting attestations.

Bundles

Attestations are aggregated into reward attestation bundles that are then carried into mining templates.

Settlement

At epoch close, one reward settlement inserts the final payout outputs into the block coinbase.

Auditability

The result is visible and auditable through CLI and API reward history surfaces.

Shared halving interval

Miner subsidy and node reward budget follow the same shared halving schedule, with one halving every 111,000 blocks.

Mining Difficulty

Difficulty retargeting uses a fixed-window proportional adjustment.

Difficulty does not change on every block. It changes only at the end of each retarget window. Between those boundaries, the bits field remains the same as the previous block.

Current windows

  • Mainnet: one retarget every 1,000 blocks.
  • Testnet: one retarget every 200 blocks.
  • Testnet retarget heights therefore occur at 200, 400, 600, 800, and so on.

Target window time

  • Target block time: 300 seconds.
  • Testnet target window: 300 * 200 = 60000 seconds.
  • Mainnet target window: 300 * 1000 = 300000 seconds.

Actual timespan

actual_timespan_seconds = timestamp_last_block - timestamp_first_block

Target timespan

target_timespan_seconds = target_block_time_seconds * difficulty_adjustment_window

Proportional retarget

next_target = previous_target * actual_timespan / target_timespan

Clamp rule

The measured window is clamped between one quarter and four times the target window before computing the next target.

PoW limit

The final target is capped so it can never become easier than the configured PoW limit.

Snapshot Bootstrap

Bootstrap via trusted snapshots makes the live testnet more practical to operate.

Snapshot import lets a node start from a trusted chainstate anchor and sync only the delta after that anchor, reducing the cost of fresh bootstrap and recovery.

Operational use

Useful for new nodes, follower nodes, VPS test deployments, and operational recovery after interruption.

Public path

Snapshot bootstrap is already part of the current startup story and is exposed through the public snapshot manifest path.

Practical impact

It makes the current testnet materially easier to join than full replay from genesis on every fresh machine.

Wallet and Faucet Operations

The practical user path is wallet first, faucet second, explorer third.

Users should first prepare a valid wallet address, then request testnet funds, then verify the result in the explorer or directly in the wallet.

Recommended order

  1. Open the wallet overview page.
  2. Install the browser wallet if needed.
  3. Create or import a wallet and copy a CHC address.
  4. Use the faucet for testnet testing.
  5. Check the result in the explorer.

Related Pages

Use the public pages according to their real current role.

Protocol explains the project, Node Rewards explains the main novelty, Whitepaper gives the short paper, Architecture explains the component map, Live Testnet exposes current public signals, Wallet explains the user path, Browser Wallet handles installation, Faucet handles testnet funding, and this page stays focused on the technical reference layer.