šCreating a Pool
Step-by-step guide to creating your first Blend Vault
Last updated
Step-by-step guide to creating your first Blend Vault
Last updated
The information provided by Aloe Labs, Inc. (āwe,ā āusā or āourā) on docs.aloe.capital (the āSiteā) is for general informational purposes only. All information on the Site is provided in good faith, however we make no representation or warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of any information on the Site.
Under no circumstance shall we have any liability to you for any loss or damage of any kind incurred as a result of the use of the site or reliance on any information provided on the site. Your use of the site and your reliance on any information on the site is solely at your own risk.
Aloe Blend is decentralized and permissionless, so anyone can deploy a pool. Unlike some other "permissionless" protocols, pool creators have no special access or control. Once a pool is deployed, all users are treated equally. Note: Pool creators do choose what silos are attached to the new pool. If they write nefarious silo code, they could rug-pull users. As such, it's important to read through silo code before interacting with a Blend pool.
~1 ETH you're willing to part with
the Aloe Blend repository, cloned and yarn installed or extreme confidence in your Etherscan skills
the address of the underlying Uniswap V3 pair
Deployment costs are dependent on gas prices, as well as the cardinality of the underlying Uniswap V3 oracle. It's also cheaper to use existing silos than it is to deploy new ones.
When a Blend pool is first deployed, it'll create a very wide liquidity position in the underlying Uniswap V3 pair. Once Blend detects that 10% (or less) of earned yield is sufficient to compensate bots for rebalance()ing, it will start scaling position width based on implied volatility. This implied volatility is computed from Uniswap oracle data, so you'll need to make sure the Uniswap pair has sufficient oracle cardinality.
We recommend increasing the Uniswap oracle cardinality before creating a Blend pool, but it's not strictly necessary. In most cases, it'll take a few weeks for the contract's internal trackers to equilibriate. Only then will it start calculating implied volatility. If you haven't increased cardinality by then, rebalance() transactions will fail until you (or someone else) remembers to do so.
To increase Uniswap oracle cardinality, follow these steps:
Open scripts/poke_oracle.js and scroll to the bottom. Write/modify lines to call increaseOracleCardinality(poolAddress, gasPrice) where poolAddress is the address of the Uniswap pair and gasPrice is expressed in wei (so 100 gwei would be entered as 100e9)
By default, the oracle cardinality is increased by 300. Assuming every block contains at least 1 transaction that interacts with the pair and a block is mined every 13 seconds, this corresponds to hours of oracle data. Blend requires at least 1 hour and will use up to 24 hours if available. Just be careful to provide enough gas when increasing cardinality, and spread your calls out over multiple blocks if necessary.
Once you're satisfied that everything looks correct, open a terminal in the repository's root directory and run npx hardhat run scripts/poke_oracle.js --network mainnet. Assuming you've configured your .env file correctly, this will send a transaction from the DEPLOYER account.
Note: This step is pointless if the Uniswap Pair's cardinality is too low.
Similar to the Factory contract, the VolatilityOracle is independent of the Blend pool itself. As such, you have to initialize it separately. To do so, follow these steps:
Visit the Volatility Oracle contract page on Etherscan
Connect your wallet and select cacheMetadataFor
Enter the address of the Uniswap pair you've chosen and click "Write"
After that transaction is confirmed, select estimate24H, enter the same address as before, and again click "Write"
That's it!
Every Blend pool is associated with two silos: silo0 and silo1. When Blend detects that liquidity wouldn't be productive in Uniswap, it instead deposits it to these silos. token0 is placed in silo0 and token1 is placed in silo1. It is crucial that the silos can actually handle their corresponding ERC20s.
You can read more about existing silos here and the code is available here. If you want to deploy a new instance of something like FuseFTokenSilo or implement a new silo altogether, we assume you know what you're doing. Feel free to reach out on Discord or open a PR on GitHub so that we can document your work.
This is the easy part. Open another terminal in the Aloe Blend repository's root directory and run:
This script will prompt you for information as needed, validate inputs, and verify whether the underlying Uniswap pair and Volatility Oracle are ready to go. If everything looks good, a new Blend pool will be deployed and the script will spit out another command you can run to verify the new contract on Etherscan.
Example:
