System Architecture
Last updated
Last updated
Knox's vault system sells covered calls and "cash" secured puts on a weekly basis using collateral deposited by users. Liquidity providers deposit their collateral into the Queue, when the epoch ends, queued deposits are transferred into the Vault. Shortly after these deposits are transferred, the Auction contracts begins selling the option selected for the week. At the end of the auction the premiums are sent to the Vault and the options are underwritten.
A Vault is distinguished by its collateral asset (wETH, wBTC, DAI, etc) and option delta. It is therefore possible to deploy multiple vaults carrying different option deltas for the same asset, across a wide range of assets.
Each subsystem is composed of several contracts which follow the “visibility layer” design pattern where an external and internal contract are used to separate logic. External contracts are intended to be called directly by a proxy, users, and other contracts. Internal contracts may be inherited by other internal contracts and external contracts. In most cases, the diamond storage pattern has also been implemented for the purposes of managing the storage layout of the corresponding contracts. The storage layout is a single library which contains state variables available to all external and internal contracts.
The Vault is responsible for managing assets (collateral, premiums), underwriting options positions every week, and performing epoch maintenance. It consists of three "facet" contracts:
VaultAdmin, extends access to privileged functions capable of setting state variables, and performing epoch maintenance.
VaultBase, implments ERC4626 and overrides deposit, mint, withdraw, and redeem functions.
VaultView, read-only functions that expose the vaults state.
Implmentation contracts ("facets") are deployed behind an upgradable/ownable EIP2535 Diamond Proxy. Upon initial deployment, it is required that the setAuction, setPricer, and setQueue functions are called with the correct contract addresses.
The following functions are restricted to the following EOA or contract addresses:
Keeper
initializeAuction, initializeEpoch, processAuction
Owner
setAuction, setAuctionWindowOffsets, setDelta64x64, setFeeRecipient, setKeeper, setPricer, setQueue, setPerformanceFee64x64, setWithdrawalFee64x64
Queue
deposit, mint
The Queue acts as a liquidity buffer for the Vault, LP’s must deposit their collateral into the Queue prior to its deposit into the Vault at the end of the epoch. Implementation contracts are deployed behind an upgradable/ownable proxy contract.
The following functions are restricted to the following EOA or contract addresses:
Owner
pause, setMaxTVL, setExchangeHelper, unpause
Vault
processDeposits
The Auction contract sells options once per week using a Dutch Auction format. Implementation contracts are deployed behind an upgradable/ownable proxy contract.
The following functions are restricted to the following EOA or contract addresses:
Owner
setExchangeHelper
Vault
initialize, processAuction, setAuctionPrices, transferPremium
The Pricer is responsible for determining the strike price, and option max/min price. This contract is not upgradable, nor ownable.