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 — every change is visible on-chain and auditable.
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. Parameter updates go through on-chain governance — they're auditable, revocable, and no single entity can unilaterally control the chain. From a dApp builder's perspective the important property is that every change is visible on-chain (with a timestamp), so you can watch for it. The exact key-management and proposal flow lives outside the dApp surface area.
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.