KiteTrace Platform(KiteClaw)

Demo

About

The problem it solves ## The problem it solves KiteTrace Platform is agent-native payment infrastructure on Kite Testnet, designed for **Agent-to-API (ATAPI)** and **Agent-to-Agent (A2A)** paid interactions. ### The Problem It Solves Autonomous agents need frequent micropayments to collaborate, but most flows either: - require repeated wallet approvals (breaks autonomy), or - rely on custodial key handling (adds security risk), while lacking scoped controls and verifiable agent identity. ### What People Can Use It For - Paid API/data access (e.g. BTC price feed, analytics, scoring services) - Paid agent capabilities (e.g. reactive stop-order workflows) - Task delegation, metered compute, and pay-per-action automation ### How It Makes Tasks Easier and Safer - **One-time setup -> autonomous execution**: session-based flow for repeated x402 payments with minimal manual intervention - **Bounded and revocable controls**: policy guardrails (limits, recipient scope, revoke/unrevoke) - **Verifiable identity**: ERC-8004-style registry-backed identity checks - **Direct on-chain confirmation**: each paid action is traceable via `requestId <-> txHash`, plus `block`, `status`, and `explorer link` Bottom line: KiteTrace Platform turns agent interactions into verifiable economic actions on Kite Testnet, so agent activity is traceable and can serve as reliable input for future reputation systems. Use of AI tools and agents I use codex(vscode) to conduct vibe coding for the entire project. I use Grok to generate avatar images , collect the latest technologies on X and optimize my frontend . I also have my Openclaw control the workflow and gather information, and then use Xiaming AI subtitles.

How it's made

Challenges we ran into Building KiteTrace Platform on Kite AI Testnet hit several testnet-specific limitations. Here are the key ones and solutions: 1. **No public / accessible ERC-8004 identity registry on Kite testnet** Many testnets had ERC-8004 deployed, but Kite's was either missing or restricted (limited access), blocking open agent identity verification. → **Solution**: Self-deployed a fully ERC-8004-compatible **IdentityRegistry** (with Reputation & Validation hooks) open to everyone. Agents now get verifiable on-chain agentId, wallet binding, and evidence rendering — integrated in backend lookup & frontend UI. 2. **Native AA only supported insecure EIP-3009 gasless transfers** Original Kite AA relied on EIP-3009 authorizations, requiring backend custody of private keys for repeated gasless actions — major security risk. → **Solution**: Upgraded to full **ERC-4337** + **session-scoped delegation**: - One-time owner signature creates scoped session key with on-chain rules. - Follow-up payments executed by session key under enforced limits (allowlist, per-tx/daily caps, expiry). - No owner private key exposure — shifted to secure, non-custodial model. 3. **Needed transparent, auditable self-hosted x402 gateway** Vendor black-box gateways lack clear payment-action mapping, proof integrity, and transparent failure handling — critical for bounty verifiability. → **Solution**: Built a **fully self-hosted x402 gateway + policy engine**: - Flow: 402 → pay → proof submission → unlock. - Strict requestId ↔ txHash mapping via on-chain Transfer log (not local-only). - Verification: direct ERC20 Transfer event checks. - Graceful failures: expired/fake proof, low balance, scope violation with clear errors. - Kill switch: instant revoke/unrevoke. - Dual audit: x402 logs + Goldsky subgraph for independent on-chain proof. These turned into strengths: public identity, secure AA upgrade, transparent x402 — fully open-source, directly hitting bounty criteria (x402 flows, verifiable identity, autonomy, security).