Don't just watch the next decentralized ecosystem grow. Help build it.
ZooBC exposes the chain through gateways and APIs, while the Wallet demonstrates exchange, payments, applications, communication, storage, business tools, and infrastructure controls already built around it.
Why this symbol?
The beaver turns raw material into working environments. It represents developers and product teams who transform protocols into tools, bridges, applications, and places people can use.
Build against the protocol that exists, including its sharp edges.
ZooBC exposes a broad transaction and application surface, but integration starts with exact wire behavior: which service receives a request, which fields belong in the signed envelope, which amounts are atomic, how fees are calculated, and which result proves success.
Choose the correct service
Chain reads under /api/v1/ may be served from archival history. Transaction POSTs must reach a full node because they require a mempool. Some application-state routes are node endpoints rather than archival endpoints.
Model the signed envelope
Every transaction wraps a typed body in a common envelope. Recipient and memo may live in the envelope rather than the type body. Sign the complete unsigned envelope using the account type's required scheme.
Keep value exact
API amounts use atomic units: 1 ZBC equals 100,000,000 atomic units. Read current fee parameters or estimate the exact transaction instead of reproducing fee math from an old interface.
Verify the effect
A successful submission is not the end of the workflow. Retain the transaction identifier, find its inclusion, inspect resulting movements or state, and distinguish a node acceptance response from confirmed chain state.
Treat these as technical contracts.
Most integration failures come from violating a boundary that the user interface had hidden.
| Contract | Required behavior | Common failure |
|---|---|---|
| Read vs write routing | Use a readable chain endpoint for GETs and a full-node mempool route for transaction POSTs. | Broadcasting to archival history and interpreting its rejection as an invalid transaction. |
| Atomic amounts | Represent ZBC and token values as integer atomic units; apply token decimals only for display. | Sending a decimal display value as though it were the wire amount. |
| Fee calculation | Read /api/v1/fee-params or use the exact fee estimator for the serialized transaction. | Hard-coding a fee that no longer matches size, storage, duration, or network fee scale. |
| Envelope and body | Serialize the common envelope plus the exact little-endian typed body and optional modifiers. | Placing recipient, memo, token ID, or timing data in the wrong layer. |
| Key handling | Sign locally and keep private material out of URLs, logs, process listings, analytics, and servers. | Passing a private key as a visible command-line argument or remote form field. |
| State interpretation | Use transactions for signed actions and movements or application state for resulting protocol effects. | Assuming every reward, refund, vesting release, or app outcome is a new user transaction. |
Build one verifiable vertical slice first.
Before designing a large interface, make one read, one signed testnet action, and one confirmed result work end to end.
- 01
Prove the connection
Query blockchain status and retain the returned height. Confirm the target network and gateway behavior before creating accounts or requesting test coins.
- 02
Select one exact transaction type
Read its envelope, body layout, account type, fee behavior, modifiers, and result. Do not infer one transaction format from another merely because the interface looks similar.
- 03
Build and sign locally
Serialize integer atomic amounts, estimate the exact fee, and sign without exposing the private key to a server, log, URL, analytics event, or shell history.
- 04
Submit, confirm, and reconcile
Submit to a full node, retain the returned identifier, find inclusion through the Explorer or API, and inspect any resulting movements or application state before reporting success.
Do not move from testnet to value-bearing use while the integration can leak keys, confuse display units with atomic units, hard-code stale fee assumptions, submit to the wrong service, or report node acceptance as final confirmation.
Use the reference closest to the behavior.
The developer guide explains topology; API documentation describes routes; manuals document serialization and application rules; live tools let you test the complete path.
Gateway behavior, first routes, transaction submission, node targeting, operations, and downloads.
↗ROUTE REFERENCEAPI documentationMethods, paths, parameters, authentication, request bodies, and response examples.
↗WIRE FORMATTransaction manualEnvelope anatomy, signatures, atomic units, fee estimation, modifiers, and all transaction types.
↗COMMANDSCLI manualCommand behavior and supported transaction-building routes for testnet work.
↗APPLICATION RULESApps manualApp transaction bodies, registry, payouts, randomness, state channels, state routes, and verification.
↗TEST VALUEFaucetObtain valueless testnet ZBC for supported development and transaction testing.
↗Make failure explicit and keys boring.
A useful integration is precise about state and uninteresting to an attacker.
- Keep private signing material local and outside telemetry.
- Use integer atomic units throughout the data layer.
- Estimate fees from the live protocol surface.
- Retain transaction IDs and reconcile resulting movements.
- Show unavailable, pending, rejected, included, and confirmed states distinctly.
- Hard-code old fees, heights, node lists, or release hashes.
- Send writes to archival-only routes.
- Treat a 200 response as proof of confirmed state without reading its body and following the transaction.
- Invent undocumented transaction fields or application behavior.
- Put private keys in query strings, logs, screenshots, or support messages.
Does this sound like you?
For developers, application teams, protocol engineers, testers, and technical contributors.
You build applications, protocols, integrations, infrastructure, or developer tools.
You want to test emerging features, find bugs, or improve documentation.
You care about open systems, local signing, verifiable behavior, and user ownership.
You can turn technical capability into something other people can actually use.
Enter through a real door.
Each route below leads to an existing ZooBC page, tool, or current community destination.
Developer guide
Learn the gateway model, core routes, transaction submission, and operator boundaries.
↗REFERENCEAPI documentation
Inspect methods, paths, authentication requirements, request bodies, and examples.
↗SOURCE BEHAVIORTransaction manuals
Understand transaction types, wallet behavior, applications, and CLI commands.
↗Follow the evidence.
Use the source that matches the question instead of relying on a single marketing page.
From interest to participation.
- 01Read the technical model
- 02Use the APIs and testnet tools
- 03Bring a build, bug report, test, or technical proposal
Don't just watch the next decentralized ecosystem grow. Help build it.
ZooBC exposes the chain through gateways and APIs, while the Wallet demonstrates exchange, payments, applications, communication, storage, business tools, and infrastructure controls already built around it.