Complete Guide on Uniswap V4

이 글은 2025년 1월 출시된 Uniswap V4에 대해 알아보며, 전체적인 동작 원리와 Hook 생태계를 다루고 있습니다. 이 글은 투자 조언이 아니며, 필자는 Uniswap 및 해당 글에서 언급된 어떠한 프로젝트와도 관련이 없습니다.

배경

Uniswap의 역사: V1 & V2

V4에 대해 더 자세하게 들여다보기 전에, 맥락을 위해 Uniswap이 프로토콜을 어떻게 발전시켜 왔는지 알아봅시다. Uniswap은 V1부터 현재 V4까지 약 7년이 넘는 세월에 걸쳐 프로토콜을 빌딩해 왔습니다.

2017년 만들어진 Uniswap V1은 매우 단순한 AMM이었습니다. 코드의 총 길이가 약 500줄이라는 점에서 그 단순성을 확인할 수 있죠. 이러한 단순성을 기반으로 Uniswap V1은 기존에 존재하였던 AMM들보다 더 가스비가 저렴하다는 장점을 가지고 있었습니다. 다만, V1에서는 ETH와 ERC20 토큰 간의 스왑만을 지원하여 ERC20 토큰 간의 스왑을 하려면 ETH를 거쳐야 한다는 비효율성이 존재하였습니다.

2020년 5월 런칭된 Uniswap V2는 이러한 문제를 해결하는, 더 발전된 구조를 가지고 있었습니다. Uniswap V2는 ERC20 토큰 간에도 풀을 생성할 수 있도록 만들어, 두 토큰 간 직접적인 스왑이 가능한 구조를 통해 V1의 비효율을 해결하였습니다. 또한 오라클이 추가되어 V2 풀에서 직접 가격을 쿼리할 수 있게 하거나, 플래시론이 지원되어 트레이더들이 안전하게 자금을 빌려 차익거래를 할 수 있게 만드는 등, 여러 가지 발전된 기능들이 제공되었습니다.

그러나, Uniswap V2에도 문제가 존재하였습니다. 이는 게으른 유동성이라고 불리는 문제입니다. 이에 대해 예를 들어서 알아보겠습니다.

Alice가 Uniswap V2에서 USDC-ETH 풀에 1000달러만큼의 유동성을 공급했다고 생각해봅시다. 그 유동성은 ETH의 가격과 상관없이, 0부터 무한대의 가격 레인지에 균등하게 분배됩니다. 그 이후 Bob이 해당 풀에서 스왑을 진행하여, ETH의 가격이 3000달러에서 3100달러로 상승하였다고 가정해봅시다.

그런데 이 스왑에서 실제로 사용된 Alice의 유동성은 그녀가 공급한 1000달러 중 극히 일부에 불과합니다. 대부분의 유동성은 가격이 변하는 동안에도 거래에 직접적으로 관여하지 않은 채 그대로 남아있게 됩니다. 이러한 현상을 “게으른 유동성(Lazy Liquidity)” 문제라고 합니다.

이 문제는 스테이블코인 간의 풀에서 더 두드러지게 나타났습니다. 스테이블코인의 가치는 1달러에 고정되어있는 경우가 대부분이며, 디페깅이 발생하는 경우는 극히 드뭅니다. 즉, 스테이블코인 페어 간의 거래는 대부분 1달러 근처에서 이루어집니다. 하지만 Uniswap V2에서는 유동성이 전 가격대에 걸쳐 균등하게 분배되기 때문에, 실제 거래에 영향을 미치는 유동성은 일부에 불과하고, 나머지 유동성은 거의 활용되지 않은 채로 남아있게 됩니다. 이는 DEX 전반에서, 특히 스테이블코인 페어에서 자본 효율성을 악화시키는 문제로 이어지게 됩니다.

Uniswap V3

Uniswap V3에서는 위 Uniswap V2의 문제를 해결하기 위해, 집중화된 유동성이라는 개념을 도입하였습니다. 이는 유동성 공급자(LP)들이 각각 본인의 유동성이 적용될 가격 범위를 결정할 수 있게 하는 메커니즘입니다.

(Concentrated Liquidity in Uniswap V3 | Source: Uniswap V3 whitepaper)

위 그림처럼, 집중화된 유동성 하에서는 LP들이 유동성을 공급할 가격 범위를 결정할 수 있습니다. 같은 크기의 유동성이더라도 현재 가격과 가깝게 가격 범위를 설정하면 유동성의 ‘밀도’가 높아집니다. 이때 스왑이 발생하면, 수수료는 LP가 공급한 유동성의 밀도에 비례해 주어지기 때문에, 가격을 좁게 설정한 LP들은 더 많은 수수료 수익을 얻을 수 있습니다. 즉, LP 입장에서는 가격 변화에 알맞게 범위를 좁게 설정해 유동성을 공급하는 전략이 더 유리하다고 생각할 수 있습니다. 이는 현재 가격에 가깝게 유동성을 모으는 효과를 발생시켜, 풀 전체적으로 자본 효율성을 높이고 슬리피지를 줄이는 효과를 주게 됩니다.

이에 대한 대표적인 예시로, 현재 Ethereum 메인넷 위 Uniswap V3의 USDC-DAI 풀을 들 수 있습니다. 아래 그림과 같이, 현재 USDC-DAI 풀 내 대부분의 유동성은 0.9998달러부터 1.0002 달러 사이에 모여 있는 것을 확인할 수 있습니다.

(DAI-USDC Pool at Uniswap V3 | Source: app.uniswap.org)

이는 유동성 공급자들이 DAI와 USDC의 디페깅이 일어나지 않을 것이라고 예측해, 1달러 부근에 유동성을 몰아놓은 것입니다. 이렇게 유동성이 밀집되어있는 구조는 LP들에게 더 많은 스왑 수수료를 챙겨줄 뿐만 아니라, 트레이더에게도 더 적은 슬리피지를 제공할 수 있다는 장점을 가집니다.

한편, Uniswap V3에도 문제가 있었습니다. 이는 다음과 같이 두 가지로 요약될 수 있습니다.

1. 획일화된 코드베이스로 인한 확장성 제한

Uniswap V3에서는 모든 풀이 동일한 코드를 가지고 있도록 되어 있습니다. 이는 Uniswap V3 내 모든 사용자들의 니즈를 충족시킬 수는 없다는 본질적인 한계로 이어졌습니다. 이를테면, Uniswap V3 풀 코드에 내장된 오라클 기능은 전문 트레이더 및 데이터 제공자들에게 매우 유용하였지만, 스왑을 하는 사용자들의 비용을 증가시킨다는 단점이 있었습니다. 또한, 코드를 제공된 대로 사용하여야 했기 때문에, Uniswap의 유동성을 기반으로 지정가 주문 등의 커스텀한 기능을 구현하기 어렵다는 단점도 존재하였습니다.

즉, Uniswap V3 하에서 Uniswap은 ‘잘 구현된 토큰 거래소’이긴 했으나, 빌더들을 이끌 수 있는 ‘유동성 플랫폼’으로 발전하지는 못하였습니다.

2. 가스비 개선 필요성

Uniswap V3의 가스비는 타 DEX들에 비해선 저렴한 축에 속했으나, 그럼에도 스왑 한 번에 20만 가스 이상이 소모되었고, 특히 여러 풀을 거쳐 Routing을 해야 할 때는 배로 많은 가스비가 소모되었습니다. 이 높은 가스비를 개선한다면, Uniswap의 사용자 경험은 훨씬 좋아질 것으로 예상되었습니다.

Uniswap V4는 무엇을 혁신하는가

Uniswap V4는 위에서 제시된 V3의 문제점을 해결하기 위해 스왑을 보다 효율적으로 만들고, 확장성을 높여 더 다양한 빌더들이 Uniswap의 유동성을 활용할 수 있게끔 하는 프로토콜입니다. Uniswap V4는 어떤 메커니즘을 가지고 있고, 이를 활용하면 어떠한 유즈케이스를 만들어낼 수 있을까요?

우선, Uniswap V4에서 새로 추가된 기능들에 대해 알아보겠습니다. Uniswap V4의 기본 풀 구성 자체는 Uniswap V3와 유사하게 집중화된 유동성 구조를 택하고 있습니다. 그러나 Uniswap V4는 다음과 같이 세 가지 측면에서 새로운 기능 및 구조를 도입하여, Uniswap V3보다 나은 사용자 경험을 제공하려고 하고 있습니다.

• Singleton Architecture
• Flash Accounting
• Hook

각각의 의미와, 이것들이 어떠한 이점을 가져다줄 수 있는지에 대해 더 자세히 알아봅시다.

Singleton Architecture

이전 Uniswap V3까지는 코드를 Factory / Pool 두 개로 나누어, 풀이 생성될 때마다 Factory에서 새로운 풀 컨트랙트를 생성했었습니다. 그러나 Uniswap V4에서는 PoolManager라는 이름의 컨트랙트 하나로 모든 풀을 관리합니다. 이러한 구조를 통해, 여러 풀을 거쳐야 하는 스왑을 실행할 때 풀 간의 Routing을 훨씬 저렴하게 만들 수 있습니다.

(Swap Routing at Uniswap V4 vs. V3 | Source: Uniswap Blog)

예를 들어 ETH를 USDC로 바꾸고, USDC를 OP 토큰으로 바꾸는 Routing 작업을 수행한다고 생각해봅시다. V4 이전에는 ETH-USDC풀에 ETH를 넣고 USDC를 받아, 이를 다시 USDC-OP 풀로 전송하여 OP를 받는 방식이었습니다. 그러나 V4에서는 단순히 각 풀에 대해 내부 잔고 변화 정보만을 바꿔 기록해주는 방식으로 Routing을 수행할 수 있습니다. 중간 중간에 풀마다 잔고를 수정하는 것이 아니라 한 컨트랙트 내에서 처음과 마지막에만 잔고를 수정하므로, Routing 프로세스가 매우 단순해지고 저렴해졌다고 볼 수 있습니다.

또한 풀 배포 비용도 매우 저렴해졌습니다. 이전에 풀을 배포하려면 별도의 풀 컨트랙트를 배포해야 했고, EVM에서 컨트랙트 배포는 비싼 액션에 속하기 때문에, 적지 않은 비용이 들었습니다. 그러나 V4에서는 별도의 컨트랙트 배포 없이 PoolManager 컨트랙트 내 함수를 호출하면 되기 때문에, 이전과 비교했을 때보다 배포 비용을 약 99% 이상 아낄 수 있습니다.

EIP-1153을 통한 Flash Accounting

Uniswap V4에 도입된 두 번째 핵심 기능은 Flash Accounting입니다. 이는 스왑이나 유동성 공급 등의 액션을 처리할 때, 독특한 “부채 정산” 모델을 사용해 가스비를 줄이는 혁신적인 방식입니다.

Uniswap V4에서는 스왑이나 기타 액션이 실행되는 동안 풀과 사용자 간에 발생하는 부채를 각각 추적하는 메커니즘이 존재합니다. 그리고 모든 액션이 종료될 때, 시스템은 반드시 풀과 사용자 간의 모든 부채가 완전히 정산되도록 합니다.

예를 들어서 알아보겠습니다. 우선 Uniswap V4에서 사용자가 스왑을 한다고 할 때, 이 액션에 참여하는 객체는 아래와 같이 세 개로 구성되어 있습니다.

1. 사용자: Router 컨트랙트에 스왑을 요청합니다.
2. Router: 사용자의 토큰을 받아, Uniswap 코어 컨트랙트에 이 토큰을 전달하고 스왑을 요청합니다.
3. PoolManager: Router의 요청을 받아 핵심 로직을 수행하고, 사용자가 요청한 만큼의 토큰을 전달합니다.

위 세 개의 객체 간 일어나는 일들을 그림으로 표현하면 아래와 같습니다.

(Initial Swap Process at Uniswap V4)

우선 사용자가 DEX 인터페이스와 상호작용해 스왑을 요청하면, Router는 스왑에 필요한 데이터와 힘께 PoolManager의 unlock 함수를 호출합니다. 이 함수는 컨트랙트 내에서 기록하고 있는 잔고 정보를 ‘잠금 해제’하여서, 잔고 수정을 가능하게끔 하겠다는 의미입니다.

해당 함수의 목적은 다음과 같은 두 가지로 요약할 수 있습니다.

1. 한 트랜잭션에서 두 번 ‘잠금해제’하는 것을 방지하여 재진입 공격을 막음.
2. 실제 모든 액션을 수행하는 Router의 콜백 함수를 호출.

실제 스왑 및 정산 등 모든 실질적인 액션은 Router 내의 콜백 함수(unlockCallback) 내에서 발생하며, 이 콜백 함수는 PoolManager 내 여러 함수들을 호출하여 사용자가 요청한 액션을 수행합니다.

스왑 상황에서, unlockCallback 이 수행하는 액션은, 사용자와 풀의 잔고를 조정하고 정산을 수행하는 것입니다. 이 과정은 다음과 같은 두 단계로 나눠질 수 있습니다.

1. 잔고 수정 및 부채 계산
2. 부채 정산 및 스왑 마무리

이를 그림으로 표현하면 다음과 같습니다.

(Debt Settlement Process at unlockCallback() function at Uniswap V4)

이때 중요하게 봐야하는 것은, 이 트랜잭션에서 수행되는 전체 작업 전후로 불변해야만 하는 값이 있다는 것입니다. 대표적으로, 사용자와 풀 간의 상호 부채를 나타내는 delta는 트랜잭션 시작 시와 종료 시 그 값이 0으로 불변해야만 합니다.

EVM에는 이러한 성격을 가진 값에 사용할 수 있는 공간이 존재합니다. 이는 ‘transient storage’라고 불리는 저장 공간으로, 2024년 Dencun 업그레이드에 적용된 EIP-1153에 의해 도입되었습니다. transient storage는 일반적인 EVM의 스토리지와 동일하게 동작하나, ‘한 트랜잭션 내에서만’ 유효하다는 특징이 있습니다. 즉, 어떤 트랜잭션을 통해 transient storage에 저장된 모든 값은 해당 트랜잭션이 끝날 때 아래와 같이 초기화됩니다.

(Mechanism of Transient Storage)

값이 임시로 저장되며 이더리움의 스토리지 용량을 늘리지 않기 때문에, transient storage에 값을 저장하고 읽는 액션들은 일반 스토리지에 대한 액션에 비해 매우 저렴하게 가격이 매겨져 있습니다. 이를테면 빈 스토리지에 값을 저장하는 액션의 가스는 20,000인데에 비해, transient storage에 값을 저장하는 액션에는 100 가스밖에 소모되지 않습니다.

Uniswap V4의 부채 정산 메커니즘은 이를 활용하여 가스비를 절감합니다. V4에서는 부채를 나타내는 delta 를 transient storage에 저장하도록 하고 있습니다. 이를 통해, 기존이라면 십만 가스 이상이 소모되었던 액션의 비용을 몇백 가스 수준으로 줄여, 스왑 및 정산 과정에서 드는 가스비를 최소화할 수 있습니다. 뿐만 아니라, Uniswap V4에서는 재진입 공격 방어에 사용되는 재진입 가드에도 transient storage를 사용하여 추가적으로 가스비를 절약합니다.

정리하자면, Uniswap은 유니크한 ‘부채 정산’ 모델을 도입하여 transient storage를 사용하는게 유리하게끔 프로토콜을 설계하였고, 스왑 등 사용자의 가스비를 Uniswap V3에서보다 훨씬 더 저렴하게 만들었습니다.

실제로 Uniswap에서 스왑을 시도해보면 이 가스 효율성의 효과를 쉽게 확인해볼 수 있습니다. 아래는 Hayden Adams가 직접 0.3 ETH를 USDT로 스왑하고자 했을 때 Uniswap의 Router가 최적의 경로를 찾아준 상황으로, 이때 Uniswap V4 내 ETH-USDT 풀은 유동성이 약 400K 밖에 되지 않았음에도 Router는 가장 효율적인 경로로 V4 풀을 택한 것을 확인할 수 있습니다.

(Uniswap Routing Result for ETH-USDT swap | Source: Hayden Adams X)

Router는 슬리피지, 가스 수수료 등 모든 요소들을 종합적으로 고려하여 스왑 경로를 찾는데, 위 스왑의 경우는 V4의 높은 가스 효율성으로 인해 V4 풀이 알고리즘에 포함된 것입니다. 이러한 V4의 특성으로, V4 풀에는 더 많은 스왑 요청이 전달될 것이고, 해당 풀의 LP들은 더 많은 수익을 벌게 될 수 있습니다.

Hooks

Hook은 Uniswap V4에 새로 등장한 기능 중 가장 중요한 기능입니다. Uniswap V3를 포함한 대부분의 이전 DEX들에서 사용자들은 프로토콜이 제공하는 기능만을 사용할 수 있었다면, Uniswap V4는 Hook을 통해 풀 배포자가 풀을 직접 커스텀할 수 있도록 하여, 풀 배포자의 입맛에 맞는 다양한 기능들을 Uniswap 풀에 붙일 수 있도록 합니다. 이를 통해, Uniswap V4의 풀들은 사용자들에게 유리한 여러 기능들을 제공할 수 있게 됩니다.

Uniswap은 V4 블로그 포스트에서 Hook을 통해 다음과 같은 기능들이 구현되길 기대한다고 이야기하였습니다.

• TWAMM
• 변동성에 따른 동적 수수료 기능
• 온체인 지정가 주문
• 가격 범위를 벗어난 유동성을 대출 프로토콜에 예치
• 커스텀 온체인 오라클
• LP 수수료 자동 재예치
• MEV 수익을 LP에게 재분배

Hook은 어떻게 동작하길래 이러한 기능들이 구현될 수 있다고 이야기하는 걸까요? 그리고 해당 기능을 활용하면 이외에도 어떠한 유즈케이스가 도입될 수 있을까요? 또, 실제로는 어떠한 것들이 빌딩되고 있을까요? 이제부터 이러한 관점을 바탕으로, Hook에 대해 아주 자세히 알아보도록 하겠습니다.

Uniswap V4 Hook 딥다이브

Hook의 일반적인 동작 방식

프로그래밍에서 Hooking이라는 행위는, 소프트웨어 컴포넌트 간 오가는 함수 호출, 메세지, 이벤트 등을 가로채서 소프트웨어 동작의 기능을 변경하거나 확장하는 행위를 의미합니다. 그리고 이렇게 가로챈 메세지, 함수 호출 등의 처리를 담당하는 컴포넌트를 Hook이라고 하죠. 이러한 패턴은 주로 디버깅이나 소프트웨어 기능 확장에 사용됩니다.

Hook의 다섯 가지 기능

Uniswap V4에서는 이 프로그래밍 패턴을 통해, 빌더들이 DEX의 기능을 확장할 수 있게끔 하고 있습니다. Uniswap V4에서 Hook은 다음과 같이 크게 다섯 가지 기능을 가질 수 있습니다.

함수 이름에서 알 수 있듯이, Uniswap V4에서는 어떠한 액션을 수행하기 전후로, 해당 액션을 위해 사용되는 데이터를 Hooking해서 커스텀한 액션을 수행할 수 있도록 합니다. 예를 들어, beforeSwap은 사용자의 스왑 액션을 수행하기 전에 호출되어, Hook 개발자가 정의한 작업을 실행하고, 그 이후에 PoolManager에서 스왑을 실행합니다.

Hook마다 위 기능들 중 하나의 함수만 사용해도 되지만, 여러 개의 함수를 동시에 가질 수도 있기 때문에, 개발자들은 Uniswap V4 내의 거의 모든 사용자 액션에 본인이 원하는 로직을 붙일 수 있습니다.

Hook의 형태

Uniswap V4에서 Hook은 풀과 분리된 별도의 스마트 컨트랙트로 존재합니다. 풀을 배포할 때, 배포자는 해당 풀에서 사용할 Hook의 주소를 지정해야 하며, 한 번 설정된 Hook은 변경할 수 없습니다. 단, 하나의 Hook은 여러 개의 풀 사이에서 공유될 수 있습니다.

특히 중요한 점은, 동일한 거래 페어(예: USDC-ETH)와 동일한 수수료 구조를 가진 풀이라도, 어떤 Hook이 적용되었느냐에 따라 서로 다른 풀로 간주된다는 점입니다. 이전 Uniswap V3에서는, 동일한 거래 페어 내에는 수수료 크기가 다른 6가지의 풀만 존재할 수 있었습니다. 반면 Uniswap V4에서는 같은 수수료 크기를 가지더라도, 오라클 기능이 포함된 풀, 지정가 주문이 가능한 풀 등 서로 다른 기능을 가진 수많은 USDC-ETH 풀이 존재할 수 있습니다.

정리하자면, Uniswap V4에서는 Hook을 활용해 특정 기능이 결합된 커스텀 풀을 구성할 수 있으며, 이는 기존 버전과의 주요 차별점입니다.

여기서 다음과 같은 궁금증이 들 수 있습니다.

1. 정말로 Hook에 임의의 로직을 붙일 수 있는가?
2. Hook으로 어떤 수준의 로직까지 구현할 수 있는가?

이러한 질문의 답에 대해 더 자세히 알아보도록 하겠습니다.

Hook의 내부 동작 방식

Hook의 코어 로직

Hook이 내부적으로 어떻게 동작하는지 알려면, Hook 내의 함수들이 어떻게 구성되어있는지 알아야 합니다. Uniswap은 V4에서 Hook이 어떠한 형태의 데이터를 받고, 어떠한 데이터를 내뱉는지를 정의해두었습니다. 이번 섹션에서는 Hook 내 함수들의 형태를 같이 살펴보면서, Hook이 Uniswap V4의 컨트랙트로부터 어떤 데이터를 받아 오는지, 그리고 그 데이터를 활용해 어떠한 일들을 할 수 있는지 확인해보겠습니다.

가장 대표적인, beforeSwap / afterSwap 함수를 예시로 알아보겠습니다. beforeSwap 함수는 PoolManager 컨트랙트 내 스왑 로직이 실행되기 전 호출되며, PoolManager로부터 다음과 같은 다섯 가지 데이터를 전달받습니다.

즉, Hook 입장에서는 풀에서 스왑이 실행될 때마다 다음과 같이 다양한 정보들을 얻을 수 있는 것입니다.

1. 누가 스왑을 요청했는지
2. 요청된 스왑의 양은 얼만큼인지
3. 요청된 스왑이 특정 토큰을 사는 것인지 파는 것인지
4. 요청된 스왑의 최대 슬리피지는 얼마인지

로직을 실행하고 나면, beforeSwap 함수는 다음과 같은 값들을 PoolManager에게 반환합니다.

여기서, Uniswap V4의 Hook은 단순한 확장 기능이 아니라, 풀과의 상호작용을 통해 스왑 과정에 개입할 수 있는 강력한 메커니즘을 제공한다는 것을 알 수 있습니다. Hook에서의 반환 값 중 아래 두 가지 값인 beforeSwapDelta와 lpFeeOverride를 활용하면, 스왑 프로세스와 수수료 체계를 유연하게 조정할 수 있기 떄문입니다.

첫 번째로, beforeSwapDelta는 위에서 언급했던 Uniswap V4의 부채 청산 모델과 연결된 값입니다. Uniswap V4에서는 스왑 과정에서 Router와 풀이 서로 빚을 지고 이를 나중에 청산하는 구조를 가집니다. 마찬가지로, Hook도 풀과 부채 관계를 형성할 수 있으며, 이를 통해 스왑 과정에 더욱 적극적으로 개입할 수 있습니다. 예를 들어, Hook이 사용자의 스왑 요청량 중 일부를 수수료로 가져가거나, 특정 거래에서 리베이트를 제공하는 등의 로직을 구현할 수 있습니다. 즉, beforeSwapDelta를 활용하면 단순한 거래 중개를 넘어, 스왑의 흐름을 조정하고 그 결과에 직접적인 영향을 미칠 수 있는 모델을 설계할 수 있습니다.

뒤에서 더 자세히 설명하겠지만, Hook이 이 값을 반드시 반환해야 하는 것은 아닙니다. Hook 중에는 이 값을 반환하지 않는 Hook이 있을 수도 있으며, 그러한 형태의 Hook은 스왑 메커니즘과는 상관 없는 액션을 수행하게 됩니다.

두 번째로, lpFeeOverride는 Uniswap V4에서 제공하는 동적 수수료 기능과 관련된 값입니다. Uniswap V4에서는 특정 조건에 따라 유동적으로 수수료를 조정할 수 있으며, 이러한 수수료 변경은 오직 Hook을 통해서만 가능합니다. 동적 수수료는 두 가지 방식으로 구현될 수 있습니다.

첫 번째 방식은 풀의 수수료를 영구적으로 변경하는 것입니다. Hook은 updateDynamicLPFee 함수를 호출하여 특정 이벤트(예: 시장 변동성 증가, 유동성 부족 등)에 맞춰 수수료를 조정할 수 있습니다. 이를 활용하면, 변동성이 높은 시점에는 수수료를 높여 LP의 수익을 극대화하고, 거래가 적은 기간대에는 수수료를 낮춰 거래량을 유도하는 등 풀 운영을 더욱 유연하게 조정할 수 있습니다.

두 번째 방식은 특정 액션에서만 임시로 수수료를 변경하는 것입니다. lpFeeOverride 값을 설정하면 기본 수수료는 변경되지 않고, 특정 사용자나 특정 조건에서만 일시적으로 새로운 수수료가 적용됩니다. 예를 들어, 특정 NFT를 보유한 사용자에게는 수수료를 할인해주거나, 스마트 계정을 이용하는 사용자에게만 별도의 우대 수수료를 적용하는 방식으로 활용할 수 있습니다. 이러한 구조를 통해, Uniswap V4는 풀마다 개별적인 거래에 대해 맞춤형 수수료 정책을 적용할 수 있으며, 이는 기존 AMM 방식에서는 구현하기 어려운 차별화된 기능입니다.

정리하자면, beforeSwap 함수를 통해 Hook은 크게 다음과 같은 세 가지 작업을 수행할 수 있습니다.

1. 권한 컨트롤

Uniswap V4의 Hook은 beforeSwap 함수의 인자를 통해 PoolManager로 스왑을 요청한 주소를 확인할 수 있습니다. 이를 활용하면 특정 조건을 만족하는 사용자만 스왑을 수행할 수 있도록 권한 컨트롤 기능을 구현할 수 있습니다. 예를 들어, 특정 NFT를 보유한 사용자만 거래할 수 있는 풀을 만들 수도 있습니다.

그러나 여기서 주의할 점은, 사용자가 직접 PoolManager에 스왑 요청을 보내는 것이 아니라는 것입니다. 대부분의 경우 사용자는 Router를 통해 PoolManager와 상호작용하며, 결국 Hook이 beforeSwap을 통해 확인하는 sender 정보는 실제 사용자 주소가 아닌 Router 주소입니다.

따라서, Hook 내부에서 직접적인 권한 검사를 수행하는 것이 아니라, 특정 Router를 지정하고, 해당 Router가 권한 컨트롤을 담당하는 방식이 일반적입니다. Hook은 어떤 Router를 통해 스왑이 실행될지 결정하는 역할을 하고, 실질적인 접근 제한 로직은 Router에서 구현되는 구조입니다.

2. 스왑 로직 개입

Uniswap의 Hook은 스왑 로직에도 직접적으로 개입할 수 있습니다. Hook은 PoolManager로부터 사용자가 요청한 스왑의 정보들을 모두 받을 수 있고, 이를 기반으로 사용자의 트레이드에 동적으로 개입해 결과를 바꿀 수 있습니다.

이를 활용하면 다양한 사용 사례를 만들어낼 수 있습니다. 단순하게 이를 활용하여 커스텀한 스왑 로직을 구현할 수도 있습니다. Uniswap V4의 기본 스왑 로직은 집중화된 유동성을 기반으로 하고 있고, 이는 가격 구간을 여러 개의 틱(tick)으로 나눈 다음 한 틱 내에서 xy=k 형태의 CPMM 알고리즘이 적용되는 방식입니다. Hook을 사용하면 이 스왑 알고리즘에 커스텀한 로직을 더할 수 있기 때문에, 풀의 형태에 맞는 새로운 스왑 알고리즘을 사용할 수 있습니다. 예를 들어, 스테이블코인 페어에 대해 Curve 스타일의 Stableswap 알고리즘을 적용하여 더욱 슬리피지를 줄이고, 큰 규모의 스왑을 원하는 트레이더에게 더 유리한 환경을 제공할 수 있습니다.

3. 풀 수수료 변경

마지막으로, Hook은 풀의 LP들이 받는 수수료를 동적으로 조정할 수 있습니다. 이러한 동적 수수료 메커니즘은 여러 경우에서 매우 유용하게 사용될 수 있으며, 특히 LP들에게 유리한 옵션이 될 가능성이 큽니다.

가장 대표적인 동적 수수료 메커니즘은, 변동성에 따라 수수료를 조정하는 모델입니다. 한쪽 방향으로 변동성이 커지면 일반적으로 LP들은 비영구적 손실(Impermanent Loss)을 입게 되고, 나아가 LVR(Loss-Versus-Rebalancing)로 인해 손해도 볼 수 있게 됩니다. 이에 대한 보완책으로, 변동성이 커지면 수수료를 더 크게 부과하는 형태의 동적 수수료를 적용해 LP의 전반적인 수익을 늘리고, 유동성을 더 깊게 만들 수 있습니다.

여기서 기억해야 하는 점은, Hook이 풀의 수수료를 항상 조정할 순 없고, ‘동적 수수료를 쓰겠다’고 선언된 풀의 수수료만을 업데이트할 수 있다는 점입니다. 즉 고정 수수료로 배포된 풀에 대해서 사용자는 수수료가 변할 걱정 없이 스왑을 진행할 수 있습니다.

How Hooks Are Installed In The Pools

그렇다면 Hook은 풀 내에 어떻게 설치되는 것일까요? 아무 Hook이나 풀에 설치될 수 있는 걸까요? 답부터 이야기하자면 그렇지 않습니다.

Uniswap V4에서는 아무 Hook이나 풀에 자유롭게 설치할 수 없습니다. PoolManager가 풀을 배포할 때, 해당 풀과 함께 설치될 Hook의 ‘주소’를 검증하는 과정을 거치도록 설계되어 있습니다.

Hook 컨트랙트는 본인의 ‘주소’를 통해, 본인이 가지고 있는 기능들을 PoolManager에게 알려줍니다. 여기서 중요한 부분은 주소의 마지막 네 자리(16비트)입니다. 이 16비트 값을 통해 Hook이 어떤 함수들을 구현하고 있는지를 나타낼 수 있습니다.

예를 들어, Hook 컨트랙트의 주소가 ‘0x4f....00C0’의 형태를 가진다고 해봅시다. 여기서 뒷 네자리는 ‘00C0’이고, 이를 2진수 형태로 변환하면 다음과 같습니다.

0000 0000 1100 0000

여기서 각 비트(0 또는 1)는 특정 함수의 구현 여부를 의미합니다. 비트가 1이면 해당 Hook이 해당 기능을 구현하고 있으며, 0이면 구현되지 않았음을 의미합니다.

이 값에서 각 비트(0 또는 1)는 특정 함수의 구현 여부를 의미합니다. 예를 들어, 뒤에서 14번째에 있는 자리의 비트는 beforeInitialize 함수가 구현되었는지를 나타내며, 0이면 구현이 되지 않았음을, 1이면 구현이 되었음을 의미합니다. 여기서는 뒤에서 7번째와 8번째 비트만이 1로 되어 있으니, 이 Hook은 두 가지 함수만이 구현되어 있음을 알 수 있습니다. 각 자리마다 구현되어 있는 함수의 종류를 나타내면 다음과 같습니다.

예제의 00C0 값(0000 0000 1100 0000)을 보면, 뒤에서 7번째(beforeSwap), 8번째(afterRemoveLiquidity) 비트가 1로 설정되어 있습니다. 이는 이 Hook이 beforeSwap과 afterRemoveLiquidity 함수만을 구현하고 있음을 의미합니다.

이렇게 Hook의 주소를 가지고 Hook의 역할을 설정하는 것은, 전체적인 가스비를 줄이기 위함입니다. Uniswap V4에서는 Hook이 어떤 기능을 가지고 있는지 미리 알 수 있어야 가스비를 절약할 수 있습니다.

만약 이러한 방식을 택하지 않는다면, PoolManager가 Hook에 어떤 함수가 구현되었는지 모르는 상태에서 실행해야 하기 때문에, 모든 가능성을 고려하여 모든 함수 호출을 시도해야 합니다. 그러나 이렇게 하면 실제론 동작하지 않는 함수들도 불필요하게 호출되며, 이는 가스비 낭비로 이어집니다.

예를 들어, 어떤 Hook에 beforeSwap 함수만 구현되어있다고 가정해봅시다. 그러나 PoolManager 컨트랙트는 해당 Hook에 어떤 함수가 구현되었고 어떤 함수는 구현되지 않았는지 알 방법이 없기 때문에, beforeSwap 뿐만 아니라 afterSwap 등 다른 함수들이 호출되어야 하는 상황이 왔을 때, 해당 함수를 직접 호출하지 않으면 해당 함수의 구현 여부를 알 수 없습니다. 즉, 실제론 아무런 역할을 하지 않는 함수들도 하나하나 호출해서 구현 여부를 확인해야 한다는 의미입니다.

그러나 위와 같은 방식을 사용하면, Hook의 주소 자체가 어떤 함수들이 구현되었는지를 미리 나타내기 때문에, PoolManager에서의 불필요한 함수 호출을 사전에 방지할 수 있습니다. 즉, Hook 주소만 확인하면 어떤 함수만 실행하면 되는지 미리 알 수 있기 때문에, 불필요한 호출을 건너뛰어 가스를 절약할 수 있습니다.

위 표에서 마지막 4개의 항목(returns delta가 붙은 함수)은 해당 Hook이 스왑 또는 유동성 공급 과정에서 결과를 변경했는지를 나타내는 기능입니다. 예를 들어, 어떤 Hook이 beforeSwap 함수에서 스왑 결과를 수정했다면, beforeSwapDelta 값을 반환할 것이며, 이를 Hook 주소의 마지막 3번째 비트(beforeSwap (returns delta))를 통해 표시해야 합니다. 이러한 구조는 스왑이나 유동성 공급 과정에서 아무런 영향을 미치지 않는 Hook이 불필요한 연산을 하지 않도록 설계되어, 추가적인 가스비 절감이 가능하도록 합니다.

그런데 여기서, Hook의 기능은 주소의 마지막 16비트에 의해 결정되기 때문에, Hook 개발자는 원하는 기능에 알맞는 주소를 직접 찾아 배포해야 합니다. 이를 어떻게 할 수 있을까요?

EVM의 CREATE2 opcode을 활용하면 같은 스마트 컨트랙트 코드라도 특정한 salt 값을 설정하여 원하는 주소에 배포할 수 있습니다. 이 방식은 "주소 마이닝(Address Mining)"이라고 불리며, Hook 개발자들은 이를 통해 적절한 salt 값을 찾아 원하는 주소를 얻어야 합니다.

CREATE2를 사용하면, 스마트 컨트랙트 주소는 다음과 같은 공식에 의해 결정됩니다.

address = keccak256(0xff + sender + salt + keccak256(init_code))

• 0xff → CREATE2를 나타내는 특정 바이트
• sender → 컨트랙트를 배포하는 주소
• salt → 개발자가 설정할 수 있는 임의의 값
• init_code → 배포될 컨트랙트의 바이트코드

즉, 같은 코드라도 salt 값을 변경하면 주소가 달라지기 때문에, 개발자는 특정한 salt 값을 찾아 원하는 주소의 끝자리를 맞출 수 있습니다.

그러나 이는 분명히 개발자 경험을 해칠 수 있습니다. Hook을 실제로 배포해야 할 때 주소를 찾아주어야 하기 떄문도 있지만, Hook을 테스팅해볼 때도 매번 주소를 맞추어 테스트를 돌려야 하기 때문입니다. 이에 Uniswap에서는 테스트 코드 내에서 주소 마이닝을 쉽게 수행할 수 있는 HookMiner라는 라이브러리를 제공하고 있습니다. 개발자들은 이를 활용하여 테스트 내에서 Hook 주소를 찾아, Hook의 기능들을 쉽게 테스트해볼 수 있습니다.

(V4 Hook Address Mining Tool | Source: v4hookaddressminer.xyz)

또한, 실제 배포 과정에서는 더 쉽게 UI를 통해서 Hook의 주소를 마이닝할 수 있습니다. 이는 사용자가 직접 원하는 Hook 기능을 선택하면 자동으로 적절한 salt 값을 찾아주는 기능을 지원하는 툴입니다. 이를 통해, 개발자는 번거로운 계산 없이 원하는 기능을 가진 Hook을 쉽게 배포할 수 있습니다.

Hook에서 고려해야 하는 것들

위에서 Hook의 동작 방식과, 이를 통해 Uniswap이 확장성을 갖출 수 있다는 점에 대해서 알아보았습니다. 반면, 이러한 기능의 도입으로 생기는 사이드 이펙트들은 없을까요?

Uniswap V4의 Hook 구조 도입으로 인해 우려되는 부분은 아래와 같이 두 가지입니다.

• Hook이 보안에 미치는 영향
• Uniswap V4의 Routing 문제

각각에 대해 간단히 알아보도록 하겠습니다.

Hook이 보안에 미치는 영향

Uniswap V4 Hook은 설치 과정 및 입력 / 반환값에서 일정한 제한이 존재하나, 함수 내부에서 로직이 어떻게 구현되어야 하는지에 대해서는 제한이 존재하지 않습니다. 이를 반대로 말하면, Hook 내부에 악의적인 로직을 구현하여 트레이더 혹은 유동성 공급자의 자금을 훔쳐갈 수도 있다는 의미입니다.

예를 들어, Hook 개발자는 동적 수수료 알고리즘을 악용해 풀에 대한 DoS 공격을 수행하여 사용자의 활동을 효과적으로 막을 수 있습니다. 예를 들어, 해당 Hook에서 특정 가격에 도달하는 등 어떤 조건을 만족시키면, 스왑 수수료를 100%보다 높게 만들어, 스왑이 아예 실패하도록 만드는 것입니다.

뿐만 아니라, 올비르지 않은 액세스 컨트롤 등으로 풀의 자금이 동결되거나 하는 케이스도 발생할 수 있습니다. Composable Security의 글에서는 beforeInitialize 함수를 누구나 호출할 수 있게 열어두면, 풀에 유동성이 영원히 잠기는 공격 방식을 소개합니다.

그러면 사용자들은 Uniswap을 사용하면서 어떤 부분을 조심해야 할까요? 우선 Uniswap 공식 인터페이스에서 스왑하는 사용자들은 Hook을 신경쓰지 않고 스왑해도 상관 없습니다. Uniswap에는 스왑 인텐트 네트워크인 UniswapX가 통합되어 있으며, 이를 활용하면 Hook의 악의적인 로직으로 인한 리스크는 사용자의 인텐트를 처리하는 filler가 지게 되어 있습니다. 즉, Uniswap의 인터페이스에서 UniswapX를 사용한다면, 악의적인 Hook 로직을 걱정하지 않아도 됩니다.

다만, 유동성 공급자들은 조심할 필요가 있습니다. Uniswap V4에서 유동성을 공급할 때의 인터페이스를 보면, 아래와 같이 유동성을 공급할 풀에 붙은 Hook 주소를 특정할 수 있습니다.

(Liquidity Provision Interface at Uniswap | Source: Uniswap Official Page)

이때 주소를 넣은 Hook이 해킹을 당하거나 악의적인 Hook이었다면, 공급한 유동성이 동결되거나 탈취될 수 있게 됩니다. 따라서 유동성 공급자들은 위 기능 사용에 주의를 기울어야 하며, 오딧을 받고 안정성이 검증된 Hook이 연결된 풀에만 유동성을 공급해야 합니다.

Uniswap V4의 Routing 문제

Uniswap V4에서는, 사용자가 스왑을 요청했을 때 어떤 방식으로 최적의 스왑 경로를 찾을 수 있을까요?

이에 대해 알아보기 위해, 기존 Uniswap에서의 Routing이 어떻게 발전해왔는지 간단하게 알아보도록 하겠습니다.

Uniswap V3에서 원래 사용자가 스왑을 요청하면, 이 요청은 Uniswap의 백엔드에 있는 Smart Order Router로 이동하였습니다. 여기서 최적의 스왑 루트를 찾아내서 반환하고, 사용자는 V3에 붙어있는 Router 컨트랙트에 이 경로를 입력하여 스왑을 진행하는 방식이었습니다.

그러나 2023년 7월, Uniswap은 스왑 효율 개선과 더 나은 크로스체인 UX를 위해 탈중앙화 인텐트 처리 프로토콜인 UniswapX를 발표했습니다. 이는 기존 Smart Order Router가 하는 역할을 탈중앙화 인텐트 처리 네트워크에 위임하는 것입니다. UniswapX에선 각각의 Filler가 더치 옥션 방식으로 사용자의 스왑 요청을 누가 처리해줄지를 결정하고, 해당 Filler는 사용자의 스왑 인텐트를 옥션의 결과에 맞게 처리합니다. 이 과정을 간단하게 표현하면 다음과 같습니다.

1. 사용자는 Permit2 서명을 통해 본인이 어떤 토큰(Input)을 얼마(Amount)만큼 어떤 토큰(Output)으로 스왑할지 등의 정보가 담긴 인텐트를 생성합니다.
2. Filler들은 이 서명에 적힌 의도 내에서는 어떻게든 스왑을 처리할 수 있는 권한을 가집니다. 예를 들어, Alice가 1 ETH를 3200 USDC로 스왑하려고 하고, 지정한 최소 Output 토큰의 양은 3190 USDC이라고 해 봅시다. Filler인 Bob은 이를 Uniswap V3에서 1 ETH ↔ 3199 USDC로 처리하고 Alice에게 3190 USDC를 보내서 차익인 9 USDC를 얻을 수 있습니다.
3. 그러나 만약 또 다른 Filler인 Charlie가 Alice에게 1996 USDC로 주문을 처리해주고 3 USDC의 차익만을 얻는 제안을 한다면, Charlie의 제안이 선택되고 Bob은 차익을 얻지 못하게 됩니다. UniswapX에서는 이러한 방식으로 트레이더에게 가장 유리한 제안을 하는 Filler의 주문이 선택되는 ‘Dutch Order’ 방식을 택하고 있습니다.
4. 사용자에게 선택받은 Filler는 Permit2 서명을 Reactor 컨트랙트로 보내서 거래를 시작합니다. Reactor 컨트랙트는 Filler의 Executor 컨트랙트를 호출해 스왑을 실행한 후, 거래의 조건이 충족되었는지 확인합니다.

V4에서는 이러한 알고리즘이 잘 동작할까요? 우선 V3와 비교했을때 V4의 Routing에서 더 어려워진 점은, 최적의 스왑 경로를 찾을 때 각 Hook의 로직까지 모두 고려해주어야 한다는 것입니다.

Hook은 위에서 언급했듯 임의의 로직이 담길 수 있기 때문에, 주소를 보고 어떤 함수가 구현되었는지는 알 수 있어도, 해당 Hook이 붙은 풀에서 어떤 일이 벌어질지는 직접 실행해보기 전에는 알 수 없습니다. 이러한 점 때문에, Uniswap V4에서는 Routing이 매우 어려울 것이라는 말이 많았습니다.

(Routing Problem at Uniswap V4 | Source: X of Alex Nezlobin)

즉 Hook의 보안 이슈로 인해, Uniswap V4에서 Routing은 Filler들이 풀들과 연결된 Hook의 로직을 완전히 이해하고 신뢰해야 이루어질 수 있습니다. 즉, UniswapX의 Filler들은 커뮤니티나 온체인 데이터를 통해 특정 Hook이 충분한 검증을 거쳤는지, 오딧이 완료되었는지 등을 확인한 후, 신뢰할 수 있는 Hook만을 Routing 로직에 포함하여 운영하게 될 것입니다.

이로 인해, 이미 널리 사용되고 있거나 충분한 유동성을 보유한 풀에 통합된 Hook들은 Filler들의 선택을 받을 가능성이 상대적으로 높으며, 해당 Filler들의 Routing 알고리즘에 포함될 확률이 큽니다.

다만, Filler들은 수익을 극대화하기 위해 항상 새로운 Hook과 새로운 풀들을 적극적으로 탐색하려고 할 것입니다. 따라서 신뢰성을 입증할 수 있는 Hook이라면, Filler들이 이를 Routing 로직에 포함시키도록 유도할 방법을 고민해볼 필요가 있습니다.

이러한 상황에선, 투명하게 Hook에 대한 정보를 보여주는 일종의 ‘Hook 대쉬보드’의 역할이 중요합니다. 커뮤니티에서는 이미 이러한 툴에 대한 빌딩이 이루어지고 있으며, 대표적으로 Uniswap V4 Hook에 대한 L2Beat를 표방하는 HookRank를 예시로 들 수 있습니다.

(HookRank | Source: hookrank.io)

HookRank 사이트에 가면, 각 Hook의 이름, 주소 뿐만 아니라 해당 Hook과 연결된 풀의 TVL 총량 및 트랜잭션 성공률도 확인할 수 있습니다. 현재는 출시 초기라 그리 데이터가 많지 않지만, 향후 Hook과 V4 풀의 개수가 매우 많아진다고 가정하면, 위와 같은 툴이 제공하는 정보들은 UniswapX Filler들에게 매우 귀중할 수 있습니다.

Uniswap V4 Hook 생태계

Uniswap V4는 2025년 2월 기준 출시된지 몇 주 지나지 않은 초기 생태계지만, 다양한 팀들이 V4 위에서 Hook을 활용하여 여러 프로덕트를 빌딩하고 있습니다. 이번 섹션에서는 Uniswap V4 Hook 기반의 주목할 만한 프로젝트들이 어떤 것들이 있는지 알아보고, Hook으로 어떠한 프로토콜까지 구축할 수 있는지 그 가능성에 대해 알아봅니다.

Hook Landscape

(Uniswap V4 Hook Landscape)

위 그림은 Uniswap V4 Hook을 기반으로 빌딩하고 있는 프로토콜들을 포함해 다양한 분야에서 Uniswap V4 Hook의 쓰임새를 나타냅니다.

각각의 분야에 대해 Uniswap V4 Hook이 어떠한 메커니즘으로 통합될 수 있는지 알아보겠습니다.

Hook의 주요 유즈 케이스

MEV 최소화

일반적으로 MEV라고 하면, 샌드위치 공격 등 트레이더에게 가해지는 단점들을 떠올리기 마련입니다. 그러나, Uniswap과 같은 DEX에서 MEV가 가져오는 단점은, 유동성 공급자 사이드에서도 매우 크게 나타납니다. 단적으로 이야기하면, LP들은 MEV로 인해 수익성이 악화됩니다.

이는 Loss-Versus-Rebalancing (LVR) 이라는 이름으로 연구되어오고 있는 문제입니다. LVR은, DEX의 시간은 블록 타임을 기준으로 뚝뚝 끊어지기 때문에 LP가 동적으로 포지션을 관리할 수 없어서 발생하는 문제를 의미하며, LP는 이상적으로 자산을 리밸런싱할 수 있는 환경과 비교했을 때 ‘손해’를 보고 있다는 사실을 내포합니다.

(LVR & IL of LP at dynamic market condition | Source: Delphi Digital)

예를 들어, 위 예시와 같이 ETH의 가격이 CEX에서만 $2000으로 두 배 급등했다고 해봅시다. 아비트라저는 DEX에서 ETH를 사고, CEX에서 ETH를 판매하는 방식으로 차익거래를 하여 이득을 취하려고 할 것입니다. 그러나 이때 DEX의 LP는 이에 바로 반응할 수 없으며, 그들은 시장 가격인 $2000보다 훨씬 더 낮은 가격에 ETH를 차익거래자에게 팔아야 합니다.

그런 다음, 즉시 ETH 가격이 다시 $1000으로 돌아간다고 해 봅시다. 차익거래자는 CEX에서 ETH를 사서 DEX에 판매하는 방식의 차익거래를 진행할 것이고, 이때도 LP는 시장가보다 더 불리한 가격에 거래를 진행하게 될 수밖에 없습니다.

즉, “DEX의 LP들은 시장의 변동으로 인해 생기는 수익의 기회들을 차익거래자에게 모두 넘겨줄 수밖에 없다”, 혹은 “원래 LP들이 다이나믹하게 포지션을 리밸런싱하면서 얻어야 했던 수익들은 차익거래자가 가져가게 된다”는 것이 LVR의 대략적인 개념입니다.

(Toxicity of Uniswap V3 Order Flow | Source: An Automated Market Maker Minimizing Loss-Versus-Rebalancing)

실제로 이는 Uniswap V3에서 LP의 수익성을 떨어뜨리는 큰 문제 중 하나로 지적받고 있었습니다. 위 그래프는 Uniswap V3 LP들을 일종의 ‘트레이더’로 가정하고, 그들이 포지션을 언제 종료하는지에 따라 PnL이 얼마가 되는지를 계산한 그래프입니다. 시간 프레임을 어느 구간으로 잡던 간에, LP들은 거의 모든 타임프레임에서 막대한 손해를 보고 있음을 확인할 수 있습니다.

이러한 LVR 문제의 근본적인 원인은 LP들이 가격 변화에 액티브하게 대응하지 못하고 있기 때문이며, 이에 대한 가장 쉽고 직접적인 해결책은 MEV 수익의 일부분을 LP에게 분배하는 프로토콜을 만드는 것입니다.

Arrakis Diamond Protocol

대표적인 예시로, Arrakis에서 Diamond Protocol을 참고해 만든 LVR 최소화 Hook을 들 수 있습니다. 우선 이 Hook의 핵심 개념은 다음과 같습니다.

아비트라저들이 풀에서 차익 거래를 하기 위해서는 일정량의 토큰 담보를 Hook에 맡겨야 합니다. 이를 통해 차익거래자들의 MEV 수익을 효과적으로 낮추고, 백러닝 트랜잭션만이 발생하도록 유도하여 LVR을 줄이는 것이 핵심 목표입니다.

Arrakis의 PoC 구현체를 기반으로 조금 더 자세히 설명드리겠습니다. 해당 구현체에서는 두 가지 가정을 두고 있습니다.

첫째, 앞서 언급한 차익거래자는 풀에 들어갈 트랜잭션과 그 트랜잭션으로 인한 풀의 가격 및 유동성 변화를 모두 파악하고 있는 블록 빌더입니다.

둘째, 이 블록 빌더는 다음 블록이 생성되기 전에 풀의 토큰 가격을 외부 시장 가격에 맞추는 차익거래를 수행합니다.

Arrakis의 Hook이 적용된 풀에서 차익거래를 하기 위해서는, 블록 빌더가 Hook에 담보를 맡겨야 합니다. 여기서 특이한 점은 두 가지가 있습니다.

1. Arrakis의 메커니즘에 따라 블록 빌더는 담보를 맡기는 첫 번째 트랜잭션에서 스왑을 통해 풀의 토큰 가격을 외부 시장 가격과 동일하게 맞추도록 되어 있습니다. 예를 들어, 현재 Uniswap V4 풀에서 ETH 가격이 $1200인데 외부 시장에서는 $1100이라면, 빌더는 V4 풀의 가격을 $1100으로 맞추는 액션을 수행해야 합니다. 이렇게 외부 시장 가격과 일치시킨 가격을 committed price라고 부릅니다. 만약 이 액션이 제대로 실행되지 않는다면, 해당 블록에서 스왑은 아예 불가능해집니다.
2. 블록 빌더가 맡기는 담보의 크기는, 해당 블록에서 스왑이 발생해 풀의 가격이 committed price 이상으로 올라갔을 때, 이를 다시 committed price로 되돌릴 수 있을 만큼의 충분한 양이어야 합니다. 이는 블록 종료 시 풀의 가격이 committed price로 맞춰짐을 보장하기 위함입니다. 빌더는 블록에 들어갈 트랜잭션을 모두 알고 선택할 수 있으므로, 담보 크기 계산 역시 어렵지 않게 수행할 수 있습니다.

풀의 가격이 외부 시장 가격과 일치하게 조정되면, 블록 빌더 입장에서는 이제 해당 풀에서 스왑이 발생할 경우 이를 다시 외부 시장 가격으로 돌려놓는 차익거래를 하는 것이 가장 유리한 전략이 됩니다. 즉, 빌더는 백러닝 MEV 트랜잭션을 보내도록 유도됩니다.

그런데 만약 빌더가 이러한 전략을 따르지 않고 백러닝을 수행하지 않는다면 어떻게 될까요? Arrakis의 메커니즘에서는, 만약 블록 종료 시점에 풀의 가격이 committed price와 다르게 유지된다면, 블록 빌더가 맡긴 담보를 모두 회수하지 못하도록 설계되어 있습니다.

이러한 방식은 빌더가 약속한 가격(즉, 외부 시장 가격)과 다르게 풀의 가격을 유지할 경우, 차익거래 기회를 상실하거나 담보를 잃게 만들어, 결국 빌더가 백러닝을 통해 가격을 외부 시장과 일치시키도록 강제하는 역할을 합니다.

이를 위해선 매 스왑마다 변하는 풀의 가격과, 차익거래자가 되찾을 수 있는 담보의 양을 트래킹할 수 있어야 합니다. 이를 위해 Arrakis의 Hook에서는 afterSwap 함수를 활용해, 해당 스왑이 풀의 가격을 committed price에서 얼만큼 벗어나게 만들었는지를 기반으로 차익거래자가 되찾을 수 있는 담보의 양을 재계산하는 과정을 거칩니다.

정리하자면, Arrakis의 LVR 최소화 Hook은 블록 빌더가 매 블록마다 풀의 가격을 강제로 외부 시장가(committed price)에 맞추도록 강제하는 방식을 통해, 빌더가 추출할 수 있는 MEV를 줄입니다. 이를 통해 LVR은 유의미하게 감소될 수 있고, LP들의 수익성을 보장할 수 있죠.

이에 대한 시뮬레이션 결과를 통해, 이 Hook이 적용된 풀에서 LP의 수익성이 얼마나 증가되는지 확인해볼 수 있습니다.

(Profitability of LPs at different strategies to minimize LVR | Source: LVR-minimization in Uniswap V4)

위 그래프는, 다양한 LVR 최소화 전략에서 LP의 수익성을 일반적인 Uniswap 풀과 비교해 나타낸 것입니다. HODL을 제외한 두 전략에서 모두 LP들은 일반적인 Uniswap 풀(CFMM)과 비교했을 때 대략 5% 가량, 많게는 20%가 넘는 추가 수익을 얻을 수 있음을 확인할 수 있습니다.

정리하자면, Arrakis의 LVR 최소화 Hook은 차익거래자의 액션을 강제하는 기능을 가지고 있으며, 이를 통해 LP의 수익성을 크게 높여줄 수 있습니다.

Sorella Angstrom

Sorella가 만든 Angstrom도 Uniswap V4 Hook의 형태로, 역시 LVR 최소화를 위한 App-Specific Sequencing 솔루션입니다. Sorella는 Angstrom을 통해, AVS를 활용한 오프체인 합의 알고리즘과 Uniswap V4 Hook을 결합해 유니크한 MEV 재분배 메커니즘을 제안하고 있습니다.

(Angstrom Architecture | Source: Sorella Blog)

이 아키텍처에서 유저 플로우는 다음과 같습니다. 우선, Angstrom Hook이 붙은 풀에서 차익거래를 하고 싶은 아비트라저들은 ‘해당 풀의 첫 트랜잭션을 보낼 권리’를 두고 경매를 수행합니다. 그 동안, 사용자들은 Angstrom의 AVS 노드들이 공유하는 멤풀로 스왑 요청을 보냅니다.

Angstrom 네트워크는 자체 합의와 경매 결과 및 멤풀 정보를 기반으로 보낼 번들을 구성합니다. 이때, 이 번들의 첫 트랜잭션은 가장 높은 bid를 넣은 아비트라저의 트랜잭션이 되어야 합니다. 이 번들은 이더리움 블록 빌더와 멤풀로 전달되어 체인에 포함됩니다.

이때 중요한 점은, 경매에서 승리한 아비트라저의 bid는 LP들에게 분배된다는 사실입니다. 즉, Angstrom은 MEV 추출을 위한 경매를 유도하고, 이 경매의 수익을 LP들에게 주는 방식으로 LVR을 최소화할 수 있습니다.

이를 구현하려면 LP들에게 경매 수익을 분배해줄 수 있어야 하며, LP들이 포지션을 빼거나 추가할 때 이에 대한 상태 업데이트를 해주어야 합니다. Angstrom은 이를 Hook의 beforeAddLiquidity, beforeRemove를 통해 구현하고 있습니다.

Uniswap V4에서는 V3와 마찬가지로, LP가 벌어들이는 수수료 수익을 feeGrowthInside라는 변수에 저장합니다. 이 값은 LP가 제공한 유동성 단위당 해당 포지션에서 발생한 누적 수수료를 의미합니다. Angstrom 역시 동일한 방식으로, Hook 내부에서 LP들에게 배분될 bid 보상을 계산하고 저장합니다. 즉, Angstrom 번들이 실행될 때마다, bid 값만큼 이 보상 값이 증가하며, LP들이 새로운 유동성을 공급하거나, 기존 포지션을 추가·제거할 때, Hook의 beforeAddLiquidity, beforeRemoveLiquidity 함수가 이를 자동으로 업데이트하도록 설계되어 있습니다.

Volatility-Based Dynamic Fee

한편, 꼭 LVR 문제를 MEV 재분배 혹은 제한 등으로 풀어야 하는 것은 아닙니다. LVR은 변동성이 큰 상황에서 차익거래 기회가 늘어나면서 커지기 때문에, 변동성이 큰 상황에서 LP들의 수익을 더 보장할 수 있는 동적 수수료 알고리즘을 도입하는 것도 해결책이 될 수 있습니다. Uniswap V4는 풀의 메커니즘부터, Hook의 구성까지 동적 수수료 알고리즘 도입이 매우 쉽게 가능한 구조로 되어있기 때문에, 이를 활용해 LP의 수익을 극대화하는 Hook들이 생길 수 있습니다.

이러한 메커니즘은 Uniswap이 아닌 다른 DEX에서 이미 많이 구현된 바 있으며, 대표적으로 Trader Joe, Algebra, Hypersea 등에서 이러한 변동성 기반 동적 수수료 메커니즘을 사용하고 있습니다. Uniswap V4에서는 A51 Finance, Bunni 등이 이러한 변동성 기반 동적 수수료 메커니즘을 가진 Hook을 빌딩하려고 하고 있으며, 이를 기반으로 LP들의 손해를 최소화할 수 있을 것으로 기대됩니다.

토큰 런칭

Uniswap V4 Hook을 활용하면, 다양한 방식의 토큰 및 풀 런칭도 구현할 수 있습니다.

Flaunch

가장 대표적인 예시로, 일정 기간 동안 모두가 동일한 가격에 토큰을 구매할 수 있게 하는 Fair Launch Hook을 구현한 Flaunch를 들 수 있습니다. pump.fun과 같은 일반적인 Fair Launch 프로토콜은 별도의 컨트랙트에서 Fair Launch 세일을 진행한 후, 해당 세일이 종료되면 이를 DEX의 풀로 옮기는 방식으로 구현되어있지만, Flaunch는 모든 Fair Launch 및 풀 런칭, 거래 시작 등의 액션이 Uniswap V4의 풀 내에서 이뤄지도록 구현해두었습니다.

대략적인 메커니즘은 다음과 같습니다. Flaunch는 풀 런칭 후 고정된 가격에 토큰을 사고팔 수 있고, 지정된 시간이 지나거나 공급된 유동성에 해당하는 토큰이 모두 팔린 경우 Uniswap V4에서 본격적으로 거래할 수 있게 되는 방식으로 Fair Launch를 구현하고 있습니다. 이를 위해, Flaunch는 Hook 내 beforeSwap 함수를 활용합니다. 우선 Hook에 풀이 Fair Launch 상태인지를 나타내는 변수를 정의한 후, Fair Launch가 끝나기 전에 들어오는 거래에 대해서는 현재 가격을 고정 가격으로 만들어 스왑을 진행해줍니다. 그리고 Fair Launch가 끝난 후에는, 일반적인 Uniswap의 방식으로 스왑을 진행합니다.

이러한 방식을 통해, Flaunch는 별도의 컨트랙트를 사용하지 않고도 오로지 Uniswap V4 위에서 Fair Launch를 구현해내었습니다.

Doppler by Whetstone Research

이러한 Fair Launch와 유사하게, Uniswap V4를 통해 유동성이 필요한 토큰 프로젝트에 유동성을 부트스트래핑할 수도 있습니다. Whetstone Research에서 제안한 Doppler가 그 대표적인 예시이며, Doppler는 더치 옥션을 기반으로 한 동적 본딩 커브 알고리즘을 활용해 토큰의 초기 가격을 찾고 Uniswap V4 풀에 유동성을 부트스트래핑합니다.

기존 정적인 본딩 커브 메커니즘은 초기 유동성이 없어도 토큰의 거래를 촉진할 수 있다는 장점이 있지만, 봇들이 토큰을 낮은 가격에 구매하고, 가격이 올라가는 즉시 판매하는 스나이핑 전략에 취약하다는 단점이 존재합니다. Doppler는 본딩 커브에 더치 옥션을 결합한 Uniswap V4 Hook을 통해 이 문제를 해결하고자 합니다.

Doppler의 토큰 런칭 시스템은 두 가지 페이즈로 구성되어 있습니다.

1. 초기 시장가를 발견하기 전까지는 가격이 급격하게 떨어짐
2. 초기 시장가 발견 후부터는 동적인 본딩 커브를 기반으로 가격이 천천히 증가

첫 번째 페이즈에서는, Uniswap V3와 V4에서 가격을 나타낼 때 사용되는 tick을 기준으로 가격이 시간에 따라 점점 내려가는 더치 옥션이 진행됩니다. 이 더치 옥션은 구매자가 나타날 떄까지 진행되어, 토큰의 초기 가격을 찾는 용도로 사용됩니다.

(Target Tick Decay Over Time | Source: Doppler Whitepaper)

토큰의 초기 가격이 발견되면, 본딩 커브 메커니즘을 통해 토큰의 자유로운 거래가 시작됩니다. 이때 중요한 점은, 본딩 커브가 고정되어 있지 않고, 시장 상황에 따라 움직인다는 점입니다. Doppler는 본딩 커브의 진행을 에포크 단위로 나누고, 에포크마다 충분한 토큰이 팔렸으면 본딩 커브를 위쪽으로 이동시키거나, 충분한 토큰이 팔리지 않았으면 본딩 커브를 아래로 이동시킵니다. 이를 통해, Doppler는 가격 발견 과정이 실제 시장 상황을 보다 더 잘 반영하도록 만들 수 있습니다. 또한, 이러한 조치는 봇들의 예측 가능성을 떨어뜨려, 스나이핑 등으로 시장에서 가치를 추출하는 행위를 어렵게 만듭니다.

(Dynamic Bonding Curves | Source: Doppler Whitepaper)

또한, Doppler는 본딩 커브가 끝날 때 바로 유동성을 풀에 배포하는 것이 아니라, 매 에포크마다 조금씩 풀에 유동성을 배포하는 ‘스트리밍’ 방식을 택합니다. 이는, 토큰 세일 프로세스가 끝났을 때 모든 유동성이 한꺼번에 풀에 추가되면, 봇이 프론트러닝 및 샌드위치 공격으로 풀의 정상적인 동작과 사용자의 일반적인 스왑을 방해할 수 있기 때문에 추가되는 조치입니다.

위와 같은 메커니즘들은 Hook 내의 beforeSwap, afterSwap, beforeAddLiquidity 등을 통해 구현되어 있습니다.

즉, 정리하자면 Doppler는 유동성 부트스트래핑을 위해 더치 옥션과 동적 본딩 커브를 결합하여 유니크한 솔루션을 제공합니다. 이를 통해 토큰의 초기 가격 발견 문제, 기존 본딩 커브에서 MEV로 발생했던 부작용 등의 문제를 해결할 수 있으며, 이를 구현하는 데는 Uniswap V4의 Hook이 핵심 역할을 수행합니다.

Uniswap V4와 DeFi의 미래

Uniswap은 이더리움 역사상 가장 많이 사용된 DEX이며, Uniswap V4는 이를 보다 모듈화하고, 효율적이며, 커스텀화할 수 있도록 만들었습니다. 이는 어떠한 의미가 있고, 향후 Uniswap V4와 DeFi 생태계는 어떻게 변모해갈까요?

더 자본 효율적이고 지속 가능한 DeFi

AMM이 가진 가장 큰 한계 중 하나는 비효율성이었습니다. 비영구적 손실, LVR, 높은 가스비 등의 문제가 지속적으로 제기되어 왔습니다. 이 중 높은 가스비 문제에 대해, Uniswap V4는 Singleton 아키텍처, Flash Accounting 및 Native ETH 지원 등의 전략으로 접근하고 있습니다. 이를 통해 특히 풀 배포 비용이 99% 이상 저렴해졌으며, 스왑 수수료도 Uniswap V3와 비교했을 때 매우 저렴하기 때문에, 수수료가 비싼 이더리움 메인넷에서 이전보다 훨씬 좋은 UX를 제공할 수 있습니다.

또한, V4에서는 Hook을 통해 빌더들에게 매우 높은 수준의 자율성을 제공하여, Uniswap이 중앙화 거래소들와 경쟁할 수 있는 수준의 자본 효율성을 갖출 수 있는 환경을 구축하고 있습니다. 특히, App-Specific Sequencing 및 MEV 최소화 등 LP들에게 더 많은 수익을 안기는 Hook들이 많이 개발되며, MEV 수익의 일부를 LP에게 분배하는 모델이 정착될 가능성이 큽니다. 이는 기존 MEV로 인한 LP들의 손실을 최소화하고 수익을 증가시켜줌으로써, 더욱 지속 가능한 DeFi 구조를 만들어낼 수 있습니다.

플랫폼으로써의 Uniswap

Uniswap V4의 가장 큰 혁신 중 하나는 Hook의 도입입니다. 이 기능은 개발자들에게 AMM 구조를 자유롭게 조정하고, 동적 수수료 모델을 채택하며, 맞춤형 전략을 설계할 수 있는 가능성을 열어줍니다. 이제는 기존의 정형화된 AMM 모델에 구애받지 않고, 다양한 시장 환경에 최적화된 유동성 풀이 등장할 것으로 예상됩니다.

앞서 설명한 것처럼, Uniswap V4는 토큰 런칭을 위한 맞춤형 전략, 변동성에 따른 수수료 자동 조정, MEV 최소화 및 LP 수익 극대화와 같은 다양한 기능을 갖춘 유동성 풀을 만들 수 있는 플랫폼이 됩니다. 이로 인해, 개발자들은 각기 다른 요구와 상황에 맞는 풀을 설계할 수 있게 됩니다.

또한, 위에서 자세히 다루지는 않았지만, Uniswap 위 유동성을 기반으로 렌딩 혹은 파생상품을 빌딩하려는 프로토콜이나, 나아가 특정 조건을 충족하는 사용자만 거래할 수 있도록 하여 규제 요건을 맞추는 기관 투자자 전용 풀 등 새로운 형태의 유동성 공급 방식도 등장할 수 있습니다.

이는 Uniswap이 단순한 DEX에서 벗어난다는 것을 의미합니다. Uniswap은 앞으로 Hook을 기반으로 다양한 프로토콜들이 Uniswap의 유동성 위에서 빌딩하는 하나의 플랫폼이 되어, 생태계를 구축해나갈 가능성이 큽니다.

이렇게 형성된 Uniswap V4의 생태계는 지속 가능성이라는 중요한 특성을 지니고 있습니다. 예를 들어, 2022년 초 전성기를 맞이했던 Curve의 생태계는 주로 $CRV 토큰 리워드를 기반으로 한 투표에 의존하는 구조였기 때문에 시장 하락에 대응하기 어려운 한계를 보였습니다. 반면, 현재 Uniswap이 구축하려는 생태계는 각자가 서로 다른 로직을 추가해 각자만의 경쟁력을 추구하는 빌더 생태계이고, 별도의 토큰 리워드가 아닌 Hook의 높은 유연성을 인센티브로 빌더들을 끌어들이고 있습니다.

이러한 빌더 생태계에서, 뛰어난 프로젝트들이 서로 경쟁하고 협력하면서 점진적으로 프로토콜을 발전시켜 나간다면, Uniswap V4는 더 높은 LP 수익을 통해 TVL을 증가시키고, 이를 기반으로 더 많은 스왑 볼륨을 유도하는 선순환 구조를 형성할 수 있을 것이라고 생각됩니다.

Appendix 1 — 프로젝트 리스트

이는 위 Hook Landscape에 존재하는 프로젝트들의 리스트입니다. 위 글에 언급된 어떠한 내용도 아래 프로젝트들에 대한 투자 조언이 아닙니다.

MEV Mitigation

• Arrakis
• A51 Carbon
• Sorella Angstrom
• Semantic Layer

Token Launch

• Flaunch fair launch
• Whetstone Doppler
• Clanker V4
• Bonsai

Capital Efficiency

• Bunni
• Flaunch

Data & Informative Tools

• RigoBlock
• Flaunch Notifier

Privacy

• Vortex Protocol

Lending, Derivatives, & Risk Management

• Tenor Finance
• Cork
• Likwid

Appendix 2 — Hook 빌딩 /모니터링에 유용한 툴 및 페이지

• Uniswap V4 Docs: Uniswap V4 공식 문서
• Scaffold Hook: Uniswap V4 Hook 개발 스택
• v4-template: Uniswap V4 Hook 템플릿 (by Uniswap Foundation)
• DEX Analytics: Uniswap V4 거래들에 대한 API 및 대시보드
• Uniswap V4 Hooks: 커뮤니티 및 해커톤에서 나온 Uniswap V4 Hook 아이디어 및 구현체
• awesome-uniswap-hooks: Uniswap V4 관련 문서 및 코드의 전체 리스트
• HookRank: Uniswap V4 Hooks을 위한 L2Beat
• Uniswap V4 Leaderboard: Uniswap V4의 체인, 풀, 그리고 Hook들에 대한 실시간 대시보드
• V4 Hook Address Miner: Uniswap V4 Hook 주소 마이닝 페이지

Reference

• Uniswap V2 Overview | Uniswap Blog
• Uniswap V3 Whitepaper
• Introducing Uniswap V3 | Uniswap Blog
• Our Vision for Uniswap V4 | Uniswap Blog
• Demystifying EIP-1153
• Build secure Uniswap V4 Hooks in AVS
• V4 Hook Address Miner
• Loss Versus Rebalancing | Delphi Digital
• An Automated Market Maker Minimizing Loss-Versus-Rebalancing
• LVR-minimization in Uniswap V4 | ethresearch
• Diamond: A Uniswap V4 Hook minimizing LVR | Arrakis Blog
• A New Era of DeFi with App-Specific Sequencing | Sorella Blog
• Flaunch Docs
• Doppler Whitepaper | Whetstone Research