Canary has implemented two types of vault contracts responsible for managing ERC20 and ERC721 assets. The primary function of the ERC20 vault is to act as a restaking aggregator, connecting with various restaking options, such as Symbiotic.
The reviewed contracts have been categorized into three main components: factories and management contracts, receipt tokens, and vaults, which will be detailed in the following sections.
4.1 Factories and Management Contracts
The NFTFactory and TokenFactory contracts serve as factory contracts responsible for creating receipt tokens. Each receipt token is deployed via these factories as a proxy. The factory handles the proper initialization of these tokens and transfers the ownership of the proxy admin to the designated external owner.
The VaultManager and NFTVaultManager contracts operate similarly to the factories but are responsible for the complete initialization of vaults. Initially, they deploy all receipt tokens through the respective factories and subsequently deploy the vault itself, which is initialized by the manager. The vault is created as a proxy to enable upgradability. Furthermore, the MINTER role is assigned to the vault for all receipt tokens, ensuring that only the vault can mint these tokens.
4.2 Receipt Tokens
Receipt tokens come in two variants based on the ERC standard: CanaryNFT, which is minted as a receipt for deposited NFTs in the NFTVault, and clToken, which is minted upon depositing ERC20 assets into the Vault contract.
Each receipt token has a designated withdrawal period, functioning as a notice period before withdrawing the underlying asset from the vault. Each Vault manages three distinct clToken types, each associated with different withdrawal periods: 7 days, 30 days, and 90 days. The NFTVault, however, issues only a single type of CanaryNFT with a 7-day withdrawal period.
All receipt tokens are also pausable, allowing the protocol to halt the transfer of these tokens if needed.
4.3 Vaults
The vaults are categorized into two types: the Vault contract, responsible for managing ERC20 assets, and the NFTVault for handling ERC721 assets. Each vault is designed to manage only one underlying token.
The vault architecture is consistent across both types. Users can deposit the underlying assets via the stake(...) function. For the NFTVault, users specify the tokenId, and in return, they receive a receipt token corresponding to the same tokenId. In the case of the Vault, users specify the amount of ERC20 tokens they wish to deposit along with the index of the clToken they want to receive as receive.
// NFTVault.sol function:
function stake(uint256 tokenId) external;
// Vault.sol function:
function stake(uint256 underlyingAmount, uint256 index) external;
When a user decides to withdraw their underlying asset, they must call the requestWithdraw(...) function, which initiates a withdrawal request and burns the user's receipt token. Once the withdrawal period associated with the receipt token has elapsed, the user can finalize the process by calling the claimWithdraw(...) function to retrieve their asset.
// NFTVault.sol functions:
function requestWithdraw(uint256 tokenId) external;
function claimWithdraw(uint256 tokenId) external;
// Vault.sol functions:
function requestWithdraw(uint256 amount, uint256 index) external;
function claimWithdraw(uint256 index) external;
The Vault contract is designed to function as a restaking aggregator, meaning it has the capability to interact with restaking protocols. To facilitate this, the vault introduces two functions that allow administrators with the SYMBIOTIC_ROLE to deposit and withdraw assets from the Symbiotic vault.
function depositIntoSymbiotic(uint256 amount) public onlyRole(SYMBIOTIC_ROLE)
function withdrawFromSymbiotic(uint256 amount) public onlyRole(SYMBIOTIC_ROLE)
