규칙을 넘는 송금은 못 나가요

전역 정책은 체인 차원의 거버넌스 소관이에요 — 여러분에겐 읽기 전용이지만, 아무도 못 바꾸는 규칙은 아니에요. 한도 값과 면제 조건을 바꾸는 건 외부 전역 policyAdmin이고, 변경 내역은 온체인에 남아 전역 현황에서 대조할 수 있어요. 중요한 변경은 미리 알려드리려고 하지만, 지금 걸려 있는 값은 전역 현황에서 직접 확인하는 게 확실해요. 제재(InDenylist)는 전역 정책 목록에 들어 있는 항목이 아니에요 — 이 앱이 전역 정책을 끝까지 펼쳐 봤을 때 제재 항목은 없었어요. 제재 스크리닝은 별도로 관리되니 따로 확인해야 하고, 내 컨트랙트에만 적용할 차단 주소 목록은 규칙으로 직접 얹을 수 있어요.

막힌 송금은 어떤 규칙이 막았는지 ReasonCode로 되돌려줘요(InDenylist · VolumeAboveMaxLimit). 상태는 전혀 바뀌지 않으니, 그냥 실패한 것과는 달라요.

컨트랙트 정책은 여러분이 이 프록시에 직접 얹는 규칙이에요. 배포한 지갑(정책 admin)이 changeContractPolicies로 갱신하고 removeContractPolicies로 전부 지울 수도 있는 층이에요 — 구현체 업그레이드 권한을 가진 ProxyAdmin 컨트랙트와는 다른 주체예요. 전역 정책은 체인이 정한 읽기 전용 규칙이라 여기선 조회만 돼요. 이 앱이 확인한 집행 지점은 프록시 훅이고, 사용자 호출이 들어오면 preCall에서 두 층을 함께 평가해요(체인 차원에서 더 앞단에 적용되는 경로가 있을 수 있지만 이 앱은 확인하지 못했어요). 두 층은 서로 덮어쓰지 않아요.

아니요 — 사용자 호출은 우회하지 못해요. 여러분이 직접 보내든 에이전트가 대행하든, 프록시로 들어오는 사용자 호출은 같은 훅 파이프라인(preCall → delegatecall → postCall)을 지나요. 프록시에 쌓인 상태와 자금은 프록시 주소로만 움직이니, impl 주소로 직접 보낸 호출은 그 상태를 건드리지 못해요. 예외는 하나예요 — 프록시 admin(ProxyAdmin)의 업그레이드 호출은 fallback을 타지 않아 정책 평가를 거치지 않아요.

impl은 '무엇을 하는가', 컨트랙트 정책은 '무엇을 허용하는가'예요. impl 코드는 온전히 여러분 것이고, 전송 경로만 프록시를 지나요. 정책은 impl 코드와 분리돼 있어서 코드 배포 없이 갱신할 수 있어요. 갱신은 배포한 지갑(정책 admin)이 changeContractPolicies로 보내요 — 지금 이 앱에는 재편집 화면이 없어요.

전역 한도는 인증(KYC)으로 면제될 수 있어요. 건당 한도는 발신자 본인의 인증으로도, 에이전트 소유자 중 한 명의 인증으로도 풀리고, 24시간 누적 한도는 에이전트 소유자 각각의 인증으로 풀려요(전역 정책 두 세트가 모두 “한도 이내 또는 인증” 구조예요). 에이전트를 쓰지 않는 지갑은 이 24시간 한도가 발신자 자신에게 걸리고, 발신자 본인의 인증으로 풀려요(실측). 다만 한도 값과 면제 조건을 정하는 건 외부 거버넌스 소관이에요. 제재(denylist)는 전역 정책 목록에 들어 있는 항목이 아니라서, 여기서는 항상 막힌다고 단정하지 않아요 — 제재 스크리닝은 별도로 확인해야 해요.