권한과 교체

CUBIT은 식별자가 고정된 핵심, 유지보수 한정 guardian, 주변 모듈 관리 팀을 구분합니다. guardian 만료가 팀 교체 권한을 없애지는 않습니다.

고정되는 항목

주변 setter는 토큰, 주 hook, PoolManager, poolId, 보상 WETH, 레지스트리 앵커를 교체하지 않습니다.

토큰은 일회 연결로 hook을 승인합니다. 확인한 소스에 핵심 세율 setter는 없습니다. 핵심 변경 정책은 새 버전·검증·배포가 필요하며 이전 풀을 자동 갱신하지 않습니다.

guardian은 권한 만료 전 pause(), unpause()를 호출합니다. 정지는 raiseFloor(), rebalance()를 막지만 스왑은 멈추지 않습니다.

GUARDIAN_LIFETIME은 14일입니다. 코드의 guardianExpiry는 hook 생성 timestamp + 14일입니다. 출시 계획에서 J+14라 해도 통합은 실제 컨트랙트 만료를 읽어야 합니다.

기한 후 이전 유지보수 정지는 효력이 없습니다. burnAbsorbed()는 이 정지와 무관하게 접근 가능합니다.

기존 isImmutable()는 핵심 뷰의 이 만료를 뜻하며 생태계 전체 관리 권한 부재를 증명하지 않습니다.

팀은 CubitV2의 authority()입니다. 주변 모듈 관리를 유지하며 다음 네 주소를 교체할 수 있습니다:

Setter	주요 연결 검사	결과
`setVault(next)`	코드 존재, 동일 hook/token/WETH, 새 Vault, 미정산 Vault 없음	향후 예치의 새 기준 컨트랙트
`setRouter(next)`	코드 존재, 동일 hook/PoolManager/poolId	현재 라우터 교체
`setLens(next)`	코드 존재, 동일 hook/PoolManager/poolId/token	현재 읽기 컨트랙트 교체
`setForge(next)`	코드 존재, 동일 hook, 팀 curator	향후 출시 기준 factory 교체

변경마다 ModuleUpdated를 내고 moduleRevision을 증가시킵니다. 작업 전 새 주소와 코드를 확인하세요.

올바른 주소를 선언하는 getter는 예상 연결만 보이고 후보 코드 전체 안전성을 보장하지 않습니다. 향후 구현의 proxy나 악의적 동작 부재도 증명하지 않습니다.

따라서 팀이 향후 작업의 주변 코드를 고릅니다. 각 교체, bytecode, 상호작용을 확인해야 합니다.

Vault 교체는 이전 컨트랙트 CUBIT이나 보상을 옮기지 않습니다. 포지션·기한·출금은 이전 Vault에 남습니다. 레지스트리는 Vault 목록을 유지하며 프런트엔드가 계속 표시해야 합니다.

first-bound 연결과 누적 referral 청구액은 유지됩니다. 이전 라우터는 새 referral 귀속 권한을 잃지만 hook 세금은 그대로 적용됩니다.

Forge 교체는 향후 출시에만 영향을 주며 기존 자식은 컨트랙트를 유지합니다.

setter는 결함 컨트랙트를 소급 수리하거나 보유 자금을 옮기지 않습니다. 온체인 출금 호출 가능성과 프런트엔드 제공 여부를 따로 확인해야 합니다.

승인은 특정 spender에 귀속되며 레지스트리 현재 주소를 따라가지 않습니다. 개정·모듈 변경 시, 특히 승인과 스왑 사이에 프런트엔드는 작업을 재검증해야 합니다.

Links 서명은 EIP-712 도메인의 레지스트리와 체인에 묶입니다. 서명 데이터를 재검토하지 않고 다른 컨트랙트로 돌려서는 안 됩니다.

출처: CubitV2.sol, CubitHook.pause, isPaused, isImmutable, contracts/docs/MODULE_SETTERS.md 및 프런트엔드 검사 releases.ts / vault.ts.

CUBIT / 2026년 9월 10일 출처와 방법