Skip to main content

Private transactions (sapling)

Sapling is a protocol that enables transactions of fungible tokens while increasing privacy. It hides transactions from the public, but allows specific entities to view them to comply with regulations.

The key steps are as follows:

  1. A shielded pool is created within a contract which a number of users can call to perform transactions whilst keeping details private.
  2. The users send tokens to this shielded pool, which is called shielding tokens. Information about these transactions is public.
  3. Users perform shielded transactions, in such a way that the amount, sender of receiver of each transactions are not revealed publicly. Only the origin and destination of each transaction have access to the transaction information.
  4. Later, users may get some or all of their tokens out of the pool by unshielding their tokens. Information about these transactions is public.

If a regulator needs access to the transactions of a user, this user may share a viewing key, which gives access to all the transactions made by this user.

Note that using the sapling protocol in a shielded pool and expecting a high degree of privacy requires taking a number of precautions, including:

  • Making sure there are enough members in the pool to ensure anonymity. For example, if there are only two members, it becomes very easy to identify the source and destination of transactions.
  • Adding dummy transactions, or dummy inputs and outputs of transactions, to hide the actual number of parties involved in each transaction.
  • Making sure to use shielded tokens in multiple transactions. For example, if a user shields exactly 16.32 tokens and another user later unshields exactly 16.32 tokens, the transaction may be traceable.
  • Being careful about information that can be deduced from the timing of transactions.

The internals of sapling are quite technical. The system is based on an UTXO (bitcoin-like) transaction system, where each transaction consumes some unspent output and produces new unspent outputs. It uses a system of cryptographic commitments in place of public amounts and addresses, that can then be "consumed" using a system of nullifiers. The process uses a mix of cryptographic tools including SNARKs, incremental Merkle trees, and Diffie-Hellman key exchanges.

Implementation information​

Last updated on