Skip to content

An honest trust model

ZecOne is a trusted-relayer payment system, not a trustless bridge. This page states exactly what is private, what is public, who can link them, and what is switched off.

How money moves, and who can see it

Two chains with very different privacy, joined by an operator you have to trust.

Zcash, shielded

  1. Customer walletPays shielded ZEC
  2. ZecOne receiving addressOne shielded address, viewing key on the watcher

Sender, recipient and amount are encrypted on chain.

Z1

ZecOne operator

Verifies the payment, then a prefunded relayer pays out. Can link both legs.

Base, public

  1. Relayer walletPrefunded with ETH
  2. Merchant payout addressVerified by wallet signature

Amounts and addresses are public and permanent.

There is no cross-chain message. The two legs are joined only by the operator's ledger.

Privacy is not all or nothing

Private on chain

The public cannot see

The customer's shielded Zcash address, the amount and the note contents. The payment sits inside the shielded pool.

Public on chain

Anyone can see

The Base payout: the ETH amount, the merchant's receiving address and the relayer address. It is permanent.

Visible to the operator

ZecOne can see

The operator verifies the shielded payment with the wallet's viewing key, so it can link the Zcash payment to the Base payout. ZecOne does not promise anonymity from the operator.

Trusted relayer, prefunded liquidity

Not a trustless bridge. A trusted, prefunded relayer executes the Base payout after the operator verifies the Zcash payment. If the operator misbehaves, the merchant is not paid; nothing on chain forces it.

Liquidity. The relayer pays from its own ETH balance. A quote is issued only if that balance covers it and all open payouts. There is no automatic ZEC to ETH conversion, and the relayer can be paused.

Key boundaries

  • Payment APIHolds no spending key, relayer key or signing credential. It cannot move funds.
  • Mainnet watcherUses a viewing key only (UFVK). It can see incoming payments, never spend them.
  • Relayer submitterThe only component that could pay on Base. Paused by default and behind separate SIGN and BROADCAST approvals.
  • Merchant credentialsAPI keys and sessions are stored hashed, scoped, rate-limited and rotatable.

Switched off in this build

Live settlement is disabled. These stay off until a separate, reviewed release.

Live settlement is disabled

The merchant API refuses to start in live mode. Demo checkouts are simulated; monitor mode observes real deposits but never pays out.
  • Live Base payouts
  • Zcash mainnet broadcast
  • The Base relayer submitter (paused)
  • Any payout without separate operator SIGN and BROADCAST approvals
  • Browser-triggered payment completion (demo replays run on the server only)
  • Spending keys, keystores or passphrases on any public API process

Still enforced: quote expiry, a 20-confirmation policy for live attribution, one source transaction per order, relayer liquidity checks, signed webhooks with replay windows, and an append-only event log. Merchant accounts are created only after an EIP-4361 signature over a single-use, server-issued message, and payouts can only go to that verified address.