Vault

The Vault is a smart contract designed to securely store and manage a variety of assets, including tokens, NFTs, and tokenized real-world assets. It serves as a unified ownership solution, with a single owner controlling access, which enables efficient management of assets, even in complex scenarios like gaming or decentralized finance.

Assets sent to the Vault can either be actively managed or locked, depending on the use case. Active management of an asset in the Vault may be required in scenarios such as decentralized gaming, social media, and others. In contrast, locking assets is more common in decentralized finance, where a locked asset typically serves as collateral. One example of a Vault implementation is integrated into the Fraction Protocol Platform, where assets are fractionalized.

The Vault relies on the ODC architecture, where a series of smart contracts are involved in the process of asset locking. These smart contracts provide the data storage, access-control layer, and data manager. At this stage, it is important to define components that have not been previously mentioned:

  • Vault Data Object - This smart contract is required to create and manage new vaults where users' assets are locked. It stores mappings of data points and vault addresses, deployed deterministic vaults, and valid signatures for a given hash.
  • Generic Vault - Represents a smart contract where collateral in the form of assets is stored.

The diagram presented below highlights the creation of a new Vault and the corresponding asset transfer to the Vault:

image
  1. A user interacts with the front-end of the Data Manager smart contract, approves it using their wallet, and submits a transaction to call a specific function to deposit their assets into the Vault.
  2. The Data Manager calls a specific function and forwards the data, along with the Data Point, to the Data Index.
  3. The Data Index verifies if the Data Manager is allowed to write to the Vault Data Object. If so, the Data Index calls the write function in the Vault Data Object. In this scenario, the write operation represents the vault creation function.
  4. The Vault Data Object creates a new Generic Vault by using the GenericVaultFactory smart contract. It then saves the mapping of the new vault address and the Data Point.
  5. The Vault Data Object then returns the result of the operation to the Data Index.
  6. The Data Index also returns the result of the operation to the Data Manager.
  7. Then the Data Manager transfers the assets to the Generic Vault from the user's wallet.

Vault types

Depending on the implementation, the Vault Data Object can deploy two types of Generic Vault:

  • Individual Generic Vault, which is generated specifically for each user who wants to store their assets in the vault.
  • Collective Generic Vault, which is generated only once, and all users store their assets in that vault.

Verification of asset ownership

In order to manage an asset and verify ownership, the ERC-1271 standard was implemented to enable the Vault Data Object smart contract to verify the signature of a given transaction and call the specified function that manages the asset for a user.

Suppose a user interacts with an external service that needs to manage the user's asset. In this example, the external service is represented as an online game that interacts with smart contracts. This example highlights only one of the possible implementations.

image
  1. To manage the asset, the user must send a request to the External Service.
  2. The service responds to the user's request with a newly generated message, asking the user to sign it.
  3. The user signs the message and sends the hash of it to the Data Manager.
  4. The Data Manager forwards the hash and user address to the Data Index.
  5. The Data Index forwards the hash and user address to the Vault Data Object. The Vault Data Object stores the hash and address for further verification.
  6. The user sends the signature to the External Service.
  7. The External Service sends the hash of the initial message (from Step 2) and the signature to the Generic Vault for verification purposes.
  8. To verify the hash and signature, the Generic Vault also forwards them to the Vault Data Object.
  9. The Vault Data Object retrieves the user address from the signature and compares the previously saved hash and address (from Step 5) with the currently received hash and address. If the verification is successful and both hashes and addresses match, the Vault Data Object returns the result of the operation to the Generic Vault, confirming that the signature is correct.
  10. The Generic Vault returns the result of this operation to the External Service, which can then act accordingly and manage the user's asset.

On this page