# Animica Post-Quantum ML-DSA-65 Document Signing

> Animica Post-Quantum ML-DSA-65 Document Signing 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).

Creates a FIPS 204 ML-DSA-65 post-quantum digital signature over a document hash or JSON payload, returning a verifiable envelope without exposing the original document.

## Facts

- Endpoint: POST https://animica.dev/x402/pq/sign
- 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-post-quantum-ml-dsa-65-document-signing-3cc37b6f
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_x9vKXzpsRLQ24iJnM5Z66

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-post-quantum-ml-dsa-65-document-signing-3cc37b6f -d '<json body>'
```

Example prompt: Sign this SHA-256 digest 'a3f1c9e2b7d4...8f0e' with the label 'model-card-v2-release' using a post-quantum ML-DSA-65 signature on Animica — I need an envelope I can publish or put on-chain that will still be verifiable even after quantum computers exist.

## When to prefer this

Choose this endpoint when you need a signature that remains verifiable by third parties years or decades from now without trusting a shared HMAC secret, and when the long-term threat of cryptographically-relevant quantum computers makes classical ECDSA signatures unacceptable. It is ideal when the document itself must not be disclosed but a signed commitment to its exact bytes is required — for dataset manifests, model cards, audit log segments, inter-agent delivery receipts, or any legally or compliance-relevant artifact. It is preferable to HMAC (which proves nothing to third parties) and to classical ECDSA (which is retrospectively vulnerable to quantum adversaries).

## Known failure modes

- Both digest and payload provided simultaneously — endpoint rejects with an error requiring exactly one
- Digest is not exactly 64 hex characters — returns validation error
- Label exceeds 128 printable ASCII characters — rejected
- Non-JSON or malformed payload when using payload mode — canonicalization fails
- digest_alg specified alongside payload mode as something other than sha256 — rejected
- Service temporarily unavailable — HTTP 503 with retry guidance
- Payment not included or insufficient — HTTP 402 challenge with price details

## How this service works

Get a post-quantum ML-DSA-65 signature (FIPS 204, scheme 4099 — the same scheme the Animica L1 admits transactions with) over a document you never have to send us. Post a sha256 digest, or post a JSON payload and we canonicalise and hash it here; either way the signature covers the HASH, so the resulting envelope can be published, escrowed or put on-chain without disclosing the content. Buy this when a claim has to stay checkable by a third party years from now — a dataset manifest, a model card, an audit-log segment, a delivery receipt between two agents, the exact bytes of an agreement — because an HMAC proves nothing to anyone but its issuer and an ECDSA signature made today is retrospectively forgeable once a cryptographically-relevant quantum computer exists. You need no PQ library and no key of your own. Verification is FREE (POST /x402/pq/sign/verify) and the signing public key is FREE (GET /x402/pq/sign/pubkey), so anyone can check an envelope offline without paying us. The signed statement records whether YOU or WE computed the digest, because those are different claims. If the signer or its key is not reachable you get a 503 with the reason and are NOT charged — this endpoint has no branch that returns an unsigned envelope.

## Output

A signed envelope containing the ML-DSA-65 signature (FIPS 204 scheme 4099), the hash that was signed, the client-supplied label, the declared digest algorithm (or a marked default), a reference to the signing public key for offline verification, and metadata indicating the signature scheme — all without the original document ever leaving the caller's custody.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "properties": {
  "label": {
   "type": "string",
   "description": "your own annotation for what this covers, up to 128 printable ASCII characters; signed, and marked in the envelope as the client's claim"
  },
  "digest": {
   "type": "string",
   "description": "64 hex characters — the 32-byte digest of your document. Send this OR payload, never both. Your document never leaves your side."
  },
  "payload": {
   "type": "object",
   "description": "a JSON value to canonicalise and SHA-256 here instead of sending a digest. Hashed and dropped: never stored, logged or returned."
  },
  "digest_alg": {
   "type": "string",
   "description": "how YOU computed digest, recorded in the signature as your declaration: sha256, sha3-256, keccak-256, blake2b-256. Omit it and the signature says sha256 with document_digest_alg_source:'assumed_default' — a default, marked as one, never presented as something you stated. With payload it must be omitted or sha256, which is what we run."
  }
 }
}
```

## Response schema (JSON Schema)

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

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/animica-post-quantum-ml-dsa-65-document-signing-3cc37b6f/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)