PCL Built-in Policy Templates
The six policy templates Maroo ships with V1, covering denylists, volume limits, attestation gates, and tiered KYC variants.
Maroo's PCL ships with six built-in policy templates that cover the most common regulatory and business compliance gates. Each template defines a parameter schema and evaluation logic; administrators instantiate them as UnitPolicy entries with concrete parameters and group them under a GlobalPolicyConfig (network-wide) or ContractPolicyConfig (per-contract). The full canonical list is in x/pcl/types/policies.pb.go; new templates can be registered by governance without touching chain core.
The six V1 templates
| Template | Purpose | See |
| :--- | :--- | :--- |
|
|
|
|
|
|
Click through to each template's page for parameter schema, evaluation logic, ReasonCode behavior, and typical usage.
| :--- | :--- | :--- |
|
DENYLIST_POLICY | Block transactions from listed addresses (sanctions, frozen accounts) | pcl-template-denylist-policy ||
VOLUME_POLICY | Per-tx min/max amount limits per denom (dust prevention, single-tx caps) | pcl-template-volume-policy ||
PERIODIC_VOLUME_POLICY | Cumulative volume limits over a sliding window (24h, 30d) | pcl-template-periodic-volume-policy ||
EAS_POLICY | Require sender to hold a valid EAS attestation under a schema (KYC/KYB gate) | pcl-template-eas-policy ||
OKRW_EAS_TRANSFER_LIMIT_POLICY | Per-tx amount cap that depends on whether sender is EAS-attested (tiered access) | pcl-template-okrw-eas-transfer-limit-policy ||
OKRW_EAS_PERIODIC_VOLUME_LIMIT_POLICY | Cumulative period cap that depends on EAS attestation status (Travel-Rule tier) | pcl-template-okrw-eas-periodic-volume-limit-policy |Click through to each template's page for parameter schema, evaluation logic, ReasonCode behavior, and typical usage.
How they compose
Templates are composable. A typical production
1.
2.
3.
4.
Each UnitPolicy is evaluated independently; rejection on any one of them rejects the whole transaction with the corresponding
GlobalPolicyConfig enforces several at once:1.
DENYLIST_POLICY (sanctioned addresses).2.
OKRW_EAS_TRANSFER_LIMIT_POLICY (un-attested users limited per-tx).3.
OKRW_EAS_PERIODIC_VOLUME_LIMIT_POLICY (un-attested users limited per 24h cumulatively).4.
VOLUME_POLICY (a hard ceiling for everyone, even attested users).Each UnitPolicy is evaluated independently; rejection on any one of them rejects the whole transaction with the corresponding
ReasonCode. This lets you stack independent compliance gates without designing a monolithic policy.Adding new templates
Adding a new template requires a Maroo network upgrade (it's chain-core code). Adding a new UnitPolicy using an existing template requires only a governance proposal — Legal Oracle parameter supply. The pattern is: when regulators introduce a new requirement that maps to existing template logic, configure it via UnitPolicy. When the requirement needs a fundamentally new evaluation path, register a new template in the next upgrade.