Vault Creation Zap
To assist in the creation of an NFTX vault, we created a zap that amalgamates a number of processes into a singular contract call. This call will allow you to perform the following steps:
Create a default vault
(optional) Add an eligibility storage module
(optional) Add 721 or 1155 tokens to the vault, returning tokens to the sender
(optional) Set vault features
Set vault fees
Finalise the vault
Please note: Due to the evolution of ERC721 support, we have chosen to exclude support for the CryptoKitties contract to save gas for the majority of users.
Our vault creation function takes the following attributes, each of which will be explained in this document. Upon successful creation we receive the ID of the vault that was created. This can then be subsequently referenced in our NFTX Vault Factory to get address and implementation information.
vaultData
Takes a formatted struct containing basic information regarding the vault.
vaultFeatures
A integer value of a binary representation of booleans. This allows us to map five boolean values, one for each optional vault feature, inside of a single parameter. The order of these booleans aligns as:
Allow minting to the vault
Allow random redemptions
Allow targeted redemptions
Enable random swaps
Enable targeted swaps
For example, to allow only minting inside the vault, but no redemptions or swaps, this would give a binary value of 10000
as this would equate to true, false, false, false, false
. Converted into an integer value, this would then come out as 16
, which would be passed to the contract.
We can use parseInt
in JS to make this conversion into an integer value simple:
Examples
vaultFees
The fees for the vault, entered in 9-decimal format.
eligibilityStorage
Allows for a vault eligibility storage implementation to be specified for the vault to use. The moduleIndex
will represent the index ID of a valid eligibility module, and the initData
bytes will be passed to the module when initialising. More information about eligibility modules can be found here.
If no module is required, then you can set a moduleIndex
of -1
.
assetTokens
Tokens to be transferred to the vault to populate its initial supply. The vault tokens will be returned to the msg.sender
.
Note: Tokens must all be owned and approved for the zap to use by the sender as a precursor to calling.
An array of token ID values that belong to the specified vault assetAddress
, along with the amount of each token. If you're sending ERC721
tokens, then the amount values will be ignored, though this will be required for ERC1155
tokens to indicate how many of each token ID will be sent to the vault.
Example Call
The below shows an example of an 1155 vault, deployed with 10 tokens across 3 different IDs. We don't have an eligibility module attached, but define features and fees.
Last updated