ZOOBC / 에이전트 트레저리 인프라
AI 에이전트에게 자금을 맡기세요. 넘을 수 없는 상한과 함께.
ZooBC는 자율 에이전트가 스스로의 자제력이 아니라 네트워크가 강제하는 예산 경계 안에서 지출하고, 고용하고, 거래할 수 있는 여지를 줍니다. 의존성 없는 Python 참조 구현이 실제 TestNet에서 전체 트랜잭션 흐름을 입증합니다.
- 한도
- 사전에 잠금
- 제어
- 증액은 사람이 서명
- 기록
- 독립적으로 검증 가능
여기서 시작 / 세 가지 실시간 자료
탐색부터 검증된 트랜잭션까지.
에이전트나 개발자는 브라우저, SDK, 의존성 설치 없이 탐색 파일 하나에서 시작해 확정된 TestNet 트랜잭션까지 도달할 수 있습니다.
에이전트에게 파일 하나를 주세요.
llms.txt는 실제 TestNet, 필수 엔드포인트, 서명 모델, 포셋, 그리고 에이전트가 다음에 읽어야 할 문서를 알려 줍니다.
llms.txt 열기 ↗02 / 구현전체 에이전트 가이드를 읽으세요.
AGENTS.md는 트랜잭션 구성, 예약 허용액, 만료되는 에스크로, 멀티시그 지출, 감사 쿼리, 알려진 한계를 문서화합니다.
AGENTS.md 읽기 ↗03 / 실행작동하는 참조 구현을 실행하세요.
의존성 없는 Python 파일 하나가 키를 생성하고, 테스트 코인을 받고, 수수료를 추정하고, 서명하고, 제출하고, 확정한 뒤 실제 트랜잭션을 검증합니다.
Python 참조 구현 열기 ↗아직 풀리지 않은 제어 계층
자율성에 백지수표가 필요해서는 안 됩니다.
AI 시스템은 점점 자신만의 작업, 도구, 구매 결정을 갖게 되고 있습니다. 어려운 부분은 모든 움직임을 지켜보지 않고도 금융 권한을 주는 것입니다. ZooBC는 지출 경계를 네트워크 상태로 만듭니다. 에이전트는 그 안에서 자유롭게 행동할 수 있지만, 경계를 다시 쓸 수는 없습니다.
소프트웨어는 제안하고, 원장은 강제합니다.
세 가지 제어 + 세 가지 기능
네트워크가 강제하는 것, 그리고 애플리케이션이 그 위에 구축하는 것.
잠긴 허용액, 만료되는 에스크로, 멀티시그 임계값은 제어 장치입니다. 상거래, 토큰 정산, 선언된 신원은 ZooBC 트랜잭션과 데이터로 조립하는 기능입니다.
AI 에이전트가 넘을 수 없는 허용액.
자금 조달 모드 0으로 만든 예약 이체는 생성 시점에 전체 기간의 허용액을 잠급니다. 에이전트는 지급될 때마다 정해진 금액을 받으며, 총액을 늘리려면 소유자가 승인한 새 트랜잭션이 필요합니다. 남은 금액은 회수하거나 다른 곳에 재할당할 수 있습니다.
돈을 묶어 두지 않고도 결제가 당신의 결정을 기다릴 수 있습니다.
에이전트는 지정된 승인자가 수락하거나 거절할 때까지 대기 상태로 남는 결제를 제안할 수 있습니다. 시간 제한은 절대 Unix 타임스탬프입니다. 응답 없이 그 시점이 지나면 금액과 커미션이 온체인에서 자동으로 반환됩니다.
큰 결제에는 둘 이상의 서명을 요구하세요.
멀티시그 이체는 정해진 N-of-M 서명 임계값이 충족된 후에만 실행됩니다. 애플리케이션은 소액 트랜잭션은 에이전트가 직접 처리하게 하고, 큰 약정은 독립적인 승인자를 거치도록 할 수 있습니다.
에이전트는 거래하고 검증 가능한 영수증을 남길 수 있습니다.
에이전트 간 상거래는 서명된 트랜잭션과 위의 제어 장치로 구축하는 사용 사례입니다. 누구나 어느 에이전트의 비공개 로그에도 의존하지 않고 트랜잭션 해시, 블록 확정, 계정 내역, 잔액 변동을 조회할 수 있습니다.
기계 간 소액 결제를 온체인에서 정산하세요.
소액 결제는 ZBC, 사용자가 발행한 토큰, 서명된 이체, 온체인 거래소 위에 구축하는 사용 사례입니다. 애플리케이션은 이 인프라를 이용해 조회, API 호출, 기타 기계 작업의 대금을 정산하면서 공개 결제 기록을 남길 수 있습니다.
에이전트가 스스로를 무엇이라고 주장하는지 게시하세요.
에이전트는 운영자, 목적, 기능, 엔드포인트, 예산 일정을 설명하는 서명된 데이터셋 레코드를 기록할 수 있습니다. 이는 계정이 내놓는 검증 가능한 주장일 뿐, 체인이 강제하는 신원 기본 요소가 아닙니다. 이를 신뢰할지는 여전히 애플리케이션이 결정해야 합니다.
하나의 에이전트 / 두 개의 경제 계층
모델이 소비한 것과 에이전트가 지출한 것을 함께 확인하세요.
유용한 에이전트에는 계량기가 두 개 있습니다. 모델 제공자는 추론 사용량을 측정합니다. ZooBC 계정은 에이전트가 현실에서 행동하며 지출한 가치를 기록합니다. 애플리케이션은 같은 에이전트와 워크플로를 기준으로 두 기록을 대조할 수 있습니다.
제공자가 보고하는 토큰, 호출, 연산량.
온체인에 기록된 결제, 에스크로, 일정, 수수료, 잔액 변동.
모델 사용량을 독립적으로 검증 가능한 체인 지출과 대조합니다.
강제 경계: ZooBC는 체인 측 허용액과 트랜잭션 규칙을 강제합니다. 추론 계량의 기준은 여전히 모델 제공자이므로, 두 기록을 결합하는 것은 애플리케이션 코드의 몫입니다.
실제 트랜잭션 경로
일정 설정부터 원장 증명까지, 한도가 정해진 결제.
이 패턴 뒤에 있는 실제 ZooBC 작업들입니다. 전문가를 고르고, 작업을 검증하고, 어떤 서명을 인정할지 결정하는 것은 여전히 애플리케이션 코드의 몫입니다.
- 01 / TX 유형 29
허용액을 잠급니다.
scheduled-transfer
funding_mode: 0소유자가 총액을 미리 잠급니다. 전체 기간 상한을 바꾸려면 새 트랜잭션이 필요합니다.
→ - 02 / 에스크로
결제를 제안합니다.
zbc-send
--escrow-approver에이전트가 승인자를 지정하고, 자동 반환을 위한 절대 Unix 시간 제한을 제시합니다.
→ - 03 / 멀티시그
임계값을 충족합니다.
zbc-cli multisig
2 of 3 example큰 결제라면 애플리케이션이 납품을 검증하고, 내부 이체가 실행되기 전에 필요한 서명 세 개 중 두 개를 모읍니다.
→ - 04 / 공개 API / TESTNET
정산하고 검증합니다.
approve-escrow approval: 0
GET https://zoobc.network/api/v1/transactions/{hash}
GET https://zoobc.network/api/v1/accounts/{address}/history승인되면 자금이 지급되고, 시간이 초과되면 반환됩니다. 어느 경로로 진행되었는지는 트랜잭션과 계정 내역이 증명합니다.
✓
작동 방식
첫 파일부터 검증된 트랜잭션까지, 네 단계.
어려운 질문
경계가 해결하는 것과 해결하지 못하는 것.
원장은 금융 조건을 강제할 수 있습니다. 하지만 신중한 에이전트 설계, 신원 주장, 결과 검증을 대신할 수는 없습니다.
01지출 상한이 있으면 에이전트가 안전한가요?
위험에 노출되는 금액을 제한할 뿐, 모든 구매가 현명하다는 것을 보장하지는 않습니다. 작업 권한, 공급자 선택, 결과 검증, 운영 모니터링은 여전히 지갑을 둘러싼 에이전트 시스템이 맡아야 합니다.
02에이전트가 스스로 허용액을 늘릴 수 있나요?
여기서 설명한 한도 패턴에서는 불가능합니다. 약정된 상한을 늘리려면 허용액을 통제하는 계정이 승인한 새 트랜잭션이 필요합니다.
03제안된 결제가 끝내 승인되지 않으면 어떻게 되나요?
제안에는 만료 시점을 둘 수 있습니다. 기한까지 승인이 오지 않으면, 에스크로된 금액은 무기한 대기 상태로 남지 않고 설정된 반환 경로를 따릅니다.
04어떤 에이전트가 작업을 승인했는지 무엇으로 증명하나요?
암호학적 서명은 특정 키의 보유자가 메시지나 트랜잭션을 승인했음을 증명합니다. 그 키의 운영자, 목적, 평판에 관한 주장에는 여전히 명확한 서명 기록과 독립적인 검증이 필요합니다.
05이것은 에이전트 제품인가요, 블록체인 기본 요소의 모음인가요?
현재 그 기반은 ZooBC 트랜잭션 계층입니다: 계정, 서명, 에스크로, 다중 서명 승인, 토큰, 감사 가능한 원장. 실제 운영 환경의 에이전트 통합에는 여전히 특정 워크플로에 맞게 이 기본 요소들을 조립하는 소프트웨어가 필요합니다.
TESTNET 운영 중
먼저 증명을 실행하고, 그다음 경계를 더하세요.
작동하는 참조 구현으로 시작해 실제 TestNet 트랜잭션을 확인한 다음, 워크플로에 필요한 허용액, 승인, 감사 제어를 추가하세요.