Additional languages will be enabled after the site is complete.
A distributed mesh of varied luminous ZooBC network nodes converges toward a user-controlled assembly point

ZOOBC / POST-MAINNET PROTOCOL DIRECTION

The internet used to work like this. AI should too.

Email began as independently run servers speaking directly to each other. AI is consolidating in the opposite direction. ZooBC is exploring a network where independent specialist systems can contribute to an answer without one provider owning the entire interaction.

STATUSThis is a protocol direction, not a live AI service today.

Explore the direction See what works today

THE DIRECTION / MANY OPERATORS

Intelligence nobody owns alone.

The goal is not to scatter one company's model across cheaper machines. It is to coordinate genuinely independent systems that can specialize, disagree, prove what they contributed, and be paid without handing one operator control of the whole exchange.

ZooBC can supply accounts, signed records, settlement, and an auditable coordination layer. Distributed inference, routing, quality evaluation, and private task decomposition remain protocol work.

INDEPENDENT EXPERTSUSER-CONTROLLED ASSEMBLY

01 / INDEPENDENT SPECIALISTS

Not one model split into pieces. Many real experts working together.

The protocol direction is a network of independently operated systems with different models, training, tools, and specialties. Relevant nodes could contribute their own work, while an evaluation layer compares and combines useful results. The hard part is proving quality and resisting coordinated bad answers. That mechanism still has to be specified and tested.

Continue
MEDLAWCODEDATA
DISTINCT SYSTEMS / SHARED TASK

02 / NO SINGLE GATEKEEPER

No single company should decide what every AI can say.

Independent operators can reduce the power of any one model provider to control access, policy, and tone. Decentralization does not mean a rule-free system. Applications still choose what they request and display, and a protocol still needs defenses against abuse. The difference is that one corporate policy is not the only possible upstream answer.

Continue
ABCDE
NO PRIVILEGED CENTER

03 / LIMITED DISCLOSURE

Design the route so no operator needs the whole picture.

A future client could decompose work and send only the context each specialist needs. That could reduce what any one operator learns, but it is not a privacy guarantee by itself. Metadata, task correlation, malicious routing, and colluding nodes all matter. Privacy has to be measured against a published threat model, not assumed from the word decentralized.

Continue
01020304
PARTIAL CONTEXT / EXPLICIT THREAT MODEL

04 / USER-SIDE ASSEMBLY

The final assembly should happen on your side.

The proposed flow brings evaluated contributions back to software the user controls. That final layer could choose the tone, include or reject sources, and preserve local preferences before presenting an answer. This requires open client software and clear provenance so the user can see what was combined and which choices were applied.

Continue
ABC
CONTRIBUTIONS / LOCAL POLICY / FINAL ANSWER

05 / INTELLIGENCE ECONOMY

Let useful specialist systems earn for useful work.

ZooBC already provides signed accounts, tokens, transfers, escrow, multisignature approval, and public transaction records. Those are settlement ingredients for a future expert market. The marketplace itself still needs discovery, pricing, quality measurement, dispute rules, and resistance to operators rewarding themselves.

Continue
WORKVERIFYSETTLE
CONTRIBUTION / EVALUATION / PAYMENT

06 / GRACEFUL DEGRADATION

Build a network that can route around failure.

A diverse peer network can be designed to keep working when individual nodes disappear. That outcome depends on enough independent operators, replicated capabilities, reliable discovery, and routing that can recognize failure. Resilience is an architectural target to test, not a promise that every request will always succeed.

Continue
LIVEOFFLIVELIVEOFFLIVE
FAILED PEERS / ALTERNATE PATHS

PROPOSED PROTOCOL FLOW

From one request to many contributions and back.

This is the intended architecture to research and test. It is not an available ZooBC endpoint or node workflow today.

  1. 01

    Decompose locally

    Client software separates a request into bounded tasks and decides what context each task requires.

  2. 02

    Find specialists

    Open discovery and routing identify independent systems suited to each part of the request.

  3. 03

    Evaluate contributions

    The protocol or application compares provenance, quality signals, conflicts, and the cost of each result.

  4. 04

    Assemble for the user

    The client combines accepted contributions under the user's own tone, policy, and disclosure settings.

THE HONEST BOUNDARY

What exists today, and what still has to be built.

LIVE FOUNDATION

ZooBC testnet and agent transaction controls.

  • Signed accounts and transactions
  • Tokens, transfers, escrow, and multisig
  • Public account and transaction history
  • Agent guide and working Python reference
Explore AI Agents
POST-MAINNET DIRECTION

Decentralized AI coordination.

  • Specialist discovery and request routing
  • Quality evaluation and aggregation
  • Privacy threat model and task decomposition
  • Open node market and failure recovery
Read the roadmap

BUILT FOR AFTER MAINNET

Help turn the direction into a protocol.

Start with what ZooBC can prove today. Then follow the roadmap, challenge the assumptions, and join the work needed to make independent AI coordination real.

Read the current foundation Join early