get-recent-transactions는 무엇을 반환합니까?

한 체인의 최신 스테이블코인 전송으로, recipient 또는 payer로 필터링할 수 있고 커서로 페이지를 나눕니다. items[]에는 tx_hash, log_index, block_number, block_time, payer, recipient, amount {최소 단위 금액, 소수 자릿수, 토큰 심볼}, token(컨트랙트 주소), finality, 그리고 가격이 매겨진 경우 usd_amount가 들어갑니다. limit의 기본값은 25이며 허용 범위는 1–200뿐입니다. REST 피드 GET /v1/transfers는 같은 행에 전체 필터 목록을 제공합니다. 어떤 행이든 오프로드된 뒤에는 두 응답 모두 hot_window_start를 담습니다.

무엇에 답합니까

카드 설명: 단 하나의 체인에서 최신 스테이블코인 전송을 수취인/송금인으로 필터링하고 커서로 페이지를 나눕니다(next_cursor). 응답: items[], 각 행은 tx_hash, log_index, block_number, block_time(RFC 3339), payer, recipient, amount {amount(최소 단위, 문자열), decimals, token(심볼)}, token(컨트랙트 주소), finality, 그리고 가격이 매겨진 경우 usd_amount. 체인은 요청한 체인이며 행에서 반복되지 않습니다. 일반적인 온체인 Transfer 사실입니다. chain의 기본값은 8453(베이스(Base))입니다 — 카드 설명: get-recent-transactions에서 T…나 base58 형식의 payer/recipient 필터는 대신 트론이나 솔라나를 선택합니다 — 그러니 명시하십시오. limit의 기본값은 25입니다. 매뉴얼: 1–200 밖의 값은 거부됩니다(A2A에서는 -32602, MCP에서는 도구 오류). REST도 마찬가지로 거부합니다.

REST 피드

GET /v1/transfers — 정산 피드(next_cursor로 페이지를 나눔. 허용하는 필터는 ?payer=, ?recipient=, ?token=, ?chain=, ?tx=, ?block=, ?finality=final|pending, ?dir=older|newer, ?limit=(1–200, 기본값 50, 그 밖의 값은 400), ?cursor=, ?offset=이며 이 목록이 전부입니다. 이 주소와 관련된 모든 것을 한 번에 거르는 결합 필터는 없습니다 — payer와 recipient를 따로 조회해 병합하십시오). 알 수 없는 매개변수, 예를 들어 ?address=는 400 unknown_param입니다. 2026-10-13 이더리움(Ethereum)에서 읽은 한 행: block_time 2026-10-13T13:50:23Z, amount {"amount": "30891500", "decimals": 6, "token": "USDT"}, token은 USDT 컨트랙트, finality는 pending. 페이지에는 next_cursor, total: 25000, capped: true, hot_window_start: "2026-10-11T00:00:00Z"가 있었습니다.

결제가 도착했습니까?

정산 스킬의 절차: GET /v1/transfers?chain=<chain>&recipient=<address>&limit=50, 또는 거래 하나에 대해서는 &tx=<hash>. next_cursor로 페이지를 넘긴 다음 GET /v1/sync/status?chain= — “받지 못함”으로 결론 내리기 전에 확인하십시오. 검증 규칙: *_usd6 필드는 마이크로달러입니다(스킬의 예시 행 — amount_usd6, 심볼로 된 token — 은 예전 구조입니다. 실제 행과 openapi.json에는 amount {…}, 가격이 매겨진 경우 usd_amount, 컨트랙트 주소로 된 token이 있습니다). finality: "pending" 행은 아직 재구성(reorg)으로 사라질 수 있으니 확정되지 않은 것으로 보고하십시오. freshness_seconds가 큰데 items가 비어 있으면 “아직 인덱싱되지 않음”이지 “일어난 적 없음”이 아닙니다. total_unavailable_reason과 함께 "total": null이면 개수 집계가 끝나지 않았다는 뜻이며 행은 실제입니다. 그리고 hot_window_start가 있는 빈 &tx= 응답은 없음이 아니라 알 수 없음입니다 — 해시에는 경계와 비교할 시각이 없기 때문입니다(원시 행은 얼마나 과거까지 닿습니까?). 매뉴얼의 루프는 이 단계로 끝납니다 — 수취인에 대해 get-recent-transactions, 그다음 get-sync-status: 전송 후, 이 인터페이스에서 인덱싱되었는지 확인하십시오 … — 그리고 x402 결제 검증에는 이 호스트가 맞지 않는다고 덧붙입니다.

해시 하나, 네트워크 없음

chain 없는 /v1/transfers?tx=는 베이스만 검색하며 chain_source: "default"로 그 사실을 밝힙니다. 해시만 갖고 있다면 GET /v1/verify?tx={hash}가 인덱싱된 모든 네트워크에 한 번에 묻습니다. 2026-10-13 새 이더리움 해시는 found: true, chain_slug: "ethereum", transfers_total: 1, 그리고 여섯 개의 chains[] 행(그중 다섯 개는 not_found)으로 답했습니다 — 솔라나는 묻지 않으며, 해시가 맞는 id 형식을 가진 네트워크에만 묻고, 각각 그 네트워크의 동기화 응답을 담습니다. 멀티시그 제출은 스테이블코인을 움직이지 않습니다. /v1/transfers?tx=와 /v1/freezes?tx=가 모두 비어 있으면 세 번째 조회는 /v1/freezes/proposals?tx=입니다.

Stablecoin scanner ACHIVX에서

이더리움 피드를 JSON으로 열기 ↗

• REST 피드: /v1/transfers?chain=1&limit=5. 사람이 읽는 페이지: 정산 피드.
• 전체 필터 목록은 /openapi.json에 있습니다. 모든 네트워크에서 해시 하나 조회: /agents.md §2의 GET /v1/verify?tx=.

출처

• A2A 에이전트 카드 (1.4.0)
• 에이전트 매뉴얼 — agents.md (버전 2026-10-05)
• REST 인터페이스의 OpenAPI 3.1 명세 (API 1.4.0)
• stablescan-settlement-data SKILL.md
• GET /v1/transfers?chain=1&limit=2 (2026-10-13 조회)
• GET /v1/verify?tx=0x9af1…fe9f (2026-10-13 조회)

더 알아보기

• 정산 표
• 스테이블코인 결제는 온체인에서 어떻게 정산되나요?

관련 질문

• get-sync-status는 무엇을 반환합니까?
• 페이지 나누기와 캐시는 어떻게 합니까: 커서, ETag, If-None-Match?
• 기계가 조회할 때 원시 행은 얼마나 과거까지 닿습니까?

정직성 계약과 여덟 가지 기능 · 스킬 · 2026-10-13 작성, 스캐너 자체의 기계용 문서와 그날 조회한 실시간 응답을 바탕으로 했습니다. 구조는 그대로 인용했으며, 수치는 날짜 기준이고 인덱스에 따라 바뀝니다.