# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.notcentralised.com/workflows/tokens.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.