# Tokens

**NotVault** ensures the confidential management and transaction of tokens, utilizing both censorship-resistant technologies and smart contracts known as 'The Vault'.

#### Key Features

Here are some core features provided by the Token SDK:

* **Token Life-cycle Management**: **NotVault** allows you to manage the entire life-cycle of token transactions with ease and high-level security.
* **The Vault Smart Contract**: The Vault stores hash values of token balances instead of conventional numerical values. This further promotes secure and private token transactions.
* **Zero Knowledge Proofs**: zkSNARKs or Zero Knowledge Proofs ensure that balance updates remain confidential yet consistent, bolstering the privacy of transactions.
* **Asynchronous Transfer Pattern**: **NotVault** adopts an asynchronous transfer pattern for private transfers. Unlike synchronous ERC20 transfers, these transfers require the receiver's acceptance before completion.

### Roles in the Token Workflow

In a **NotVault** token transaction workflow, two roles are crucial:

* **Sender**
* **Receiver**

#### Workflow Steps

Below is a step-by-step walkthrough of a token transaction using **NotVault**:

1. **Deposit**: The sender deposits tokens from their public balance.
2. **zkSNARK Proof Generation by Sender**: Before a sender can transfer tokens, they generate a zk proof. This verifies that the sender knows their balance before the transfer and ensures the transferred amount is less than or equal to the available balance, avoiding double spending.
3. **Send Request**: The transferred amount is locked in The Vault smart contract as a Send Request, identified by a unique ID.
4. **Balance Update by Receiver**: When ready to accept the transfer, the receiver identifies the Send Request through its unique ID and updates their balance in The Vault.
5. **zkSNARK Proof Generation by Receiver**: To update their balance, the receiver generates a zk proof, verifying that they know the transferred amount and their balance before the update.
6. **Withdrawal**: Finally, the receiver withdraws the accepted amount from their private balance to their public standard balance.

#### A Use Case Scenario

To put things into perspective, here's an example scenario of token workflows in **NotVault**:

* Owner A (sender) has 1000 tokens in their public balance. They deposit 100 of these tokens into their private balance within The Vault.
* Owner A's private balance is now 100 tokens, represented on-chain as a hash.
* Owner A calculates their new balance after sending 10 tokens, and creates a new hash for the remaining 90 tokens.
* Using zkSNARK, Owner A verifies the balance update's consistency and updates their on-chain balance in The Vault, replacing the old hash with the new one.
* Owner A initiates a Send Request, locking the 10 tokens in it.
* Owner B (receiver), upon identifying the Send Request through its unique ID, calculates their new balance after adding the transferred tokens, and creates a new balance hash.
* Owner B creates a zkSNARK proof to verify their new balance hash is indeed the old balance plus the transferred amount.
* Owner B updates their on-chain balance in The Vault using the proof.
* Finally, the smart contract invalidates the Send Request's key to ensure it's spent only once.