Cheshire
Research prototype · test signet

Cheshire

Bitcoin is private Bitcoin.

A shielded pool that lives in a single Bitcoin coin. You prove your own payments on your phone, and Bitcoin's own consensus re-checks the proof on every settlement. No bridge, no federation, no token.

Post-quantum, Zcash-Orchard-class privacy, running natively in Bitcoin Script. It needs the Great Script Restoration soft fork, so today it runs on a GSR test signet with test coins.

Why, how, what

Privacy on Bitcoin, enforced by Bitcoin.

Why

Bitcoin is a public ledger. Every payment shows its amount, and chains of payments show who pays whom, forever.

Privacy has usually meant leaving Bitcoin for a sidechain, a federation, a bridge or a token, and trusting whoever runs it. Cheshire keeps your coins on Bitcoin, under rules Bitcoin itself enforces.

How

One covenant coin holds a shielded pool of private notes, in the style of Zcash's Orchard. Your wallet proves its own payment on your phone; no key or amount leaves it.

Payments settle in batches. Every settlement is one ordinary Bitcoin transaction whose script re-runs a STARK verifier, so a settlement that cheats does not confirm.

What you get

Private payments

Who paid whom, and how much, stay off the chain. Each payment leaves one record of about 29 vB, and every one is two notes in, two out, so even counts are hidden.

Your seed is the backup

Every note you own can be rebuilt from your seed and the Bitcoin chain alone. No server holds your keys or your history.

A way out no one can refuse

A forced exit request on chain must be handled by the next drain, every sixth settlement: paid if its note is unspent and its anchor recent, otherwise voided, never skipped. If settlements stop altogether, a solo exit needs no one.

Post-quantum proofs

Hash-based STARKs over SHA-256, with no elliptic curves in the proofs. Two pieces are not post-quantum yet: the payment-code handshake and taproot's key path. The docs say what that means.

No trusted setup

No ceremony and no toxic waste. The pool's value is public, and Bitcoin's rules cap what it can ever pay out at that value.

Built for a phone

The app proves on the device, checks Bitcoin's headers itself, and sends everything through Tor, built in and on by default.

How a payment works

Four steps, one record on chain.

  1. Prove it on your phone

    Your wallet makes a zero-knowledge proof that a note is yours, is unspent, and adds up to the notes you create, in about a second.

  2. Hand over the proof

    It goes over Tor to the share chain, where nodes agree on a batch and split the proving work. They are paid in notes, by the settlement's own proof.

  3. Bitcoin checks it

    One transaction spends the pool coin and makes the next. Its script runs the STARK verifier on the whole batch, with about 29 vB of record per payment.

  4. It arrives

    The payee's wallet finds its note in the records; nobody else can. Once settled, it can be spent again or rebuilt from the seed.

Until its settlement confirms, a payment is pending. Deposits come in through deposit coins, and withdrawals leave through a vault output; amounts at that boundary are public, as with Zcash's transparent side.

The Cheshire app icon: a cat's face with bitcoins for pupils

The wallet

Cheshire for iPhone.

A self-custodial wallet that does the private part itself. TestFlight soon

  • Every payment is proved on the phone; keys never leave it.
  • Tor is built in and on by default.
  • Checks Bitcoin's headers and blocks from Bitcoin's own peers.
  • Rebuilds your wallet from its seed and the chain.

Test coins only. We'll post the TestFlight link here when it opens.

What Bitcoin needs

The Great Script Restoration.

Cheshire runs in Bitcoin Script, with one change Bitcoin does not have yet: GSR. Its covenant and its STARK verifier use GSR's new tapscript leaf version and nothing else.

The verifier does field arithmetic with OP_MUL and OP_MOD, hashes with OP_SHA256 and OP_CAT, and the covenant rebuilds its own transaction with OP_CAT to carry the pool's state forward. An OP_CAT-only version was built first: each settlement took about 1.87 MvB over many transactions, and it could not bind the published data to the proof.

Neither BIP is active on Bitcoin. Cheshire is a demonstration of what the restoration makes possible, and we support the effort to activate it.

BIP-440Varops budget

A budget that keeps blocks fast

Every opcode pays for the bytes it reads and writes, so the restored opcodes cannot be used to make a block slow to validate.

Read BIP-440

BIP-441Restored opcodes

The opcodes disabled in 2010, back

OP_CAT, OP_SUBSTR, OP_MUL, OP_DIV, OP_MOD, shifts and bitwise operations; stack items above 520 bytes; script numbers of any length.

Read BIP-441

0xc2Both apply only in this new tapscript leaf version, so nothing changes for existing scripts.

Where it stands

An honest status.

Cheshire is a research prototype. Here is what is real, what is not, and where it is weaker than the systems it is compared with.

  • Settled on gsr-netA first pool settled deposits and a private payment on gsr-net, a public GSR test signet, in November 2026. A new pool on the current circuits is being launched there. Signet coins are worth nothing.
  • Run end to end with real proofsDeposits, private payments, withdrawals, forced exits and recovery from seed have run with real proofs on GSR nodes, under standard relay policy.
  • UnauditedNobody outside the project has reviewed the circuits, the proving system's fork, the on-chain verifier or the covenant. Machine-checked proofs cover only the bounds of the arithmetic gadgets.
  • Zero-knowledge, stated preciselyThe spend proof your wallet makes is statistically zero-knowledge in the programmable random-oracle model, under a written argument with stated assumptions. The project has checked it; no one else has.
  • Not for mainnet valueGSR is not active on Bitcoin, and the proof parameters are set for a test network. Do not put real money near it.

Compared with Zcash

Cheshire borrows Orchard's notes and nullifiers. Where it differs:

Stronger

  • No trusted setup
  • Hash-based, post-quantum proofs
  • Payment counts hidden; Orchard shows its action counts
  • It is bitcoin, on Bitcoin: no new coin

Weaker

  • Maturity: unaudited, against years in production
  • Cost per payment at low volume: each settlement carries a fixed-size verifier
  • Fewer payments to hide among: while use is low, each settlement holds only a few, so the timing of a payment narrows down who sent it

Can the supply be inflated?

The pool's value is public, and Bitcoin's own rules cap what it can pay out at that value: no bug in Cheshire can make it pay out more bitcoin than it holds.

Inside the pool, forging a note would take a bug in the circuits or the verifier; there is no setup to compromise. Such a break could misallocate the pool's real value, and that is detectable against its public value. Finding those bugs first is what an audit is for.