For technical documentation, see departments


Departments in Mezzanine are analogous to departments in a typical organization. They are used to separate different business units to better delegate tasks related to the operation of the organization. Similar to a company's treasury, departments in Mezzanine are multi-signature wallets. Specifically, they are Safe (formerly Gnosis Safe) wallets.

Departments, like the organization's treasury, can have sub-departments, their sub-departments can have sub-departments, and so on. The number of departments in an organization is bespoke and determined by its needs.

Access control of departments resembles a tree-like data structure. A department can manage any of its sub-department's signers, its sub-department's sub-departments, and its sub-department's modules. Access to the organization's treasury's funds behaves similarly: to spend funds, a department must have approvals from its parent, its parent must have approval from its parent, and so on. A department must approve its respective sub-departments and modules for them to access funds.

As multi-signature wallets, departments can spend funds at their discretion. They can interact with any other smart contract outside of the Mezzanine system, such as Uniswap, OpenSea, among others.

Giving spending powers comes with risks. To address this, a department's ancestors will be able to block its multi-signature functionality from interacting with specified contracts or specified functionality within contracts. For example, a parent of a department can prevent a department from interacting with all Uniswap contracts, or the parent could disable the department from borrowing on AAVE while maintaining the ability to lend. This type of enforcement can be completed in one of two ways:

  1. A whitelist

  2. A blacklist

By default, departments are created with a blacklist on Mezzanine's interface. A department will not be able to interact with any specified functions or contracts on this list. This list is managed by the department's parent. Conversely, this blacklist can be swapped for a whitelist by the department's ancestors. Departments subjected to a whitelist will not be able to interact with any contract, including itself, via its multi-signature functionality until it is whitelisted by its parent. This includes ERC20 smart contracts, meaning departments subjected to a whitelist will not be able to transfer funds outside of the Mezzanine protocol until they are permitted to do so. Under certain circumstances, such as during a company's recapitalization, a department's whitelist or blacklist will be controlled by shareholders.

We recommend that the threshold of the department's multi-signature functionality be at least two. The signers should also be trusted individuals. However, these suggestions are not enforced on-chain.

The majority of departments in larger Mezzanine organizations will solely be able to:

  • Spend and transfer funds

  • Add other departments and modules as children

Their standalone functionality is notably limited and stems from smart contract size limits. However, the insertion of modules enables a plethora of functionality.

Last updated