What Sable hides, and what it doesn't

Sable is built on fully homomorphic encryption via the Zama Protocol. Values are encrypted in your browser and stay encrypted on-chain. The contracts compute over the ciphertext — adding yield, comparing a random draw point against your ticket range, selecting between branches — without ever decrypting anything.

Access is enforced by an on-chain access control list. Sable grants your address permission to decrypt your own handles and nobody else’s. When you reveal a balance, your wallet signs a time-bounded authorisation, and the key management service re-encrypts the result to a key held only by that browser session.

Encrypting balances is now reasonably well understood. Encrypting the choice is the harder problem, and it is where most confidential prize-savings designs leak.

If changing your mode meant calling a different function, the function selector would publish your choice to anyone reading the mempool — the balance would be encrypted and the decision beside it in plaintext. That cuts both ways: since a new position opens in Lucky, the disclosure a naive design would leak is the decision to leave the draw. Sable avoids it structurally, in either direction:

• One function, one encrypted argument. Steady and Lucky produce identical calldata shapes.
• One event, carrying only an address. There is no LuckyModeEnabled event to subscribe to.
• Eligibility is computed with a homomorphic select over the encrypted bit, so both branches always execute and the gas cost is identical.
• A Steady saver receives an empty ticket range — arithmetically indistinguishable from any other allocation.
• Even never having set a mode is indistinguishable from having chosen Lucky, because the default is Lucky and is stored encrypted like any other selection.

Being precise about the limits is more useful than a stronger-sounding claim. The following are visible to anyone watching the chain, and Sable does not attempt to hide them:

• Your address. Transactions are sent from your wallet, so participation itself is public. Sable protects what you hold, not that you hold something.
• Timing. When you deposited, withdrew or changed mode is public. Frequent activity around round boundaries is a behavioural signal no amount of encryption removes.
• The amount you shield. Converting a public token into the confidential one calls wrap(to, amount), where the amount is cleartext — as is the approval before it. Shielding is not itself private. What it buys is everything afterwards: the resulting balance, every transfer of it, your deposit and your yield mode are all encrypted. The same applies in reverse when you unwrap.
• Aggregates. The round’s prize pool is published, which is the sum of what Lucky savers contributed. With very few participants, an aggregate necessarily says more about each of them.
• The rollover bit. Whether a jackpot point matched any ticket is published. That is one bit about total allocation across all savers, and nothing about any individual.
• Participant count. How many accounts were scored in a round is public; which accounts, and with what weight, is not.

Administrators can configure and advance rounds, and pause deposits in an emergency. That is the whole list.

They cannot decrypt any balance, read any mode, see any weight, choose a winner, re-run a completed round, or move user funds. This is not a policy commitment — there is no function that does any of it, and the access control list never grants an administrator permission over another account’s ciphertext. Withdrawals are deliberately not gated on the pause switch.

Nothing sensitive. Plaintext amounts exist only in browser memory between the moment you type them and the moment they are encrypted. They are never logged, never sent to a server, never placed in a URL or query parameter, and never written to local storage.

Revealed balances are held in memory only and re-mask automatically after ninety seconds. The decryption authorisation is discarded when you disconnect or switch accounts. Private statements are generated entirely in your browser — no decrypted figure is transmitted to produce one.

There is no analytics on this application, and no error-reporting service receiving values.

Sable runs on a test network with a test asset that has no value. As with any smart contract, the code carries risk: bugs are possible, and this protocol has not been externally audited.

What the design does guarantee is narrower and worth stating exactly: no rule in this protocol routes one saver’s principal into another saver’s prize. Prizes are funded from yield alone. That is a property of the code, not a promise about DeFi in general — and it is not a claim that saving here is risk-free.

The security page covers the architecture and trust assumptions in more detail.