@ixo/impactxclient-sdk

README

IXO Impacts Client SDK

@ixo/impactxclient-sdk

The ultimate utility client for the IXO Blockchain

The IXO Impacts Client SDK @ixo/impactxclient-sdk is a type-safe TypeScript SDK for Javascript developers. It is compatible with most Javascript frameworks, including React, React Native, Vue.js, and Node.js. The Impacts Client SDK is designed to interact with the IXO blockchain and other Cosmos appchains. It provides a comprehensive set of tools to query a Cosmos blockchain, form messages, and sign transactions. The SDK also supports interchain communication and smart contract interactions. The Impacts Client SDK provides support for both ESM (ECMAScript Modules) and CJS (CommonJS).

Table of Contents

• The ultimate utility client for the IXO Blockchain
  • Table of Contents
  • Key Features
  • API
  • Getting Started
    • Prerequisites
    • Installation
  • Import Strategies & Bundle Size
  • Usage
    • Utility Functions
    • RPC Client
    • Query Client
      • Custom Queries
    • Signing Client
      • Composing Messages
        • Composing IBC Messages
      • Signing Messages
        • Initializing the Stargate Client
        • Creating Signers
      • Broadcasting Messages
    • Cloudflare Workers
    • Blockchain Modules
      • IXO Modules
        • IIDs
        • Entities
        • Tokens
        • Claims
        • Bonds
      • Cosmos Modules
    • Smart Contracts
      • CosmWasm
      • Swap Contract
      • DAODAO Contracts
    • Notes
      • React Native
        • BigInt React Native
      • Bundle size & tree-shaking
      • Attributions
  • How to contribute to the Impacts Client SDK
    • Set up your local environment
    • Codegen
    • Publishing
  • License

Key Features

• Easy-to-use API for querying and transacting with the IXO blockchain
• Wallet integration for secure transactions
• Custom queries to simplify complex queries
• Support for smart contracts
• Integrates interchain communications
• Supports multiple Cosmos chains
• Dual ESM + CommonJS build with "sideEffects": false for tree-shakeable, small frontend/Worker bundles
• First-class Cloudflare Workers support (atomic sequence management via a Durable Object)

API

• Import Strategies & Bundle Size
• Query Client
• Signing Client
• Cloudflare Workers
• Blockchain Modules
• Smart Contracts
• Inter-Blockchain Communication
• Utility Functions

Getting Started

Prerequisites

• Node.js v22 or higher — the crypto stack (@cosmjs 0.39 → @noble/@scure) uses APIs that only ship in Node 22+.
• TypeScript 5.7 or higher if you consume the types (CosmJS binary types now carry Uint8Array<ArrayBuffer> generics).
• moduleResolution set to bundler, node16, or nodenext in your tsconfig.json (the SDK ships an exports map; the legacy node/node10 resolver cannot read it).
• A package manager — npm, yarn, or pnpm.

Installation

npm install @ixo/impactxclient-sdk
# or
yarn add @ixo/impactxclient-sdk
# or
pnpm add @ixo/impactxclient-sdk

The package ships three artifacts, selected automatically by your toolchain via the exports map:

Format	Path	Used by
ESM	module/	bundlers (Vite, webpack, esbuild, Rollup), modern import in Node
CJS	main/	require(), Jest, older Node tooling
Types	types/	TypeScript

"sideEffects": false is declared, so bundlers tree-shake unused modules. See Import Strategies & Bundle Size for how to keep bundles small.

Import Strategies & Bundle Size

This SDK wraps the full IXO + Cosmos + IBC + CosmWasm proto surface, so how you import matters a lot for frontend and Cloudflare Worker bundle sizes. There are three tiers, from smallest to largest.

All sizes below are esbuild, minified / gzipped, measured against a real bundle. Reproduce them yourself with the harness in treeshake-test/.

1. Granular subpaths — smallest, recommended for frontends & Workers

Import a single generated module directly. The bundler pulls in only that message/query and its proto dependencies — nothing else.

// one message type — ~45 KB / 14 KB gzip, fully typed
import { MsgCreateIidDocument } from "@ixo/impactxclient-sdk/codegen/ixo/iid/v1beta1/tx";

const msg = MsgCreateIidDocument.fromPartial({ id: did, signer: address });

// a slim, hand-composed query client — ~461 KB / 128 KB gzip
// createRpc is stargate-free; add only the query modules you actually use
import { createRpc } from "@ixo/impactxclient-sdk/queries";
import { QueryClientImpl as IidQuery } from "@ixo/impactxclient-sdk/codegen/ixo/iid/v1beta1/query.rpc.Query";
import { QueryClientImpl as BankQuery } from "@ixo/impactxclient-sdk/codegen/cosmos/bank/v1beta1/query.rpc.Query";

const rpc = await createRpc(RPC_ENDPOINT);
const iid = new IidQuery(rpc);
const bank = new BankQuery(rpc);

const doc = await iid.iidDocument({ id: did });
const balance = await bank.balance({ address, denom: "uixo" });

Available subpaths (all typed): @ixo/impactxclient-sdk/codegen/**, /utils, /queries, /messages, /custom_queries, /stargate_client, /cloudflare.

2. Namespace imports — convenient, medium/large

The documented ixo. / cosmos. / cosmwasm. / ibc. namespaces are runtime objects that aggregate an entire proto tree, so touching one pulls in that whole tree. Fine for Node backends; heavy for browsers.

// convenient, but ~2,667 KB / 402 KB gzip because `ixo` aggregates all ixo modules
import { ixo } from "@ixo/impactxclient-sdk";
const msg = ixo.iid.v1beta1.MsgCreateIidDocument.fromPartial({ id: did });

Prefer strategy 1 in hot frontend/Worker paths; use namespaces freely in scripts and backends where bundle size is irrelevant.

3. Full clients — largest, unavoidable when you need everything

import { createSigningClient } from "@ixo/impactxclient-sdk"; // ~1,836 KB / 303 KB gzip
import { createQueryClient } from "@ixo/impactxclient-sdk";   // ~1,223 KB / 221 KB gzip

createSigningClient carries a registry of every chain message type (that is the point of it) plus cosmjs-types, so it is inherently large. createQueryClient instantiates every module's query client. Both are the right choice for a Node backend or a dApp that touches many modules; for a Worker or a focused frontend, prefer the slim composition in strategy 1.

Size cheat-sheet

What you import	min / gzip	Best for
One msg via /codegen/**	45 KB / 14 KB	frontends, Workers
Slim query client (createRpc + subpaths)	461 KB / 128 KB	query-only Workers/frontends
createQueryClient (all modules)	1,223 KB / 221 KB	backends, multi-module dApps
createSigningClient	1,836 KB / 303 KB	signing dApps/backends
ixo namespace only	2,667 KB / 402 KB	scripts, backends
/cloudflare (SequenceManagerDO)	2.8 KB / 1.2 KB	Cloudflare Workers

Recommendations by environment

• Cloudflare Workers / edge: import from granular subpaths only; use createRpc + the specific QueryClientImpls you need. Re-export the Durable Object from @ixo/impactxclient-sdk/cloudflare (see Cloudflare Workers). Enable nodejs_compat in wrangler.jsonc.
• Frontend (React/Vue/Vite): granular subpaths for message/query types on hot paths; a single createSigningClient behind a lazy import() if you need signing, so it is not in your initial chunk.
• Node backend / scripts: import whatever is convenient — namespaces and full clients are fine.

Usage

The Query Client and Signing Client provide simple interfaces to abstract away the complexity of querying data on the IXO blockchain and signing messages for broadcasting to the IXO blockchain. These clients also work for other Cosmos appchains.

Utility Functions

• ./utils

Import the utils object from @ixo/impactxclient-sdk to destructure utlity functions to help with using this SDK.

import { utils } from "@ixo/impactxclient-sdk";

const conversionUtils = utils.conversions;
const didUtils = utils.did;
const mnemonicUtils = utils.mnemonic;
const addressUtils = utils.address;

RPC Client

First connect to an RPC Client in order to interact with a blockchain; in this case the IXO blockchain.

The Cosmos Chain Resolver SDK, created by IXO, provides a simple way to retrieve RPC endpoints for any Cosmos chain.

We added a custom Query Client that includes the Cosmos modules and IXO modules, as well as Custom Queries.

Remember to set the RPC_ENDPOINT environment variable.

• Published RPC_ENDPOINT providers can be found at the Cosmos Chain Registry Github repository for Mainnet.
• Testnet providers are found here.
• Providers for Devnet are found here.

Example that describes how to set up your queryClient with an RPC endpoint.

import { ixo, createQueryClient } from "@ixo/impactxclient-sdk";

const queryClient = await createQueryClient(RPC_ENDPOINT);

Query Client

IXO created a custom QueryClient to facilitate queries to the cosmos and ixo modules, as well as to provide Custom Queries.

First connect to an RPC client.

Example code snippet assuming that the queryClient has been initialised with an RPC endpoint.

import { ixo, createQueryClient } from "@ixo/impactxclient-sdk";

const queryClient = await createQueryClient(RPC_ENDPOINT);

// Example of querying the Cosmos Bank module for the balances of an account on the IXO blockchain
const balance = await queryClient.cosmos.bank.v1beta1.allBalances({
  address: "ixo1addresshere",
});
// Example of querying the IXO Entity module for all entities on the IXO blockchain
const entities = await queryClient.ixo.entity.v1beta1.entityList();

Bundle-size tip: createQueryClient instantiates the query client for every module (~221 KB gzip). If you only query a few modules — especially in a Cloudflare Worker or frontend — compose a slim client with createRpc instead. See Import Strategies & Bundle Size.

import { createRpc } from "@ixo/impactxclient-sdk/queries";
import { QueryClientImpl } from "@ixo/impactxclient-sdk/codegen/ixo/entity/v1beta1/query.rpc.Query";

const rpc = await createRpc(RPC_ENDPOINT);
const entity = new QueryClientImpl(rpc);
const entities = await entity.entityList();

Custom Queries

Import the customQueries object from @ixo/impactxclient-sdk. Use the object to destructure currency functions that will allow you to get the token info based on the provided denom or the contract functions that will provide ixo or daodao contract codes for instantiation.

Example of custom queries.

import { customQueries } from "@ixo/impactxclient-sdk";

// get token info based on denom (coinMinimalDenom)
const token = customQueries.currency.findTokenFromDenom("uixo");

// get ibc token info based on ibc hash (and instantiated query client)
const ibcToken = await customQueries.currency.findIbcTokenFromHash(
  queryClient,
  "ibc/u05AC4BBA78C5951339A47DD1BC1E7FC922A9311DF81C85745B1C162F516FF2F1"
);
// `findIbcTokensFromHashes` requires an array of hashes to fetch multiple ibc token infos

// get coincodex info for a coin
const coinCodexInfo = customQueries.currency.findTokenInfoFromDenom("ixo");
// `findTokensInfoFromDenoms` requires an array of denoms to fetch multiple coinCodex infos

// get daodao contract codes (for devnet) to instatiate
const contractCodes = customQueries.contract.getContractCodes(
  "devnet",
  "daodao"
); // contractCodes = [{ name: "dao_core", code: 3 }, ...];
const { code } = contractCodes.find((contract) => contract.name === "dao_core");

// get specific contract code (for testnet) to instantiate
const daoCoreContractCode = customQueries.contract.getContractCode(
  "testnet",
  "dao_core"
);

Signing Client

A message to the IXO blockchain requires three steps:

• Compose Message
• Sign Message
• Broadcast Message

See Note

IXO has developed an improved signing client named SignX that interacts seamlessly with the Impacts X mobile app. Read more about how to utilise the SignX client instead of using this SigningClient.

Composing Messages

The following example describes one type of message. Reference the __tests__ directory of this repository for further examples of most messages and how to format them.

import { ixo } from "@ixo/impactxclient-sdk";

const message = {
  typeUrl: "/ixo.iid.v1beta1.MsgCreateIidDocument",
  value: ixo.iid.v1beta1.MsgCreateIidDocument.fromPartial({
    id: did,
    verifications: [
      ixo.iid.v1beta1.Verification.fromPartial({
        relationships: ["authentication"],
        method: ixo.iid.v1beta1.VerificationMethod.fromPartial({
          id: did,
          type: "EcdsaSecp256k1VerificationKey2019",
          publicKeyMultibase: "F" + toHex(pubkey),
          controller: controller,
        }),
      }),
    ],
    signer: address,
    controllers: [did],
  }),
};

Composing IBC Messages

Reference Composing Messages for information about composing messages in general.

• ./codegen/ibc/bundle

import { ibc } from "@ixo/impactxclient-sdk";

Signing Messages

Here are the docs on creating signers in cosmos-kit that can be used with Keplr and other wallets.

Initializing the Stargate Client

IXO ships a custom Stargate signing client, created via createSigningClient. It comes pre-loaded with the full IXO + Cosmos + IBC + CosmWasm registry, so you do not need to register proto types manually.

Note

Signing defaults to SIGN_MODE_DIRECT (proto). If the wallet you pass is an amino signer (e.g. Ledger via Secp256k1HdWallet), the client automatically falls back to SIGN_MODE_LEGACY_AMINO_JSON — provide aminoTypes in the options for any custom messages that need amino JSON.

import { createSigningClient } from "@ixo/impactxclient-sdk";

// createSigningClient(rpcEndpoint, offlineWallet, ignoreGetSequence?, options?, localStoreFunctions?)
const signingClient = await createSigningClient(RPC_ENDPOINT, offlineWallet);

With gas price and a local sequence store (recommended for apps sending back-to-back transactions):

import { createSigningClient } from "@ixo/impactxclient-sdk";
import { GasPrice } from "@cosmjs/stargate";
import store from "store"; // or any get/set-backed storage

const signingClient = await createSigningClient(
  RPC_ENDPOINT,
  offlineWallet,
  false,
  { gasPrice: GasPrice.fromString("0.025uixo") },
  {
    getLocalData: (k) => store.get(k),
    setLocalData: (k, d) => store.set(k, d),
  }
);

Creating Signers

createSigningClient accepts any CosmJS OfflineSigner. Common ways to get one:

• Browser wallets — cosmos-kit (recommended), or Keplr directly.
• From a mnemonic — CosmJS DirectSecp256k1HdWallet (a direct dependency of this SDK, no extra install).

WARNING

Never hard-code a mnemonic / seed phrase in plain text. The example below is illustration only and holds no balances. Use secure storage / encryption in production.

import { DirectSecp256k1HdWallet } from "@cosmjs/proto-signing";

const mnemonic =
  "unfold client turtles either pilots stocks floors glow toward bullets cars science";
const offlineWallet = await DirectSecp256k1HdWallet.fromMnemonic(mnemonic, {
  prefix: "ixo",
});

For ed25519 keys and DID helpers, the SDK's own signer utilities under @ixo/impactxclient-sdk/utils (utils.mnemonic, utils.did) generate IXO-native addresses and DIDs. See Utility Functions.

Broadcasting Messages

Now that you have your stargateClient, you can broadcast messages that were composed as described in Composing Messages. This example demonstrates broadcasting the /cosmos.bank.v1beta1.MsgSend message.

const msg = send({
  amount: [
    {
      denom: "coin",
      amount: "1000",
    },
  ],
  toAddress: address,
  fromAddress: address,
});

const fee: StdFee = {
  amount: [
    {
      denom: "coin",
      amount: "864",
    },
  ],
  gas: "86364",
};
const response = await stargateClient.signAndBroadcast(address, [msg], fee);

Cloudflare Workers

The SDK runs on Cloudflare Workers. Enable nodejs_compat in wrangler.jsonc and import from granular subpaths to keep the Worker small (see Import Strategies & Bundle Size).

When multiple Workers sign transactions from the same account concurrently they race for the account sequence number. The SDK ships a Durable Object, SequenceManagerDO, that hands out sequence numbers atomically. Import it from the dedicated /cloudflare subpath (which avoids loading crypto at module-load time).

• Re-export the Durable Object from your Worker:

// Use the /cloudflare subpath — tiny (~1.2 KB gzip) and crypto-free at load time
export { SequenceManagerDO } from "@ixo/impactxclient-sdk/cloudflare";

• Bind it in wrangler.jsonc:

{
  "durable_objects": {
    "bindings": [{ "name": "SEQUENCE_MANAGER", "class_name": "SequenceManagerDO" }]
  },
  "migrations": [{ "tag": "v1", "new_classes": ["SequenceManagerDO"] }]
}

• Wire it into the signing client via createDOStoreFunctions:

import { createSigningClient, createDOStoreFunctions } from "@ixo/impactxclient-sdk";

const doStub = env.SEQUENCE_MANAGER.get(env.SEQUENCE_MANAGER.idFromName("global"));
const storageFunctions = createDOStoreFunctions(doStub);

const client = await createSigningClient(rpc, wallet, false, options, storageFunctions);
await client.signAndBroadcast(address, msgs, "auto", memo);

Tune the inter-transaction stagger with the IXO_CLIENT_SEQUENCE_MIN_DELAY_MS Worker var (default 400).

Blockchain Modules

IXO Modules

Available at the IXO Blockchain repository.

See potential use cases that may be applicable to your application.

• ./codegen/ixo/bundle.d.ts

IIDs

The IID (Interchain Identifier) Module establishes a decentralized identity mechanism, ensuring a standardized approach for all entities within the system. By harnessing the power of DIDs (Decentralized Identifiers) and IIDs, this module facilitates a robust, secure, and universally recognizable identity framework, paving the way for a seamless integration across various platforms and networks.

• ./codegen/ixo/iid/v1beta1/query
• ./codegen/ixo/iid/v1beta1/tx

Entities

The Entity Module introduces a holistic approach to NFT-backed identities, bridging the gap between decentralized identifiers and tangible assets. Upon entity creation, a symbiotic relationship forms between an IID Document, an NFT, and the Entity's metadata. Further enriched with the concept of Entity Accounts, this module ensures a seamless transition of ownership, while offering a robust framework for entities to operate within a decentralized landscape.

• ./codegen/ixo/entity/v1beta1/query
• ./codegen/ixo/entity/v1beta1/tx

Tokens

Embracing the versatility of the EIP-1155 standard, the Token Module offers a sophisticated mechanism for managing multi-token smart contracts. Whether you're dealing with fungible or non-fungible tokens, this module streamlines the process of creation, minting, and management. From defining token collections to ensuring transparent on-chain token attributes, the Token Module stands as a beacon of efficiency and flexibility in the decentralized token ecosystem.

• ./codegen/ixo/token/v1beta1/query
• ./codegen/ixo/token/v1beta1/tx

Claims

The Claims Module provides an advanced structure for handling Verifiable Claims (VCs), cryptographic attestations regarding a subject. By aligning with the W3C standard and incorporating unique IXO system identifiers, this module offers a comprehensive solution for creating, evaluating, and managing claims. It enables entities to define protocols, authorize agents, and maintain a verifiable registry, ensuring authenticity and transparency in all claim-related processes.

• ./codegen/ixo/claims/v1beta1/query
• ./codegen/ixo/claims/v1beta1/tx

Bonds

The Bonds Module provides universal token bonding curve functions to mint, burn or swap any token in a Cosmos blockchain.

• ./codegen/ixo/bonds/v1beta1/query
• ./codegen/ixo/bonds/v1beta1/tx

⚠️ Disabled on IXO mainnet (v8): as of the v8 upgrade the bonds module is intentionally disabled on-chain (emergency security measure). Bonds queries still work, but any state-changing bonds message (MsgCreateBond, MsgBuy, MsgSell, …) is rejected by the chain with the bonds module is disabled (this surfaces as a thrown BroadcastTxError, not a failed-tx response). The proto types remain in the SDK for decoding historical data and for chains where the module is enabled.

Cosmos Modules

Available at the Cosmos SDK repository. View the examples provided by the Cosmos SDK team.

• ./codegen/contracts
• ./codegen/cosmos/bundle
• ./codegen/cosmwasm/bundle
• ./codegen/ibc/bundle
• ./codegen/ica/bundle
• ./codegen/ics23/bundle
• ./codegen/tendermint/bundle

Smart Contracts

In order to instantiate and execute smart contracts on the IXO blockchain, messages on the wasm module have to be invoked. The wasm message contains the smart contract details and the message to execute.

CosmWasm

Available at the CosmWasm module repository.

• ./codegen/cosmwasm/bundle

There are a few steps to follow when working with a CosmWasm smart contract.

Instantiation is only required when the contract is not available on the chain instance that you are working with.

• See note above. Only instantiate an instance of the contract, if needed.
• Retrieve the contract code for your target smart contract.
  • Contract code is provided by the contract namespace in custom queries.
  • ./custom_queries/contract
• Create the message to Execute on the contract.
• Execute the message on the contract by signing it.

Here is an example code snippet that shows how to instantiate and execute messages on a contract using the ixo1155 contract code:

import { createSigningClient, customQueries, cosmwasm, cosmos } from '@ixo/impactxclient-sdk';

/*
// Create a signing client in order to sign messages.
// Retrieve the Account Address for the connected user account.
*/
const client = await createSigningClient(rpc, offlineSigner);
const account = {};
const myAddress = account.address;

/*
// NB: Instantiation is only required when the contract is not available on the chain instance that you are working with.
// 1. Create the instantiation message for the contract.
// - Retrieve the Code for this contract (using ixo1155 for this example).
// - Remember to provide 1 uixo as message funding.
// 2. Sign the message and broadcast it to the IXO blockchain.
// - The most important part of this response is the Contract Address.
// - It is required for all further interactions with the contract.
*/
const contractCodes = customQueries.contract.getContractCodes('devnet', 'ixo');
const contractCode = contractCodes.find((contract) => contract.name === 'ixo1155');
const instantiateContractMessage = {
  typeUrl: '/cosmwasm.wasm.v1.MsgInstantiateContract',
  value: cosmwasm.wasm.v1.MsgInstantiateContract.fromPartial({
    admin: myAddress,
    codeId: contractCode.code,
    funds: [
      cosmos.base.v1beta1.Coin.fromPartial({
        amount: '1',
        denom: 'uixo',
      }),
    ],
    label: account.did + 'contract' + contractCode.code,
		msg: new Uint8Array(Buffer.from(JSON.stringify({
      minter: myAddress
    }))),
    sender: myAddress,
  }),
};

const instantiateContractResponse = await client.signAndBroadcast(
  myAddress,
  [instantiateContractMessage],
  "auto"
);
const contractAddress = JSON.parse(instantiateContractResponse.rawLog!)[0]
  .events
  .instantiate
  .attributes
  ._contract_address
  .value;

/*
// Execute messages on the contract with these steps:
// 1. All contract messages need to be wrapped in the /cosmwasm.wasm.v1.MsgExecuteContract blockchain message.
// - Remember to provide 1 uixo as message funding.
// 2. Create the message that you want to execute on the contract and include it in the msg field.
// - This example executes the batch_mint message.
// 3. Sign the message and broadcast it to the IXO blockchain.
// - A successful message execution means that the transaction was completed.
*/

// tokenId is an example in this case to support the batch_mint contract message.
const tokenId = 'CARBON:bafybeib22s3lyz3guicawoboeieltpyewkdnuuheklpeu3zbrwekmpdew5';
const executeContractMessage = {
  typeUrl: '/cosmwasm.wasm.v1.MsgExecuteContract',
  value: cosmwasm.wasm.v1.MsgExecuteContract.fromPartial({
    contract: contractAddress,
    funds: [
      cosmos.base.v1beta1.Coin.fromPartial({
        amount: '1',
        denom: 'uixo',
      }),
    ],
		msg: new Uint8Array(Buffer.from(JSON.stringify({
      batch_mint: {
        to: myAddress,
        batch: [[tokenId, '5000', 'uri']],
      },
    }))),
    sender: myAddress,
  }),
};
const executeContractResponse = await client.signAndBroadcast(
  myAddress,
  [executeContractMessage],
  "auto"
);

Swap Contract

IXO developed a smart contract named ixoSwap to enable swapping of tokens on the IXO network. Read more about the contract in the Swimm documentation. The contract has been audited by an independent party.

Examples of how to use the ixoSwap contract are available here:

• View implementation examples in the __tests__ directory of this repository.
• Another working example is available at the Jambo repository in this branch.

DAODAO Contracts

The basic DAO contracts are forked from the DAO-DAO Github organisation's dao-contracts repository.

IXO has implemented the contracts in an innovative manner and this implementation is generally available as DAO Tooling in the Impacts Portal.

Examples of how to use DAODAO Contracts can be found here.

See potential use cases that may be applicable to your application.

Notes

React Native

Install the below Library and import into your main app entry file. This ensures the required Polyfils are covered on mobile.

yarn add @walletconnect/react-native-compat

BigInt React Native

To ensure no issues with the React Native bigInt implementation, be sure to wrap your decimal gas amounts and others in a JS Double.

Bundle size & tree-shaking

The treeshake-test/ folder is a self-contained harness that measures how the SDK bundles under esbuild and Rollup, verifies it loads under both Node ESM and CJS, and checks that every import style resolves types. Run it after any dependency or packaging change:

cd treeshake-test && npm install
npm run build        # bundle sizes per import strategy
npm run check:node   # Node ESM + CJS loadability
npm run check:types  # every import style resolves types

See Import Strategies & Bundle Size for the resulting numbers and recommendations.

Attributions

Types were generated from the *.proto files of the IXO appchain using the @osmonauts/telescope@0.92.2 package.

See @ixo/impactxclient-sdk/types/index.d.ts for the complete list of types.

The generated src/codegen/ output carries a few required manual patches (cosmjs package renames, a local createProtobufRpcClient, tree-shaking fixes). These are wiped by yarn codegen and must be re-applied — see CODEGEN_PATCHES.md.

How to contribute to the Impacts Client SDK

IXO welcomes contributions and comments of all kinds!

First off, thank you for applying your mind and time to improving this repo - it helps the Internet of Impacts to save our planet! Whether you are contributing in your own space-time or following a bounty; we are grateful!

• Fork the repo.
• Ensure that you sync the fork often.
• Clone your fork and create a branch.
• Implement your changes one at a time and commit regularly to your fork.
• Once your change is completed and passes all of the local tests, create a PR.
• Your change will be reviewed as soon as possible with helpful feedback for your further updates to the change.
• Finally, when everything is good to go and your PR approved, you can squash and merge your branch.

Set up your local environment

Clone the repository. After successfully cloning:

yarn
yarn build

Codegen

Contract schemas live in ./contracts, and protos in ./proto. Look inside of scripts/codegen.js and configure the settings for bundling your SDK and contracts into ixo-multiclient-sdk:

yarn codegen

⚠️ IMPORTANT: yarn codegen deletes and regenerates all of src/codegen/, which wipes several required manual patches (cosmjs package renames, the local protobufRpcClient, and other bundle-size/tree-shaking fixes). After every regeneration, re-apply the patches and run the verification checklist documented in CODEGEN_PATCHES.md before publishing.

Publishing

Build the types and then publish:

yarn build:ts
yarn publish

License

This SDK is licensed under the Apache 2 License. See the LICENSE file for more information.