AI AI
속보
심층
이벤트
Pro
더보기
자금 조달 정보
특집
온체인 생태계
용어
팟캐스트
데이터
OPRR
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
BTC
$96,000
5.73%
ETH
$3,521.91
3.97%
HTX
$0.{5}2273
5.23%
SOL
$198.17
3.05%
BNB
$710
3.05%
XRP
$2.25
2.07%
DOGE
$0.325
2.23%
USDC
$0.999
3.05%

Polymarket PnL 정확한 계산: 왜 당신의 손익이 잘못되었을 수 있나요?

이 글을 읽으려면 13 분
Polymarket 양자, 첫 번째 단계는 전략을 찾는 것이 아니라 자신의 수익을 먼저 확인하는 것입니다.
원문 제목: "Polymarket PnL 정확한 계산: 왜 당신의 수익/손실은 모두 잘못될 수 있습니다"


저자: Leo, 암호화폐 분석가


나는 Polymarket에서 자체 개발한 자동화 거래를 반 년간 진행했는데, 가장 큰 문제는 전략 실패가 아니라 얼마나 많은 돈을 벌었는지조차 제대로 계산하지 못한 것이었습니다.


이게 나의 실력이 나빠서가 아니라 PM의 PnL 계산 자체가 함정이기 때문입니다. 공식 API가 제공하는 숫자는 잘못되었을 뿐만 아니라, 제3자 분석 웹사이트에서 보여주는 순위 또한 틀렸습니다. 직접 스크립트를 작성해 계산해도, 대부분의 경우 여전히 틀립니다.


어디까지 오차가 심했느냐하면, 3위인 kch123은 잘못된 방법으로 계산하여 350만 달러 손해를 봤지만 실제로는 1140만 달러를 벌었습니다. 몇 프로 포인트 차이가 나는 게 아니라, 수익과 손실의 부호조차 뒤집혔습니다.


이 기사는 내가 겪은 모든 문제점을 자세히 설명합니다. 거래를 하는 사람, 도구를 개발하는 사람, 순위를 보는 사람들은 언젠가는 마주치게 될 주제일 것입니다.


문제 1: cashPnl은 이미 정산된 이익을 포함하지 않습니다


가장 직관적인 방법은 /positions 인터페이스를 가져와 cashPnl(현금 손익) 필드를 합산하는 것입니다.


상위 15위의 세 주소를 테스트한 결과:


swisstony: cashPnl 합산 +3.5만 달러, 실제 순위 +560만 달러, 158배 차이


kch123: cashPnl 합산 -3.52백만 달러, 실제 순위 +11.4백만 달러, 부호가 반대로


gmanas: cashPnl 합산 -2.64백만 달러, 실제 순위 +5.02백만 달러, 부호가 반대로


세 주소 중 두 곳에서 이익과 손실의 부호가 반대였습니다.


이유: /positions 인터페이스로 받은 cashPnl은 이미 closed/redeemed된 realized PnL을 포함하지 않습니다. 이기는 포지션이 자동으로 USDC로 상환되면, 해당 position은 API 응답에서 삭제됩니다. 남아 있는 것은 정산되지 않은 보유 중인 포지션인데, 이는 대부분 미결제 손실을 포함합니다.


당신은 전체 손익을 계산했다고 생각하였지만, 실제로는 미결산 부분만 받은 것입니다.


함정 2: makerPnl 필드와 체인 상 현금 흐름 불일치


거래 데이터 JSONL에는 makerPnl(메이커 손익) 필드가 있습니다. 이름만 보면 PnL을 계산하는 데 사용되는 것처럼 보입니다. 믿지 마세요.


내가 메이커 데이터에서 관찰한 바에 따르면, SUM(makerPnl)로 계산된 숫자는 체인 상 현금 흐름과 한 숫자가 다릅니다. 구체적인 배수는 상황에 따라 달라질 수 있지만, 방향은 동일합니다: makerPnl의 내부 계산 논리가 실제 USDC 흐름과 일치하지 않습니다.


어떤 차이가 있든, 결론은 같습니다: 이 필드로 손익을 계산하지 마십시오.


함정 3: txHash로만 중복 제거할 수 없음


이것은 가장 직관에 반하는 부분입니다.


동일한 txHash(트랜잭션 해시)에 여러 레코드가 나타납니다. 정상적인 사람의 첫 번째 반응은 중복 데이터를 제거하는 것입니다.


이렇게 하면 안 됩니다. PM의 CLOB(체인 상 리미트 주문 대장)은 한 거래에서 여러 maker 주문을 매치시킬 수 있으며, 동일한 txHash 아래의 여러 레코드는 실제 독립적인 체결입니다.


이전에는 txHash + 자산으로 중복을 제거했으며, 매수 측에서 $133을 잘못 계산했습니다. Polygon 체인에서 확인한 결과, 거래 해시 하나에 실제 독립적인 USDC 전송 이벤트가 여러 개 있습니다. 각각의 이벤트는 실제 거래에 해당합니다.


결론: txHash만으로 중복을 제거할 수 없습니다. 손익을 계산하려면 직접 /activity 원본 데이터를 합산하십시오.


함정 4: offset 페이지 네비게이션에 제한이 있음


/activity 엔드포인트를 페이징할 때 offset(오프셋)을 사용하나요? 3000을 초과하면 직접적으로 400 오류가 발생합니다. 문서에는 기술되어 있지 않습니다.


위 세 주소를 모두 확인해보았습니다: GET /activity?offset=3100을 요청하면 HTTP 400을 반환하며, max historical activity offset of 3000 exceeded라는 오류 메시지가 나타납니다. 맨 위의 플레이어들은 종종 수천 개의 거래를 하지만, 3000개의 항목은 충분하지 않습니다.


end 매개변수를 사용하여 (이전 페이지의 마지막 타임스탬프 - 1)을 커서로 사용하여 페이지를 이동하며, 상한선이 없습니다.


함정 5: 순위표 PnL 차이


주소의 PnL을 계산하고 순위표와 비교하면 약간의 차이가 있습니다.


대부분의 경우 차이는 $10 이내입니다 (지니값 변동에 의한 보유 자산 가치). 그러나 차이가 크게 벗어나는 경우에는 순위표의 집계 창, 캐시 갱신 지연, 또는 사용자가 여러 프록시 지갑에 연결되어 있는 등의 이유가 있을 수 있습니다.


실험 결과, 현금 흐름 방법을 사용하여 계산된 단일 주소 PnL은 lb-api의 반환 값과 매우 일치합니다. 결과가 크게 다른 경우에는 먼저 페이지 이동이 완전한지 (함정 4), 잘못된 필드를 사용하지는 않았는지 (함정 1-2)를 확인하십시오.


올바른 접근 방식


다양한 우회 방법을 시도한 후, 확인된 가장 신뢰할 수 있는 방법은 데이터 API의 현금 흐름 요약입니다. 사전 계산 필드를 사용하지 않고, 원천 거래 기록에서 자금 이동을 직접 계산합니다.


수식:


PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + 보유 자산 가치


TRADE BUY: USDC로 토큰을 구매함 (지출)

TRADE SELL: 토큰을 판매하여 USDC를 회수함 (수입)

REDEEM: 이긴 포지션을 USDC로 환급함 (수입)

SPLIT: USDC를 토큰 쌍으로 분할함 (지출)

MERGE: 토큰 쌍을 다시 USDC로 병합함 (수입)

MAKER_REBATE: 메이커 리베이트 (수입)

REWARD: 보상/에어드랍 (수입)


· 데이터 소스:

GET /activity?user=<address>&limit=500, end로 페이지네이션하여 전체 데이터를 가져온 후 유형별로 합산합니다.


· 보유 포지션 가치:

GET /positions?user=<address>, size × 현재 가격.


· 크로스 확인:

계산 결과를 Polymarket 랭킹 API(lb-api.polymarket.com/profit?window=all&address=X)와 비교하며, 차이가 <$10이면 통과입니다. 차이는 보유 포지션 가치의 실시간 변동에서 나옵니다.


확인: 상위 15 랭킹 실증


현금 플로우 방법으로 계산한 후, 랭킹 API와 크로스 확인:


swisstony: 현금 플로우 +$56.01M, 랭킹 +$56.01M, 차이 < $10


kch123: 현금 플로우 +$113.96M, 랭킹 +$113.96M, 차이 < $10


gmanas: 현금 플로우 +$50.24M, 랭킹 +$50.24M, 차이 < $10


세 주소의 오차는 모두 $10 이내로, 차이는 보유 포지션 가치의 실시간 변동에서 나옵니다.


방법이 성공적으로 실행된 후, 상위 수백 개의 주소의 실제 이익과 손실을 분석했습니다. 그것은 또 다른 문제였습니다.


요약


/positions에서 SUM(cashPnl) → 불가능, 이미 정산된 이익을 포함하지 않으며 부호가 반대로 될 수 있습니다.


makerPnl 필드 합계 → 불가능, 체인의 현금 흐름과 일치하지 않습니다.


txHash를 중복을 제거한 후에 계산 → 불가능, $100 이상, 실제 fill이 삭제되었습니다.


오프셋 페이지 + 합계 → 안 돼, 데이터가 잘림, 3000 초과 오류


데이터 API Cash Flow → 현재 가장 신뢰할 수 있음, 10 미만


양자화의 첫걸음은 알파를 찾는 것이 아니다. 먼저 당신이 올바르게 계산했는지 확인해야 한다.


상기 내용은 모두 라이브 거래에서 발생한 삽질이며, 이론적인 유도가 아닙니다. PM의 API는 언제든지 행동을 조정할 수 있으므로 귀하의 계산 결과를 정기적으로 랭킹 API를 사용하여 교차 확인하는 것이 좋습니다.


원문 링크


BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹:https://t.me/theblockbeats

Telegram 토론 그룹:https://t.me/BlockBeats_App

Twitter 공식 계정:https://twitter.com/BlockBeatsAsia

문고 선택
새 문고 추가
취소
완료
새 문고 추가
자신만 보기
공개
저장
오류 신고/제보
제출