[ANN] PICOIN (PI) | Proof of Pi (Pow) | BBP-Hex Algor | MAINNET LAUNCH June 1st

[johannFac]

PICOIN mainnet has been updated with competitive mining and block reward maturity.


Mining now works in competitive rounds: multiple miners can receive work for the same round, the first valid result that reaches validator quorum wins the block, and the other tasks from that round are marked stale. Miner block rewards now mature after 2 blocks, so the newest rewards may appear as immature before they are credited as mature balance. This is expected behavior and helps protect accounting during replay/sync events. Validators should update to the latest code before continuing validation.
Linux node/validator update:

sudo systemctl stop picoin-validator picoin-reconciler picoin-miner picoin-auditor 2>/dev/null || true

sudo mkdir -p /opt/picoin/src

if [ ! -d /opt/picoin/src/PICOIN/.git ]; then
  sudo git clone https://github.com/devcoffeecoin/PICOIN.git /opt/picoin/src/PICOIN
fi

cd /opt/picoin/src/PICOIN
git fetch origin
git switch main
git pull --ff-only origin main



Refresh runtime:

SOURCE_DIR=/opt/picoin/src/PICOIN/picoin-proof-of-pi

sudo env \
  PICOIN_SOURCE_DIR="$SOURCE_DIR" \
  PICOIN_REPO_DIR=/opt/picoin/picoin-proof-of-pi \
  PICOIN_DATA_DIR=/var/lib/picoin/data \
  bash "$SOURCE_DIR/deploy/scripts/refresh-code.sh"

Set mainnet competitive settings:

sudo sed -i '/^PICOIN_MINING_TASK_MODE=/d;/^PICOIN_BLOCK_MATURITY_DEPTH=/d;/^PICOIN_MINER_TASK_HEARTBEAT_MIN_INTERVAL_SECONDS=/d' /etc/picoin/picoin.env

echo 'PICOIN_MINING_TASK_MODE=competitive_round' | sudo tee -a /etc/picoin/picoin.env
echo 'PICOIN_BLOCK_MATURITY_DEPTH=2' | sudo tee -a /etc/picoin/picoin.env
echo 'PICOIN_MINER_TASK_HEARTBEAT_MIN_INTERVAL_SECONDS=60' | sudo tee -a /etc/picoin/picoin.env

Restart node:

sudo systemctl restart picoin-node
sleep 15

Check protocol:

cd /opt/picoin/picoin-proof-of-pi

curl -s http://127.0.0.1:8000/protocol | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["network_id"], d["chain_id"], d.get("mining_task_mode"), d.get("block_maturity_depth"))'

Expected:
picoin-mainnet-v1 314159 competitive_round 2

cd /opt/picoin/picoin-proof-of-pi

sudo systemctl stop picoin-validator picoin-reconciler picoin-miner picoin-auditor 2>/dev/null || true

HEAD_HEIGHT=$(curl -sS https://api.picoin.science/node/sync-status | python3 -c 'import json,sys; d=json.load(sys.stdin); print(int(d.get("effective_latest_block_height") or d.get("latest_block_height")))')
echo "HEAD_HEIGHT=$HEAD_HEIGHT"

.venv/bin/python -m picoin node checkpoint --server http://127.0.0.1:8000 restore-peer \
  --peer https://api.picoin.science \
  --height "$HEAD_HEIGHT" \
  --source mainnet-validator-repair

Clean old replay queue and verify:
curl -sS -X POST "http://127.0.0.1:8000/consensus/replay?limit=100" | python3 -m json.tool

curl -sS http://127.0.0.1:8000/node/sync-status | python3 -c '
import json,sys
d=json.load(sys.stdin)
r=d.get("replay") or {}
print("snapshot=", d.get("snapshot_height"))
print("effective=", d.get("effective_latest_block_height"))
print("pending=", d.get("pending_replay_blocks"))
print("replay=", r.get("sync_status"))
print("divergent=", r.get("divergence_detected"))
print("reason=", r.get("divergence_reason"))
'

Expected:

pending=0
replay=healthy
divergent=False

Then start validator:

sudo systemctl start picoin-validator

Desktop Validator note: the Windows Desktop Validator is currently under review for the same sync/snapshot changes. Linux validators should update using the steps above now. A new Desktop Validator release will be announced after testing.
PICOIN mining (proof of pi)

1. **The miner requests a task**
   The client calls `/tasks/next` with its `miner_id`.
   In competitive mode, the node assigns a task for the **next block**: the same `competitive_round_height`, the same Pi range for all miners in that round, but each miner receives a unique `task_id`.

2. **Multiple miners compete for the same block**
   If there are 30 active miners, there may be 30 tasks associated with the same `competitive_round_height`.
   This is expected. They are not 30 blocks; they are all competing for a single block.

3. **The miner performs the computation**
   The miner computes the assigned BBP segment of Pi and generates the required proofs/samples.
   Finishing first does not automatically win the block; the result must still pass validation.

4. **Commit**
   The miner submits `/tasks/commit`.
   This records a commitment to the computed result without revealing all details yet. It locks in the miner's work and prevents later manipulation.

5. **Reveal**
   The miner then submits `/tasks/reveal`.
   At this stage, the required samples are revealed so validators can verify the result.

6. **A validation job is created**
   Once a task reaches the `revealed` state, the bootstrap node creates a `validation_job`.
   This job is added to the validator queue.

7. **Validators vote**
   Eligible validators request `/validation/jobs`, review the task, and submit their votes through `/validation/results`.
   On mainnet, 3 approvals are currently required when enough eligible validators are available.

8. **Only one leading candidate per round**
   With the latest fix, if multiple jobs are revealed for the same competitive block, validators focus on the first pending candidate of that round.
   All other candidates are placed into `competitive_round_waiting`. This prevents votes from being split across multiple candidates.

9. **If quorum is reached, the block is created**
   Once the leading candidate receives quorum approval, the node finalizes the block:

   * Inserts the block into the `blocks` table
   * Marks the winning task as `accepted`
   * Marks all other tasks from the same round as `stale`
   * Distributes miner rewards, protocol reserves, and validator rewards

10. **Reward maturity**
    The miner's reward is not immediately spendable.
    With `block_maturity_depth=2`, the reward remains `immature` for 2 blocks before becoming `mature`.

11. **If nobody completes the task**
    Tasks have an expiration time. If no miner reveals or no validator approves a result before expiration, the task expires and the network can issue a new round to attempt the next block.

### Summary

PICOIN uses competitive mining.** Multiple miners compete to produce the first valid result approved by the validator network for the next block. The winning miner receives the block reward, while losing tasks become `stale` or eventually `expired`. This model eliminates mining backlogs and moves PICOIN closer to a fully decentralized and competitive consensus mechanism.

[johannFac]

PICOIN Mainnet Decentralization Update - June 8, 2026

Hello PICOIN community,

We are preparing an important mainnet decentralization update scheduled for June 8, 2026.

This update is the result of several weeks of work across multiple decentralization phases. The goal is to move PICOIN further away from a single centralized API path and toward a stronger network model with independent full nodes, peer synchronization, decentralized mempool propagation, validator finality, exchange-ready full nodes, safer wallet operations, and better public mining/pool support.

This is a major infrastructure update. During the rollout, miners, validators, pool workers, and node operators may temporarily experience bugs, idle periods, rejected tasks, sync issues, or behavior changes while services are upgraded and verified.

After the merge to `main`, all miners, validators, pool operators, and node operators should update to the latest `main` version.

This post summarizes what has been implemented, what the README now documents, what changed in the pool, and what the community should expect during the mainnet update.


1. Why This Update Matters

The first version of PICOIN mainnet worked, but several network functions still depended heavily on the main bootstrap/API path. That was useful for launching, testing, and stabilizing the chain, but it is not the final architecture we want.

The decentralization work focuses on these goals:

• Allow independent full nodes to follow mainnet safely.
• Allow nodes to reconcile chain, mempool, proposal, and block data from peers.
• Reduce dependency on a single public API server.
• Make miners less dependent on one node endpoint.
• Improve validator liveness and finality handling.
• Improve public pool mining and payout accounting.
• Add exchange/infrastructure full-node support.
• Add snapshot restore and fast sync.
• Add safer operational runbooks for mainnet updates.
• Add smoke tests before any production rollout.

This update is not just a feature update. It is a network-hardening update.


2. Phase Summary

Below is a summary of the decentralization phases that have been implemented, tested, or documented.


Phase 0 - Stable Mainnet Baseline

Phase 0 was about protecting the live mainnet while decentralization work happened separately.

The rule was simple: mainnet stability first.

During this phase, we kept the current mainnet path stable while testing decentralization code on isolated branches and candidate droplets. This prevented experimental peer-sync, mempool, validator, and pool changes from being pushed directly into production before being tested.

Main goals:

• Keep mainnet mining, validators, explorer, wallet, and bootstrap stable.
• Avoid merging decentralization work until acceptance gates passed.
• Track known issues separately from live production.
• Keep rollout controlled and reversible.

Phase 1 - Independent Full Node Verification

Phase 1 introduced the first isolated full-node verification path.

The purpose was to prove that a node can run independently and verify chain data without acting as a miner, validator, or bootstrap authority.

This phase focused on:

• Running a full node in an isolated lab.
• Verifying local chain data.
• Testing health, audit, and sync endpoints.
• Confirming that a node can be used as an observer without mining or validating.

This phase became the foundation for later exchange and infrastructure full-node work.


Phase 1B - Mainnet Shadow Full Node

Phase 1B moved the full-node concept closer to production by running a read-only shadow node against live mainnet data.

The shadow node was not used as the main bootstrap, did not mine, did not validate, and did not serve as the main public API. It existed only to prove that a separate node could follow mainnet safely.

This phase helped us verify:

• Mainnet sync behavior from a separate host.
• Replay health.
• Divergence detection.
• Read-only mainnet observation.
• Whether a future public full-node package was realistic.

Phase 2 - Multiple Public Bootstrap Candidates

Phase 2 tested multiple bootstrap candidates.

Instead of assuming one public API node should always be the only source of truth, we tested candidate nodes that could expose public read endpoints and stay aligned with mainnet.

This phase included:

• Candidate bootstrap configuration.
• Public node identity.
• Read-only node operation.
• Candidate comparison.
• Endpoint parity checks.
• Bootstrap candidate health verification.

The goal was not to immediately replace the main bootstrap. The goal was to prove that multiple public candidates could exist and be compared safely.


Phase 3 - Peer Gossip And Consensus Propagation

Phase 3 added the first major peer-to-peer improvements.

This phase focused on how nodes discover, filter, and reconcile with peers.

Implemented and tested improvements included:

• Peer inventory exchange.
• Mempool inventory endpoint support.
• Peer filtering.
• Stale peer detection.
• Compatible-peer selection.
• Reconcile behavior between bootstrap candidates.
• Fast-fail behavior for divergent nodes.

One important improvement was that divergent nodes should stop expensive reconciliation attempts and report that restore is required instead of hanging or wasting resources.

This is important for production because a bad node should not silently keep trying to sync forever if it already knows its local chain state is invalid.


Phase 4 - Decentralized Mempool And Block Candidate Construction

Phase 4 was one of the most important phases.

It focused on decentralized mempool behavior and deterministic block candidate construction.

Before this work, transactions and block candidates were more dependent on the central path. Phase 4 tested whether multiple nodes could hold the same mempool data and construct the same transaction commitment.

Key work included:

• Mempool transaction propagation.
• Mempool inventory reconciliation.
• Transaction hash consistency.
• Fee-priority ordering.
• Nonce ordering.
• Transaction Merkle root calculation.
• Selected transaction hash commitment.
• Deterministic block candidate state root.
• Multi-node mempool comparison.

In the Phase 4 lab, candidates A, B, and C were able to hold the same mempool set and compute matching transaction commitments.

This matters because decentralized mining requires more than just calculating Proof of Pi work. Nodes must agree on which transactions are selected, in what order, with what fees, and with what resulting state root.


Phase 5 - Miner Task Independence

Phase 5 focused on miner independence.

The goal was to prove that miner identity and task execution could work across multiple nodes, not only through one fixed API endpoint.

This phase tested:

• Miner identity portability.
• Deterministic competitive task ids.
• Cross-node task assignment.
• Commit acceptance.
• Reveal acceptance.
• Miner restart persistence.
• Failover-style miner behavior across candidate nodes.

The lab proved that the same miner identity could interact with different nodes and that task metadata remained stable after restart.

This is an important step toward miners being able to use multiple endpoints in the future instead of depending on only one public API server.


Phase 6 - Validator Finality Certificates

Phase 6 focused on validator finality.

Mining alone is not enough. A decentralized network also needs validators to confirm that work is valid and that blocks can be finalized with quorum.

This phase worked on:

• Validator vote tracking.
• Finality certificate structure.
• Required approval counts.
• Validator quorum behavior.
• Certificate verification tooling.
• Finality inspection by block height.

This phase also showed why validators are critical. If validators are offline, out of sync, or not voting, mined work can remain stuck waiting for validation.

Because of that, the update runbook now includes specific validator gates before and after deployment.


Phase 7 - Exchange And Infrastructure Full Node Package

Phase 7 was focused on exchanges, explorers, custodians, and infrastructure operators.

The goal was to allow an operator to run a local PICOIN full node without relying on the public API server for basic reads.

This profile runs:

• `picoin-node`
• `picoin-reconciler`

And keeps these disabled by default:

• `picoin-miner`
• `picoin-validator`
• `picoin-auditor`

Phase 7 added and documented:

• Clean full-node install script.
• Mainnet full-node environment template.
• Snapshot restore support.
• Fast sync from canonical bootstrap snapshots.
• Local health checks.
• Local protocol checks.
• Local sync checks.
• Local block and transaction reads.
• Account balance and history checks.
• Wallet nonce checks.
• Deposit confirmation policy.
• Backup and restore commands.
• Phase 7 full-node smoke test.

This phase was tested on a clean droplet using a canonical mainnet snapshot restore. The node restored from snapshot, caught up with mainnet, stayed replay healthy, showed no divergence, and passed the exchange full-node smoke test.


Phase 8 - Exchange Wallet Write Path And Public Operator Hardening

Phase 8 added the write-path smoke test for exchange and operator wallets.

This phase does not make every full node a hot-wallet system by default. The public exchange full-node profile remains read-only unless the operator explicitly provides a wallet and chooses to submit a signed transaction.

Phase 8 added:

• Hot-wallet metadata validation.
• Local/reference nonce parity checks.
• Wallet network and chain validation.
• Local/reference balance checks.
• Safe preflight mode that does not spend funds.
• Optional signed withdrawal submit.
• Reference bootstrap visibility check.
• Optional confirmation parity check.
• Timeout handling for transactions that become visible after submit timeout.
• Public reporting without exposing private keys.

Phase 8 was validated on mainnet with a small real transaction:

• Hot wallet: `PIFDE77B556D494F5DE4B1523D8CDDDCA961A76151E8C761`
• Recipient: `PI3BEE15E913DD2BF4D1194E47B5127339D1AAF79C976CE2`
• Transaction: `3f12faa6f9bd9a6455d7749f0437270cb1d5bf361696b8715b4fe4fdc13f45e3`
• Amount: `0.001 PI`
• Transaction fee: `0.001 PI`
• Confirmed block: `10563`
• Local/reference nonce after confirmation: `confirmed_nonce=1`, `pending_nonce=0`, `next_nonce=2`

This proves that a local full node can be used in an operator withdrawal flow and that the reference bootstrap can observe the same transaction without nonce drift.


3. README And Documentation Updates

The documentation has been expanded so operators do not need to guess how the system works.

The README and deployment documentation now include:

• Mainnet profile values.
• Mainnet environment setup.
• Wallet requirements before mainnet.
• Miner setup.
• Validator setup.
• Public pool setup.
• Exchange full-node install guide.
• Snapshot restore guide.
• Fast-sync guide.
• Phase 7 full-node smoke test.
• Phase 8 withdrawal smoke test.
• Service preflight checks.
• Backup and restore procedures.
• Safe mainnet update drill.
• Rollback rules.

A new safe update process has been documented for mainnet.

The key idea is simple:

Do not update everything at once.

The documented update order is:

[list=1]

• Test the new code first on a canary full node.
• Verify health, sync, replay, audit, and smoke tests.
• Back up the mainnet bootstrap environment and database.
• Update only the bootstrap node and reconciler first.
• Verify replay health, no divergence, audit validity, and protocol identity.
• Update validators one by one.
• Update miners and pool after the node layer is stable.
• Stop immediately if divergence, audit failure, stuck validation, or miner crashes appear.

4. New Public Pool Improvements

The public pool also received major improvements.

The pool work focused on making pool mining more usable, more transparent, and fairer for public workers.

Main improvements include:

• Public worker support.
• Pool mode support in Miner Desktop.
• Linux pool worker support.
• Pool statistics endpoint.
• Active worker reporting.
• Pool hashrate reporting.
• Worker hashrate reporting.
• Better task/chunk state reporting.
• Automatic chunk sizing.
• Speculative assignment support.
• Hybrid race mode.
• Improved worker logs.
• 429 handling improvements so miners do not stop production on temporary rate limits.
• Pool payout accounting.
• Operator fee accounting.
• Pending balance handling.
• Automatic payout interval configuration.
• Minimum payout configuration.

The pool now supports a more competitive task distribution model.

Instead of manually guessing chunk size, the pool can now operate with automatic strategies. The goal is to keep faster workers busy, avoid waiting too long for slow workers, and reduce idle time.

The pool modes include:

• One-unit speculative queue: each unit can become its own work item, and workers keep asking for more.
• Full-task race mode: when useful, workers can race on the full task and the fastest valid result closes the work.
• Hybrid race mode: chooses between full-task race and chunked work depending on the relationship between task size and active workers.

The pool has also improved payout behavior.

Current intended payout model:

• Pool operator fee: `1%`.
• Transaction fee per payout transaction: `0.001 PI`.
• Automatic payout interval: configurable.
• Minimum payout amount: configurable, currently designed around `0.1 PI`.
• If a worker does not reach the minimum payout, the amount remains pending.
• Pending balance is tracked as coin value, not just work units.
• Shares are counted in the current reward window and should reset after a won block window is settled.

The pool has already mined blocks and payouts have been tested, but pool accounting will continue to be monitored closely during the mainnet update. Pool users should report any missing pending balance, wrong payout address, duplicate payment, or unexpected share display.


5. Miner And Validator Impact

Because this update touches node sync, mempool behavior, validator finality, miner task handling, and pool code, miners and validators may see temporary issues during the rollout.

Possible temporary miner issues:

• Idle messages while no task is available.
• Temporary 429 rate-limit responses.
• Commit/reveal retries.
• Task already revealed or waiting for validation.
• Miner Desktop requiring update.
• Linux miner requiring update.
• Pool worker reconnects.

Possible temporary validator issues:

• Heartbeat interruptions.
• Out-of-sync status while nodes restart.
• Validation jobs waiting for quorum.
• Validator service requiring restart after update.
• Stale validator status until the node catches up.

Possible node/operator issues:

• Replay queue catching up.
• Snapshot restore needed on a divergent node.
• Full-node health temporarily degraded if it has no validators.
• Reconciler restart required.
• Service sandbox preflight warnings if writable paths are missing.

If you are running a miner, validator, pool worker, full node, or infrastructure service, please be ready to update after the `main` merge.


6. Mainnet Update Date

The mainnet decentralization update is scheduled for:

June 8, 2026

During the update window, the network may experience temporary instability while services are upgraded and verified.

This is expected for a controlled infrastructure rollout.

We will not update everything blindly. The rollout will follow safety gates:

• Canary full-node validation.
• Bootstrap node/reconciler update.
• Replay health check.
• Divergence check.
• Audit check.
• Validator quorum check.
• Miner task flow check.
• Pool health check.
• Wallet/nonce smoke checks where needed.

If any critical gate fails, the rollout will stop and the issue will be fixed before continuing.


7. What The Community Should Do

After the `main` branch is updated, please update your software.

Miners:

• Update Miner Desktop to the latest release.
• Linux miners should pull the latest `main` code.
• If using pool mode, make sure your worker is using the latest pool worker code.
• Report repeated crashes, not normal idle messages.

Validators:

• Update from the latest `main`.
• Restart validator service after updating.
• Confirm your validator is online and synced.
• Watch for validation jobs and heartbeat status.

Pool workers:

• Update Miner Desktop or Linux worker.
• Keep your payout address configured correctly.
• Watch your pending balance and worker status.
• Report any payout/accounting issue with wallet address and worker id.

Node operators:

• Use the documented update drill.
• Do not update all services at once.
• Back up env and database before touching production.
• Verify replay health and no divergence before enabling extra services.

8. Final Notes

This decentralization update is a major step for PICOIN.

It improves the foundation for:

• More independent infrastructure.
• Better public node operation.
• Safer exchange integration.
• More resilient mining.
• Better validator coordination.
• Public pool growth.
• Future decentralization phases.

There may be bugs during the rollout. That is normal for a network-level update, but the important difference is that we now have better tests, better documentation, better smoke scripts, better rollback rules, and better visibility into what is happening.

Thank you to everyone who insisted, tested, reported bugs, complained when something did not make sense, and helped push the network forward.

Without that pressure, PICOIN would not improve.

Please stay alert for the June 8 mainnet update announcement, update to the latest `main` version after the merge, and report any miner, validator, pool, or node issue as soon as possible.

PICOIN continues moving toward a more decentralized and production-ready network.

[johannFac]

Operator Documentation And Public Tools

For operators, exchanges, pools, miners, validators, and community members, the updated documentation is now organized by role.

Exchange / Infrastructure Full Node

Exchanges, custodians, explorers, payment processors, and infrastructure operators should use the Exchange Full Node guide.

Repository path:

Code:

picoin-proof-of-pi/deploy/README-exchange-full-node.md

This README explains:

• How to install a read-only mainnet full node.
• How to restore from a canonical snapshot.
• How to catch up from the bootstrap.
• How to verify health, protocol, sync, audit, balances, transactions, and wallet nonce.
• How to run the Phase 7 exchange full-node smoke test.
• How to run the Phase 8 withdrawal write-path smoke test.
• Backup and restore procedures.
• Deposit confirmation policy.

Mainnet Update / Safe Rollout

Mainnet operators should read the mainnet runbook before updating production services.

Repository path:

Code:

picoin-proof-of-pi/deploy/README-mainnet.md

This includes the new safe mainnet update drill:

• Canary full-node test first.
• Backup before bootstrap update.
• Update node/reconciler before miners, validators, or pool.
• Validator and miner health gates.
• Rollback rules.

Public Pool

Pool operators and pool workers should use the pool README.

Repository path:

Code:

picoin-pool/README.md

Pool deployment examples:

Code:

picoin-pool/deploy/picoin-pool.service.example
picoin-pool/deploy/nginx-pool1.conf.example
picoin-pool/deploy/install-pool-worker-service.sh

This documentation covers:

• Pool server setup.
• Pool worker setup.
• Linux worker service installation.
• Authentication token usage.
• Pool payout wallet configuration.
• Pool fee configuration.
• Automatic payout interval.
• Minimum payout threshold.
• Public worker mode.
• Pool task and chunk behavior.

Web / Explorer / Pool Page

The public web frontend lives here:

Code:

picoin-web/README.md

Important web files:

Code:

picoin-web/index.html
picoin-web/explorer.html
picoin-web/miner.html
picoin-web/wallet.html
picoin-web/transaction.html
picoin-web/pool1.html

Pool public page:

Code:

picoin-web/pool1.html
picoin-web/pool1.js

Explorer page:

Code:

picoin-web/explorer.html
picoin-web/explorer.js

Miner page:

Code:

picoin-web/miner.html
picoin-web/miner.js

The web frontend includes public pages for:

• Main PICOIN entry page.
• Explorer.
• Wallet tools.
• Transactions.
• Miner information.
• Pool status page.

General Main Roadmap

The main decentralization roadmap and phase status are in:

Code:

README.md

This file includes the completed phase summaries, acceptance evidence, current mainnet status, and the decentralization roadmap.