사람이 개입하지 않는 일반적인 루프는 무엇입니까?

루프 · 검증하고, 위험이 그럴 만하면 더 깊이 살펴보고, 전송이 여기서 인덱싱되었는지 확인

  • 에이전트용
  • 5분
  • 고급
  • 개발자
  • 루프

ACHIVX Academy 원문 (영어) ↗

매뉴얼 §5의 세 단계: 자금을 받거나 보내기 전에 거래 상대를 검증합니다(get-address-risk, 그다음 get-address-compliance). 위험이 그럴 만하면 더 깊이 살펴봅니다(get-address-exposure, token을 지정한 get-wallet-graph-walk). 전송 후에는 이 인터페이스에서 인덱싱되었는지 확인합니다(수취인에 대한 get-recent-transactions, get-sync-status). 모든 페이로드는 완전한 JSON-RPC 2.0 봉투이며, 매뉴얼의 첫 예제는 그대로 실행할 수 있습니다.

루프 원문

매뉴얼 §5 일반적인 루프(사람이 개입하지 않음) — 봉투는 필수이며, 서버는 봉투 없는 {"method":…}를 -32600으로 거부합니다:

# 1. vet the counterparty before you accept or send funds (runnable as-is:
#    0x5754…b949 is Tether Treasury, a hub-scale address, so the answer shows §4
#    at work rather than a fixed tier …)
POST /a2a {"jsonrpc":"2.0","id":1,"method":"get-address-risk",
           "params":{"chain":1,"address":"0x5754284f345afc66a98fbb0a0afe71e0f007b949"}}
POST /a2a {"jsonrpc":"2.0","id":2,"method":"get-address-compliance",
           "params":{"chain":1,"address":"0x5754284f345afc66a98fbb0a0afe71e0f007b949"}}
# 2. if risk warrants, look deeper (pass token explicitly — see §2)
POST /a2a {"jsonrpc":"2.0","id":3,"method":"get-address-exposure",
           "params":{"chain":1,"address":"0x…"}}
POST /a2a {"jsonrpc":"2.0","id":4,"method":"get-wallet-graph-walk",
           "params":{"chain":1,"token":"USDT","address":"0x…","hops":2}}
# 3. after the transfer, confirm it indexed on THIS surface …
POST /a2a {"jsonrpc":"2.0","id":5,"method":"get-recent-transactions",
           "params":{"chain":8453,"recipient":"0x…"}}
POST /a2a {"jsonrpc":"2.0","id":6,"method":"get-sync-status","params":{"chain":8453}}

에이전트 옆에서 읽는 사람을 위해 한 줄씩 설명합니다: jsonrpc, id, method는 봉투입니다. params.chain은 네트워크이며 모든 호출에 명시적으로 전달합니다 — 매뉴얼의 예제는 이더리움(Ethereum)(1)에서 검증하고 베이스(Base)(8453)에서 확인합니다: 3단계는 전송이 정산된 네트워크를 받습니다. params.address는 그 네트워크 자체의 표기 방식으로 씁니다. walk의 token은 스테이블코인을 지정하며 기본값이 없습니다. 예제에서 hops는 2입니다 — 그래프 탐색 스킬의 조언: 2홉에서 시작하고, 질문에 필요할 때만 더 깊이 가십시오. 마지막 두 호출은 수취인의 최신 전송과 네트워크의 최신성을 읽습니다. 정산 스킬의 검증 목록이 말하듯 freshness_seconds가 큰데 items가 비어 있으면 “아직 인덱싱되지 않음”이지 “일어난 적 없음”이 아니기 때문입니다.

첫 예제가 트레저리인 이유

매뉴얼은 일부러 허브 규모 주소를 골랐습니다: 노출 탐색이 시간 예산을 소진하면 등급이 unknown으로 표시될 수 있습니다 — 응답은 incomplete_reasons(time_budget)와 signal이 coverage인 evidence 행에 중단을 밝히고, get-address-exposure에 탐색 정보(truncation_reason, hops_completed)가 있습니다 — 그리고 그 옆의 서비스 플래그는 맥락일 뿐 결코 등급을 움직이지 않습니다. time_budget 중단 후 약 10초(그 외에는 60초) 안에 반복하면 computed_at을 포함해 같은 판정이 반환됩니다. 입력 일부를 잃은 판정은 재사용되지 않습니다 — §4와 §6을 보십시오. 이 루프는 정직성 계약을 읽는 연습이기도 합니다.

스킬로 된 같은 루프

stablescan-screening은 REST 위에서 절차로 만든 루프입니다 — new_counterparty를 위한 ?from=이 붙은 위험 판정, 그 뒤의 사실, 등급이나 사실이 그럴 만하면 노출과 승인(approval), 거래 해시가 발생시킨 발행사 기록, 제재 목록의 최신성 — 그리고 답하기 전에 검증할 목록이 있습니다. 그리고 End-of-life 아래 매뉴얼의 마지막 규칙: 하려던 일을 마쳤으면 멈추십시오. 이 인터페이스에는 “접속 상태”라는 개념이 없습니다 — 온라인에 머물러도 아무 일도 일어나지 않습니다. 루프를 닫고 종료하십시오.

Stablecoin scanner ACHIVX에서

에이전트 매뉴얼 열기 ↗

출처

더 알아보기

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

이 페이지는 ACHIVX Academy 영어 원문을 한국어로 옮긴 것입니다. 번역과 원문이 다르면 영어 원문이 기준입니다.