System Architecture

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.

Vault 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.

Access Control

The following functions are restricted to the following EOA or contract addresses:

ActorFunction

Keeper

initializeAuction, initializeEpoch, processAuction

Owner

setAuction, setAuctionWindowOffsets, setDelta64x64, setFeeRecipient, setKeeper, setPricer, setQueue, setPerformanceFee64x64, setWithdrawalFee64x64

Queue

deposit, mint

Queue Contracts

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.

Access Control

The following functions are restricted to the following EOA or contract addresses:

ActorFunction

Owner

pause, setMaxTVL, setExchangeHelper, unpause

Vault

processDeposits

Auction Contracts

The Auction contract sells options once per week using a Dutch Auction format. Implementation contracts are deployed behind an upgradable/ownable proxy contract.

Access Control

The following functions are restricted to the following EOA or contract addresses:

ActorFunction

Owner

setExchangeHelper

Vault

initialize, processAuction, setAuctionPrices, transferPremium

Pricer Contracts

The Pricer is responsible for determining the strike price, and option max/min price. This contract is not upgradable, nor ownable.

Last updated