Polymarket Bot을 위한 Polygon RPC: Alchemy, QuickNode, Ankr

Polymarket Bot Tutorial · 32장 중 5장

2026년 Polymarket bot을 위한 Polygon RPC provider 비교: Alchemy, QuickNode, Ankr, public endpoints, self-hosted. Latency, rate limits, paper trading에 사용할 수 있는 free-tier까지.

Polymarkets.co.il의 수석 작가 Harley Young 작성. 최종 검토: 2026년 5월.

이 장에서 다루는 내용

Polygon RPC endpoint는 bot이 on-chain state를 직접 확인할 수 있는 유일한 창구입니다. balances, allowances, settlement confirmations, UMA events까지 모두 여기서 읽습니다. Polymarket의 자체 API는 이 중 대부분을 숨기지만, production bot은 자체 bookkeeping을 검증하기 위해 on-chain truth를 읽어야 합니다. 이 장에서는 주요 RPC provider들을 실제 부하 환경에서 비교하고, 각 provider가 무료 요금제에서 언제 한계에 도달하는지 보여주며, 마지막에는 대부분의 bot이 결국 채택하는 two-provider failover pattern을 소개합니다.

• RPC가 bot에서 하는 역할
• Alchemy: free tier와 pricing
• QuickNode: dedicated nodes
• Ankr: 가장 저렴한 paid tier
• Public Polygon RPCs (free, rate-limited)
• Self-hosted Polygon node (언제 의미가 있는가)
• Latency benchmark (US-East vs EU)
• Failover patterns

RPC가 bot에서 하는 역할

RPC endpoint는 bot이 Polygon chain state를 읽고 쓰는 HTTPS 또는 WebSocket URL입니다. Polymarket bot에서 RPC는 네 가지 일을 처리합니다.

• Read balances: proxy에 얼마나 많은 pUSD 또는 USDC가 있는지, 실제로 어떤 outcome token을 보유하고 있는지 확인합니다. CLOB API의 view가 chain truth와 일치하는지 검증하는 데 필요합니다.
• Read allowances: Polymarket contract가 사용자의 token을 사용할 수 있는지 확인합니다. allowance 설정이 잘못되면 order가 조용히 거절될 수 있습니다.
• Subscribe to events: UMA Optimistic Oracle proposal과 dispute, deposit confirmation, 다른 wallet에서 발생한 대규모 on-chain transfer를 감지합니다.
• Verify settlement: CLOB가 "matched"라고 해도 chain에서는 아직 ERC-1155 transfer가 확정되지 않았을 수 있습니다. chain을 읽으면 실제로 완료되었는지 확인할 수 있습니다.

bot이 order를 RPC를 통해 sign하는 것은 아닙니다. order signing은 로컬에서 수행되고, signed payload는 CLOB HTTP API로 전송됩니다. RPC는 대부분의 전략에서 순수하게 read-and-event 채널입니다.

Alchemy: free tier와 pricing

Alchemy는 우리가 아는 Polymarket builder들 사이에서 가장 많이 사용되는 Polygon RPC provider입니다. free tier는 대부분의 paper trading과 소규모 bot 사용 사례를 커버합니다: 초당 300 compute units, 월 3억 compute units, Polygon mainnet과 Polygon testnet endpoint를 provisioning하는 데 사용하는 것과 동일한 dashboard를 제공합니다.

일반적인 20-market bot이 30초마다 balance + UMA event를 읽는 경우 월 약 5천만~8천만 CU를 사용하므로, free cap 아래에서 충분히 운영할 수 있습니다. paid plan은 대체로 월 $50부터 시작하며, 총 호출 수보다 더 높은 per-second throughput을 구매하는 형태입니다. 대부분의 paper-trading bot이 부딪히는 제약은 월 사용량이 아니라 free tier rate limit입니다.

Alchemy는 실패한 request를 확인할 수 있는 유용한 dashboard와 method별 latency breakdown을 제공합니다. 느린 read를 디버깅할 때 특히 도움이 됩니다. 첫 bot을 만들 때는 dashboard만으로도 no-dashboard provider보다 선택할 이유가 충분합니다.

QuickNode: dedicated nodes

QuickNode는 더 높은 throughput 요구를 겨냥합니다. pricing은 tier보다 월 request volume에 따라 확장되며, 많은 WebSocket event filter를 구독하거나 heavy historical-log query를 수행하는 bot에 특히 적합합니다. entry tier는 대략 월 $10~20이며, 일부 free Alchemy tier에서 제한되는 WebSocket 지원이 포함됩니다.

US-East 기준 QuickNode의 per-request latency는 보통 5~15ms로, 부하가 걸린 Alchemy free tier보다 약간 더 좋습니다. 단일 전략 bot에서는 체감하기 어렵지만, 100개 market에 quote를 내는 market-maker라면 의미가 있을 수 있습니다. archive node access(전체 historical state)는 필요할 경우 세 주요 provider 중 가장 저렴합니다.

단점은 JSON-RPC error response가 Alchemy보다 덜 구체적이라는 점입니다. method가 실패했을 때 디버깅에 더 오래 걸립니다.

Ankr: 가장 저렴한 paid tier

Ankr는 주요 provider 중 가장 저렴한 Polygon RPC를 제공합니다. entry premium plan은 대략 월 $10이며 1,500 CU/second를 제공합니다. free tier는 rate limit이 빡빡하지만 paper trading에는 충분히 사용할 수 있습니다.

주의할 점이 두 가지 있습니다. 첫째, Ankr의 load-balanced endpoint는 가끔 약간 오래된 block data를 반환합니다(tip보다 1~2 blocks 뒤). balance read에는 문제없지만, 최신 block에 의존하는 arbitrage strategy에는 중요한 문제가 될 수 있습니다. 둘째, 특정 region의 node에 문제가 생겼을 때 support response time이 Alchemy나 QuickNode보다 느립니다.

Ankr는 비용에 민감한 bot의 primary provider로 합리적이며, primary와 무관하게 backup provider로는 매우 훌륭합니다. 아래의 failover-pattern 섹션에서 함께 사용하는 방법을 다룹니다.

Public Polygon RPCs (free, rate-limited)

Polygon은 몇 가지 free public RPC endpoint를 제공합니다-polygon-rpc.com, rpc.ankr.com/polygon(public, paid Ankr와 별개), 그리고 몇몇 community-hosted endpoint입니다. 동작은 하지만 caveat가 있습니다.

• rate limit이 공격적이고 문서화되어 있지 않습니다. 초당 약 10 req/sec를 지속적으로 넘기면 throttling될 가능성이 큽니다.
• support도 없고 dashboard도 없습니다. endpoint가 실패하면 bot의 error rate가 올라가는 것으로만 알 수 있습니다.
• 대개 1~3 blocks 뒤처집니다. 시간에 덜 민감한 read에는 괜찮습니다.

public endpoint는 laptop에서의 development, two paid provider 뒤에 둔 failover stack의 세 번째 tier, 단발성 script에 사용하세요. live bot trading의 primary로 public endpoint를 사용하지 마세요.

Self-hosted Polygon node (언제 의미가 있는가)

자체 Polygon full node를 운영하는 것은 가능합니다-4-vCPU/16GB VPS에 Bor + Heimdall을 올리고 약 2TB SSD를 사용해 며칠 안에 sync할 수 있습니다. 직접 운영할지 여부를 가르는 계산은 단순합니다.

Cost: 주요 host 기준으로 VPS + storage에 대략 월 $40~80 정도가 듭니다. 편안한 paid RPC plan의 약 4배입니다.

Win: per-request fee가 없고, rate limit도 없으며, chain state에 도달하는 latency가 가장 낮습니다(호스팅 provider까지 인터넷으로 20~50ms가 걸리는 대신 1~3ms).

Pain: snapshot management가 필요하고, Heimdall과 Bor는 각각 crash mode가 있으며, trading 중간에 sync가 멈추면 조용히 stale read가 발생합니다.

대부분의 builder에게는 self-hosting을 권하지 않습니다. node maintenance에 들어가는 시간이 RPC 요금 절감보다 훨씬 큽니다. read latency 30ms가 PnL에 실제로 영향을 주는 전략이 있고, 이미 hosted provider에서 그 전략이 검증된 경우에만 self-host하세요.

Latency benchmark (US-East vs EU)

2026년 5월, 세 지역의 VPS에서 각 provider의 가장 가까운 Polygon RPC로 측정한 median round-trip time입니다.

수치는 주 단위로 약 3ms 정도 변동합니다. 패턴은 안정적입니다: QuickNode와 Alchemy는 사실상 비슷하고, Ankr는 일관되게 5~10ms 뒤처지며, public endpoint는 15~25ms 더 느립니다. Asia-hosted bot은 Polygon의 North-America 중심 backbone 때문에 피할 수 없는 약 80ms의 비용을 치르게 됩니다.

Failover patterns

RPC 하나만 쓰면 단일 장애 지점이 됩니다. production bot은 간단한 swap rule로 두 provider를 사용합니다.

패턴: provider A로 먼저 호출하고, timeout(3초) 또는 5xx response가 오면 provider B로 retry합니다. 둘 다 실패하면 5초 sleep 후 primary를 다시 시도합니다. 연속된 primary 실패 횟수를 추적하고, 3번 실패하면 60초 동안 B에 auto-pin한 뒤 다시 primary를 probe합니다.

권장 조합: Alchemy paid를 primary로 사용하고, Ankr free 또는 public Polygon endpoint를 backup으로 사용합니다. 서로 다른 upstream node operator를 사용하므로 한쪽의 hiccup이 다른 쪽과 연관될 가능성이 낮습니다. 같은 provider의 두 endpoint를 쓰는 것(예: 두 개의 Alchemy key)은 피하세요. 진짜 redundancy가 되지 않습니다.

구현은 web3.py 또는 ethers.js 주변에 얇은 wrapper를 두고, 호출마다 provider를 선택하는 방식입니다. 약 30줄 정도의 코드로, provider에 regional outage가 한 번만 와도 충분히 값어치를 합니다.

자주 묻는 질문