ZOO

Open intelligence, built together

Private money. Open models. Shared computing. Chain data you can ask.

ZOO AI · Public draft v0.2 · 27 September 2026

This paper describes ZOO's vision, available services and proposed development path. The Gateway is available in beta. Wallet, model, index and token capabilities have separate delivery milestones. No token sale is open on this page; the token network and participation terms are not final.

Abstract

Access to capable artificial intelligence is becoming part of the infrastructure of everyday life. People use it to learn, build software, understand information and produce work. ZOO's founding belief is that people should be able to participate in that infrastructure: run useful models themselves, understand the systems they rely on, and combine resources to use machines that would be impractical to buy alone.

ZOO is building a community-funded path to that independence. The goal is to make useful open models runnable on personal devices and larger workloads accessible through a shared fleet. In the proposed service, access is allocated against measured capacity and a published operating budget. Private payment and clear data-handling boundaries make it possible to use the service without routinely attaching a personal payment identity to each interaction. The long-term aim is affordable, durable participation in the AI economy.

The first planned chain-data application connects AI models to ZOO's blockchain indexers. It can begin with supported hosted models, before ZOO releases its own models. A person asks a question in ordinary language; the system queries supported chain data, performs exact calculations and returns an explanation with the underlying evidence. Developers can use the same data through documented tools and APIs. ZOO aims to make on-chain information easier to understand and less costly to access, while making coverage, freshness and limitations visible.

The ecosystem connects four practical capabilities: a wallet for shielded money, a gateway for model choice, open models that users can run or access through shared infrastructure, and an index that turns public chain records into usable answers. The long-term aim is to reduce dependence on proprietary credit systems for every task by making useful AI runnable, portable and affordable through shared resources. The proposed ZOO token coordinates a bounded share of network services and future contributor incentives. Funding the fleet and sustaining it are separate obligations: the initial capital can buy machines, while recurring service income and explicit reserves must support their operation and replacement.

The measure of success is useful work people can reliably do with resources they helped make possible. ZOO intends to turn community alignment into working models, maintained indexes, affordable access and increasing user control.

1. The founding vision

1.1 AI as a capability people can keep

ZOO begins with a belief about the future: local AI will become an important part of how people use computing. An available model, suitable hardware and usable software can give a person continuing capability without requiring every interaction to pass through one remote service. Open artifacts also let developers inspect behavior, build alternatives and adapt systems to their own needs, subject to their licenses.

The aim is agency. A student should be able to learn with a useful model. A developer should be able to keep building when a provider changes a product. A researcher should be able to inspect the evidence behind an answer. A community should be able to fund infrastructure that serves its priorities and understand what it costs to keep it running.

Local execution has limits. Personal devices vary in memory, speed and power. Large models and sustained workloads can exceed an individual's budget. ZOO connects local capability with access to larger shared resources so that personal control and ambitious workloads can develop together.

1.2 Pooling resources expands participation

Many people cannot justify a large GPU purchase for their own intermittent use. A group can combine demand, capital and technical work to make a shared service practical. Whether that service is cheaper depends on utilization, hardware choice, power, support and the cost of maintaining a reliable product. ZOO will measure those factors rather than assume sharing always wins.

The proposed model gives participants a continuing, metered share of ZOO-operated capacity while they meet the published access conditions. The access token is not consumed by each included request. The machines still consume electricity, age and require maintenance. Those costs must be funded transparently.

This is the economic alignment ZOO seeks: members benefit when the community delivers more reliable useful capacity at lower sustainable cost. Contributions to models, indexing, infrastructure and software can increase what the shared system accomplishes. Growth is valuable when it improves service and resilience, rather than merely increasing the number of people competing for a fixed allowance.

1.3 Crypto is the starting community

Crypto users provide a natural first audience. They already work with keys, private payments, open software and public ledgers. They also need better ways to understand on-chain activity and build applications from it.

The broader product remains useful for writing, coding, learning, research and everyday analysis. A user should be able to start with an ordinary question, then discover chain-data tools when relevant. The wallet, model and index have practical roles independent of speculation about the token. A developer should be able to evaluate the API before considering long-term participation; a downloaded open model remains useful outside the hosted service under its license.

ZOO's ambition is to make capable AI accessible to a wider community of users and contributors. Crypto provides the initial tools and audience for coordinating that effort.

1.4 Keeping the freedom to build

Independent developers can build valuable workflows around a monthly AI allowance. If that allowance tightens or more work moves to usage-based billing, long agent runs, repeated experiments and large contexts can become difficult to afford. ZOO's thesis is that people need practical alternatives before the economics of a service dictate what they can build.

This is a scenario to prepare for, not a prediction that subscriptions will disappear. Bundled allowances and metered extras already coexist, as illustrated by documented usage-credit options; competition, efficient models and added capacity can also improve access. ZOO must earn its place through useful quality and sustainable total cost, regardless of how other providers price their services.

Local AI offers continuing capability, but moving inference onto personal hardware shifts costs rather than removing them. Not everyone can afford the GPU memory, electricity or maintenance required for demanding workloads. ZOO proposes to bridge that gap with usable local releases and shared machines funded by a community. Participants could combine resources to access capable models and maintained indexes under transparent capacity rules.

The ambition is durable freedom to build: run what fits locally, share the resources that are too costly individually, and keep a practical choice over where intelligence runs.

2. One ecosystem, connected by use

The gateway is the entrance for people who want immediate model choice. The wallet provides a private payment route. ZOO-operated models and indexes supply distinctive services the community can help fund and improve. The token connects participation to those services where its finalized design supports that role.

2.1 Existing gateway boundaries

The Gateway offers a passkey with a separate recovery backup or an independent access-key account, with no email or name sign-up. Existing key accounts can add a passkey while retaining their credit, points and receiving address. Gateway passkey recovery replaces passkeys and browser sessions but leaves existing API keys valid. A financial and usage ledger and account-security records exist even though the gateway keeps no prompts, answers or IP log. Chat history remains in the browser, encrypted at rest; clearing site data erases it unless the user has kept a separate chat backup. Shared sign-in across ZOO products remains in development; wallet custody and mailbox encryption retain separate recovery boundaries.

The live payment route accepts shielded ZEC. The private-pool route for other assets remains testnet-only pending audit. Existing model credit is prepaid usage and is not refundable or withdrawable. Credit, points, any future sale allocation and staked access must remain distinct in both the interface and the records.

Each ZEC paid for model credit earns 100,000 ZOO points. Points have no cash value and promise no token, allocation or return. Model credit, points and the proposed token serve different purposes; earning points does not establish a token entitlement. See the token overview.

ZOO Wallet’s Chrome extension is under review in the Chrome Web Store. An approved listing and verified installation link will be published when available. Until then, another compatible shielded Zcash wallet can fund Gateway credit.

3. Three ways to use intelligence

3.1 On your device

ZOO intends to publish usable packages for running selected open models locally, with clear hardware requirements, model provenance and setup instructions. Small models should handle useful work on accessible devices. Higher-capability models may require more powerful personal hardware.

For a genuinely offline task, model inputs need not leave the device. A request for current chain data, remote inference or web search introduces an external connection and should say so. Device security, application telemetry and backups still matter. “Local” describes where inference runs, not an unconditional security guarantee.

Downloadable weights alone are insufficient for broad access. Documentation, supported runtimes, evaluation results and a usable interface are part of the product. Model choices will follow evaluations of useful tasks, hardware requirements and release licenses.

3.2 On ZOO's shared fleet

The proposed shared fleet would run larger models on infrastructure operated by ZOO, initially using a single accountable operator. A participant's included allowance is backed by measured serving capacity and a funded service budget. It renews under published rules while the participant is eligible. It is subject to model availability, workload weights and rate limits.

Shared remote inference is different from inference on the user's own device. The ZOO serving process receives the prompt in plaintext, and administrators, software and hosting infrastructure remain trust boundaries. Owning the server improves operational control but does not automatically remove those boundaries.

The objective is a dependable community resource: enough headroom to respond well, clear service conditions, recoverable failures, and transparent funding for maintenance and replacement.

3.3 Through other providers

External models remain available through ordinary prepaid credit where supported. They give users choice and allow the gateway to serve needs that the ZOO fleet does not yet cover. Staked access to ZOO resources does not automatically pay an outside provider's invoice.

The interface must identify the actual host and route. Moving between local execution, ZOO-hosted inference and another provider should be an explicit choice. An included allowance running out must not silently trigger paid external-model use.

4. An answer interface to on-chain data

4.1 Ask the chain

Ask the Chain is the planned answer and search interface for supported on-chain information. ZOO Index supplies records to a tool-capable model; the first integration can use an existing hosted model. ZOO-operated and adapted models can follow without replacing the underlying query service. The user expresses an intent in ordinary language. The model selects a supported query, the index retrieves the records, deterministic code performs any calculations, and the model explains the result.

For example:

• “Explain this transaction and show the fees.”
• “What were the largest transfers of this token in the indexed period?”
• “Compare activity across these contracts over the last seven supported days.”
• “Give me the exact records behind that answer as JSON.”

These are target capabilities, not a statement that every chain or query type is already supported. Results must identify the dataset and supported interval. If the relevant data is missing, stale or outside coverage, the system should say so.

The user experience should make verification easy. An answer carries a source card with the chain, block height or range, transaction references where applicable, index freshness and relevant finality assumptions. The underlying table or machine-readable result is available alongside the explanation. A fluent answer without a valid source is not a successful chain-data query.

4.2 A query engine with language at the front

The proposed zoo.chain.query interface describes bounded operations across supported chain adapters. The model selects tools and arguments; it does not receive unrestricted database access. Query validation, parameterization, time limits, row limits and exact numeric handling protect correctness and service cost. Retrieved contract text and token metadata are data, not instructions to the model.

Indexers handle ingestion, indexing, reorgs and supported historical coverage. Model inference handles interpretation and explanation. Fine-tuning can improve tool use and domain understanding, but live balances, recent events and exact totals come from queries rather than model memory.

This separation lets users change models without replacing the underlying data service. It also gives developers direct API access when they already know the query and do not need a language model.

4.3 Competing on access, clarity and cost

ZOO aims to make reliable blockchain data easier to use and more affordable to access. The opportunity is to combine maintained indexes, predictable metering and language-based discovery so that users need less integration work to obtain a useful answer.

Public blockchain data is open, but reliable ingestion, storage, historical queries and support have real costs. ZOO's case must be demonstrated through comparable workloads: query coverage, freshness, reliability, latency and the total cost of obtaining the same result. Lower prices and easier access are goals to prove, not assumptions established by a token or a model release.

The initial focus is Zcash public data and Robinhood Chain. Ethereum and Solana are planned additions, with availability dependent on verified coverage. Each adapter requires its own coverage and correctness work. An EVM-compatible interface reduces some implementation work; it does not automatically supply complete indexes for every EVM chain.

4.4 Respecting shielded data

A public Zcash index can expose supported public metadata, transparent activity and available aggregate information. It cannot reveal encrypted shielded note contents simply by indexing the chain. Private wallet analysis would require a separate user-authorized flow and a defined disclosure boundary. An AI interface does not bypass that protection. Zcash address and shielded-transaction documentation

5. From serving open models to releasing ZOO models

The model program spans four areas of work within the six-stage roadmap in section 10:

The early technical focus is useful integration, trustworthy data and a good service. Training a frontier model from scratch is not a prerequisite. Larger training programs require a separate research plan, budget and evaluation target.

“Open weights” means model parameters are available under specified terms. “Open source” is a claim about the released software or model artifact and its actual license. Each planned ZOO release will identify its license and upstream dependencies rather than treating those phrases as interchangeable. Some releases may be adaptations of third-party models; their origin remains visible.

Production prompts and answers are not a training corpus. The proposed adaptation program uses appropriately licensed public data, synthetic tasks and purpose-built evaluation sets. Any future opt-in contributed dataset needs a separate, explicit collection process. It must not be obtained by quietly changing the gateway's retention policy. Operational metering can inform resource allocation without storing conversation content or profiling what individual users ask.

Model upgrades should follow tests of quality, cost, compatibility and privacy. A newly released model is not automatically better for ZOO's actual users. Release notes will identify the selected checkpoint and material behavior changes.

6. A community that builds and benefits together

6.1 Participation beyond holding

A durable community needs useful roles. Participants can help by maintaining tools, adding documented index coverage, improving model evaluations, writing local deployment guides, reproducing bugs or operating reliable infrastructure once independent operators are supported.

The proposed contribution program ties rewards to verifiable work and funded budgets. A query counter alone is not proof of useful service; self-generated traffic does not demonstrate productive contribution. Independent compute providers will require published performance requirements, privacy obligations, verification and a process for handling poor service. Independent operation remains a future capability with its own delivery requirements.

Members share a reason to improve service because better models, coverage and reliability improve the capacity they can actually use. Product releases and operating reports are intended to make those gains visible.

6.2 Accountability before decentralization

ZOO AI is the project and operating identity. The gateway, index and proposed first fleet are centrally operated. Token holders do not automatically acquire legal ownership of machines, equity in an operating entity or a right to treasury distributions. Any such rights require an explicit, separately established structure.

The initial accountability proposal is concrete: publish who controls deployment and treasury decisions, disclose administrator and contract-upgrade powers, separate operating funds from other balances, report service capacity and funded runway, and document incidents. Community input can guide model selection, chain priorities and contributor work while the operator remains responsible for delivering the service.

Later governance may give participants defined decisions over budgets or protocol parameters. Its scope, voting rules, concentration controls, emergency powers and implementation must be specified before governance rights are marketed. Operational facts should remain inspectable even when decisions are not yet decentralized.

6.3 Independence should be practical

Open interfaces, downloadable releases and portable user data reduce dependency on ZOO as well as on external providers. Users should be able to keep their backups, run released models independently where hardware permits, and build clients against documented tools. The long-term goal is an ecosystem that other people can maintain and extend.

These capabilities turn the broad idea of securing a place in the AI economy into practical options: continuing access to useful software, a transparent share of shared resources and a path to contribute to the infrastructure itself.

7. Sustainable access and the proposed ZOO token

7.1 What staking would activate

The proposed role of ZOO is to allocate access to ZOO-operated compute and indexed-data services. Eligible staked balances receive a proportional daily allowance under published rules, without spending the staked token on each included request. The service is funded by capital, recurring revenue and reserves; staking is the allocation mechanism.

Compute and index work use separate, non-transferable allowance counters in the proposed access design. Model calls with retrieval can consume both. Different models, context lengths, generated tokens and query classes have different costs. The exact schedule must come from measured service economics.

For an eligible account stake s, total eligible stake S, and published daily budgets C and Q:

compute allowance = C × s / S
index allowance   = Q × s / S

When S is zero, no stake-based allowances are assigned. If eligible stake rises while capacity stays constant, each existing stake's share falls. If measured funded capacity grows, the pool can grow. A token's market price does not directly determine inference throughput.

The proposed service separates a funded allowance from best-effort use of idle capacity, with refresh timing, model availability and congestion visible before work begins. The proposal does not assume that unused daily allowances accumulate indefinitely. Refresh, eligibility, unbonding and allocation-change rules remain terms to finalize.

7.2 Service quality is part of the entitlement

A large nominal token allowance is not useful if every request waits in a long queue. Capacity planning must include concurrent streams, response speed, input processing, reasoning output, retrieval load and failure headroom. The service should grow ahead of committed demand where procurement lead times require it.

A published allowance needs testing against its workload and stated service objectives. A fixed daily promise to every eligible member needs an all-active capacity test; expected average activity alone is insufficient. Optional idle-capacity access can make the ordinary experience more generous, with its best-effort status clearly shown. Serving benchmarks can measure latency and successful work within those objectives. Benchmark methodology reference

The proposed access model has no unlimited tier. Dedicated capacity requires an actual reservation and separate economics. Gateway fee discounts, if adopted, apply to ZOO's own service fee; outside provider charges still need funding.

7.3 A Zcash-native asset route

ZOO is evaluating a native shielded-asset route for its proposed token. The research includes Zcash Shielded Assets (ZSA), described in ZIP 226: Transfer and Burn and ZIP 227: Issuance. These proposals provide a technical direction to evaluate; they do not establish that ZOO has a deployed asset or a selected network.

Adoption depends on protocol availability, compatible wallets, a reviewed implementation and workable issuance, staking and recovery flows. The token network is not selected. This research does not imply endorsement by the Zcash ecosystem or announce a ZOO asset launch. Shielded ZEC payments in the Gateway are available independently of that decision.

7.4 Participation terms

Final supply, allocations, vesting, staking eligibility, exit rules and service conditions remain to be defined. They will be published together with the selected network and asset identifier before participation opens. This paper does not publish an offering schedule or establish a distribution or buyback commitment. Existing points carry no promise of a token allocation.

The token overview describes the proposed access model. The Fund milestone identifies the work required before a sale can open.

8. Financing the shared infrastructure

8.1 Capital buys a beginning; operations sustain it

Initial capital could fund model serving, indexing, software, hardware and an operating reserve. Hardware needs replacement. Models need ongoing evaluation. Indexes need storage, ingestion and maintenance. Buying equipment does not prepay those obligations forever.

The proposed operating model therefore separates four budgets: current service operation, hardware replacement, protected contingency and discretionary expansion. Customer prepaid balances also create service obligations and should be accounted for separately. Treasury tokens and uncollected sales are not cash available to pay suppliers.

Potential recurring funding includes paid index/API services, reserved throughput, paid burst capacity and gateway fee contribution after external provider costs. These are proposed revenue sources, not booked income. The objective is for useful services to support continuing access without making the business dependent on perpetual new token sales or token-price appreciation.

8.2 Prove the experience before scaling the fleet

The first proof can be small: one hosted model, one supported chain, a bounded real-data index and a handful of useful questions answered with evidence. This tests the query experience before ZOO operates its own model. A subsequent ZOO-hosted pilot can measure the costs and service quality of shared inference.

Rented GPUs allow model and demand testing without committing the whole treasury. Owned machines become attractive when measured use, control requirements and total cost justify them. The first owned fleet can operate in an established colocation facility. A separately fitted-out data center becomes an option only when site costs, utilization, power and operational capability support it.

Fleet size and facility decisions will follow measured workloads, vendor quotations and a funded operating plan. A larger budget is useful only when it produces dependable capacity for the people using the service. No raise target, hardware purchase commitment or member-capacity promise is established here.

8.3 Funding tied to a deliverable service plan

No token sale is open on this page. Before any sale opens, ZOO intends to publish what funds will buy, which services already work, which capabilities remain planned and the conditions for delivery. Final terms must cover eligibility, custody, allocation, vesting, recovery and what happens if funding or delivery conditions are not met.

A larger raise does not automatically create a better member experience. Service obligations can grow faster than capacity, so accepted funding and promised access need a matched deployment and operating plan. Pricing, contribution thresholds, caps and allocation mechanisms are not set by this whitepaper.

Model credit is prepaid usage and is not refundable or withdrawable. That existing policy is separate from any future token-sale payment, claim or recovery rules. A sale requires its own published terms and tested implementation.

US access remains excluded at launch. Other eligibility rules require final terms. Shielded payment and key-based access do not remove those conditions.

9. Privacy with specific boundaries

Private payment and private inference are different parts of the experience. The following boundaries explain where information is processed and what users can expect.

Each model displays its host and one of the applicable route labels:

• “Direct to the model provider, identity stripped”
• “No-retention providers only, identity stripped”

The first label does not imply the second. Nor does either label mean that a user cannot put identifying information inside a prompt. Requests involving private data need clear routing choices.

The proposed ZOO-hosted no-content-retention design covers request middleware, proxy logs, tracing, crash dumps and backups, as well as the main application. Its operational reporting would use necessary non-content counters and appropriately aggregated statistics. Exact ledger fields, retention periods and any separate sale-verification records require a published data map consistent with the implemented service.

Token claims, staking and any later eligibility checks can introduce new identifiers. Their collection and linkability must be disclosed before those features ship. Any public claim mechanism needs a reviewed design that avoids exposing authentication-derived identifiers and minimizes retained data. ZOO Wallet is being developed for shielded Zcash. Support for a future ZOO token will depend on the selected network and a separately verified integration.

10. A roadmap driven by evidence

Today → Connect → Measure → Fund → Release → Expand

These are the same six stages shown on the roadmap. Progress depends on delivery gates, not promised dates.

ZOO Wallet’s Chrome extension is under review in the Chrome Web Store. Release depends on review and verified availability. Native shielded-asset research and the testnet-only private-pool payment route have their own dependencies; neither is made live by advancing an unrelated milestone.

Independent work can overlap. An owned fleet, a dedicated facility or a larger research program depends on demand, power, economics, operating capability and reserves. The long-term direction is more user control, useful open releases, verifiable data access and dependable shared resources.

11. How progress will be measured

The proposed reporting framework connects the vision to member experience:

• Useful access: task success, response latency, availability and the experience under peak load.
• Verifiable data: supported chains/query classes, freshness, exact-result correctness and reproducible source records.
• Sustainable affordability: full cost per defined workload, paid service contribution, funded months of operation and replacement reserves.
• User control: downloadable releases, documented interfaces, usable backups and clarity about where a request runs.
• Community contribution: accepted maintained work and reliable delivered service, with reward budgets and evaluation methods disclosed.
• Accountability: treasury use, hardware commitments, administrative powers, incidents and material changes to allocation rules.

Reports can use privacy-preserving aggregate measures. They should not require collecting production conversation content. A growing token-holder count alone does not establish progress on these measures.

12. Limitations and unresolved decisions

This is a development proposal. The token, ZOO-operated serving program, full index coverage and community-operator network should not be treated as live because they are described here. Funding may be insufficient, demand may be different from assumptions, and execution may fail.

Capacity and quality depend on the selected models, contexts and hardware. Equipment depreciates and can fail. Shared service involves an operator and infrastructure dependencies. Licenses, data rights and upstream software can constrain particular releases. Claims about comparative cost require comparable measurements.

The sale and token require final decisions on network, contract design, supply controls, allocations and vesting, eligibility, custody, claim recovery, failure handling and applicable requirements. A live utility does not by itself resolve those questions. Token holdings do not guarantee market value, liquidity, distributions, perpetual service or legal ownership of company assets.

Points have no cash value and promise no token, allocation or return. Users are responsible for saving their account key and browser-history backup; recovery limits are described in the docs. Separate risks apply to any future staking or token custody arrangement and must be described when the implementation is chosen.

The purpose of these boundaries is to make the vision buildable: state what exists, fund what is promised, measure what is delivered, and give the community a clear account of what remains to be done.

13. Project identity

ZOO AI is the project and operating identity. This whitepaper describes the product vision and proposed service model. Final commercial terms will identify the contracting party, contact details and applicable conditions.

ZOO Gateway accepts Zcash and is not affiliated with or endorsed by Zooko Wilcox, the Electric Coin Company or the Zcash Foundation. Zcash is a trademark of the Zcash Foundation. Support for a named chain or model does not imply affiliation with its developer or operator.

Further reading

• Gateway and developer docs: account keys, model credit, routes and privacy boundaries.
• The ecosystem: the Gateway, Wallet, Model, Index and proposed token.
• The token overview: stake-based access and the distinction between credit, points and tokens.
• The roadmap: six delivery stages and the evidence required at each gate.

Technical references are linked where relevant. They describe external specifications and methods, not endorsements of ZOO or guarantees of future delivery.