Skip to main content
These workflows show the canonical message patterns from the @ixo/impactxclient-sdk README. For full type definitions, see @ixo/impactxclient-sdk and the proto definitions.
There is no single blessed CLI for every IXO operation. Prefer the SDK, Cosmos-compatible wallets, or deployment-specific CLIs your operator documents. For HTTP-oriented domain examples, see Domain registration.

Prerequisites

  1. Install dependencies: @ixo/impactxclient-sdk. For Agentic Oracle integration, see Agentic Oracles ADK.
  2. Choose RPC endpoint and chain ID from Networks and endpoints.
  3. Choose auth for each surface from Authentication matrix. On-chain writes require a funded signer (wallet or key management you control).

1. Initialize query and signing clients

Reads use createQueryClient. Writes need a signer-backed createSigningClient. Both target the same RPC endpoint.
Errors: RPC misconfiguration surfaces as connection timeouts or JSON-RPC errors. Try a different node if your operator allows; confirm TLS and chainId against the network row in Networks and endpoints. For signer setup (Cosmos-kit, Keplr, or getOfflineSigner from cosmjs-utils), see SDK README — Creating signers.

2. Register an entity (digital twin)

Compose MsgCreateEntity, sign and broadcast.
Read the resulting entity through the query client:
Errors: invalid entityType or context key/value pairs that the chain does not accept return failed transactions. Inspect code and rawLog on the broadcast response.

3. Submit a claim

Errors: missing collectionId, schema mismatch, or insufficient authorization produce chain errors. Cross-check Claims management and Custom authorisations for IXO Claims.

4. Evaluate a claim (oracle-assisted)

An Agentic Oracle returns a determination off-chain; the on-chain record is written by MsgEvaluateClaim. The example below assumes an Agentic Oracle service exposes a verify endpoint your code calls — see Agentic Oracles ADK for the canonical SDK home and Build agentic oracles for the architecture.
callOracleVerify is a placeholder for whatever HTTP, MCP, or SDK call your Agentic Oracle exposes. The on-chain side is what @ixo/impactxclient-sdk covers — the off-chain agent service is your application code.
Errors: oracle 401/403 typically means wrong operator credential or DID. Chain-side MsgEvaluateClaim failures usually point to authorization (no EvaluateClaimAuthorization) or claim state.

5. Issue tokens against an evaluated claim

After approval, mint tokens with MsgMintToken against your token contract — see Manage tokens for the full message family.

6. Verifiable credentials

Credential issuance and verification are governed by your program’s issuer keys, schemas, and registry or IXO Matrix storage — see Credential issuance and Identity and credentials. Implement issuance in the component that holds the issuer key; verifiers should check signature, issuer DID, schema, and revocation/status lists. For HTTP-oriented credential flows on Emerging, see Emerging API and the matching auth rules in Authentication matrix.

Error handling

  • HTTP service calls: use Error handling for status codes; add retry/backoff for 429 and transient 5xx.
  • GraphQL (Blocksync): partial errors may appear in a top-level errors array while data is non-null — always check both. Unauthenticated introspection may be disabled on some deployments.
  • DID resolution: if resolution fails, confirm the DID is registered on the expected network and that you query the correct registry or indexer endpoint.

Next steps

IXO MultiClient SDK

Module-level features on protocol.

SDK and kit overview

Canonical SDK overview and route selection.

Implementation examples

Worked end-to-end flows.

Agentic Oracles ADK

Build the off-chain side of evaluation.