한 사용자 스왑이 라우터를 거쳐 여러 풀 hop으로 나뉘면 이벤트 기준 거래량은 여러 구간에 잡힐 수 있다. pool volume을 단순 합산하면 최종 사용자가 교환한 명목보다 커질 수 있다. 따라서 transaction·route·pool 세 단위를 분리하고 중간 토큰 hop을 식별한다.
사용자 스왑 한 번이 여러 pool event가 되는 구조
DEX 라우터는 사용자가 원하는 input token과 output token 사이에 직접 풀이 없거나 더 나은 가격이 예상되면 중간 토큰을 거치는 path를 선택할 수 있다. 각 풀은 자기 구간의 Swap event를 하나씩 남긴다.
따라서 transaction 수는 하나여도 hop이 두 개면 pool-level swap은 두 개다. pool volume은 각 풀이 처리한 금액을 세고 user notional은 경로의 최초 입력 또는 최종 출력을 한 번 세므로 두 지표의 합계가 달라진다.
풀 거래량은 각 유동성 풀의 처리량이고 사용자 거래량은 경로의 시작과 끝이다. 합계 목적이 다르다.
JOBCOIN 해설
exactInput·exactOutput과 path 방향
Uniswap v3 exactInput multihop은 고정 input으로 가능한 최대 output을 구하고 tokenIn-fee-tokenMid-fee-tokenOut 순서의 path를 실행한다. exactOutput은 원하는 output을 고정하고 필요한 input을 계산하며 path encoding 방향이 반대다.
여러 route로 분할되면 하나의 transaction 안에 같은 input token에서 출발하는 경로가 둘 이상 생길 수 있다. event 수만 세어 사용자 수나 주문 수로 바꾸지 말고 transaction hash, router call과 log 순서를 함께 분석한다.
1,000달러 스왑이 1,997달러로 보이는 예시
교육용 가정으로 사용자가 1,000 DAI를 WETH로 바꾸고 경로가 DAI→USDC→WETH라고 하자. 첫 풀에서 1,000 DAI가 997 USDC가 되고 둘째 풀에서 997 USDC가 WETH로 바뀌면 사용자 input notional은 약 1,000달러다. 그러나 각 hop의 USD 명목을 단순 합치면 1,000+997=1,997달러의 pool volume이 된다.
1,997달러가 잘못된 숫자라는 뜻은 아니다. 두 풀이 각각 처리한 유동성 사용량을 묻는다면 올바른 합계다. 최종 사용자가 얼마를 교환했는지를 묻는데 모든 Swap event를 합치면 중간 USDC가 다시 세어져 과대 집계된다. 집계 목적과 단위를 먼저 선언한다.
| 단위 | 한 거래에서 세는 것 | 적합한 질문 |
|---|---|---|
| transaction | 사용자의 최종 입력 또는 출력 한 번 | 사용자 명목 거래량 |
| route | 입력→출력 경로별 금액 | 라우터 경로 선택 분석 |
| hop | 각 중간 토큰 교환 | 멀티홉 구조 분석 |
| pool event | 각 풀의 Swap 이벤트 | 풀별 유동성 사용량·수수료 |
멀티홉과 분할 라우팅은 서로 다르다
Uniswap v3 공식 예시의 exactInput multihop path는 tokenAddress-fee-tokenAddress 순서로 풀을 지정하고 DAI→USDC→WETH처럼 중간 토큰을 거친다. 한 경로 안에서 앞 hop의 출력이 다음 hop의 입력이 된다.
smart order router는 더 좋은 결과를 위해 여러 hop뿐 아니라 여러 route로 주문을 나눌 수 있다. 예를 들어 1,000 DAI 중 600은 직접 DAI/WETH 풀, 400은 DAI/USDC/WETH 경로를 쓸 수 있다. transaction input 합은 여전히 1,000이지만 pool event는 세 개다.
- transaction hash와 호출자를 기준으로 사용자 요청을 묶는다
- router calldata에서 exactInput·exactOutput과 path를 확인한다
- 각 Swap event의 pool 주소·token0·token1을 저장한다
- 중간 토큰의 출력이 다음 hop 입력인지 연결한다
- 사용자 거래량과 pool 처리량을 별도 지표명으로 게시한다
수수료와 USD 환산에서도 중복이 생긴다
각 풀은 fee tier가 다를 수 있고 멀티홉 거래는 hop마다 풀 수수료와 가격충격을 겪는다. 사용자 input에서 output의 USD 가치를 뺀 차이를 모두 프로토콜 수수료로 부르면 price impact와 환산시각 차이까지 섞인다. 풀별 fee growth 또는 명세의 fee tier를 별도로 본다.
중간 토큰이 스테이블코인이라도 정확히 1달러로 고정해 환산하면 디페깅 시 거래량이 왜곡된다. 모든 hop을 같은 reference price timestamp로 환산하고, token decimals를 적용한 원시 수량도 보관한다.
한 transaction의 route를 재구성하는 순서
transaction receipt의 logIndex 순으로 Swap 이벤트를 정렬한다. 동일 transaction 안에서 이전 event의 token output과 다음 event의 input이 이어지는지 확인하고 pool fee와 주소를 붙인다. router 외부의 transfer event를 swap으로 세지 않는다.
사용자 명목은 최초 입력 1,000 DAI 또는 최종 출력의 기준통화 가치 중 하나로 정해 한 번만 센다. pool volume은 1,000 DAI hop과 997 USDC hop을 각각 해당 풀에 귀속한다. 두 지표를 합쳐 하나의 DEX 시장 점유율로 쓰지 않는다.
공식 Uniswap 문서는 라우팅과 path 실행 구조를 뒷받침한다. 예시 금액은 교육용이며 실제 체결이나 특정 라우터의 우월성을 나타내지 않는다.
자주 묻는 질문
멀티홉 거래량은 무조건 중복인가요?
pool별 처리량을 묻는다면 각 hop을 세는 것이 맞다. 사용자 최종 거래 명목을 묻는데 중간 hop까지 더하면 중복이다.
transaction 하나에는 Swap event도 하나뿐인가요?
아니다. 멀티홉과 분할 route에서는 여러 pool contract가 각각 Swap event를 낼 수 있다.
Transfer event를 모두 DEX 거래량으로 세도 되나요?
안 된다. 승인·router 이동·환불과 중간 토큰 전송이 섞일 수 있다. pool Swap event와 router calldata로 실제 경로를 확인한다.
