> ## Documentation Index
> Fetch the complete documentation index at: https://ixoworld-canonical.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Claims management

> Build claim workflows while keeping IXO Protocol and service API responsibilities separate.

Use this guide for workflow design and integration choices. Use API reference pages for exact request/response contracts.

## Before you start

* Decide whether your claim operation runs at protocol layer or service layer.
* Confirm endpoint and network values in `/reference/networks-and-endpoints`.
* Confirm auth requirements in `/reference/authentication-matrix`.

## Protocol vs service boundary

* Protocol layer: claim module transactions and state queries through protocol gateways.
* Service layer: product-specific reporting and workflow APIs (for example, Registry service endpoints).

## Claim workflow outline

1. Create or collect claim data.
2. Submit to the target surface (protocol or service).
3. Run evaluation and dispute handling.
4. Track lifecycle transitions.

## Example protocol message literal

```typescript theme={null}
const msg = {
  typeUrl: "/ixo.claims.v1beta1.MsgSubmitClaim",
  value: {
    creator,
    claimId,
    claimType,
    data: claimData
  }
};
```

## Verify the result

Expected result:

* accepted claim write or query response on the target surface;
* clear traceability of whether execution happened through protocol gateways or a service API.

## See also

* [Identity and credentials](/guides/dev/identity-and-credentials) — how claims relate to DIDs and verifiable credentials
* [Developer workflows](/guides/dev/workflows) — SDK-oriented create and evaluate patterns
* [Blockchain RPC API](/api-reference/rpc-api)
* [Registry API](/api-reference/registry-api)
* [Product and SDK map](/reference/product-and-sdk-map)
* [Networks and endpoints](/reference/networks-and-endpoints)
* [Authentication matrix](/reference/authentication-matrix)

## Troubleshooting

* **Broadcast / transaction failures** — Read `rawLog` or `code` from the node response. `insufficient funds`, `unauthorized`, and `sequence mismatch` are common: fix fees, signer, or account sequence. Compare your `chainId` and RPC URL with [Networks and endpoints](/reference/networks-and-endpoints).
* **GraphQL partial failures** — Blocksync may return `errors` alongside partial `data`. Treat the response as failed for downstream writes if any required field is null; re-check filters and IDs.
* **DID or entity not found** — Confirm the entity is indexed on the network you query; registry vs indexer lag can produce temporary “not found” results.

## Next steps

Use the [API introduction](/api-reference/intro-apis) matrix to pick RPC, REST, GraphQL, or Registry for each step of your workflow.