Next-generation privacy L1

The chain is a control plane,
not a compute plane.

zase is a Rust BFT layer-1 that coordinates a private, open compute market — registration, matching, escrow, settlement, SLA, commitment anchoring — while the real computation runs off-chain with payloads encrypted end to end. Payments are shielded: amounts hidden, recipients hidden, memos encrypted.

block height
transparent supply
shielded pool
system contracts
The thesis

Separate coordination from computation

Most chains try to run computation on-chain and pay for it with global replication. zase splits the problem into three planes. The chain stores only what must be trust-minimized — commitment hashes, bids, stake, reputation, escrow — and pushes the heavy, private work off-chain where it belongs.

      clients / wallets                         provider daemons × N
           │   E2E-encrypted payload (transport plane)   │
           │   ┌──────────── blob (ciphertext) ──────────┤
           ▼   ▼                                          ▼
   ┌──────────────────────────────────────────────────────────────┐
   │  CONTROL PLANE — zase L1  (BFT, 2f+1 deterministic finality) │
   │    actor kernel  ·  WASM / wasmtime / fuel-metered             │
   │    system contracts: registry · market · escrow · settlement  │
   │    shielded pool: Pedersen + Bulletproofs + encrypted memo     │
   │    on-chain: commitment hashes, bids, stake, reputation only   │
   └──────────────────────────────────────────────────────────────┘
What's inside

One chain, a full market stack

Each capability is a real, exercised subsystem in the workspace — not a roadmap promise. See the whitepaper for the honest boundaries of each.

◈ shielded

Shielded payments

Pedersen-committed amounts with Bulletproofs range proofs, hidden recipients, and a 512-byte encrypted memo per transfer. Real cryptography, today.

zk-shielded · zk-crypto
⊞ market

Open compute market

Permissionless providers stake, build reputation, and bid on jobs. A verification ladder — redundant execution, optimistic challenge, commit-reveal — keeps results honest.

market · zk-verify
✓ verify

Verifiable compute

Computing is expensive; verifying can be cheap. zase is building a certificate market where a result ships with a succinct proof of correctness — starting with LP-duality certificates.

idea-A
⇌ exchange

On-chain exchange

A single contract hosting a multi-asset central-limit order book and an AMM — issue tokens, make markets, place limit orders, or swap against pools.

exchange (CLOB + AMM)
⏱ lease

Compute leases

Reserve capacity with streaming, pay-as-you-go billing metered in compute units, with heartbeats and SLA enforcement — for workloads that outlive a single job.

lease
⊘ mesh

GPA-resistant mesh

A private control mesh for self-hosted infrastructure: bLSAG linkable ring signatures hide the command initiator; the data plane is compartmentalized. Metadata anonymity targets a Nym boundary.

zk-ring · zk-control
⬡ kernel

Actor kernel

Contracts are deterministic WASM actors on wasmtime with fuel metering, storage deposits, timers, cross-contract reply, and in-place migration.

zk-kernel · zk-sdk
⛬ consensus

BFT consensus

Tendermint-style Byzantine fault tolerance with 2f+1 quorums and deterministic finality, over an actor-model ledger with reproducible state roots.

zk-consensus · zk-ledger
Lifecycle of a job

How a computation flows through zase

The payload is encrypted to the chosen provider(s) the whole way; the chain only ever sees commitments and escrow state.

Post

A client posts a job: an encrypted WASM payload, a price, and a redundancy factor (e.g. redundant:2). Only a blake3 commitment of the ciphertext lands on-chain.

Bid & match

Registered providers bid; the client accepts bids. Stake is escrowed and an SLA clock starts. The payload blob is relayed to the matched providers.

Execute off-chain

Each provider decrypts the payload and runs it in a deterministic sandbox, then submits a commitment to its result. Redundant providers must agree.

Verify & settle

Matching commitments release escrow; divergence or SLA timeout triggers slashing. The client fetches the result, decrypts it, and checks it against the on-chain commitment.

Try it

Up and running in minutes

Build the workspace, spin a local devnet, and walk the full job lifecycle with the one-shot demo — or point a wallet at the live network. Full steps in the getting-started guide.

Getting started → RPC reference →
# build everything (Rust workspace)
cargo build --workspace

# end-to-end acceptance demo: spins a 4-validator
# devnet, runs a job, shields a payment, verifies
./scripts/demo.sh

# …or just read the live chain
curl https://rpc.zase.io/status
Stewardship

Built in the open by the zase Foundation

zase is stewarded by the zase Foundation, a non-profit dedicated to public-good privacy infrastructure. No token sale and no pre-mine pitch — the Foundation funds protocol research, security audits, and open-source development, and progressively hands governance to the community as the network matures. ZASE, the native unit, exists to meter fees, escrow, and staking — it is not a speculative product.

Read the whitepaper →
◇ open

Open by default

Apache-2.0, public specifications, reproducible builds. Every doc on this site is generated from the source of truth and renders straight from the repository.

⚖ neutral

Credibly neutral

A non-profit steward, not a company. The protocol answers to its users and validators — not to a cap table or an exit.

⊚ honest

Honest about its limits

This is an unaudited proof of concept, and we state plainly where the cryptography is real and where it is still Phase 2.

Honest status. zase is a proof-of-concept and is not audited — do not use it to secure real value. The cryptography that hides amounts, recipients, memos, and payloads is real; spender privacy (a zk membership proof over the note set) is still Phase 2, so a spend currently reveals the input position and owner key. Redundant execution detects divergence but cannot yet attribute blame at k=2, the transport plane is an HTTP relay stub, and full metadata anonymity depends on an external Nym boundary. The whitepaper documents every boundary in detail.