Chain-bound signing goes live after the testnet relaunch

The chain restarted with a new signing rule

At 02:45:52 UTC on September 16, ZooBC’s testnet and devnet started again from block zero. Their new genesis hashes became part of every transaction signature.

A transaction signed for testnet can no longer be replayed on devnet, or on another chain using the same transaction format. Nodes now verify:

SHA3-256("ZBC-TX" ‖ genesis_hash ‖ transaction_bytes)

Escrow approvals also changed. They now identify the escrowed transaction by its full hash rather than its numeric ID.

The node team introduced the rule in version 0.4.0. The wallet first supported both signing formats, then removed version-one signing in build 160. The current wallet footer shows V1.53, and five taps on its network pill reveal the signing version and genesis fingerprint.

That removal has a compatibility cost. Nodes still enforcing the old rule cannot accept transactions from the current wallet, including escrow approvals. Whether any public node remains on the old rule is unconfirmed.

The wallet obtains the genesis hash from /api/v1/node/info and caches it for offline use. If it has never learned the genesis hash for a chain, it refuses to sign. On startup, it also reproduces the published signing test vector and logs the result in the browser console.

This was not a MainNet launch. ZooBC has not launched MainNet.

Roberto had earlier referred to changes being deployed to MainNet, then corrected that statement to testnet. He said testnet had restarted twice within about a week and a half. The September 16 relaunch is verified from the live chains; the exact time of the earlier restart is not established in the supplied records.

The Foundation’s current MainNet target is February 14, 2027.

A token name became executable code

After the relaunch, forum testing moved from protocol compatibility into the interfaces that display chain data.

A reporter created a token named <img src=x onerror=alert(1)>. In affected wallet versions, opening the token page executed the embedded JavaScript.

The wallet team changed how node responses and token fields are handled. Token names and symbols now pass through a sanitizer at the fetch boundary, and the remaining raw rendering points in the Exchange tab escape their values. The fix is in build 168, wallet V1.53.

Two related paths were also closed during the period. Quote-unsafe escaping in 16 locations had allowed chain strings to close an HTML attribute and add an event handler. Token icons had also been inserted through innerHTML after regex-based SVG filtering, which did not stop onerror or <svg onload> variants.

The wallet now uses quote-safe escaping in those locations. Token icons are parsed with a DOM-based sanitizer and rendered through an isolated image element. Dataset definitions are accepted only from the account permitted to set them; missing or incorrect setters fail closed.

The node still accepts arbitrary bytes as a token name. The wallet fix prevents the current client from interpreting the reported payload as markup, but it does not prevent the value from being stored on-chain.

A token-name rule has been written and tested on the consensus branch. It will not become active until the next relaunch.

The wallet also has no Content-Security-Policy. Its single-file deployment keeps code inline, making a conventional script-src 'self' policy unusable without changing that deployment model. No CSP change is planned; the wallet currently relies on sanitizing data before it reaches rendering code.

Forum reports changed the tools

Cebo reported that zbc-cli liquid-payment-stop passed a transaction ID through std::stoll, silently truncating it. The report was marked high severity because the command controls funds.

The tools team made an initial fix. Cebo tested the public repository, found that the change was incomplete, and reported that result. A second change completed the fix on September 18.

The wallet received a separate fix for token transfers. After a successful transfer, the form had retained its values, allowing a second press of Confirm to send the same transfer again. Build 165 clears the fields after success.

Escrow handling also changed. A deadline in the past had silently become an escrow lasting 60 seconds; the wallet now rejects it and asks for a future date and time. Escrow screens now show the approver, deadline, commission and instruction before confirmation.

Other corrections included accepting the ZTX_ transaction identifier in node lookups, accepting dashed address spellings on account routes and clearing an escrow amount display that had shown the raw atomic value instead of formatted ZBC.

The published Python agent example had continued to sign with the old rule after chain-bound signing became required. Every transaction produced from that example was rejected. The example now includes the ZBC-TX signing tag.

The PIN counter was not the lock it appeared to be

Forum topic #239 showed that the wallet’s five-attempt PIN counter existed only in localStorage. A user could reset it by editing that value.

Build 167 mirrors the counter in IndexedDB and uses the higher value from the two stores.

That does not protect a copied vault from offline guessing. Anyone able to copy the wallet file can attack it outside the wallet, where neither browser counter applies.

The wallet now states that limitation during setup. It says that a six-digit PIN can stop someone observing a PIN entry, but that a copied wallet file protected only by that PIN can be cracked in under a minute. A passphrase of at least eight characters is the option presented for protecting a copied file.

PIN-only wallets remain supported, and no server-side lockout is planned because the vault is local and must work offline.

The faucet had two separate failures

After the relaunch, the faucet’s statistics endpoint appeared healthy while every claim returned HTTP 503. The gateway was still running an August signer that used the old transaction digest.

The faucet deployment now includes its signer, and the service was restored on September 16. The duration of that outage is unconfirmed.

A separate forum report described bypassing the faucet rate limit by spoofing X-Forwarded-For. Roberto said that bug was fixed and deployed. He attributed the faucet implementation to the same agent used for node development. The supplied material does not describe the deployed fix.

More tests are public, but some results remain open

The node test programme was published on the forum on September 18. Its topics cover escrow, multisig, payments, tokens, storage, applications, node operation and adversarial cases.

That testing has already left unresolved work.

Explorer pagination can duplicate or skip entries when block rewards are included in “All activity.” The report is open and has not yet been reproduced by the source author.

Gateway responses from /api/v1/node/info show peer_count as zero because the archival passthrough hard-codes the value. The nodes themselves report 10 peers. The gateway value remains unfixed.

Dataset values containing a zero byte are still truncated. javascript: URLs can still be stored in gateway, archival and relay registrations. Token mint modes 2 and 3 are accepted even though their behaviour is undefined.

Fixes for those cases, the token-name rule and the token-icon namespace are assigned to the next relaunch. No relaunch date has been set. The team groups consensus changes before restarting because past consensus data can otherwise become incompatible.

The manuals for the CLI, transactions, applications and wallet are in the repository, but zoobc.network/manuals/* still returns 404 and no published page links to them.

Participation widened before rewards were distributed

The first phase of the token pre-sale was limited to early adopters, friends and family and was not promoted publicly. Phase two is now open to everybody. The supplied material does not state its allocation terms.

The Foundation says it records completed bug-bounty reports and distributes the associated ZBC allocations at the end of each month. It previously processed rewards covering July and August and plans to process September reports at the end of September.

No September report, recipient or amount is confirmed as distributed in the supplied records. Allocated ZBC cannot be claimed until MainNet starts.

The Foundation is also building an allocation view for zoobc.foundation, including a way for a user to associate an account without publicly identifying themselves. That work is not yet reported as complete.

Kostason, a Foundation co-founder working on UI and UX, has been preparing pages for zoobc.com and zoobc.foundation.

Roberto reports that the forum chat is available through a blue button on zoobc.com, zoobc.foundation and zoobc.network. It requires a forum account and is not available until the account passes the forum’s spam checks. The deployment record still describes the gateway-wide chat widget as staged and awaiting publication, so those two records do not yet agree.

Work intended for MainNet is not finished

The Foundation is in discussions with two unnamed hardware-wallet companies. No memorandum of understanding has been signed, so the companies are not being named and no integration is confirmed.

It also intends to publish an open-source hardware-wallet blueprint that people could build or order. That blueprint has not shipped.

Three software-as-a-service applications are being considered for node-backed budget records. Some belong to Foundation participants and others are third-party applications. No completed integration or application name is confirmed in the supplied material.

The stated aim is to have applications and integration documentation ready before MainNet. Today, testnet resets still erase those applications’ chain history, and the remaining consensus changes require at least one more relaunch whose date has not been set.