Legal Oracle
The governance-controlled feed that supplies PCL with up-to-date regulatory parameters — without touching the policy engine itself.
Regulations change. Travel-Rule thresholds shift, sanctions lists update, jurisdictional rules evolve. Maroo separates the policy engine (PCL — stable, rarely changes) from the parameter supply (Legal Oracle — updated as laws and regulations evolve). New regulatory requirements are absorbed by adding a parameter — or, at most, registering a new PolicyTemplate — without touching chain core code. The Legal Oracle's authority to update parameters is itself governance-controlled, with multi-signature and threshold-key safeguards.
What flows through the Legal Oracle
Legal Oracle inputs are parameters, not code. Concretely:
It does NOT supply: new policy logic (that requires a network upgrade), private user data, or anything that bypasses the standard PCL evaluation pipeline.
- Updated denylists for
DENYLIST_POLICY(sanctions list adds/removes). - New
max_limit/min_limitvalues forVOLUME_POLICYand its EAS-conditional variants. - New period definitions and limits for
PERIODIC_VOLUME_POLICY. - New schema UIDs for
EAS_POLICY(e.g. when a new KYC tier is rolled out). - New parameters for newly-registered policy templates.
It does NOT supply: new policy logic (that requires a network upgrade), private user data, or anything that bypasses the standard PCL evaluation pipeline.
Authority and key management
The Legal Oracle is not a single party. Per the Maroo whitepaper §4.3, parameter updates are gated by:
The net effect: regulators and authorized parties can supply timely parameter updates without unilaterally controlling the chain. Every update is on-chain, auditable, and revocable.
- Multi-signature governance — proposals to update PCL parameters go through the same governance flow as other chain-level changes. Quorum and approval thresholds are set by the
x/govmodule's parameters. - Threshold-key distribution — for time-sensitive updates (e.g. a new sanctions list addition), a delegated signer set with threshold cryptography can sign without waiting for full governance, but their authority is itself granted and revocable through governance.
The net effect: regulators and authorized parties can supply timely parameter updates without unilaterally controlling the chain. Every update is on-chain, auditable, and revocable.
Why this separation matters for developers
If you're building on Maroo, the Legal Oracle is mostly invisible — your transactions are evaluated by PCL using whatever parameters are currently active. The reason it matters:
1. Policies are not static. A
2. Compliance is a moving target. Regulations that don't apply today may apply tomorrow. Building on PCL means you inherit the chain's compliance posture as it evolves — you don't have to track every regulatory change yourself.
3. Audit and predictability. Because parameter changes are governance events, they're public and dated. You can reason about "the rules in effect at block N" with the same auditability as any other on-chain state.
1. Policies are not static. A
VOLUME_POLICY your dapp depends on may have its max_limit updated through governance. Don't hard-code parameter values into your UI; query them from the chain (or use policy.preflight to test concrete amounts).2. Compliance is a moving target. Regulations that don't apply today may apply tomorrow. Building on PCL means you inherit the chain's compliance posture as it evolves — you don't have to track every regulatory change yourself.
3. Audit and predictability. Because parameter changes are governance events, they're public and dated. You can reason about "the rules in effect at block N" with the same auditability as any other on-chain state.