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:
Deposit: The sender deposits tokens from their public balance.
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.
Send Request: The transferred amount is locked in The Vault smart contract as a Send Request, identified by a unique ID.
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.
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.
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