# Kette Bridge Transfer Tracker

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

Reads an on-chain transaction hash, identifies the bridge protocol used, and reports the true amount leaving the wallet, fees, elapsed time relative to that bridge's expected duration, and the next required action if the transfer is stuck.

## Facts

- Endpoint: POST https://kette.halowerk.com/bridge/track
- Price: $0.004/call
- Payment: x402
- Status: unknown
- Last checked: 2026-09-14
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/kette-bridge-transfer-tracker-a2b73bef
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_6_IAg6RNGJWaSSz8N9yBb

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-bridge-transfer-tracker-a2b73bef -d '<json body>'
```

Example prompt: My bridge transfer for 500 USDC from Ethereum to Arbitrum has been pending for hours — can you look up transaction 0xabc123... and tell me which bridge it used, whether it's overdue, how much was deducted in fees, and what I need to do to claim it if it's stuck?

## When to prefer this

Use this endpoint when a user has a specific cross-chain bridge transaction hash and needs to know: which bridge was used, whether it is overdue relative to that bridge's own normal duration, what fees were deducted, or what manual step (e.g. claim) is blocking completion. Prefer this over generic transaction decoders when the primary concern is bridge-specific timing, fee reconciliation, or stuck-transfer diagnosis.

## Known failure modes

- Transaction hash not found on the specified chain — returns error indicating unknown tx
- Transaction did not touch a recognized bridge contract — bridge cannot be identified
- RPC unavailability for the source chain causing lookup failure
- Bridge protocol is new or obscure and not yet in the known-contracts index
- Source chain not supported by the endpoint

## How this service works

Reads the source transaction on chain, identifies the bridge from the contracts it touched, and reports what actually left the wallet. overdue is measured against the usual duration of THAT bridge, and the comparison value is part of the answer - not against a fixed number. For bridges that need a manual claim, next_step says which step is missing and who has to trigger it; that is the real answer for a transfer that looks stuck. amount_delta shows what was deducted on the way, so a smaller arri

## Output

Returns the identified bridge protocol, the actual amount deducted from the wallet, the amount_delta (fee or slippage), elapsed time since the source transaction, the typical expected duration for that specific bridge, an overdue flag, and a next_step field indicating whether a manual claim is required and who must trigger it.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "bridge": {
   "type": "string",
   "description": "Optional hint which bridge was used. Only used when detection fails."
  },
  "tx_hash": {
   "type": "string",
   "description": "Transaction hash of the deposit, 0x followed by 64 hex characters."
  },
  "source_chain": {
   "type": "string",
   "description": "Chain the deposit was made on."
  }
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/kette-bridge-transfer-tracker-a2b73bef/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)