작업 진행 중

이 사이트는 아직 제작 중입니다

재단은 공개적으로 만들어지고 있습니다. 이곳에서 보시는 내용은 현재 시점에서 정직한 것이지만 완성된 것은 아닙니다 — 최종 선언이 아니라 오늘 저희가 서 있는 지점으로 읽어주세요.

메인넷 출시 전까지 문구, 구조, 이미지, 수치가 바뀔 수 있습니다. 일부 페이지는 임시 자리표시자입니다. 사진이 인물을 대신하는 경우, 이는 스톡 이미지이며 실제로 언급된 인물이 아닙니다.

더 넓은 ZooBC 생태계는 단계적으로 등장합니다. 지갑, 탐색기, 커뮤니티 포럼, 소셜 채널은 메인넷이 다가옴에 따라 하나씩 온라인에 공개되며, 이 사이트도 그와 함께 성장합니다.

내용이 이상하게 읽히거나, 깨져 보이거나, 오해의 소지가 있다면 알려주세요. 지금의 피드백이 나중에 다듬어진 출시보다 저희에게 더 가치 있습니다.

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.

Roberto Capodieci 작성 · 게시

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.

소셜 미디어 고지

최종 업데이트: 2026년 9월 29일

이 페이지는 번역본입니다. 영문판과 차이가 있을 경우 영문판이 우선합니다.

본 면책 조항은 zoobc.com, zoobc.pro, zoobc.net, zoobc.network, socialconnect.network, proofofparticipation.network, zoobc.foundation와 관련된 콘텐츠를 포함하여, ZooBC Foundation이 게시하거나 그 이름으로 게시된 모든 게시물 및 소셜 미디어 콘텐츠에 적용됩니다.

1. 일반 정보

모든 게시물 및 소셜 미디어 콘텐츠(“콘텐츠”)는 오락 및 정보 제공 목적으로만 제공되며, ZooBC 또는 ZooBC의 직원, 기여자, 계약자의 견해를 반드시 대변하는 것은 아닙니다. 콘텐츠에는 오류가 없다고 할 수 없으며 부정확한 정보가 포함될 수 있습니다. ZooBC로부터 얻은 구두 또는 서면의 조언이나 정보는 본 문서에 명시적으로 기재되지 않은 어떠한 보증이나 진술도 발생시키지 않습니다.

법률, 투자, 금융, 세무 등 어떠한 종류의 조언을 위해서도 콘텐츠에 의존해서는 안 되며, 콘텐츠는 자격을 갖춘 전문가의 조언을 대체하지 않습니다.

모든 콘텐츠는 증권, 토큰 또는 디지털 자산의 판매 제안이나 매수 권유를 구성하지 않으며, 투자 활동이나 이와 유사한 행위에 대한 초대나 유인으로 해석될 수 있는 공모, 광고, 권유, 확인, 진술 또는 금융 홍보가 아닙니다.

오해의 소지를 없애기 위해 밝히자면, 콘텐츠는 투자 자문가가 제공하는 것이 아니며 ZooBC의 투자 자문 서비스가 아닙니다. ZooBC 및 ZooBC 관련 소셜 미디어 계정의 재게시, 리트윗, 팔로우, 좋아요는 ZooBC가 특정 아이디어, 개인, 단체, 기관을 지지한다는 의미가 아닙니다.

2. 연락처 정보

본 웹사이트나 이 면책 조항에 대해 궁금한 점이 있으시면 info@zoobc.foundation으로 문의해 주세요.