# Animica Transaction Preflight

> Animica Transaction Preflight is a paid API for AI agents from animica.dev, paid per call via x402, $0.0018/call, status unknown (last checked 2026-09-14).

Decodes a raw Animica CBOR transaction and performs a read-only admission dry-run against the node to reveal why it would be rejected before broadcast

## Facts

- Endpoint: POST https://animica.dev/x402/tx/preflight
- Price: $0.0018/call
- Payment: x402
- Status: unknown
- Last checked: 2026-09-14
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/animica-transaction-preflight-84c5d25e
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_kQtDt4CPQpNZUlewHu-NS

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 animica-transaction-preflight-84c5d25e -d '<json body>'
```

Example prompt: Can you preflight this Animica transaction for me — here's the raw hex: 0xa50082... — I want to know the canonical hash I'm about to sign and whether the node would admit it, without actually broadcasting anything.

## When to prefer this

Use this endpoint when you are developing an Animica transaction signer or encoder and need to validate correctness before broadcast — especially when debugging CBOR encoding issues like non-canonical key ordering, verifying the canonical hash before signing, or understanding node admission rules. It is the only read-only preflight check that combines both CBOR decoding and live node admission simulation in a single call without side effects.

## Known failure modes

- Non-canonical CBOR key ordering causes decoder to reject with explicit naming of the encoding error
- Malformed or truncated hex input returns a decode error
- Invalid 0x prefix handling if hex is malformed
- Node unreachable causes admission dry-run to fail even if decode succeeds
- Missing required body or sigs fields in the CBOR envelope returns a structural validation error

## How this service works

Find out why an Animica transaction would be rejected BEFORE you broadcast it. Decodes your canonical CBOR {body, sigs} envelope, returns the normalised fields and the CANONICAL HASH you are about to sign, then asks the node whether it would admit the transaction and why not. Both calls are read-only: nothing is inserted into the mempool and nothing is broadcast. Built for people writing Animica signers, where the alternative feedback loop is broadcast-and-see. No model.

## Output

Returns the decoded normalised transaction fields, the canonical hash that will be signed, and (unless skip_admission is true) the node's admission dry-run result including any rejection reason — all without inserting anything into the mempool or broadcasting.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "raw_tx": {
   "type": "string",
   "description": "the transaction as hex, 0x-prefixed or not. Animica expects canonical CBOR of {body, sigs} with strictly-increasing map keys — non-canonical key order is the most common first failure and the decoder names it explicitly."
  },
  "skip_admission": {
   "type": "boolean",
   "description": "decode only, skipping the admission dry-run (default false). Useful when you are iterating on encoding and do not yet have signatures attached."
  }
 }
}
```

## Response schema (JSON Schema)

```json
{
 "type": "json"
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/animica-transaction-preflight-84c5d25e/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from animica.dev](https://www.zero.xyz/host/animica.dev/llms.txt)