What PIKO is ?
Piko is an Independent implementation of the “proof-of-on-chain-work” idea publicly described by bob.fun. Own name, own token, own codebase. Not affiliated with, endorsed by, or connected to bob.fun or BOB.
It is a fixed-supply token whose only way of coming into existence is proof-of-work , no premine, no team allocation, no admin mint path anywhere in the code (checked: the reward-payout helper is only ever called from the block-win path and from retrying an already-decided pending reward : there is no function a controller can call to mint arbitrary PIKO). The ledger’s initial_balances is an empty vec at init , not just a claim in this paper, the actual init args say so.
The ledger’s mint history is the mining history, nothing else.
A transparency note before anyone asks: the chain isn’t at height 0. At this time 46 blocks (27,600 PIKO, about 0.13% of the 21M cap) were already mined before this post. All of it happened during development and testing, while the code itself was still being built, upgraded, and verified. Height and total minted are live and checkable via getStats() right now, same as every other figure in this post.
Why fully automated matters as much as fair-launch does
A fair launch that still depends on a human remembering to do something isn’t really decentralized, . So the second constraint, alongside “no team allocation,” is: nothing in the day-to-day operation of PIKO should require a person to act.
- Seven canisters, no servers, no database, nothing off-chain: ledger (unmodified ICRC-1/2), mother (coordinator), miner (optional reference/self-hosted), frontend, dice + dice-frontend, landing.
- mother self-funds its own compute: every mining fee, once swept, splits into a majority burned to the ICP ledger’s minting account and a small share (currently 20%, live via getStats()) converted to cycles via the CMC.
- mother is also the only canister here with real, ongoing ICP income (the mining fee), so it shares its cycles surplus with the four canisters that have no reliable way to earn their own: ledger, frontend, the reference miner, and dice. (dice does have its own equivalent sweep for ICP betting profit, but the sanctioned dice-frontend site is PIKO-only by design, so that loop has essentially nothing real to convert in practice , mother’s top-up is what actually keeps dice funded.) dice then relays its own balance on to dice-frontend, the one canister with no ICP exposure at all. All of this runs automatically, every 15 minutes, on the same timers that run each coordinator’s burn/profit sweep.
- Difficulty retargets itself from on-chain block timestamps every 10 blocks toward a 5-minute target , no controller call anywhere in that loop.
What’s actually under my control today, and what isn’t
I’d rather list this precisely than let anyone assume more (or less) decentralization than what’s currently deployed , and everything below is something you can check yourself via query calls, not something you have to take my word for.
Not under anyone’s control, enforced by code, no admin path exists at all:
- The supply cap and the mint path (no mint function exists outside the block-win flow)
- Difficulty retargeting (pure function of on-chain timestamps)
- PIKO Dice’s odds : 1% house edge, payoutNumerator = 99, a compile-time constant, not a variable
- The 0.3s anti-spam cooldown per principal
- The 48h timelock delay itself. Hardcoded constant, the controller can’t shorten it
- Which canisters the cycles top-up can reach (ledger/frontend/miner/dice for mother, dice-frontend for dice) — fixed at deploy time via env vars, no runtime setter
Already locked, no longer changeable by anyone : confirmed live via getStats() on mainnet right now:
- mother’s ICP fee target (which ledger, which burn account, which Cycles Minting Canister) — icpFeeTargetLocked = true
- The burn/cycles-conversion split ratio, currently 20% to cycles : cyclesFundRatioLocked = true
Still under a single controller key today : timelocked (48h public delay), lockable, not yet locked, and fully checkable via getConfig(): - dice’s ability to withdraw seeded bankroll back out : withdrawalsLocked = false - dice’s risk config (maxPayoutBps, currently 1%, and the protected bankroll floor) — riskConfigLocked = false - The mining fee itself (setMiningFeeE8s), deliberately not timelocked — it can only make mining cheaper or more expensive for everyone equally, it can’t drain supply or redirect anything, so it gets a lower bar than the parameters above
Fully under a single controller key, no timelock at all:
Upgrading the code itself, on any of the six non-ledger-standard canisters. This is the big one to be honest about, a code upgrade can rewrite any rule described above, including the already-locked params (a lock only binds the currently installed code; new code could remove the check). Blackholing (permanently removing all controllers) is what actually closes that door, and it’s deliberately not done yet —> see roadmap below.
How Piko mining actually works — a race, not a queue
A block at height h is won by finding a nonce such that sha256(previousHash || h || nonce) has at least difficultyBits leading zero bits. Every miner searches for that nonce completely independently, in parallel, with no coordination between them. No pool, no shared work assignment, no operator handing out ranges . A browser tab just starts hashing candidates against the current header on its own, exactly like every other miner is separately doing at that same moment for that same height.
1. Approve , grant mother an ICRC-2 allowance on the ICP ledger, a few blocks’ worth of fee.
2. Search, alone , hash candidates against (previousHash, h). Nobody else’s search affects yours; you’re not queued or assigned a slice, you’re purely racing your own hash rate against everyone else’s, independently.
3. Submit the instant a valid nonce turns up.
4. mother verifies it itself : recomputes the hash, never trusts a client-supplied result.
5. Pay regardless of outcome. The fixed 0.25 ICP fee is pulled the moment a submission is valid, win or lose. This is what makes it a real race: losing costs exactly what winning costs.
6. Settle: first valid submission for that height wins , if the chain height hasn’t moved since your search began, you win and the reward mints straight to your principal. If someone else’s valid proof landed first, yours is rejected and the fee is still gone.
Tokenomics
| Parameter | Value
| Max supply | 21,000,000 PIKO (8 decimals)
| Initial block reward | 600 PIKO, halving every 17,500 blocks
| Mining fee (burned/converted, win or lose) | 0.25 ICP
| Burn / cycles split | 80% burned / 20% to cycles — locked, permanent
| Difficulty | floor 18 bits, retargets every 10 blocks toward a 5-min target, max ±2 bits/window, unbounded upward |
| Anti-spam cooldown | 0.3s per principal
PIKO Dice
A separate, provably-fair on-chain dice game so PIKO has somewhere to be spent, not just mined and held. Standard “roll under” formula, 1% fixed house edge (compile-time constant). Deliberately a separate site/opt-in from mining. Every bet is checked against the game’s real, live on-chain bankroll, recomputed on every single bet, it can never accept a bet it couldn’t cover, including under concurrent load from multiple players at once.
Roadmap —>
Done:
-
Automatic difficulty retargeting (no controller path)
-
Automatic 15-minute treasury sweep on both mother and dice (burn/profit-sweep + cycles conversion + stale-entry pruning, all on one timer each)
-
Project-wide automatic cycles top-up: mother → ledger/frontend/miner/dice, and dice → dice-frontend
-
Locked mother’s ICP fee target and burn/cycles split : permanent, confirmed live on mainnet
-
PIKO Dice shipped as a companion utility, with its own timelocked risk config, lock status now publicly queryable
- Internal self-review pass — see above
Remaining, in order:
- Observation period (now) : run in production for enoug time, confirm the retarget algorithm tracks real participation as intended
- Lock dice’s withdrawal path and risk config once each is considered final (both confirmed still open as of this post)
- Blackhole ledger (standard DFINITY code, lowest bug surface , earliest candidate)
- Blackhole mother once difficulty and fee parameters have stabilized and a long enough track record backs the code
- Blackhole dice, after mother, once a real track record of betting volume has run without incident , more moving parts than mother, so a slower timeline, not the same one
- Liquidity: a PIKO/ICP pool on an ICP-native DEX first, once there’s a real community of miners to trade with
Risk disclosure
- No liquidity or listed market exists yet.
- The mining fee is real ICP, non-refundable the instant it’s pulled, win or lose.
- Not investment advice, not a security, not a promise of future value. Mine only with ICP you’re fully prepared to never see again.
- Single controller today across all six non-ledger-standard canisters , see above for exactly what that does and doesn’t allow, and note that a lock only binds the currently-installed code, not future upgrades.
- Independent project, not affiliated with bob.fun/BOB.
Genuinely looking for this to be picked apart . The concurrent-submission handling in mother under real parallel load, the retarget math, the timelock machinery, anything in dice’s bet resolution. Code and whitepaper linked above.
