1. Overview
  2. Docs
type ciphertext

Ciphertexts are encrypted information used to retrieve payments and can be decrypted with full keys or just ovk. They can be stored on-chain or transmitted off-chain from payer to recipient. *

type commitment

A commitment is the equivalent of a transaction output, with the important difference of not leaking any information. Must be stored on chain. *

type cv

Commitment value. The value of a transaction output is committed (Pedersen's commitment) separately. *

type hash
type nullifier

Nullifiers are used to invalidated a commitment, that is marking it as spent. However they can't be linked to the commitment that they invalidate. Nullifiers are derived from a commitment and a secret key using a pseudo random function. *

type rk

Randomised signature keys. All inputs are signed with a randomised version of a secret key. *

type spend_proof

Zero knowledge proofs needed to spend a transaction outputs. See spec section 4.15 *

type spend_sig

Signature needed to spend tokens. Computed with a randomised version of the secret key and verifies under a randomised version of the public key. Signs a hash of an input concatenated with an optional anti-replay string. *

type output_proof

Zero-knowledge proof needed to create money. See spec section 4.15 *

type input = {
  1. cv : cv;
  2. nf : nullifier;
  3. rk : rk;
  4. proof_i : spend_proof;
  5. signature : spend_sig;

Contains the necessary information to spend tokens (except the root which we include in the transaction). *

val input_encoding : input Data_encoding.t
type output = {
  1. cm : commitment;
  2. proof_o : output_proof;
  3. ciphertext : ciphertext;

Contains the necessary information to create tokens. *

val output_encoding : output Data_encoding.t
type binding_sig

Ties a transaction to a balance (difference between the tokens created and spent). Proves with the commitment values that sum of values of inputs minus sums of values of output equals balance. *

val binding_sig_encoding : binding_sig Data_encoding.t
type transaction = {
  1. inputs : input list;
  2. outputs : output list;
  3. binding_sig : binding_sig;
  4. balance : int64;
  5. root : hash;
  6. bound_data : string;

Transaction that is sent to a verifier. The root corresponds to a merkle tree where the inputs are present. Even if this root can in principle be very old, a verifier may keep only the last n known roots considering anything older as invalid. bound_data is arbitrary data that gets signed by the Sapling keys and can typically be used to connect the Sapling protocol to another one. For example it can contain the recipient address of an unshield operation. The memo_size field is checked at encoding and encoding to be the real memo size of all outputs. A transaction leaks the balance between inputs and outputs and the number of inputs and outputs. Note that the number of inputs is limited to 5208 and number of outputs to 2019, by a check in the encoding. This is important to avoid invalidating a proof over the balance as described in section 4.12 of the spec.

val transaction_encoding : transaction Data_encoding.t

The encoding enforces the limits on number of inputs and outputs.

val max_amount : int64

Maximum amount of shielded tokens. This value is imposed by librustzcash. *

val valid_amount : int64 -> bool
module Legacy : sig ... end