@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
- Install dependencies:
@ixo/impactxclient-sdk. For Agentic Oracle integration, see Agentic Oracles ADK. - Choose RPC endpoint and chain ID from Networks and endpoints.
- 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 usecreateQueryClient. Writes need a signer-backed createSigningClient. Both target the same RPC endpoint.
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)
ComposeMsgCreateEntity, sign and broadcast.
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
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 byMsgEvaluateClaim. 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.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 withMsgMintToken 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
429and transient5xx. - GraphQL (Blocksync): partial errors may appear in a top-level
errorsarray whiledatais 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.