KaspaCom has opened a public testnet interface for agents and wallets to analyse KCC20 markets, prepare trades and follow settlement without handing private keys to its backend. The release includes an agent guide, OpenAPI specification, machine-readable documentation and public build endpoints for the KaspaCom decentralised order book (announcement, agent guide).
The integration separates transaction planning from signing. An agent reads token discovery data, wrappers, order books and quotes through HTTP, then asks KaspaCom to build an unsigned Partially Signed Kaspa Transaction payload. The wallet or signing provider inspects the returned manifest, signs locally, broadcasts through its own wallet or wRPC stack and polls for settlement. KaspaCom states directly that a backend response is a plan rather than proof of execution, with chain and indexer reads remaining authoritative after broadcast.
That boundary allows automated software to handle market selection and transaction construction while the signing key stays with the user. No dedicated SDK is required because the public API is exposed as a normal HTTP contract. KaspaCom also lists an optional @kaspacom/kcc20-agent package and MCP integration for developers who want a packaged route rather than direct requests (machine-readable documentation, public API).
The public flow starts with token and market discovery. Agents can retrieve a canonical token ID, ticker, name, best bid and best ask, then load token-page data and the enabled wrapper covenant. Quotes are validated before construction, and the guide distinguishes between filling one selected order and sweeping several orders. The agent is expected to stop when the quote is invalid, contains errors or does not match the user strategy.
KCC20 balances introduce a UTXO-specific problem that account-based trading agents do not normally encounter. A wallet may hold enough tokens in total while lacking one compatible UTXO large enough for the requested action. KaspaCom exposes a consolidation preflight for transfers, wrapping, unwrapping and sell-order creation. The response tells the client whether consolidation is required, whether it can be performed and whether the operation should instead be split into smaller steps.
The build API covers token deployment, minting and trading operations on the public testnet surface. Each request identifies the signing wallet, while owner information can be supplied or derived from the wallet address. The backend returns unsigned material for review and signing rather than a privileged endpoint that spends funds on behalf of the user.
Agent-oriented documentation is part of the release rather than an explanatory thread alone. KaspaCom has published a Markdown integration guide, an LLM index, full machine-readable documentation, Swagger UI and OpenAPI JSON. The public endpoints were live when checked, including the health, guide and API documentation surfaces (health endpoint, OpenAPI documentation).
The current environment is testnet. The documentation also warns third-party clients to use only the public surface and avoid internal website, administration, campaign and private user-state routes. Any production agent would still need independent transaction-policy controls, signing review and settlement verification rather than treating an automatically generated payload as safe by default.
The release gives Kaspa builders a concrete agent integration path at the same time that KCC conventions are moving towards common token and authority interfaces. Its practical value will depend on wallets and independent agents completing the full build, sign, broadcast and settlement loop under real test conditions, but the interface required to attempt that integration is now public.
