PCL Policy Structure
The 3-tier hierarchy for compliance rules: PolicyTemplate → UnitPolicy → PolicyConfig.
PCL policies are defined using a 3-tier hierarchical structure that promotes reusability and clarity. PolicyTemplates act as blueprints for a rule type. UnitPolicies instantiate these templates with specific parameters and (optionally) a function selector. PolicyConfigs group UnitPolicies to apply them either globally or to a specific contract. (Note: in earlier draft versions this middle tier was called PolicyRef; the canonical name is now UnitPolicy.)
PolicyTemplate
A
Templates are registered and managed by the
PolicyTemplate is the most basic component. It defines the logic and required inputs for a specific type of compliance check. It does not contain any specific values itself, only the schema for them.template_id: A unique identifier, typically the string representation of thePolicyTypeenum (e.g.,"DENYLIST_POLICY").name: A human-readable name (e.g.,"Denylist").description: A brief explanation of what the policy does.param_schema: A JSON schema (as a byte array) defining the structure and types of parameters the policy requires. For example, a denylist schema might be{"denylist": ["address"]}.
Templates are registered and managed by the
PolicyAdmin.UnitPolicy
A
Naming note: previous drafts called this
UnitPolicy is an instance of a PolicyTemplate with concrete parameters. This is the active rule that the engine evaluates.template_id: The ID of thePolicyTemplateto use.parameters: A JSON object (as a byte array, often base64-encoded by clients) that conforms to theparam_schemaof the referenced template. For a denylist, this would be{"denylist": ["maroo1..."]}.selector: (Optional) A 4-byte function selector. If provided, the UnitPolicy only applies to EVM transactions calling a function with this selector. This lets a single contract apply different rules to different functions.
Naming note: previous drafts called this
PolicyRef. The current canonical name is UnitPolicy. Older code paths and identifiers may still surface the old name during the transition; treat them as synonyms.PolicyConfig
A
PolicyConfig is a collection of UnitPolicies that are applied together. There are two types:GlobalPolicyConfig: a list of UnitPolicies enforced on every transaction across the entire Maroo network via thePclAnteDecorator. Managed by thePolicyAdmin.ContractPolicyConfig: a list of UnitPolicies associated with a specific smart contract address. Checked only when a transaction interacts with that contract. EachContractPolicyConfigcarries its ownadminaddress that controls subsequent updates.
Example Hierarchy
1. Template — Maroo provides a
2. UnitPolicy — A
3. Config — This UnitPolicy is added to the
VOLUME_POLICY template with a schema like {"<denom>": {"max_limit": "int"}}.2. UnitPolicy — A
PolicyAdmin creates a UnitPolicy with template_id: "VOLUME_POLICY" and parameters: {"aokrw": {"max_limit": "1000000000000000000000"}}.3. Config — This UnitPolicy is added to the
GlobalPolicyConfig. Now any transaction sending more than 1,000 OKRW (1000 × 10^18 aokrw) is rejected by the network with ReasonCode: VolumeAboveMaxLimit.