파라미터 변경은 포럼 표가 게시되거나 투표가 통과됐다고 적용되는 것이 아니다. 최종 payload가 어떤 계약의 어떤 setter를 어떤 값으로 호출하는지 읽고, timelock 뒤 실행 거래와 이벤트, 현재 getter 값을 대조해야 한다. 제안 토론 중 수치가 바뀌거나 여러 네트워크 중 일부만 실행될 수 있으므로 자산·시장·체인·단위와 기준 블록을 함께 기록한다.
포럼의 숫자는 제안값일 뿐이다
리스크 서비스 제공자가 새 담보비율이나 공급한도를 제시하면 토론 과정에서 숫자와 대상이 바뀔 수 있다. 포럼 첫 글의 표, Snapshot 결과, 온체인 제안 설명이 서로 다르면 가장 나중의 최종 payload와 실행 상태를 기준으로 한다. 수정 이력이 보이지 않는 요약 기사만으로 현재 값을 판단하지 않는다.
Aave의 공개 설명은 프로토콜 설정 변경이 governance가 투표하는 payload 계약으로 구성되고, 승인 뒤 executor가 실행한다고 밝힌다. typed config engine을 사용하면 의도가 읽기 쉬워지지만 payload가 실제로 올바른 네트워크·자산·값을 담았는지는 여전히 검토해야 한다.
파라미터 뉴스의 최종 숫자는 제안서 표가 아니라 실행 뒤 계약이 반환하는 값이다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 포럼의 숫자는 제안값일 뿐이다
리스크 서비스 제공자가 새 담보비율이나 공급한도를 제시하면 토론 과정에서 숫자와 대상이 바뀔 수 있다.
- 이름이 같은 값도 범위와 단위가 다르다
LTV, liquidation threshold, liquidation bonus, supply cap, borrow cap은 서로 다른 위험을 조절한다.
- 투표 통과와 실행 사이에는 지연이 있다
민감도에 따라 다른 executor와 timelock이 적용될 수 있다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
이름이 같은 값도 범위와 단위가 다르다
LTV, liquidation threshold, liquidation bonus, supply cap, borrow cap은 서로 다른 위험을 조절한다. 담보비율을 80에서 75로 낮추는 것과 liquidation threshold를 낮추는 것은 이용자 여유와 청산 시점에 다른 영향을 준다. 특정 자산 한도인지 시장 전체 한도인지, isolated mode나 eMode 값인지 확인한다.
스마트계약은 퍼센트를 BPS, WAD, RAY 또는 토큰 decimals로 표현할 수 있다. 500을 500%가 아니라 5%로 해석하는 식의 단위 실수가 흔하다. UI 표시값, payload 상수, getter 반환값을 같은 단위로 환산하고 변화량과 최종값을 둘 다 검산한다.
| 단계 | 확인 대상 | 자주 생기는 차이 |
|---|---|---|
| 포럼 제안 | 자산·시장·현재값·목표값 | 토론 중 수정 |
| 투표 metadata | 제안 설명과 IPFS 내용 | 오래된 표·링크 |
| payload 코드 | setter·인자·체인 | 단위·주소·방향 오류 |
| 실행 거래 | executor·calldata·이벤트 | 부분 실행·실패 |
| 현재 상태 | getter와 기준 블록 | 후속 변경으로 값 재변경 |
투표 통과와 실행 사이에는 지연이 있다
민감도에 따라 다른 executor와 timelock이 적용될 수 있다. Aave의 거버넌스 설명은 일상 파라미터와 거버넌스 자체를 바꾸는 고위험 작업을 서로 다른 수준으로 다루고, 실행 전 지연을 둔다. 투표 종료 시각에 현재값이 바뀌었다고 쓰면 안 된다.
지연 중에는 시장 상황이 바뀌어 제안을 취소하거나 새 payload로 교체할 수 있다. queue 상태, 예정 실행 가능 시각, grace period, 실제 execute 거래를 확인한다. cross-chain 변경은 메시지가 목적지 체인에서 전달·실행됐는지도 별도 확인한다.
위임된 steward는 권한 경계를 함께 본다
DAO가 모든 소규모 변경을 전체 투표로 처리하지 않고 Risk Steward 같은 주소에 제한 권한을 줄 수 있다. 이 경우 ‘거버넌스 투표 없음’이 곧 무단 변경을 뜻하지 않는다. 위임 계약의 허용 파라미터, 한 번에 바꿀 수 있는 최대 폭, cooldown, 만료, 취소 권한을 확인한다.
2026년 공개된 Aave V4 Risk Steward 제안은 fixed cooldown과 maximum change per update 안에서 revocable delegated authority를 주는 구조를 설명한다. 제안 상태의 문서는 실제 활성화 증거가 아니므로, 채택 여부와 현재 역할을 온체인에서 별도로 확인해야 한다.
- 자산·시장·체인·파라미터 이름을 정확히 고정한다
- 제안값과 최종 payload 상수를 같은 단위로 환산한다
- executor 수준·timelock·목적지 체인 실행을 추적한다
- getter와 이벤트로 현재 적용값을 검증한다
- steward라면 변경 폭·cooldown·만료·취소 권한을 확인한다
숫자 변경이 이용자 포지션에 미치는 영향을 계산한다
담보 파라미터가 바뀌면 동일 가격에서도 health factor가 달라질 수 있다. 공급·차입 cap이 낮아져도 기존 포지션이 즉시 줄어드는지, 신규 행동만 제한되는지는 구현에 따라 다르다. 수수료는 적용 시점 이후 누적분에만 영향을 줄 수도 있다. 공지는 계약 동작과 대상 이용자를 구체적으로 적어야 한다.
가정 예시를 만들 때는 현재 담보 가치, 부채, liquidation threshold를 명시해 변경 전후를 계산한다. 실제 이용자는 여러 담보와 부채를 보유할 수 있어 단일 자산 예시와 결과가 다르다. 가격 변동·이자 누적·오라클 갱신도 동시에 작용하므로 안전 여유를 숫자 하나로 보장하지 않는다.
실행 뒤 모니터링이 변경 검증의 마지막 단계다
거래가 성공했어도 예상하지 않은 이벤트, cap 도달, 청산 증가나 프런트엔드 표시 오류가 생길 수 있다. payload simulation의 예상 state diff와 실제 실행 후 state diff를 비교하고, 관련 시장 지표와 오류를 정해진 관찰 기간 동안 본다.
기사에는 적용 블록과 확인일을 표시한다. 후속 변경이 잦은 파라미터를 영구적인 현재값처럼 쓰지 않고 공식 getter나 최신 거버넌스 페이지로 독자를 안내한다. 과거 변경은 당시 의사결정과 결과를 설명하는 기록으로 남긴다.
자주 묻는 질문
투표가 통과되면 파라미터가 바로 바뀌나요?
항상 그렇지 않다. timelock과 별도 execute, cross-chain 전달이 남을 수 있다.
포럼 표와 온체인 값이 다르면 무엇을 믿어야 하나요?
최종 payload와 실행 거래, 현재 getter를 우선하고 왜 제안 수치가 바뀌었는지 수정 이력을 확인한다.
BPS 500은 500%인가요?
일반적으로 10,000 BPS가 100%여서 500 BPS는 5%지만 해당 계약의 단위 정의를 반드시 확인한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
