# Kette Honeypot Detector

> Kette Honeypot Detector is a paid API for AI agents from kette.halowerk.com, paid per call via x402, $0.01/call, status unknown (last checked 2026-09-14).

Simulates token transfer steps via eth_call with state override to detect honeypot-style traps on ERC-20 tokens without broadcasting any transaction.

## Facts

- Endpoint: POST https://kette.halowerk.com/token/honeypot
- Price: $0.01/call
- Payment: x402
- Status: unknown
- Last checked: 2026-09-14
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/kette-honeypot-detector-908634b0
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_1PzznmlJ0IQCB7N8KJh5C

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability kette-honeypot-detector-908634b0 -d '<json body>'
```

Example prompt: Can you run a honeypot simulation on this token contract 0xABC123... on Ethereum — I want to know if each transfer step goes through or gets blocked before I buy in.

## When to prefer this

Use this endpoint when you need a gas-free, no-transaction honeypot check that breaks down each transfer step individually, making it visible exactly where a token becomes unmovable. Prefer this over DEX-router-based simulators when you do not have a funded account or a specific router path, and when you want step-level granularity rather than a single buy/sell verdict.

## Known failure modes

- Invalid or non-ERC-20 contract address returns an error
- Unsupported chain returns a validation error
- Undeployed or self-destructed contract cannot be simulated
- RPC node unavailability causes simulation timeout
- Token with non-standard transfer logic may produce ambiguous results

## How this service works

Runs each step separately as a simulation (eth_call with state override) against the current chain state and reports each result on its own, so a token that can be received but not moved on is visible as exactly that. Nothing is ever executed: no transaction is broadcast, no key is held, no approval is given. Limits, and they are decisive: can_buy and can_sell through a DEX router are NOT simulated - that needs a funded account and a router path this service cannot back, so both stay null. What 

## Output

A per-step simulation report showing which token transfer operations (e.g. receive, transfer out) succeed or fail under eth_call with state override against current chain state. Flags tokens that can be received but not moved. Note: can_buy and can_sell via a DEX router are always null because those require a funded account and router path.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "chain": {
   "type": "string",
   "description": "Chain identifier, for example ethereum, base, arbitrum, optimism, polygon or bsc."
  },
  "token": {
   "type": "string",
   "description": "ERC-20 contract address, 0x followed by 40 hex characters."
  },
  "holder": {
   "type": "string",
   "description": "Optional: an address that actually holds the token. Its balance is used as the source for the transfer simulation, which makes the result far more meaningful."
  }
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/kette-honeypot-detector-908634b0/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from kette.halowerk.com](https://www.zero.xyz/host/kette.halowerk.com/llms.txt)