AI 에이전트가 스테이블코인 (stablecoins)으로 API 호출 비용을 지불하는 마켓플레이스가 있습니다. 이곳에는 1,062개의 판매자 지갑에 걸쳐 약 **14,800개의 리스팅 (listings)**이 있으며, 모든 리스팅은 대금을 지급받는 주소를 공개합니다.

이는 수요 데이터가 공개되어 있음을 의미합니다. 아무도 추측할 필요가 없습니다.

저는 전체 카탈로그를 열거하고, 모든 판매자의 payTo 주소를 추출하여 Base 네트워크상의 USDC 영수증을 읽었습니다. 에이전트들이 실제로 구매하고 있는 것들은 다음과 같으며, 이는 대부분의 사람들이 구축하고 있는 것과는 다릅니다.

수익을 창출하는 항목

고유 결제 지갑 (distinct paying wallets) 기준으로 가장 큰 카탈로그를 보유한 판매자들을 샘플링했습니다:

이 목록을 다시 읽어보십시오. 거의 전적으로 지루하고 범용적인 유틸리티 (utilities)들입니다. 지오코딩 (Geocoding), 날씨, 검색, 난수 생성 (Randomness) 등입니다. 이는 크립토 네이티브 (crypto-native) 관객이 온체인 에이전트가 원할 것이라고 가정하는 것들이 아니라, 프로그램이 작업을 완료하기 위해 필요한 것들입니다.

실질적인 견인력을 가진 유일한 크립토 인접 제품은 **가스 가격 (gas prices)**이며, 이 또한 논쟁의 여지는 있지만 유틸리티에 해당합니다. 이는 "지금 어떤 체인이 가장 저렴한가"라는 질문에 답하며, 이는 트레이딩 (trading) 결정이 아닌 라우팅 (routing) 결정입니다.

수익을 창출하지 못하는 항목

저는 멀티체인 DEX 데이터 API를 운영합니다. 가격, 유동성 (liquidity), 풀 예비금 (pool reserves), 라우팅 (routing), 슬리피지 (slippage), 교차 거래소 차익거래 (cross-venue arbitrage) 등 6개 체인에 걸친 43개의 유료 엔드포인트 (endpoints)가 모두 동일한 마켓플레이스에 인덱싱되어 있습니다.

실제 제3자 쿼리 (third-party queries)는 단 한 번이라도 있었나요? 사실상 제로입니다.

이것은 품질의 문제가 아닙니다. 엔드포인트는 정확하며 저는 이에 대한 영수증을 가지고 있습니다. 이것은 **수요 (demand)**의 문제입니다. 이 시장에서 거래하는 에이전트들은 DEX 데이터를 찾고 있지 않습니다. 저는 존재한다고 가정했던 관객을 위해 구축했습니다.

수치는 매우 작으며, 이것이 중요합니다

최고 판매자(56명의 고유 결제자)는 제가 샘플링한 기간 동안 $0.70를 벌었습니다. 제가 발견한 단일 판매자 중 가장 높은 수익은 텍스트-투-이미지 (text-to-image)로 인한 $6.10였습니다.

이것은 실제적이고, 반복적이며, 조작되지 않은 결제가 발생하는 실제 시장입니다. 또한, 이는 **1센트 미만 (sub-cent)**의 시장이기도 합니다. 에이전트 결제 (agentic payments)가 현재 골드러시라고 말하는 사람은 체인을 제대로 읽고 있지 않은 것입니다.

실질적인 의미는 다음과 같습니다: 거래량이 몰려올 때 _존재하고 정확하게 작동하는 것_이 가격 책정보다 더 중요합니다. 호출당 $0.001–0.01 수준에서는 1센트를 청구하느냐 2센트를 청구하느냐의 차이는 노이즈에 불과합니다. 하지만 작동하느냐 작동하지 않느냐의 차이는 모든 것을 결정합니다.

내가 두 번이나 빠졌던 측정의 함정

두 가지 수치가 저를 잘못된 길로 인도할 뻔했으며, 두 수치 모두 권위 있어 보였습니다.

첫째: 저의 자체 대시보드는 약 8,762개의 "페이월 (paywall)에 도달한 에이전트"를 보고했습니다. 저는 몇 주 동안 이를 바탕으로 제품 전략을 세웠습니다. 마침내 원장 (ledger)을 제대로 분류했을 때: 82.7%는 저의 자체 모니터링이었고, 17.3%는 쿼리 스트링 (query string) 없이 모든 경로를 훑는 카탈로그 크롤러 (catalogue crawlers)였으며, **0%**가 실제 제3자 쿼리였습니다. 39개의 서로 다른 유저 에이전트 (user-agents)가 있었지만, 그중 37개는 파라미터 (parameter)를 전혀 보내지 않았습니다. 인덱싱 (indexed) 되는 것이 쇼핑 (shopped) 당하는 것은 아닙니다.

둘째: 이 글을 쓰는 동안, 저의 원장에는 4개의 유기적인 결제 (organic settles)가 표시되었습니다 — 프로젝트가 처음으로 확인한 수익이었습니다. 하지만 그것들은 진짜가 아니었습니다. 원장은 결제 서명 헤더 (payment-signature header)가 존재할 때마다 결제 성공 여부를 확인하지 않고 paid 행을 작성했습니다. 네 건 모두 트랜잭션 해시 (transaction hash)가 null이었고, 상위 서버(upstream)의 4xx 에러가 발생했으며, USDC는 전혀 도착하지 않았습니다. 헤더는 _주장 (claim)_일 뿐, 결제가 아닙니다.

두 버그는 공통된 형태를 공유합니다: HTTP 200, 그럴듯한 숫자, 그리고 완전히 거짓임. 상태 코드 (status codes)와 응답 형태 (response shapes)를 검증하는 테스트로는 둘 다 잡아낼 수 없습니다. 이제 저는 규모 (magnitudes)를 검증하고 출처를 교차 확인합니다 — 이 수치가 동일한 대상에 대한 두 번째의 독립적인 측정값과 일치하는가?

직접 해보세요

Discovery API는 공개되어 있으며 키가 필요하지 않습니다:

페이지네이션 (Paginate)을 수행하고, 각 리스팅에서 accepts[].payTo를 수집한 다음, Base 네트워크에서 해당 주소를 수신자 토픽 (recipient topic)으로 하여 USDC Transfer 로그를 읽으세요. 자기 결제 (self-payments)는 필터링하십시오 — 판매자가 자신의 리스팅을 활성화하기 위해 직접 결제하는 것은 흔한 일이며 수요가 아닙니다.

제 시간을 낭비하게 만든 두 가지 함정이 있었습니다. 첫째, /resources 엔드포인트는 items를 반환하는 반면 /merchant는 resources를 반환한다는 점입니다 (14,800개의 리스팅 중 단 하나의 형태가 조용히 0명의 판매자를 산출한다고 가정할 때). 둘째, 대부분의 공개 Base RPC는 eth_getLogs를 10,000블록 범위로 제한하거나, 유료 아카이브 티어(paid archive tier) 없이는 로그 쿼리를 완전히 거부한다는 점입니다.

제가 만들었다가 삭제한 것이 하나 있는데, 바로 카테고리 롤업(category rollup)입니다. 이 기능은 지리(geo), DEX, 날씨, 스포츠 등 모든 카테고리에서 150186명의 결제자를 보고했습니다. 모든 카테고리가 서로 20% 이내의 오차를 보였습니다. 이것은 균등한 수요가 아니라 인위적인 결과물(artefact)입니다. 1001,200개의 리스팅을 운영하는 판매자들이 모든 키워드 버킷(keyword bucket)에 걸쳐 있으며, 각 버킷당 한 번씩 집계되었기 때문입니다. 리스팅별 귀속(Per-listing attribution)을 통해 이를 해결할 수 있겠지만, 체인상에는 경로(route)가 아닌 지갑(wallet)으로의 결제만 나타납니다 — 따라서 이 데이터에는 그러한 귀속 정보가 존재하지 않습니다. 저는 이 수치를 그대로 출시하는 대신 삭제했습니다.

이에 대한 대응 방안

유틸리티를 구축하고 있습니다. 연구에 따르면 지오코딩 (geocoding), 추출 (extraction), 무작위성 (randomness), 그리고 검색 (search)은 현재 결제 고객을 보유하고 있지만, 저의 DEX 엔드포인트는 그렇지 않습니다. 이에 대해 논쟁하는 것은 비용이 많이 들 것입니다.

DEX 인프라는 유지합니다. 이는 정확하고, 운영 비용이 저렴하며, 해당 수요가 나타날 때를 대비해 위치를 잡고 있기 때문입니다. 하지만 다음에 출시할 것은 영수증이 실제로 누군가 원한다고 말하는 무언가가 될 것입니다.

만약 당신이 에이전트(agents)를 위해 무언가를 구축하고 있다면: 구축하기 전에 영수증을 읽으십시오. 데이터는 바로 그곳에 있으며, 그것은 기존의 내러티브(narrative)와 일치하지 않습니다.