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 범위 밖입니다.

Legal Oracle은 단일 주체가 아닙니다. 파라미터 갱신은 온체인 거버넌스를 통해 이루어지며 모두 감사·회수 가능합니다 — 어떤 한 주체도 체인을 일방적으로 통제할 수 없습니다. dApp 빌더 입장에서 중요한 점은 모든 변경이 타임스탬프와 함께 온체인에 기록되어 빌더가 이를 모니터링할 수 있다는 것입니다. 키 관리와 제안 흐름의 세부 사항은 dApp 표면 영역 밖에 있습니다.

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

1. 정책은 정적이지 않습니다. dapp이 의존하는 VOLUME_POLICY의 max_limit이 거버넌스로 갱신될 수 있습니다. UI에 파라미터 값을 하드코딩하지 말고 체인에서 쿼리합니다(또는 구체 금액을 테스트하려면 policy.preflight를 사용합니다).
2. 컴플라이언스 요구사항은 계속 바뀝니다. 오늘 적용되지 않는 규정이 내일 적용될 수 있습니다. PCL 위에서 개발하면 체인의 컴플라이언스 상태가 변화할 때마다 자동으로 반영되며, 모든 규제 변화를 직접 추적할 필요가 없습니다.
3. 감사와 예측 가능성이 보장됩니다. 파라미터 변경은 거버넌스 이벤트이므로 공개되고 날짜가 기록됩니다. 다른 온체인 상태와 같은 수준으로 감사 가능하기 때문에, "블록 N 시점에 효력 있던 규칙"을 추론할 수 있습니다.