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.

Last updated