Work in progress

This site is still being built

The Foundation is building in the open. What you see here is current and honest, but it is not finished — read it as where we are today, not as a final statement.

Between now and MainNet, things will change: wording, structure, images, and figures. Some pages are placeholders. Where a photograph stands in for a person, it is a stock image, not the individual named.

The wider ZooBC ecosystem arrives in stages. The wallet, the explorer, the community forum, and the social channels each come online as MainNet approaches, and this site grows alongside them.

If something reads wrong, looks broken, or seems misleading, tell us. Feedback now is worth more to us than a polished launch later.

Node 0.5.2 and Wallet V1.78 follow a week of testing

Community reports led to specific fixes in Wallet V1.78 and node 0.5.2. Both TestNet chains were relaunched, several features are live chain-side, and work remains before MainNet.

By Roberto Capodieci · Published

A week of testing

Thanks to Nagi, Cebo, TeresFi, Otto Graf and everyone else who filed reports, tested fixes and came back to confirm them. Nagi's reports in particular broke ZooBC more than once — which is exactly what we want to happen now rather than after MainNet.

Twelve forum reports were fixed, verified and closed on 26 September: six on the node and gateway, six on the wallet. An overnight node test on 25 September produced a further 37 fixes; those overlap with the forum reports, so the two numbers shouldn't be added together.

More faults will surface as account groups, escrow, survival deposits and the other new transaction types come into use. That's expected.

Forum reports closed

Node and gateway — topics 278, 283, 294, 295, 296 and 299, verified against the live services. They covered a caller-supplied peer address, signed-request authentication, unauthenticated host metrics, internal details in logs, unbounded calls-relay memory and public access to stored files. Topic 316 was fixed and deployed earlier.

Wallet — topics 349, 350, 351, 355, 356 and 357, verified in Wallet V1.78:

  • escalating PIN delays, with device erasure as an opt-in rather than an automatic wipe after five wrong attempts;
  • contacts, profile, transaction journal and notes kept inside the encrypted vault;
  • update notices restricted to a known publisher and download URL;
  • explicit consent before using gateways found in the on-chain registry;
  • private-network URLs refused by both wallet and node.

Two caveats. The wallet checks that a release entry came from the publisher account, that the URL is HTTPS on an allowed domain, and that the download matches the published SHA-256 hash — but it doesn't yet verify the publisher's ZBC-MSG-v1 signature. That stays open. And closing the file-storage report doesn't make an unencrypted upload private: anyone with its ZFR_ root, plus the replica operators, can read it. V1.78 encrypts uploads on-device by default; a node-side access-control list is designed but not built.

Node 0.5.2

Both fleets moved from 0.4.2 (13 September) through 0.4.5, 0.5.0 and 0.5.1 to 0.5.2. All 22 TestNet and DevNet nodes were on 0.5.2 by 17:33 UTC on 27 September. The roll took 15 minutes and neither chain paused.

0.5.2 was prompted by two stalls on 26 September:

  • TestNet mined 107 empty blocks (549–655) over 62 minutes. Five file-deletion transactions for the same path landed in one block; the second failed deterministically and invalidated the block, but wasn't evicted, so every producer hit the same failure again.
  • DevNet stalled twice for about an hour each after a transfer to an address of no known type.

0.5.2 evicts transactions after deterministic failures, limits operations on the same object within a block, and brings admission checks closer to execution checks. Two remotely triggerable crashes had already been fixed in 0.4.5, and a transaction dropped from the pool now always carries a reason on the transaction-status endpoint.

Relaunch and height-activated rules

Both chains restarted from block 0 at 16:21 UTC on 26 September. Previous balances and history are gone; TestNet coins need to be requested from the faucet again. A node installed before the relaunch may still be sitting on the dead chain with no peers — reinstall it with the node role.

Protocol changes can now activate at a block height instead of needing another relaunch. Of 35 height-controlled rules, 29 have been active since block 0 and six are scheduled for block 60,000: fee-only no-ops instead of failed blocks, the reserved dfs: namespace, recipient shape, the dataset-update deposit fix and related executor rules. Every node must be on 0.5.2 before block 60,000 or it will fork off the chain.

The stall fixes are not among the six — they're already active.

Taproot and split policy

Both are live on chain from block 0 of the relaunch. The wallet doesn't expose either yet. TAPROOT_LIVE is off, so V1.78 refuses ZBC sends to bc1p recipients and shows existing Taproot accounts as token-only even though the chain accepts ZBC for them. The split-policy screen and transaction builder are built but sit behind SPLIT_LIVE, also off. Wallet dates for both will follow.

Wallet V1.78

The biggest change is how a games are tracked. The wallet now follows it through the node's staging and mempool states, and the sealing screen shows how long it has waited and its mempool position.

The old wallet gave up after 80 seconds. During the TestNet stall it deleted three games records and reported nothing resolved — even though all three landed about 40 minutes later and one paid out. V1.78 waits up to six minutes, keeps the record after a timeout, resumes polling when the game is reopened, and never calls a bet failed while the node still has it in the mempool.

A payout display fault affecting every winning game is also fixed: matching now uses reference_id, which the API actually returns.

Also shipped:

  • minimum retained fee, fee sent and total account debit in confirmation dialogs;
  • transaction version 2 and selectable survival periods;
  • token expiry dates and extension controls, with signing refused on an expired token;
  • account groups with pooled balances, member permissions and spending limits;
  • type-5 multisig proposals and co-signatures;
  • activity rows calculated from the node ledger;
  • encrypted file uploads (ZFE1 container) by default;
  • encrypted notes interoperable with zbc-cli;
  • unknown callers arrive as incoming requests instead of ringing;
  • gateway registry entries listed as disabled until you enable them.

Reporting bugs from October

From October, a report needs to be posted on the ZooBC forum to qualify for a bug or security reward. Telegram is still fine for discussing a fault — there's a dedicated technical group for that, which also keeps the main channel free for general discussion — but the forum post is the record we use to reproduce, verify and close. Reward details will be published separately.

Coming up

Two AMA sessions are planned for mid-October: one for detailed technical questions, one at a higher level. I have built a tool for them that translates questions and subtitles into each viewer's selected language; it hasn't yet run a live session. Finger crossed it will work (you are going to be the guinea pigs to test this new system!) As fallback we have google meet. Dates and registration links will be announced separately.

The second phase of the ZBC purchase period has 18 days left. Who ever want some, please get them ASAP!

Elsewhere

Circle opened the Arc mainnet on 16 September: a permissioned proof-of-authority validator set, Malachite BFT consensus and USDC for fees. A move to permissioned proof of stake has been discussed but not scheduled. Avalanche activated Helicon on 22 September: auto-renewed staking, a 48-hour minimum staking period (down from two weeks), a 90% uptime threshold for rewards (up from 80%) and a phased reduction in mean consumption rate. Visa, Mastercard and Ant International described a "Know Your Agent" framework for identifying autonomous payment agents and tying them to responsible entities — Visa's demos still keep a person in the authorization path; Mastercard's virtual cards carry merchant restrictions, spending limits and optional approval before checkout.

Three different trust models: institution-selected validators, stake and uptime requirements, and payment-network identity controls. ZooBC is still proving out Proof-of-Participation before MainNet, and this week's relaunches, stalls and open executor findings are that work done in the open.

Social Media Disclaimer

Last updated: 29 September 2026

This disclaimer applies to all posts and social media content published by or on behalf of ZooBC Foundation, including content associated with zoobc.com, zoobc.pro, zoobc.net, zoobc.network, socialconnect.network, proofofparticipation.network, and zoobc.foundation.

1. General Information

All posts and social media content (“Content”) are for entertainment and informational purposes only and do not necessarily express the views of ZooBC or any of ZooBC’s employees, contributors or contractors. The Content is not error-free and may contain incorrect information. No advice or information, whether oral or written, obtained from ZooBC, will create any warranty or representation not expressly made herein.

You should not rely on any Content for advice of any kind, including legal, investment, financial, tax or other professional advice, and the Content is not a substitute for advice from a qualified professional.

Any Content does not constitute an offer to sell or the solicitation of an offer to purchase any security, token or digital asset, and is not an offering, advertisement, solicitation, confirmation, statement or any financial promotion that can be construed as an invitation or inducement to engage in any investment activity or similar.

For the avoidance of doubt, the Content is not provided by an investment adviser and is not an investment advisory service of ZooBC. Reposts, retweets, follows, or likes by ZooBC and ZooBC-related social media accounts are not an endorsement of any idea, individual, group, or entity by ZooBC.

2. Contact Information

If you have any questions about our websites or this Disclaimer, please contact us at info@zoobc.foundation.