Before we get into the architecture in detail, we would like to give credit to Maker DAO and UniSwap as inspirations for designing Probity. Probity draws inspiration from those project and even utilizes some of the concepts directly.


Probity is designed to be modular. Every module (besides Vault Engine) is made to be replace-able and upgradeable. With the Vault Engine contract at the center handling all the important accounting, every other module within the Probity system acts as an auxiliary to make sure that the core accounting is done correctly. The Governance address acts as the "system admin" with absolute authority over the system. Governance can be either a single key holder or a smart contract which enables customized governance functionality. For example, a governance contract could have a permission system built-in to grant key holders specific permissions to a perform actions within Probity.

Vault Engine

Vault Engine is the core accounting module with all the necessary data such as asset prices, rate accumulators, and account balances stored in this module. Other modules calculate data and update variables within Vault Engine to keep the variables relevant.


The Registry contract stores system contract addresses and their roles within the system. Registry allows Probity contracts to verify that a contract caller has the required role and restricts the callable methods to those roles only.

Asset Managers

The different Asset Managers types are NativeAssetManager, ERC20AssetManger, and VPTokenAssetManager. Each type of Asset Manager contract handles only one particular asset.
The Asset Manager contract holds tokenized assets that are deposited by users. When a user deposits the asset, their user account is credited in Vault Engine with the deposited amount. When the user withdraws, it debits the user balance in Vault Engine and credits the amount to the external user wallet.


The Treasury contract facilitates issuance and redemption of the ERC20 USD tokens that are created via lending. Treasury also does this for the ERC20 governance token, PBT.


The Teller's role is to calculate 1) the interest rate based on current utilization ratio (i.e., outstanding debt-to-equity), 2) rate accumulators based on the interest rate and last updated timestamp, and 3) protocol fees based on rate accumulators and all open positions. Teller updates the rate accumulators stored in Vault Engine.

Price Feed

The Price Feed contract fetches the current price for an asset using an oracle system. The current implementation only supports the FTSO (Flare Time Series Oracle) system of the Flare Network, and it calculates an adjusted price which is defined as the price multiplied by the liquidation ratio. Then, the Price Feed updates the adjusted price in Vault Engine.


Liquidator checks for under-collateralized debt positions and starts the liquidation process by auctioning off the collateral with the intent to sell the asset in return for US dollars. See Liquidation for more info.


Handles the bidding and actual sale of liquidated assets. See Auction Start for more details.

Reserve Pool

The Reserve Pool contract holds Probity's reserve funds (AKA, "retained earnings") and system debt. See Reserve Pool & Bond Sale for more details.

Bond Issuer

When the Reserve Pool holds too much system debt, Probity will fundraise via debt financing in order to help bring the system back to solvency. Based on time elapsed after the sale started, the bond buyer can get more debt tokens per issuance. Bond tokens are redeemable 1:1 for the Reserve Pool retained earnings.


When shutdown is initiated, all normal functionalities are paused in order to start the global net settlement process. After the final calculation, USD token holders should redeem the token from the shutdown module and in return receive a basket of assets that could be worth up to one dollar. In the case that there are many under-collateralized debt positions and not enough funds to cover them, the basket of assets may worth less than one dollar.