정책 및 컴플라이언스

마루는 두 가지 별개의 경로를 통해 트랜잭션을 처리합니다. 표준 저위험 활동을 위한 개방 경로(Open Path)와 고가치 또는 규제 자산 전송을 위한 규제 경로(Regulated Path)입니다. PCL이 올바른 경로를 자동으로 결정합니다.

규제는 변합니다. Travel Rule 임계 금액이 바뀌고, 제재 리스트가 갱신되고, 관할권 규칙이 진화합니다. 마루는 정책 엔진 (PCL — 안정적, 거의 변하지 않음)과 파라미터 공급 (Legal Oracle — 법·정책 변화에 따라 갱신)을 분리합니다. 새로운 규제 요구는 파라미터 추가로 — 길어야 새 PolicyTemplate 등록으로 — 흡수되며, 체인 코어 코드는 건드리지 않습니다. Legal Oracle의 파라미터 갱신 권한 자체도 거버넌스로 통제됩니다 — 모든 변경은 온체인에서 가시화되고 감사 가능합니다.

LogicalPolicy와 ForEachPolicy는 단일 규칙을 직접 강제하는 대신 다른 정책들을 조합하는 구조적 정책 템플릿입니다. LogicalPolicy는 자식 정책을 AND 또는 OR 수식자로 묶고, ForEachPolicy는 하나의 자식 정책을 주체 집합(예: 트랜잭션 호출자에 대해 해석된 에이전트 소유자들)에 걸쳐 확장합니다. 각 자식은 pass, fail, skip 중 하나의 단계 결과를 내며, 조합 정책의 결과 축약 동작은 이 세 결과에 대해 정확히 정의됩니다. 자식 정책이 적용 대상이 아닐 때(예: 트랜잭션 자산과 일치하지 않는 VOLUME_POLICY)의 pass / skip 구분은 트리를 설계할 때 중요합니다.

PCL의 모든 ContractPolicyConfig에는 admin 필드가 있으며, 이후 해당 컨트랙트에 대해 changeContractPolicies나 removeContractPolicies를 호출할 수 있는 유일한 주소입니다. 이 admin 슬롯은 컨트랙트 주소당 한 번만 바인딩됩니다. 바인딩 경로는 두 가지입니다. (1) 자동 바인딩 — IPcl.deployPclProxy로 컨트랙트를 배포하면 배포 호출의 EVM msg.sender가 배포 반환 전에 admin으로 기록됩니다. (2) 수동 바인딩 — 레거시 경로에서는 최초의 registerContractPolicies 성공 호출이 슬롯을 바인딩합니다(현재는 deprecated 되었으므로 슬롯이 바인딩된 후에는 changeContractPolicies를 사용합니다). 한 번 기록된 슬롯은 임의의 다른 호출자가 덮어쓸 수 없습니다. admin 교체는 현재 admin이 changeContractPolicies의 config에 새 admin을 지정하는 방식으로만 가능합니다.

마루의 PCL은 스마트 컨트랙트 상호작용에 두 가지 실행 컨텍스트를 제공합니다. 개방형 트랙은 표준 EVM 호출로, 컨트랙트 범위 정책 검사를 우회합니다(전역 정책은 여전히 적용됩니다). 규제 트랙은 IPcl.runOnPcl(...) 또는 PCL 래핑 프록시를 통한 선택적 흐름이며, 래핑된 호출을 실행하기 전에 적용 가능한 모든 전역 및 컨트랙트 범위 정책을 강제합니다. 규제 프레임 내부에서는 대상 컨트랙트가 발생시킨 내부 전송도 관찰하며, 발신자 범위 전역 검사(예: EAS attestation)에서 이 내부 전송을 원래 호출자에게 귀속시킵니다. 따라서 컨트랙트가 자금을 대는 지급이라도 원래 principal이 발신자 컴플라이언스 요건을 충족해야 합니다.

프로그래머블 컴플라이언스 레이어(PCL)는 마루 네트워크의 핵심 모듈로, 블록체인 상에서 직접 컴플라이언스 정책을 생성하고 시행할 수 있게 합니다. 이 모듈은 트랜잭션이 처리되기 전에 가로채어, 전역 및 컨트랙트별 규칙 집합에 대해 유효성을 검사합니다. 이를 통해 스마트 컨트랙트의 핵심 로직을 변경하지 않고도 KYC/AML 확인, 전송 제한, 거래량 한도와 같은 복잡한 규제 요건을 구현할 수 있습니다.

Policy Admin은 호출자가 IPcl.policyAdmin()로 확인할 수 있는 단일 주소 — 내장 PolicyTemplate 등록/제거와 체인 전역 GlobalPolicyConfig 설정/제거 권한을 가집니다. 네트워크의 모든 트랜잭션에 영향을 주는 변경은 이 역할을 거칩니다. admin 슬롯은 체인 파라미터 — 단일 키 보유자가 임의로 가져가거나 다른 주소로 옮길 수 없습니다.

마루의 모든 트랜잭션은 상태 변경 로직이 실행되기 전에 PCL을 통과합니다. 정책 관리자가 설정한 GlobalPolicyConfig의 전역 정책은 모든 트랜잭션에 대해 실행 전에(블록에 포함되기 전에) 평가됩니다. 컨트랙트 관리자가 등록한 ContractPolicyConfig의 컨트랙트 범위 정책은 규제 EVM 호출 경로(runOnPcl / preCall + postCall)로 해당 컨트랙트를 대상으로 하는 트랜잭션에만 적용됩니다. ERC-4337 userOp는 PCL이 번들러가 아니라 실제 principal(UserOperation을 발행한 스마트 계정)을 보도록 언랩됩니다.

PCL은 컴플라이언스 규칙을 JSON 객체가 아니라 Solidity로 정의된 ABI 튜플로 저장합니다. 구조는 3계층으로, PolicyTemplate(정책 관리자가 등록하는 규칙 타입)이 PolicySet(타입 ID + ABI 인코딩 파라미터 blob + 선택적 함수 selector)으로 인스턴스화되고, PolicyConfig(전역 또는 컨트랙트별 설정)에 묶입니다. 초기 초안에서 중간 계층을 PolicyRef라 불렀으나, IPcl 인터페이스의 정식 명칭은 PolicySet이며 policy 필드가 ABI 인코딩된 파라미터 바이트입니다.

PCL은 가장 흔한 규제 및 비즈니스 컴플라이언스 게이트를 포괄하는 일곱 개의 리프 정책 템플릿을 기본 제공합니다. DENYLIST_POLICY, VOLUME_POLICY, PERIODIC_VOLUME_POLICY, EAS_POLICY, OKRW_EAS_TRANSFER_LIMIT_POLICY, OKRW_EAS_PERIODIC_VOLUME_LIMIT_POLICY, AGENT_OKRW_TRANSFER_LIMIT_POLICY가 그 목록입니다. 각 템플릿은 IPcl.sol에 Solidity 파라미터 struct를 정의하며, 호출자는 이를 abi.encode하여 PolicySet.policy에 담습니다. 리프 위에 PCL은 두 개의 조합 템플릿도 노출합니다. LOGICAL_POLICY는 자식 PolicySet들을 AND/OR로 결합하고, FOR_EACH_POLICY는 에이전트의 소유자들에 자식 정책을 확장하여 적용합니다. 자세한 내용은 pcl-composite-policies 컨셉에서 다룹니다.

프로그래머블 컴플라이언스 레이어(PCL) 프리컴파일은 고정 주소 0x1000000000000000000000000000000000000005에 위치하며, 컴플라이언스 관련 모든 작업의 정식 표면입니다. 정책 템플릿 등록, 컨트랙트별 PolicySet 등록, 현재 규칙 조회, runOnPcl을 통한 규제 경로 실행을 담당합니다. 이제 모듈 파라미터를 단일 getParams() view 한 번으로 얻을 수 있으며, 반환되는 PclParams struct는 policyAdmin(템플릿과 전역 정책 등록 권한을 가진 체인 전역 admin)과 entrypoints(계정 추상화 호출에서 실제 principal을 복원할 때 PCL이 신뢰하는 ERC-4337 EntryPoint 주소 배열)를 포함합니다.

PCL로 래핑된 프록시는 IPcl.deployPclProxy(...)를 통해서만 배포할 수 있는 TransparentUpgradeableProxy 변형입니다. 이 프록시의 주소가 PCL 정책 조회 키가 되며, 프록시에 등록된 ContractPolicyConfig는 구현체 업그레이드와 무관하게 동일하게 적용됩니다. 관리자가 아닌 모든 호출에서 프록시의 fallback은 preCall로 PCL 세션을 열고, 원본 calldata로 현재 구현체를 delegatecall한 뒤 postCall로 세션을 닫습니다. PCL 거절은 revert로 그대로 노출됩니다. 관리자 권한 경로는 upgradeToAndCall 하나뿐이며, 프록시 관리자의 다른 호출은 ProxyDeniedAdminAccess로 revert됩니다.

PCL이 거절할 때는 항상 IPcl에 정의된 타입이 있는 Solidity 오류 중 하나를 함께 반환합니다. 지갑과 dApp 코드는 revert 페이로드를 IPcl ABI로 디코드하고, 자유 문자열이 아니라 오류 이름과 인자를 기준으로 UX를 구성해야 합니다. 코드는 크게 세 그룹으로 나뉩니다. 정책 위반 코드(컴플라이언스 규칙 실패), 구성 코드(잘못된 템플릿 id, 파라미터 형식 오류, 구조 제약 위반), 인프라 코드(권한 없는 호출자, ABI 디코드 실패)입니다.

에이전트 지갑이 수행하는 단일 OKRW 전송에 대해, ERC-8004 IdentityRegistry의 온체인 메타데이터(getMetadata(agentId, "TransferLimit"))에 저장된 한도를 적용합니다. 정책 struct 자체에는 설정 필드가 없으며, 상한은 에이전트 소유자가 메타데이터에 입력한 값을 그대로 사용합니다. 비에이전트 발신자에게는 적용되지 않습니다. 사람이 제어하는 계정은 막지 않으면서 에이전트(자동화된 키)가 한 트랜잭션당 옮길 수 있는 가치의 상한을 부과할 때 사용합니다.

DENYLIST_POLICY는 가장 단순한 PCL 내장 정책 템플릿으로, 자금 이동 트랜잭션을 개시할 수 없는 주소 목록을 담습니다. PCL은 각 호출의 principal(일반 트랜잭션의 EOA 서명자 또는 ERC-4337 userOp의 스마트 계정 sender)을 이 목록과 대조하며, principal이 목록에 있으면 실행 이전 단계에서 InDenylist reason code로 거절합니다. 이 목록은 GlobalPolicyConfig로 체인 전역 규칙으로 부착하거나 ContractPolicyConfig로 컨트랙트 범위 규칙으로 부착할 수 있습니다.

발신자가 특정 EAS 스키마로 발행된 유효한 (만료되지 않고 폐기되지 않은) attestation을 보유했는지를 트랜잭션 게이트의 기준으로 삼습니다. KYC, KYB, 자격 증명, 자격 기반 게이트를 구현하는 표준 프리미티브입니다. EAS 프리컴파일을 통해 attestation을 해결하므로 AnteHandler 평가 중 조회가 저렴합니다.

PERIODIC_VOLUME_POLICY의 리셋 주기 누적 추적을 EAS attestation 조건과 결합하여, 미인증 발신자에게는 엄격한 일/월 OKRW 상한을 부여하고 인증 발신자는 이 템플릿의 회계에서 완전히 면제됩니다. Travel Rule 스타일 임계값을 구현하는 표준 프리미티브입니다.

EAS attestation 검사와 건당 OKRW 상한을 결합한 템플릿입니다. 상한은 미인증 발신자에게만 발동되며, 인증된 발신자는 금액과 무관하게 입장이 허용됩니다(다른 적용 정책의 영향은 별도). KYC 계층 접근의 가장 일반적인 프로덕션 패턴으로, 미인증은 소액, 인증은 무제한(또는 다른 정책의 제약을 받음)으로 동작합니다.

설정된 리셋 주기에 걸쳐 발신자별 denom별 누적 트랜잭션 금액을 추적하고, 누적 합계가 한도를 넘는 트랜잭션을 거절합니다. 각 트랜잭션을 독립적으로 검사하는 VOLUME_POLICY와는 구별됩니다. 일/월 전송 상한 및 Travel Rule 스타일 임계값에 사용합니다.

하나 이상의 토큰 denom에 대해 건당 최소·최대 금액 한도를 강제하는 템플릿입니다. 각 트랜잭션은 다른 트랜잭션과 독립적으로 평가되며 롤링 윈도우나 누적 추적은 없습니다. 기간 기반 누적이 필요한 경우 PERIODIC_VOLUME_POLICY 페이지를 참고합니다.

마루는 누구나 지갑을 생성할 수 있는 무허가형 체인입니다. 그러나 거래 상대방의 신원, 거래 규모 및 자산 유형에 따라 트랜잭션을 규제 경로(Regulated Path) 또는 개방 경로(Open Path)로 동적으로 라우팅합니다.

해킹, 피싱, 명백히 불법인 자금 흐름은 실제 결제 시스템에서 발생합니다. 마루는 체인을 롤백하지 않고도 상태를 교정할 수 있도록 범위 제한된 3개의 recovery primitive를 제공합니다. 동결, 소각, 재발행이 그 세 가지입니다. 셋 모두 문서화된 법적 근거가 있고 정해진 절차가 이행된 경우에만 작동하며, 모든 발동은 Observer Node와 거버넌스 감사 로그에 기록됩니다. 상시 개입 장치가 아니며, 법적 근거가 허용하는 한 마루는 과거 이력 재작성 대신 전방 교정(이전 상태를 무효화하는 새 트랜잭션)을 선호합니다.