Back to selected work

ZeroS. Keeping prediction-market positions private and hedges tied to settlement

Dmitry Sergeev·10 min read

Category:Protocols

Project status:Discontinued by client

Tags:
  • Prediction markets
  • Zero-knowledge proofs
  • Private notes
  • Hedging
  • Strategy vaults
  • Settlement

Our work

We developed the private ownership, routing and settlement components for ZeroS. Our work connected confidential position records to on-chain asset backing, solver-funded execution, exact-condition hedges and separate strategy-vault accounting.

A trader can find an attractive price and still end up with an incomplete hedge. Liquidity sits across venues with different fees and execution paths, matched orders may still await settlement, and markets with similar headlines can resolve under different rules. Public token ownership adds another constraint. Anyone following the wallet can inspect positions and watch the strategy change. ZeroS brings these problems together in an execution and risk-management architecture for confidential prediction-market ownership.

The product combines an off-chain router, on-chain custody and a zero-knowledge ownership ledger. Traders can acquire positions directly or allocate to a separate strategy vault, with individual entitlements represented by private notes. The main engineering challenge was keeping those entitlements confidential without weakening asset conservation. The second was making a hedge depend on exact payoff rules and finalized inventory. Both requirements shaped the settlement path, rather than remaining features of the trading interface.

Confidential ownership had to be backed by exact assets

Hiding a portfolio in an application database would leave the operator responsible for maintaining the relationship between each displayed balance and the assets behind it. ZeroS places custody and ownership transitions on-chain. Custody contracts hold supported collateral, outcome tokens and vault shares, while individual entitlements appear as randomized commitments in a shared note tree. A shielded outcome note represents the exact underlying token held in custody. A vault-share note represents shares, without counting the vault's underlying inventory again as direct user ownership.

Each private note includes its asset identifier, quantity, ownership keys, randomness, type and policy commitment. A Poseidon commitment represents the note publicly. To spend it, the holder proves ownership and membership in an accepted Merkle root, then exposes a nullifier that prevents another spend of the same note. The proof constrains quantities and conserves value separately for each asset. Adding units of unrelated tokens together would not establish solvency, so each transition has to preserve the correct asset balance.

Deposits and withdrawals connect that private accounting to observable token movements. Boundary calls measure custody balances before and after the operation. An API response or solver acknowledgement cannot issue a backed entitlement on its own, and an unsolicited token transfer creates surplus rather than automatic user credit. A reserved withdrawal claim is excluded from the spendable note set. These rules preserve the relationship between custodied units, live private claims and reserved boundary claims through each transition.

We made note recovery independent of the operator's private database. Output commitments are published with authenticated encrypted payloads that recipients can use to reconstruct their notes. Recipient binding and ciphertext hashes form part of the authorised transaction statement. Spend, viewing and nullifier keys use separate derivation domains, so access to a report does not grant spending authority. The shared note tree also avoids automatically assigning every market its own isolated ownership anonymity set.

A private swap needs more than two valid spending proofs

A user and solver can each prove that they own an input without proving that the two spends form the trade they agreed to. That gap matters in confidential settlement because the contract cannot inspect plaintext quantities to reconstruct the bargain. ZeroS binds both parties to the same trade commitment and complete set of output commitments. The shared statement contains the asset IDs, exchanged quantities, fee allocation and a random blinding value.

Each party proves its own balance transition against that statement, using opposite flow signs and a distinct role. Atomic validation checks that both proofs refer to the same terms and account for the output set once. The contract verifies them together and settles both sides in one operation. Neither party needs to hand its spending witness to the counterparty, and unrelated inputs or change remain outside the counterparty's view. If one side cannot deliver a valid spend, the exchange does not consume the other side's assets.

This makes funded solver inventory central to the solver execution path. A solver quotes delivery of an entitlement it can already settle inside ZeroS. It can replenish its inventory on an external venue separately. The user's completed acquisition does not depend on that replenishment arriving later. A quote can still fail because the solver has committed the same inventory elsewhere, but that becomes a delivery failure rather than an unsecured claim on a future trade.

The architecture also permits approved same-chain adapters. In that path, custody releases an authorised input, the adapter performs its operation and the measured output returns before private credit is issued. Output constraints and the full operation revert together if execution fails. The trade-off is visibility: the external call exposes assets and quantities even though subsequent ownership remains confidential. Each execution mode therefore has its own privacy boundary.

A cheaper opposite outcome can still be the wrong hedge

Market names are insufficient identifiers for risk management. Two questions may look equivalent while using different cutoffs, sources, cancellation rules or dispute procedures. Buying opposite outcomes across them can leave residual exposure. ZeroS uses a versioned resolution registry to connect routing decisions to the actual payoff contracts. Its specification includes the condition, outcome partition, collateral, oracle and redemption contract, observation window and invalid-payout rules.

The registry distinguishes exact complements from reviewed equivalent specifications and merely related events. Only matching outcomes within the same condition and compatible partition can use the complete-set conversion as a protocol-level hedge. Independently issued markets retain oracle, timing and venue basis risk even when their wording has been reviewed. Automated text comparison can suggest a relationship, but approval requires recorded evidence and review. Existing tokens retain their original payout rules when registry metadata changes.

For an exact binary condition, equal quantities of YES and NO can form complete sets that merge into collateral. The hedge service therefore compares selling the existing outcome with buying its matching complement and merging. It evaluates net proceeds after fees and conversion costs. The user's mandate specifies permitted conditions, desired coverage, expenditure limits, deadline and whether partial completion is acceptable. Those constraints follow the authorised action into settlement.

For example, consider a holder of 10,000 YES units who wants to remove exposure from 6,000. At a matching NO price of 0.37 and 20 units of additional fees, acquiring the complement requires 2,240 collateral units. Merging produces 6,000 collateral units and leaves 4,000 YES. The net cash change is 3,760, but that is not profit because it excludes the original YES acquisition cost. If selling the 6,000 YES directly offers better net proceeds under the mandate, the router selects that route.

Routing had to compare deliverable outcomes

The router evaluates the cost of completing a trade, including consideration, venue and protocol fees, collateral conversion and estimated settlement cost. A configured execution-risk penalty can influence ranking, but it is shown separately from actual payable charges. Quotes name an exact output asset ID and resolution version. A headline price is therefore only one input to the decision.

Before a route becomes eligible, the system checks its execution context.

  • The router checks feed freshness and unresolved sequence gaps.
  • It checks approved assets and collateral conversions.
  • It checks the quote's resolution version and expiry.
  • Delivery is checked against the selected path's available inventory.
  • Partial completion follows the user's recorded mandate.

Large orders may be divided into independently settled child trades. That can improve access to available liquidity, but it changes the completion guarantee. An all-or-nothing promise applies only where the entire operation fits within a supported atomic settlement. External order matching remains separate from atomic user settlement. Venue replenishment and user settlement remain separate responsibilities.

Final ownership cannot come from an order acknowledgement

ZeroS gives intent and settlement separate state machines. An intent moves through quoting, authorisation and submission. Settlement moves through simulation, broadcast, inclusion and finalization, with explicit failure and reorganization paths. A venue match, RPC acknowledgement or included transaction does not substitute for finalized ownership. The coordinator publishes finalized balance updates only after reconciling the accepted chain state.

We kept the durable operational journal separate from financial ownership, which remains authoritative on-chain. Consumers expect at-least-once delivery and process events idempotently. The authorised transaction digest and nullifiers identify the financial action, rather than relying only on a relayer transaction hash that may change during replacement. After a broadcast timeout, the coordinator reconciles the action before retrying or releasing reservations. An uncertain response cannot safely be treated as rejection.

The canonical index tracks block hashes and log positions alongside commitment and nullifier updates. On a reorganization, derived trees and affected receipts roll back to the common ancestor, and provisional balances remain distinguishable from finalized ones. Encrypted note payloads are published with chain data, while indexed mirrors provide convenient access. Note reconstruction is independent of the operator's private database. Key loss remains a different problem because public chain data cannot recreate the user's spending secrets.

Vaults needed a different promise from direct ownership

A strategy vault introduces pooled exposure and an entry or exit price. The initial ZeroS strategy uses unleveraged exact-condition liquidity and complete-set conversion. Its inventory is public, while individual ownership of vault shares can remain shielded. This distinction prevents the privacy claim for shareholders from being stretched into a claim that the pooled strategy itself is invisible.

Entry and exit processing use epochs where outcome inventory has been converted to collateral and outstanding execution liabilities have been reconciled. That makes the actual share issuance and redemption price cash-based. Interim inventory valuations use executable depth, stale-data rejection and concentration haircuts for monitoring and risk decisions. A small last trade cannot determine the entry price for the entire vault. If the required cash state cannot be reached, processing stays pending.

Redemption consumes spendable share notes into locked request entitlements. The owner cannot continue trading the same shares while waiting to redeem them. Within an epoch, requests receive the same applicable price and fee treatment, with pro rata processing when liquidity is insufficient. Claimable collateral is reserved outside strategy spending, and unprocessed deposits cannot fund new trades. These transitions prevent the queue from creating a second spendable representation of the same value.

On-chain guards enforce hard limits on assets, spending and inventory. Off-chain risk services can calculate richer scenarios but cannot override those controls. A maximum unhedged duration triggers a stop on new exposure and an attempt to unwind within the mandate. It cannot manufacture liquidity at the deadline. Delayed liquidation therefore remains visible as residual exposure and can delay vault redemptions.

Routing and settlement scale separately

We separated feed ingestion, quote routing, proof verification and chain submission. A returned quote and a verified proof each represent a different stage of the trade. Final ownership is recorded only after the settlement path confirms the asset movement.

Feed ingestion scales by venue, routing by market group and relayers by sender nonce lane. Proof checks and transaction simulation use separate admission queues so invalid-proof traffic does not exhaust RPC capacity. The shared root and nullifier state still form an on-chain serialization boundary. Verifier gas, ciphertext publication, state updates and adapter calls all consume settlement capacity. Backpressure prioritizes withdrawals, claims and reconciliation over new risk-increasing trades.

Privacy and recovery remain part of settlement design

The proving stack uses Circom, Groth16 over BN254 and generated Solidity verifiers, with local snarkjs/WASM proving. Each release pins circuit source, compiler, constraint hash, setup transcript, proving key and verifier bytecode. Fixed input and output bounds keep circuit work predictable. A circuit change requires a new reviewed set of artifacts rather than an invisible change to an existing immutable pool's verifier authority.

The privacy claim remains specific to individual holdings inside the shielded ledger. Public reserves, deposit and withdrawal boundaries, external venue trades and aggregate vault inventory remain observable. Solvers learn the terms they execute. Timing and distinctive amounts can still reveal relationships, which is why batching, relayers, minimal telemetry and client-side portfolio calculation are part of the design. Batching delay has an execution cost: waiting for a larger privacy set can worsen a hedge price.

Recovery follows the same explicit boundaries. Holders can submit ordinary withdrawals through another relayer or directly when the supported circuit and custody path remain available. Vault exits still depend on liquidity and queue processing. Emergency controls distinguish stopping a vulnerable adapter from disabling an unsafe circuit, so unaffected paths can be treated separately. We kept each settlement path tied to its backing, proof and ownership-change conditions.

ZeroS connects confidential ownership to exact asset backing, and hedge coverage to finalized positions with matching resolution rules. The result is a settlement design where a private balance, a solver quote and a completed hedge each have a distinct, verifiable meaning.

See our architecture in practice.

DEVLAB · ARCHITECTURE EXAMPLE

Agent
Commerce

A look inside the software architecture behind Agent Commerce.

View architecture
Agent Commerce — Software Architecture, designed by Dmitry Sergeev