Legal Oracle

Legal Oracle 입력은 파라미터이지 코드가 아닙니다. 구체적으로:

• DENYLIST_POLICY의 갱신된 denylist (제재 리스트 추가/제거).
• VOLUME_POLICY와 EAS 조건부 변형들의 새 max_limit / min_limit 값.
• PERIODIC_VOLUME_POLICY의 새 기간 정의와 한도.
• EAS_POLICY의 새 schema UID (예: 새 KYC 계층 출시).
• 새로 등록된 정책 템플릿의 새 파라미터.

공급하지 않는 것: 새 정책 로직 (네트워크 업그레이드 필요), 사용자 개인 데이터, 표준 PCL 평가 파이프라인을 우회하는 모든 것.

Legal Oracle은 단일 주체가 아닙니다. 마루 화이트페이퍼 §4.3에 따라 파라미터 갱신은 다음으로 게이팅됩니다:

• 다중 서명 거버넌스 — PCL 파라미터 갱신 제안은 다른 체인 레벨 변경과 동일한 거버넌스 흐름을 거칩니다. 정족수와 승인 임계값은 x/gov 모듈의 파라미터로 설정됩니다.
• 임계 분산 키 분배 — 시간 민감한 갱신 (예: 새 제재 대상 추가)의 경우 임계 암호로 위임된 서명자 셋이 전체 거버넌스 없이 서명 가능하지만, 그 권한 자체는 거버넌스로 부여·회수됩니다.

순효과: 규제기관과 권한 있는 당사자가 시기적절한 파라미터 갱신을 공급할 수 있되 일방적으로 체인을 통제하지는 못합니다. 모든 갱신은 온체인이며, 감사 가능하고 회수 가능합니다.

마루 위에서 빌드한다면, Legal Oracle은 대체로 보이지 않습니다 — 트랜잭션은 현재 활성 파라미터를 사용해 PCL이 평가합니다. 왜 중요한가:

1. 정책은 정적이지 않다. dapp이 의존하는 VOLUME_POLICY의 max_limit이 거버넌스로 갱신될 수 있습니다. UI에 파라미터 값을 하드코딩하지 말고 체인에서 쿼리하세요 (또는 구체 금액을 테스트하려면 policy.preflight 사용).
2. 컴플라이언스는 움직이는 표적. 오늘 적용 안 되는 규정이 내일 적용될 수 있습니다. PCL 위에 빌드한다는 것은 체인의 컴플라이언스 자세가 진화하는 것을 상속받는다는 뜻 — 모든 규제 변화를 직접 추적할 필요가 없습니다.
3. 감사와 예측 가능성. 파라미터 변경이 거버넌스 이벤트이므로 공개되고 날짜가 찍힙니다. 다른 온체인 상태와 동일한 감사 가능성으로 "블록 N 시점에 효력 있던 규칙"을 추론할 수 있습니다.