Properties Registry and Access Control
What is the Registry
The MetaPropertyRegistry contract serves as a centralized registry and access management system. Its primary role involves facilitating the recording and organization of Categories and their Properties, and oversees the assignment of their designated managers (see Property Managers). This module also manages access roles, allowing for the identification, approval, and potential revocation of minters for ODCs. Hence, the MetaPropertyRegistry, through its features and direct interaction with the ODC Core, plays a vital role in shaping the Governance aspect of the Nexera protocol.
At present, the deployer of the Nexera protocol holds the primary authority over the MetaPropertyRegistry.
As part of our forward-looking strategy, we are planning to transition Governance responsibilities and management rights to a DAO-governed Registry.
Whitelisting Features
The MetaWhitelisting facet of the ODC Core introduces user-centric access control features, empowering both protocol users and ODC owners. Users can create and manage whitelists associated with their accounts, approving specified addresses to mint their ODCs. Additionally, they have the ability to create and associate whitelists with the IDs of the ODCs they own, approving addresses specified in these whitelists to manage the properties within the respective ODCs.
Before being effective, the addresses within these whitelists must have prior approval as minters or registration as Property Managers through the MetaPropertyRegistry.
Nexera "DEFAULT" Whitelist
Within the whitelisting features, a key component is the "DEFAULT" whitelist, encompassing addresses of Property Managers subjected to thorough audits and official approval by Nexera. Addresses included in the said whitelist are automatically endorsed as minters and Property Managers by default for all users and ODCs within the Nexera ecosystem.
Significantly, the "DEFAULT" whitelist is exclusively managed by the deployer of the Nexera Protocol, ensuring a robust level of trust and oversight. While it functions as a foundational configuration for users, it's essential to underscore the system's user-centric adaptability. Users not only have the autonomy to remove the "DEFAULT" whitelist from their set of whitelists, enabling a customized approach to access control within the protocol, but they also retain the flexibility to include it back when needed.