Modules in Mezzanine are standalone contracts that contain bespoke functionality. They are designed to be flexible and interchangeable. Modules usually contain specific logic for various types of spending assets (payroll, recurring payments, vesting, selling/distributing equity) or receiving money (billing, invoicing, subscriptions, streaming, token gating, ecommerce). To start with, a limited number of modules are available from Mezzanine. The long-term objective is to allow any developers to create and integrate many types of modules to provide companies a wide range of choices.

Modules will often be a sole function of a particular department. For example, a company may create a "payroll" department and augment it with a "streaming payroll" module. The payroll department would have authority to use the module and spend up to the amount granted by the treasury (board). Modules may have additional safeguards, protections, and approvals, depending on their design.

Technical teams can easily create custom modules in Mezzanine to suit their needs (or as 3rd party software for other Mezzanine companies). Mezzanine provides a base Module contract that can be inherited for hierarchical spending and access control. For more information about creating a module, see Creating a Custom Module.

Notably, the admin-like functionality of modules should be similar to that of departments. For example, a subscription module may contain admin-like functionality to determine pricing. This pricing, in turn, should not only be controlled by its parent but all of the module's ancestors.

In the above examples, both the Treasury and the Finance Department would be able to determine the pricing in the subscription module.

This hierarchical access control will be available for all Mezzanine-created modules but cannot be enforced for user-created modules due to their bespoke nature.

Last updated