Abstract
The proposal in one line: Horizen becomes the leading application for quantum-resistant finance with privacy on Base through two complementary pieces deployed directly on Base: a shielded pool for private transactions and balances, and Vela as the confidential-compute layer that makes private decentralized finance programmable.
Similar privacy systems are already in operation in the Ethereum arena, and this Idea proposes for the system to be built with regulatory compliance in from the start: screened deposits, selective disclosure, and non-custodial contracts.
This ZENIP proposes a direction, not parameters. The proof system, fees, staking mechanics, and timelines are deliberately left to a technical feasibility study and a governance vote, and the open items are listed below rather than guessed at.
The intention is to ship a Minimum Viable Product as soon as possible, then continue to grow and expand the capabilities over time, shipping additional products and features as they are developed.
The two parts of the direction
1. Shielded pool on Base — private transactions and balances.
Contracts on Base that let users shield assets, hold them privately, transfer them, and unshield. Notes are designed for a quantum future. Deposits are screened. Users can prove specific payments to auditors or counterparties without making everything public. This is the privacy layer for value.
2. Vela on Base — programmable private decentralized finance.
Vela is the confidential-compute environment that can operate over private data the pool alone cannot. A shielded pool proves facts about one user’s notes; it cannot compute across multiple users’ private state. Vela can, which is what enables private applications: private order books or matching, confidential settlement logic, private lending terms, agent-to-agent negotiation, and other DeFi functions that need to stay encrypted until the final attested result. Vela is deployed and improved on Base alongside the pool, not as an afterthought. It opens as a marketplace of attested operators; bonding and slashing rules come from the technical study. It is a service market, not a requirement for basic pool transfers to function.
Together they are the system: the pool for private value, Vela for private computation on that value.
Candidate early use cases
Several uses are realistic. We list them so the community can push on priority:
Pool-first uses
- Private B2B settlement between known counterparties (supplier payments, partner settlements, inter-company transfers). Parties usually already know each other; the pool mainly hides amounts and relationships from the public chain. Selective disclosure fits naturally.
- AI-agent private transfer. Agents paying for data, compute, and inference. Docs and interfaces optimized for Agentic interaction.
- Private holding and yield. Shield assets, earn yield, unshield later. Privacy is mainly about balances.
- Private swaps inside the pool. Enter with one asset, trade, exit without revealing path or size.
- DAO / protocol treasury management. Operating funds kept shielded.
- Private donations or grants.
Uses that need Vela (or benefit strongly from it)
- Private DeFi applications. Confidential matching, private lending parameters, sealed-bid style flows, or other logic that must compute over more than one user’s private data.
- AI-agent private operations. Agentic onchain DeFi without broadcasting strategy; Vela can hold the private computation. The goal would be for an AI agent to be able to access and use a Vela enclave on its own.
- Selective, attested compliance or settlement logic that should not be fully public.
Proposed launch focus for the pool: private B2B settlement between known counterparties. It can bring repeated commercial volume and has a clear privacy rationale. Vela development and deployment on Base proceed in parallel so that programmable private finance is ready as the pool gains usage. Other uses remain available and can be emphasized as the system matures. The technical study and community input can reorder priorities.
Applications on Base for Private Payments and Private Finance
Ship in atomic steps. Working products ship one at a time to generate activity and feedback, instead of waiting for a complete system. Pool and Vela work advance together:
- Private transfers and holding (pool MVP). Shield stablecoins on Base, hold them privately, and send to any address. Early usage aimed at B2B settlement between known counterparties. Deposits screened against sanctions lists. Open payroll or broad consumer payments are not the launch focus.
- Privacy you can prove. Selective disclosure: prove a specific payment to an auditor, tax authority, or counterparty without publishing it, plus the documented screening process. Privacy and demonstrable compliance arrive together.
- Vela on Base, usable for private computation. Vela deployed (or expanded) on Base so builders can run confidential jobs. Initial operation can be more centralized; the path to a marketplace of attested, ZEN-bonded operators is explicit. This is what turns the pool into programmable private finance.
- Staking for the system. ZEN has an existing staking program. This new direction enables the creation of an updated staking program with mechanics chosen to support anonymity-set growth, long-term participation, and (where appropriate) Vela operator bonding, while minimizing structures that invite securities scrutiny. Exact design set by the study.
- Private movement across assets and deeper private DeFi. Move shielded value between supported assets without publishing the path. Yield and other applications that combine the pool and Vela follow.
Each step is a shipping product with users, not a research milestone. Which study results could reorder the steps is exactly what the feasibility study and the open items below settle.
Specification (high level, parameter neutral)
- A shielded pool on Base. Contracts deployed directly on Base, where stablecoins, wallets, and on/off-ramps already are. No separate chain and no bridge. The contracts are non-custodial and permissionlessly usable. Operating functions (deposit screening, default relaying, proof aggregation) sit with the Foundation.
- Post-quantum from the start. Notes encrypted with post-quantum cryptography, with post-quantum proofs in the initial pool deployment. The exact proof system will be selected by the technical feasibility study.
- Compliance people can use. Deposits screened against third party standard sanctions lists as a named, documented, and logged process. Users can generate proofs of specific payments for auditors or tax authorities. Optional exit-side tools (such as proofs of clean origin) will be evaluated. Procedures for post-deposit issues will be published.
- Foundation-run proof aggregation at launch, so verification on Base stays cheap and reliable. The output is a proof anyone can re-verify on Base.
- Vela as the programmable private-finance layer on Base. Deployed and improved on Base in parallel with the pool. It enables confidential computation over private data for DeFi applications. It opens as a marketplace: attested operators run hardware and bond ZEN to qualify for jobs and back provable failures. Exact bonding and slashing rules come from the technical study. Basic pool transfers do not depend on Vela; private applications that need multi-party private compute do.
What ZEN does. ZEN has two jobs, both named in the proposal.
First, ZEN staking is an intention for the design. Options will be evaluated to support pool security and liquidity (including cold-start incentives that grow the anonymity set) and Vela participation, while avoiding fee-sharing structures that create clear securities risk.
Second, ZEN-bonded compute for Vela: operators bond ZEN to qualify for jobs and back provable failures, with the rules set by the technical study. One design principle up front: nobody needs to hold ZEN to make a payment in the pool.
Still being worked out, by design:
| Proposed direction | Still open, set by study or vote |
|---|---|
| Shielded pool on Base for private transactions | The proof system and exact cryptography |
| Vela on Base for programmable private DeFi | Deployment timing, marketplace rules, and ZEN bonding roles |
| Private B2B settlement as the proposed pool launch focus | Fees, pricing, onboarding, and whether another early use case should lead |
| ZEN staking | Staking mechanics, cold-start incentives, and reward design |
| Post-quantum design from the start | Which parts launch first and which follow |
Motivation
Businesses that settle with suppliers or partners in stablecoins today publish every amount and relationship on a public ledger. That leaks pricing, volumes, and commercial strategy. At the same time, decentralized finance itself is limited if every position, bid, or term must be public.
Banks already give customers private payments under rules that block prohibited transactions. On-chain finance needs both private value transfer and the ability to compute privately. For people and businesses to use onchain finance, it needs to provide better services than banks.
The shielded pool addresses the first. Vela addresses the second. Together they are how Horizen proposes to deliver quantum-resistant private finance on Base.
Horizen began in 2017 as ZenCash, a privacy coin, and Horizen moved away from privacy over the years because the granularity to create regulatory compliant private transactions and decentralized finance did not yet exist.
This is a proposal to use the 10 years of technological improvements to implement the original vision: private balances and payments, encrypted to resist quantum attack, provable to the parties who need to see them, and programmable through confidential compute.
ZEN continues to be a token on Base with no inherent privacy features of its own. What this proposal develops and deploys are applications and smart contracts on Base, within the Ethereum ecosystem, that give stablecoins and the other assets in the system practical privacy.
Background / Context
The Horizen Layer 3 is being wound down on Base’s schedule. Base’s Denim upgrade (November 5) makes Base far faster than a Layer 3 built on it can keep up with; when the upgrade reached Base’s testnet on October 21, the Horizen testnet stopped within the hour, and the chain’s operator has confirmed it cannot be patched in time.
ZEN on Base and on exchanges is not affected, and a separate announcement covers the wind-down, the exit window, and how remaining funds are returned.
What Horizen brings to the next step: ZEN and a community that has stayed through everything, Vela (a confidential-compute environment already in builders’ hands), and a cryptography team at Horizen Labs that has spent years on zero-knowledge and post-quantum work. The proposal puts those strengths directly on Base, as contracts that keep working through Base’s upgrades, where the users and the dollars already are.
Process and Reporting
The order is set: Special Council review, then open community discussion (this thread), then the Horizen Labs technical feasibility study, then a detailed dated roadmap published from the study’s results, then a ZEN-holder governance vote. Phases move forward when their conditions are met, not on a calendar.
Progress updates will be posted in plain language in this thread as the study reports. The first clarity on cryptography and costs is expected from the study itself, and the dated roadmap only after it.
Security & Privacy
Audit plans and the selective-disclosure tooling (proving a specific payment to a specific party) will be published as the implementation work locks each piece down. The design principle is that privacy and provability ship together: no product releases that force users to choose between confidentiality and compliance.
Operating functions are run by the Foundation with published methodology and logs sufficient to demonstrate that screening occurred. The underlying contracts remain non-custodial and permissionlessly usable.
Known Risks
Naming these ourselves, because each one is the reason behind a design choice, not a footnote.
- Post-quantum cryptography may not hit its numbers. Post-quantum proofs are bigger and slower than today’s, and the feasibility study may find they do not fit a fast payment product.
- Node operators for the pool could recreate the problem of third party dependency. The initial design of the pool’s plumbing (relaying, aggregation, coordination) is Foundation-run with published, verifiable output and permissionless fallbacks. ZEN bonded shielded pool nodes may be added as a future update. Vela operators are a marketplace, not pool-critical infrastructure.
- ZEN staking design. Staking should help grow the anonymity set, support Vela participation, and give holders a long-term role, while avoiding structures (especially ongoing fee-sharing presented as yield) that create clear securities risk. Mechanics will be set after the study.
- A new pool starts with a small anonymity set. Privacy is only as strong as the number of users in it, and day one numbers will be small. Focusing first on repeated B2B settlement is intended to bring real volume. Vela applications can add further usage as they ship.
- ZEN depends on Base. The L3 taught us what depending on someone else’s chain costs, and no L2 choice removes dependency entirely. What changes this time: the design is contracts, not a chain. Contracts ride Base’s upgrades instead of breaking on them, the note tree lives on Base where anyone can read and verify it, and withdrawals require nobody’s permission. The dependency becomes “we upgrade when Base does” instead of “we can be switched off.”
- Vela relies on outside hardware. It runs on AWS Nitro Enclaves today, so its confidentiality and availability depend on that provider
- Legal and regulatory review. Payments and token design raise legal questions that vary by jurisdiction. Legal analysis will be obtained as necessary, and staking designs will favor ZEN being locked and returned over ongoing claims on protocol fees.
- Sanctions and AML effectiveness of the screening model. Deposit screening is a necessary start. Limitations are real. Additional tools such as optional exit-side proofs of origin and published post-deposit procedures will be evaluated.
None of these are reasons to wait. They are the reasons the order is: study first, smallest useful product first, pool and Vela advancing together, verifiable plumbing before trusted roles, clear separation of protocol from operating functions, and updates in public.
What we are looking for from this discussion
- Push on the direction. What breaks if we build this and it’s wrong? What did we miss?
- On the two parts: Is the balance between the shielded pool (private transactions) and Vela (programmable private DeFi) right? What should ship first in each?
- On the pool launch focus: Is private B2B settlement between known counterparties the right first emphasis, or should another use case lead?
- Business owners: what would you actually need to run private supplier, partner, or inter-company payments through a shielded pool? What selective-disclosure features matter?
- Builders: what private DeFi applications would you run on Vela attached to a shielded pool?
- Community: what do you think, what are we missing here?
Rolf Versluis and Rob Viglione, cofounders of Horizen @finpunk tagged for visbility