Roles & Permissions
Every enterprise system needs a way to determine who can do what. In the Web2 world, this is handled by access control tools like Google Admin, Okta, or Rippling. These platforms manage Identity and Access Management (IAM) through role-based access control (RBAC), ensuring the right people have the right permissions at the right time.
Mezzanine takes this concept one step further: we use public keys and smart contracts to enforce access control directly onchain. If you can prove control of a wallet with the correct credential, then you can take actions—whether that’s viewing documents, changing records, proposing transactions, or approving onchain transfers. There are no passwords to reset, no centralized systems to compromise, and no risk of rogue admins changing permissions behind closed doors.
At Mezzanine, roles and credentials are one of only two things stored onchain (the other being assets). This decision is deliberate: it guarantees that only the organization itself can modify its access settings. The result is a level of access control that exceeds Web2 standards, ensuring organizational integrity through mechanical enforcement, not just policy.
Core Roles
Mezzanine organizations start with a predefined hierarchy:
- Signer – Holds the highest authority, can manage Admins
- Admin – Can manage Support roles
- Support – Can manage Members and any permissions granted by admins
- Member – Have any permissions granted by admins
- Public – what people can see if they have no credentials
Permissions are configured as a tree structure. This top-down hierarchy creates clear and auditable pathways of authority, while still allowing for flexibility and rapid delegation.
In the next version, organizations will be able to define custom roles and arbitrary groups that match their operating structure.
Onchain and Offchain Permissions
Permissions can grant access to both:
- Onchain actions, such as moving assets or adding a signer
- Offchain data, such as updating a CRM contact, editing a document, or issuing a payment
Each application added from the Mezzanine App Store can define its own permission set. Common permission types include:
- Viewer – Determines whether the app appears in a user’s interface
- Editor – Grants the ability to modify offchain data
- Approver – Grants onchain signing or transaction approval rights
Built on Hats Protocol
Mezzanine’s permissioning is built on Hats Protocol, an open standard for onchain IAM. By using Hats, we guarantee portability, extensibility, and security. Any external system that recognizes Hats roles can interact with Mezzanine’s permission structure out of the box.
No Need to Rebuild
For developers, this means one simple thing: you don’t have to rebuild roles and permissions. Every app on Mezzanine inherits this shared architecture. Developers can focus on the logic of their product, not infrastructure. IAM works out of the box—across documents, contacts, transactions, and third-party integrations.
Updated on: 04/08/2025