Application Handler
Purpose
The Application Handler supports the Application Manager by storing the application level rules data and functions. Procotol supported asset handler contracts call thecheck-application-level-rules function
via the Application Manager. The Application Manager then checks the associated Application Handler where application level rule data is stored. The Application Handler contract also serves as the Application Manager’s connection to the protocol rule processor diamond for the application level rules.
Application Level Rules
Application level rules apply to all assets associated to the Application Manager and handler when set to active. The Application Handler facilitates the rule checks for each application level rule. The first function called by the Application Manager is:Rule Functions
The Application Handler is responsible for setting each application level rule to active or inactive accordingly. Only Rule Administrators may set the status of a rule.Application Manager
Purpose
The Application Manager acts as a central hub for managing the application it is associated with. It provides the ability to manage metadata for accounts associated with the application including:- Roles
- Tags
- Risk Scores
- Access Levels
Admin Roles
The Application Manager can be utilized for both updating and checking an account’s role in relation to the application. These capabilites are provided for the following roles:Super Admin Special Case
The functions are slightly different for a Super Admin. Because there can only be one super admin at a time we use a two-step process to set a new one. The following functions are used in place of the add function the other admin types employ:Access Levels, Risk Scores and Tags
The AppManager contains the functionality used to manage the Access Levels, Risk Scores and Tags associated with accounts, with respect to the application it manages.Associated Contracts
The Application Manager also contains the functionality to register, deregister and check various related contracts, including:- The Application Handler
- Protocol Compliant Tokens
- Treasury
Protocol Asset Handler Diamond Structure
Purpose
The Protocol Asset Handler Diamond serves as the access point to the protocol for a protocol supported asset. The protocol supported asset stores the Handler Diamond proxy address and uses it to call thecheck all rules function
. The Handler Diamond stores all asset level rule data, rule activation status, and connects the token to the App Manager for role based access control.
Asset level rules are set by Rule administrators. When setting a rule status in the Handler the protocol supplied rule id for each rule and the action type are required for the set-rule function
. The Handler Diamond stores each action type and rule together within the Rule Storage Facet.
Each Protocol supported asset type (ERC20, ERC721, etc) will need one handler diamond deployed and connected to the asset. The Handler diamond architecture will remain the same for each asset type. The asset handler diamond will consist of a proxy contract, libraries, storage facets and unique facets for that type. The unique facets for the asset type are found here:

Common Contracts
Each asset handler diamond will inherit from the following contracts:- HandlerBase.sol
- HandlerUtils.sol
- HandlerDiamondLib.sol
- RuleStorage.sol
- StorageLib.sol
- TradingRulesFacet.sol
Protocol ERC 20
Purpose
The Protocol ERC 20 defines the base that contracts must conform to in order to be compatible with the protocol. Using the protocol ERC 20 does not restrict you from inheriting from other internal or external contracts, such as other OpenZeppelin contracts or custom logic contracts specific to your application.Structure
The Protocol ERC 20 inherits from multiple contracts (internal and external), overrides functions from some of the inherited contracts, and defines a few functions of its own. The following contracts are inherited:- ERC20 (external to the protocol)
- ERC165 (external to the protocol)
- EC20Burnable (external to the protocol)
- ERC20FlashMint (external to the protocol)
- ProtocolTokenCommon (internal to the protocol)
- IProtocolERX20Errors (internal to the protocol)
Protocol ERC 721
Purpose
The Protocol ERC 721 defines the base that contracts must conform to in order to be compatible with the protocol. Using the protocol ERC 721 does not restrict you from inheriting from other internal or external contracts, such as other OpenZeppelin contracts or custom logic contracts specific to your application.Structure
The Protocol ERC 721 inherits from multiple contracts (internal and external), overrides functions from some of the inherited contracts, and defines a few functions of its own. The following contracts are inherited:- ERC721Burnable (external to the protocol)
- ERC721URIStorage (external to the protocol)
- ERC721Enumerable (external to the protocol)
- ProtocolTokenCommon (internal to the protocol)
- AppAdministratorOrOwnerOnly (internal to the protocol)