@zuhaibnoor/zigchain-sdk 1.0.3 → 1.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (185) hide show
  1. package/README.md +1 -1
  2. package/dist/auth/ChainAuthApi.d.ts +0 -3
  3. package/dist/auth/ChainAuthApi.d.ts.map +1 -1
  4. package/dist/auth/ChainAuthApi.js +0 -26
  5. package/dist/auth/ChainAuthApi.js.map +1 -1
  6. package/dist/bank/ChainBankApi.d.ts +0 -9
  7. package/dist/bank/ChainBankApi.d.ts.map +1 -1
  8. package/dist/bank/ChainBankApi.js +0 -18
  9. package/dist/bank/ChainBankApi.js.map +1 -1
  10. package/dist/circuit/ChainCircuitApi.d.ts.map +1 -1
  11. package/dist/circuit/ChainCircuitApi.js.map +1 -1
  12. package/dist/client/http.d.ts +1 -0
  13. package/dist/client/http.d.ts.map +1 -1
  14. package/dist/client/http.js +10 -0
  15. package/dist/client/http.js.map +1 -1
  16. package/dist/dex/ChainDexApi.d.ts.map +1 -1
  17. package/dist/dex/ChainDexApi.js.map +1 -1
  18. package/dist/distribution/ChainDistributionApi.d.ts +47 -0
  19. package/dist/distribution/ChainDistributionApi.d.ts.map +1 -0
  20. package/dist/distribution/ChainDistributionApi.js +74 -0
  21. package/dist/distribution/ChainDistributionApi.js.map +1 -0
  22. package/dist/distribution/types.d.ts +71 -0
  23. package/dist/distribution/types.d.ts.map +1 -0
  24. package/dist/distribution/types.js +2 -0
  25. package/dist/distribution/types.js.map +1 -0
  26. package/dist/evidence/ChainEvidenceApi.d.ts +15 -0
  27. package/dist/evidence/ChainEvidenceApi.d.ts.map +1 -0
  28. package/dist/evidence/ChainEvidenceApi.js +22 -0
  29. package/dist/evidence/ChainEvidenceApi.js.map +1 -0
  30. package/dist/evidence/types.d.ts +15 -0
  31. package/dist/evidence/types.d.ts.map +1 -0
  32. package/dist/evidence/types.js +2 -0
  33. package/dist/evidence/types.js.map +1 -0
  34. package/dist/feegrant/ChainFeegrantApi.d.ts +22 -0
  35. package/dist/feegrant/ChainFeegrantApi.d.ts.map +1 -0
  36. package/dist/feegrant/ChainFeegrantApi.js +32 -0
  37. package/dist/feegrant/ChainFeegrantApi.js.map +1 -0
  38. package/dist/feegrant/types.d.ts +17 -0
  39. package/dist/feegrant/types.d.ts.map +1 -0
  40. package/dist/feegrant/types.js +2 -0
  41. package/dist/feegrant/types.js.map +1 -0
  42. package/dist/ibc/ChainIbcApi.d.ts +55 -0
  43. package/dist/ibc/ChainIbcApi.d.ts.map +1 -0
  44. package/dist/ibc/ChainIbcApi.js +82 -0
  45. package/dist/ibc/ChainIbcApi.js.map +1 -0
  46. package/dist/ibc/ibcChannel/ChainIbcChannelApi.d.ts +55 -0
  47. package/dist/ibc/ibcChannel/ChainIbcChannelApi.d.ts.map +1 -0
  48. package/dist/ibc/ibcChannel/ChainIbcChannelApi.js +82 -0
  49. package/dist/ibc/ibcChannel/ChainIbcChannelApi.js.map +1 -0
  50. package/dist/ibc/ibcChannel/types.d.ts +106 -0
  51. package/dist/ibc/ibcChannel/types.d.ts.map +1 -0
  52. package/dist/ibc/ibcChannel/types.js +2 -0
  53. package/dist/ibc/ibcChannel/types.js.map +1 -0
  54. package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.d.ts +14 -0
  55. package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.d.ts.map +1 -0
  56. package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.js +38 -0
  57. package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.js.map +1 -0
  58. package/dist/ibc/ibcChannelV2/types.d.ts +26 -0
  59. package/dist/ibc/ibcChannelV2/types.d.ts.map +1 -0
  60. package/dist/ibc/ibcChannelV2/types.js +3 -0
  61. package/dist/ibc/ibcChannelV2/types.js.map +1 -0
  62. package/dist/ibc/ibcClient/ChainIbcClientApi.d.ts +15 -0
  63. package/dist/ibc/ibcClient/ChainIbcClientApi.d.ts.map +1 -0
  64. package/dist/ibc/ibcClient/ChainIbcClientApi.js +39 -0
  65. package/dist/ibc/ibcClient/ChainIbcClientApi.js.map +1 -0
  66. package/dist/ibc/ibcClient/types.d.ts +53 -0
  67. package/dist/ibc/ibcClient/types.d.ts.map +1 -0
  68. package/dist/ibc/ibcClient/types.js +2 -0
  69. package/dist/ibc/ibcClient/types.js.map +1 -0
  70. package/dist/ibc/ibcConnection/ChainIbcConnectionApi.d.ts +11 -0
  71. package/dist/ibc/ibcConnection/ChainIbcConnectionApi.d.ts.map +1 -0
  72. package/dist/ibc/ibcConnection/ChainIbcConnectionApi.js +24 -0
  73. package/dist/ibc/ibcConnection/ChainIbcConnectionApi.js.map +1 -0
  74. package/dist/ibc/ibcConnection/types.d.ts +18 -0
  75. package/dist/ibc/ibcConnection/types.d.ts.map +1 -0
  76. package/dist/ibc/ibcConnection/types.js +2 -0
  77. package/dist/ibc/ibcConnection/types.js.map +1 -0
  78. package/dist/ibc/types.d.ts +106 -0
  79. package/dist/ibc/types.d.ts.map +1 -0
  80. package/dist/ibc/types.js +2 -0
  81. package/dist/ibc/types.js.map +1 -0
  82. package/dist/ibc-transfer/ChainIbcTransferApi.d.ts +12 -0
  83. package/dist/ibc-transfer/ChainIbcTransferApi.d.ts.map +1 -0
  84. package/dist/ibc-transfer/ChainIbcTransferApi.js +30 -0
  85. package/dist/ibc-transfer/ChainIbcTransferApi.js.map +1 -0
  86. package/dist/ibc-transfer/types.d.ts +26 -0
  87. package/dist/ibc-transfer/types.d.ts.map +1 -0
  88. package/dist/ibc-transfer/types.js +2 -0
  89. package/dist/ibc-transfer/types.js.map +1 -0
  90. package/dist/index.d.ts +26 -0
  91. package/dist/index.d.ts.map +1 -1
  92. package/dist/index.js +26 -0
  93. package/dist/index.js.map +1 -1
  94. package/dist/interchain-accounts/ChainInterChainAccApi.d.ts +9 -0
  95. package/dist/interchain-accounts/ChainInterChainAccApi.d.ts.map +1 -0
  96. package/dist/interchain-accounts/ChainInterChainAccApi.js +16 -0
  97. package/dist/interchain-accounts/ChainInterChainAccApi.js.map +1 -0
  98. package/dist/interchain-accounts/types.d.ts +12 -0
  99. package/dist/interchain-accounts/types.d.ts.map +1 -0
  100. package/dist/interchain-accounts/types.js +2 -0
  101. package/dist/interchain-accounts/types.js.map +1 -0
  102. package/dist/networks/endpoints.js +2 -2
  103. package/dist/networks/endpoints.js.map +1 -1
  104. package/dist/runtime/ChainRuntimeApi.d.ts +12 -0
  105. package/dist/runtime/ChainRuntimeApi.d.ts.map +1 -0
  106. package/dist/runtime/ChainRuntimeApi.js +16 -0
  107. package/dist/runtime/ChainRuntimeApi.js.map +1 -0
  108. package/dist/runtime/types.d.ts +4 -0
  109. package/dist/runtime/types.d.ts.map +1 -0
  110. package/dist/runtime/types.js +2 -0
  111. package/dist/runtime/types.js.map +1 -0
  112. package/dist/staking/ChainStakingApi.d.ts +1 -5
  113. package/dist/staking/ChainStakingApi.d.ts.map +1 -1
  114. package/dist/staking/ChainStakingApi.js +9 -7
  115. package/dist/staking/ChainStakingApi.js.map +1 -1
  116. package/dist/tokenwrapper/ChainTokenWrapperApi.d.ts +19 -0
  117. package/dist/tokenwrapper/ChainTokenWrapperApi.d.ts.map +1 -0
  118. package/dist/tokenwrapper/ChainTokenWrapperApi.js +26 -0
  119. package/dist/tokenwrapper/ChainTokenWrapperApi.js.map +1 -0
  120. package/dist/tokenwrapper/types.d.ts +15 -0
  121. package/dist/tokenwrapper/types.d.ts.map +1 -0
  122. package/dist/tokenwrapper/types.js +2 -0
  123. package/dist/tokenwrapper/types.js.map +1 -0
  124. package/dist/txs/ChainTxsApi.d.ts +12 -0
  125. package/dist/txs/ChainTxsApi.d.ts.map +1 -0
  126. package/dist/txs/ChainTxsApi.js +17 -0
  127. package/dist/txs/ChainTxsApi.js.map +1 -0
  128. package/dist/txs/types.d.ts +22 -0
  129. package/dist/txs/types.d.ts.map +1 -0
  130. package/dist/txs/types.js +5 -0
  131. package/dist/txs/types.js.map +1 -0
  132. package/dist/upgrade/ChainUpgradeApi.d.ts +22 -0
  133. package/dist/upgrade/ChainUpgradeApi.d.ts.map +1 -0
  134. package/dist/upgrade/ChainUpgradeApi.js +40 -0
  135. package/dist/upgrade/ChainUpgradeApi.js.map +1 -0
  136. package/dist/upgrade/types.d.ts +24 -0
  137. package/dist/upgrade/types.d.ts.map +1 -0
  138. package/dist/upgrade/types.js +5 -0
  139. package/dist/upgrade/types.js.map +1 -0
  140. package/dist/validator-set/ChainCometValidator.d.ts +8 -0
  141. package/dist/validator-set/ChainCometValidator.d.ts.map +1 -0
  142. package/dist/validator-set/ChainCometValidator.js +15 -0
  143. package/dist/validator-set/ChainCometValidator.js.map +1 -0
  144. package/dist/validator-set/ChainValidator.d.ts +8 -0
  145. package/dist/validator-set/ChainValidator.d.ts.map +1 -0
  146. package/dist/validator-set/ChainValidator.js +15 -0
  147. package/dist/validator-set/ChainValidator.js.map +1 -0
  148. package/dist/validator-set/types.d.ts +18 -0
  149. package/dist/validator-set/types.d.ts.map +1 -0
  150. package/dist/validator-set/types.js +2 -0
  151. package/dist/validator-set/types.js.map +1 -0
  152. package/dist/wasm/ChainWasmApi.d.ts +57 -0
  153. package/dist/wasm/ChainWasmApi.d.ts.map +1 -0
  154. package/dist/wasm/ChainWasmApi.js +78 -0
  155. package/dist/wasm/ChainWasmApi.js.map +1 -0
  156. package/dist/wasm/types.d.ts +77 -0
  157. package/dist/wasm/types.d.ts.map +1 -0
  158. package/dist/wasm/types.js +2 -0
  159. package/dist/wasm/types.js.map +1 -0
  160. package/docs/auth.md +438 -72
  161. package/docs/bank.md +782 -123
  162. package/docs/block-results.md +328 -21
  163. package/docs/block.md +325 -38
  164. package/docs/circuit.md +164 -35
  165. package/docs/dex.md +313 -63
  166. package/docs/distribution.md +772 -0
  167. package/docs/evidence.md +194 -0
  168. package/docs/factory.md +308 -62
  169. package/docs/feegrant.md +206 -0
  170. package/docs/gov.md +364 -0
  171. package/docs/ibc/ibcChannel.md +977 -0
  172. package/docs/ibc/ibcClient.md +771 -0
  173. package/docs/ibc/ibcConnection.md +214 -0
  174. package/docs/ibc-transfer.md +463 -0
  175. package/docs/interchain-accounts.md +223 -0
  176. package/docs/mint.md +270 -0
  177. package/docs/runtime.md +120 -0
  178. package/docs/slashing.md +287 -0
  179. package/docs/staking.md +756 -0
  180. package/docs/tokenwrapper.md +294 -0
  181. package/docs/txs.md +447 -0
  182. package/docs/upgrade.md +356 -0
  183. package/docs/validator-set.md +177 -0
  184. package/docs/wasm.md +916 -0
  185. package/package.json +1 -1
@@ -0,0 +1,977 @@
1
+ # IBC Channel Module
2
+
3
+ ## What is IBC?
4
+
5
+ **IBC (Inter-Blockchain Communication)** is a protocol that allows independent blockchains to securely exchange messages and tokens. ZigChain uses IBC to connect with other Cosmos ecosystem chains.
6
+
7
+ The IBC stack has four layers that build on each other:
8
+
9
+ ```
10
+ Packets → the messages/tokens being transferred
11
+ Channels → the lanes packets travel through
12
+ Connections → the secured links between two chains
13
+ Clients → light clients that verify the other chain's state
14
+ ```
15
+ ---
16
+
17
+ ## Important Terminology
18
+
19
+ ### Channel
20
+
21
+ A **channel** is a communication lane between a specific port on ZigChain and a specific port on a counterparty chain. All IBC token transfers go through channels. Each channel is built on top of a connection.
22
+
23
+ ```
24
+ channel-0 (ZigChain) ↔ channel-612 (counterparty)
25
+ ```
26
+
27
+ ---
28
+
29
+ ### Port
30
+
31
+ A **port** is an application-level identifier that specifies which module on a chain handles the packets. The standard token transfer port is `transfer`. NFT transfers use `wasm.<contract-address>` ports.
32
+
33
+ ```
34
+ port_id = 'transfer'
35
+ ```
36
+
37
+ ---
38
+
39
+ ### Channel State
40
+
41
+ | State | Meaning |
42
+ | ------------ | ---------------------------------------------------------- |
43
+ | `STATE_OPEN` | Channel is active and can send/receive packets |
44
+ | `STATE_INIT` | Channel is being opened — handshake in progress |
45
+ | `STATE_TRYOPEN` | Counterparty acknowledged the open, waiting for confirmation |
46
+ | `STATE_CLOSED` | Channel has been closed — no longer usable |
47
+
48
+ ---
49
+
50
+ ### Channel Ordering
51
+
52
+ | Ordering | Meaning |
53
+ | ------------------ | --------------------------------------------------------------- |
54
+ | `ORDER_UNORDERED` | Packets can be received in any order — used for token transfers |
55
+ | `ORDER_ORDERED` | Packets must be received in sequence — used for ordered apps |
56
+
57
+ All ZigChain IBC channels use `ORDER_UNORDERED`.
58
+
59
+ ---
60
+
61
+ ### Connection Hops
62
+
63
+ The list of connections a channel traverses. For a direct channel this is always one connection. Multi-hop channels (not yet standard) would have multiple hops.
64
+
65
+ ```
66
+ connection_hops = ['connection-0']
67
+ ```
68
+
69
+ ---
70
+
71
+ ### Packet Sequence Number
72
+
73
+ Every packet sent through a channel gets an incrementing integer sequence number. This prevents duplicates, ensures ordering where required, and allows tracking of specific packets.
74
+
75
+ ```
76
+ sequence = 70
77
+ ```
78
+
79
+ ---
80
+
81
+ ### Packet Commitment
82
+
83
+ A **cryptographic hash** stored on the sending chain when a packet is created. It proves the packet exists and was committed to chain state. Used by the receiving chain to verify the packet is legitimate.
84
+
85
+ ---
86
+
87
+ ### Packet Acknowledgement
88
+
89
+ A **confirmation** sent back from the receiving chain after processing a packet. It proves the packet was received and whether it succeeded or failed.
90
+
91
+ ---
92
+
93
+ ### Packet Receipt
94
+
95
+ A record stored on the receiving chain after a packet is processed. Proves the packet was received — used to prevent replay attacks.
96
+
97
+ ---
98
+
99
+ ### Proof Height
100
+
101
+ The block height at which the returned proof or data was generated.
102
+
103
+ ```json
104
+ { "revision_number": "2", "revision_height": "4647092" }
105
+ ```
106
+
107
+ `revision_number` is the chain's revision (incremented on resets). `revision_height` is the block number.
108
+
109
+ ---
110
+
111
+ ## Setup
112
+
113
+ ```ts
114
+ import {
115
+ ChainIbcChannelApi,
116
+ getNetworkEndpoints,
117
+ Network,
118
+ } from '@zuhaibnoor/zigchain-sdk'
119
+
120
+ const endpoints = getNetworkEndpoints(Network.Testnet)
121
+ const ibcChannelApi = new ChainIbcChannelApi(endpoints)
122
+
123
+ const portId = 'transfer'
124
+ const channelId = 'channel-0'
125
+ ```
126
+
127
+ ---
128
+
129
+ # 1️⃣ fetchChannels
130
+
131
+ ## Method
132
+
133
+ ```ts
134
+ async fetchChannels()
135
+ ```
136
+
137
+ ## CLI Equivalent
138
+
139
+ ```bash
140
+ zigchaind query ibc channel channels
141
+ ```
142
+ ## Description
143
+
144
+ Fetches **all IBC channels** registered on ZigChain across all ports and connections.
145
+
146
+ ## Parameters
147
+
148
+ None.
149
+
150
+ ## Usage Example
151
+
152
+ ```ts
153
+ const channels = await ibcChannelApi.fetchChannels()
154
+ console.dir(channels, { depth: null })
155
+ ```
156
+
157
+ ## Example Response
158
+
159
+ ```json
160
+ {
161
+ "channels": [
162
+ {
163
+ "state": "STATE_OPEN",
164
+ "ordering": "ORDER_UNORDERED",
165
+ "counterparty": {
166
+ "port_id": "transfer",
167
+ "channel_id": "channel-612"
168
+ },
169
+ "connection_hops": ["connection-0"],
170
+ "version": "ics20-1",
171
+ "port_id": "transfer",
172
+ "channel_id": "channel-0"
173
+ },
174
+ {
175
+ "state": "STATE_OPEN",
176
+ "ordering": "ORDER_UNORDERED",
177
+ "counterparty": {
178
+ "port_id": "wasm.inj1wvtzf6s4rdpttgvpvgwwfpepv8uw0gxvs5qwxp",
179
+ "channel_id": "channel-77060"
180
+ },
181
+ "connection_hops": ["connection-39"],
182
+ "version": "ics721-1",
183
+ "port_id": "wasm.zig12gmfscd27ercy99t9tlmntljnr87muhtpykygpjssf5m63xrma3qymqjp2",
184
+ "channel_id": "channel-25"
185
+ }
186
+ ],
187
+ "pagination": { "next_key": null, "total": "48" },
188
+ "height": { "revision_number": "2", "revision_height": "4647091" }
189
+ }
190
+ ```
191
+
192
+ ## Response Field Explanation
193
+
194
+ ### `channels[]`
195
+
196
+ | Field | Description |
197
+ | ---------------- | -------------------------------------------------------------------- |
198
+ | state | Current channel state (`STATE_OPEN`, `STATE_INIT`, etc.) |
199
+ | ordering | Packet ordering mode (`ORDER_UNORDERED` for all ZigChain channels) |
200
+ | counterparty.port_id | Port on the remote chain this channel connects to |
201
+ | counterparty.channel_id | Channel ID on the remote chain |
202
+ | connection_hops | Connection(s) this channel is built on |
203
+ | version | IBC application protocol (`ics20-1` for tokens, `ics721-1` for NFTs)|
204
+ | port_id | Port on ZigChain this channel is bound to |
205
+ | channel_id | ZigChain's channel identifier |
206
+
207
+ ### `height`
208
+
209
+ The block height at which this data was read.
210
+
211
+ ### Channel Types on ZigChain Testnet
212
+
213
+ | Version | Port Type | Use Case | Example |
214
+ | ---------- | ---------------- | -------------------- | ---------------------- |
215
+ | `ics20-1` | `transfer` | Fungible token IBC | `channel-0` to Axelar |
216
+ | `ics721-1` | `wasm.<address>` | NFT IBC transfers | `channel-25` to Injective |
217
+
218
+ ## When to Use
219
+
220
+ * Building IBC channel explorers or dashboards
221
+ * Discovering which chains ZigChain is connected to
222
+ * Finding the correct channel ID before initiating an IBC transfer
223
+ * Monitoring for new channel openings or closures
224
+
225
+ ---
226
+
227
+ # 2️⃣ fetchChannelClientState
228
+
229
+ ## Method
230
+
231
+ ```ts
232
+ async fetchChannelClientState(portId: string, channelId: string)
233
+ ```
234
+
235
+ ## CLI Equivalent
236
+
237
+ ```bash
238
+ zigchaind query ibc channel client-state <port-id> <channel-id>
239
+ ```
240
+
241
+ ## Description
242
+
243
+ Fetches the **IBC light client state** associated with a specific channel.
244
+
245
+ The light client is ZigChain's internal verifier for the counterparty chain. Its state includes the counterparty chain's ID, the latest tracked height, trust parameters, and proof specifications. This tells you what chain is on the other end of the channel and how ZigChain is currently tracking it.
246
+
247
+ ## Parameters
248
+
249
+ | Name | Type | Description |
250
+ | --------- | ------ | ----------------------------------------------------- |
251
+ | portId | string | Port the channel is bound to (e.g. `'transfer'`) |
252
+ | channelId | string | Channel identifier (e.g. `'channel-0'`) |
253
+
254
+ ## Usage Example
255
+
256
+ ```ts
257
+ const clientState = await ibcChannelApi.fetchChannelClientState('transfer', 'channel-0')
258
+ console.dir(clientState, { depth: null })
259
+ ```
260
+
261
+ ## Example Response
262
+
263
+ ```json
264
+ {
265
+ "identified_client_state": {
266
+ "client_id": "07-tendermint-0",
267
+ "client_state": {
268
+ "@type": "/ibc.lightclients.tendermint.v1.ClientState",
269
+ "chain_id": "axelar-testnet-lisbon-3",
270
+ "trust_level": { "numerator": "2", "denominator": "3" },
271
+ "trusting_period": "403200s",
272
+ "unbonding_period": "604800s",
273
+ "max_clock_drift": "40s",
274
+ "frozen_height": { "revision_number": "0", "revision_height": "0" },
275
+ "latest_height": { "revision_number": "3", "revision_height": "26422416" }
276
+ }
277
+ },
278
+ "proof": null,
279
+ "proof_height": { "revision_number": "2", "revision_height": "4647092" }
280
+ }
281
+ ```
282
+
283
+ ## Response Field Explanation
284
+
285
+ ### `identified_client_state`
286
+
287
+ | Field | Description |
288
+ | ---------------- | ------------------------------------------------------------------ |
289
+ | client_id | IBC light client ID tracking this counterparty (`07-tendermint-0`) |
290
+ | client_state.@type | Client implementation type — Tendermint for Cosmos chains |
291
+ | client_state.chain_id | The counterparty chain's chain ID |
292
+ | trust_level | Fraction of validators needed to trust an update (2/3 = standard) |
293
+ | trusting_period | How long a header can be trusted without an update (in seconds) |
294
+ | unbonding_period | Counterparty chain's unbonding period |
295
+ | max_clock_drift | Maximum allowed time difference between chains |
296
+ | frozen_height | If non-zero, the client is frozen due to misbehaviour |
297
+ | latest_height | Most recent counterparty block this client has verified |
298
+
299
+ > `channel-0` connects ZigChain to `axelar-testnet-lisbon-3` via client `07-tendermint-0`. The counterparty is at block height `26,422,416`.
300
+
301
+ > A `frozen_height` of `0` means the client is healthy and not frozen.
302
+
303
+ ## When to Use
304
+
305
+ * Identifying which chain is on the other end of a channel
306
+ * Verifying the light client is not frozen before attempting a transfer
307
+ * Debugging IBC transfer failures caused by expired or outdated clients
308
+ * Chain connectivity dashboards showing counterparty chain details
309
+
310
+ ---
311
+
312
+ # 3️⃣ fetchChannelsByConnection
313
+
314
+ ## Method
315
+
316
+ ```ts
317
+ async fetchChannelsByConnection(connectionId: string)
318
+ ```
319
+
320
+ ## CLI Equivalent
321
+
322
+ ```bash
323
+ zigchaind query ibc channel connections <connection-id>
324
+ ```
325
+
326
+ ## Description
327
+
328
+ Fetches **all channels built on a specific connection**.
329
+
330
+ A single IBC connection can host multiple channels for different applications. This lets you see all the communication lanes running over a particular secured link between two chains.
331
+
332
+ ## Parameters
333
+
334
+ | Name | Type | Description |
335
+ | ------------ | ------ | ----------------------------------------- |
336
+ | connectionId | string | Connection identifier (e.g. `'connection-0'`) |
337
+
338
+ ## Usage Example
339
+
340
+ ```ts
341
+ const byConnection = await ibcChannelApi.fetchChannelsByConnection('connection-0')
342
+ console.dir(byConnection, { depth: null })
343
+ ```
344
+
345
+ ## Example Response
346
+
347
+ ```json
348
+ {
349
+ "channels": [
350
+ {
351
+ "state": "STATE_OPEN",
352
+ "ordering": "ORDER_UNORDERED",
353
+ "counterparty": { "port_id": "transfer", "channel_id": "channel-612" },
354
+ "connection_hops": ["connection-0"],
355
+ "version": "ics20-1",
356
+ "port_id": "transfer",
357
+ "channel_id": "channel-0"
358
+ },
359
+ {
360
+ "state": "STATE_OPEN",
361
+ "ordering": "ORDER_UNORDERED",
362
+ "counterparty": { "port_id": "transfer", "channel_id": "channel-614" },
363
+ "connection_hops": ["connection-0"],
364
+ "version": "ics20-1",
365
+ "port_id": "transfer",
366
+ "channel_id": "channel-1"
367
+ }
368
+ ],
369
+ "pagination": { "next_key": null, "total": "2" },
370
+ "height": { "revision_number": "2", "revision_height": "4647092" }
371
+ }
372
+ ```
373
+
374
+ ## Response Field Explanation
375
+
376
+ Same channel object structure as `fetchChannels`. See that section for full field descriptions.
377
+
378
+ ---
379
+
380
+ # 4️⃣ fetchChannelEnd
381
+
382
+ ## Method
383
+
384
+ ```ts
385
+ async fetchChannelEnd(portId: string, channelId: string)
386
+ ```
387
+
388
+ ## CLI Equivalent
389
+
390
+ ```bash
391
+ zigchaind query ibc channel end <port-id> <channel-id>
392
+ ```
393
+
394
+ ## Description
395
+
396
+ Fetches the **channel end** — ZigChain's stored state for a specific channel.
397
+
398
+ A channel exists on both chains simultaneously; each chain stores its own "end." This function returns ZigChain's end, which includes the channel's state, ordering, counterparty identifiers, connection, and version. It is the single-channel equivalent of an entry in `fetchChannels`.
399
+
400
+ ## Parameters
401
+
402
+ | Name | Type | Description |
403
+ | --------- | ------ | ------------------------------------------------ |
404
+ | portId | string | Port the channel is bound to (e.g. `'transfer'`) |
405
+ | channelId | string | Channel identifier (e.g. `'channel-0'`) |
406
+
407
+ ## Usage Example
408
+
409
+ ```ts
410
+ const channelEnd = await ibcChannelApi.fetchChannelEnd('transfer', 'channel-0')
411
+ console.dir(channelEnd, { depth: null })
412
+ ```
413
+
414
+ ## Example Response
415
+
416
+ ```json
417
+ {
418
+ "channel": {
419
+ "state": "STATE_OPEN",
420
+ "ordering": "ORDER_UNORDERED",
421
+ "counterparty": { "port_id": "transfer", "channel_id": "channel-612" },
422
+ "connection_hops": ["connection-0"],
423
+ "version": "ics20-1"
424
+ },
425
+ "proof": null,
426
+ "proof_height": { "revision_number": "2", "revision_height": "4647092" }
427
+ }
428
+ ```
429
+
430
+ ## Response Field Explanation
431
+
432
+ ### `channel`
433
+
434
+ | Field | Description |
435
+ | --------------- | ------------------------------------------------------- |
436
+ | state | Current channel state |
437
+ | ordering | Packet ordering mode |
438
+ | counterparty | Port and channel ID on the remote chain |
439
+ | connection_hops | Connection(s) this channel uses |
440
+ | version | IBC application protocol version |
441
+
442
+ ### `fetchChannels` vs `fetchChannelEnd`
443
+
444
+ | Feature | fetchChannels | fetchChannelEnd |
445
+ | --------------------- | ----------------------- | ---------------------------- |
446
+ | Scope | All channels | Single channel |
447
+ | Includes channel ID | ✅ Yes | ❌ No (you provide it) |
448
+ | Includes proof_height | ❌ No | ✅ Yes |
449
+ | Use case | Full channel discovery | Single channel verification |
450
+
451
+ ## When to Use
452
+
453
+ * Verifying a specific channel is open before initiating a transfer
454
+ * Checking counterparty channel and port for a known channel
455
+
456
+ ---
457
+
458
+ # 5️⃣ fetchNextSequenceReceive
459
+
460
+ ## Method
461
+
462
+ ```ts
463
+ async fetchNextSequenceReceive(portId: string, channelId: string)
464
+ ```
465
+
466
+ ## CLI Equivalent
467
+
468
+ ```bash
469
+ zigchaind query ibc channel next-sequence-receive <port-id> <channel-id>
470
+ ```
471
+
472
+ ## Description
473
+
474
+ Fetches the **next packet sequence number ZigChain expects to receive** on a channel.
475
+
476
+ If this returns `15`, ZigChain has already processed packets 1–14 and is waiting for packet 15. A value of `0` on ZigChain testnet's `channel-0` reflects that this channel is primarily used for outbound transfers.
477
+
478
+ ## Parameters
479
+
480
+ | Name | Type | Description |
481
+ | --------- | ------ | ------------------------------------------------ |
482
+ | portId | string | Port the channel is bound to (e.g. `'transfer'`) |
483
+ | channelId | string | Channel identifier (e.g. `'channel-0'`) |
484
+
485
+ ## Usage Example
486
+
487
+ ```ts
488
+ const nextRecv = await ibcChannelApi.fetchNextSequenceReceive('transfer', 'channel-0')
489
+ console.dir(nextRecv, { depth: null })
490
+ ```
491
+
492
+ ## Example Response
493
+
494
+ ```json
495
+ {
496
+ "next_sequence_receive": "0",
497
+ "proof": null,
498
+ "proof_height": { "revision_number": "2", "revision_height": "4647093" }
499
+ }
500
+ ```
501
+
502
+ ## Response Field Explanation
503
+
504
+ | Field | Description |
505
+ | --------------------- | ---------------------------------------------------------------------- |
506
+ | next_sequence_receive | The next packet sequence this chain expects to receive on this channel |
507
+ | proof | Merkle proof (null for simple queries) |
508
+ | proof_height | Block height at which this data was read |
509
+
510
+ ## When to Use
511
+
512
+ * Monitoring incoming packet delivery progress
513
+ * Detecting stuck inbound packets
514
+ * Verifying a channel is actively receiving packets
515
+
516
+ ---
517
+
518
+ # 6️⃣ fetchNextSequenceSend
519
+
520
+ ## Method
521
+
522
+ ```ts
523
+ async fetchNextSequenceSend(portId: string, channelId: string)
524
+ ```
525
+
526
+ ## CLI Equivalent
527
+
528
+ ```bash
529
+ zigchaind query ibc channel next-sequence-send <port-id> <channel-id>
530
+ ```
531
+
532
+ ## Description
533
+
534
+ Fetches the **next packet sequence number that will be assigned** when a new packet is sent on this channel.
535
+
536
+ If this returns `74`, then 73 packets have already been sent and the next outbound transfer on this channel will be sequence `74`.
537
+
538
+ ## Parameters
539
+
540
+ | Name | Type | Description |
541
+ | --------- | ------ | ------------------------------------------------ |
542
+ | portId | string | Port the channel is bound to (e.g. `'transfer'`) |
543
+ | channelId | string | Channel identifier (e.g. `'channel-0'`) |
544
+
545
+ ## Usage Example
546
+
547
+ ```ts
548
+ const nextSend = await ibcChannelApi.fetchNextSequenceSend('transfer', 'channel-0')
549
+ console.dir(nextSend, { depth: null })
550
+ ```
551
+
552
+ ## Example Response
553
+
554
+ ```json
555
+ {
556
+ "next_sequence_send": "74",
557
+ "proof": null,
558
+ "proof_height": { "revision_number": "2", "revision_height": "4647093" }
559
+ }
560
+ ```
561
+
562
+ ## Response Field Explanation
563
+
564
+ | Field | Description |
565
+ | ----------------- | ----------------------------------------------------------------- |
566
+ | next_sequence_send | The sequence number the next outbound packet will be assigned |
567
+ | proof | Merkle proof (null for simple queries) |
568
+ | proof_height | Block height at which this data was read |
569
+
570
+ ## When to Use
571
+
572
+ * Tracking total outbound transfer volume on a channel
573
+ * Predicting the sequence number of the next transfer
574
+ * Auditing outbound packet counts
575
+
576
+ ---
577
+
578
+ # 7️⃣ fetchPacketAcknowledgement
579
+
580
+ ## Method
581
+
582
+ ```ts
583
+ async fetchPacketAcknowledgement(portId: string, channelId: string, sequence: number | string)
584
+ ```
585
+
586
+ ## CLI Equivalent
587
+
588
+ ```bash
589
+ zigchaind query ibc channel packet-ack <port-id> <channel-id> <sequence>
590
+ ```
591
+
592
+ ## Description
593
+
594
+ Fetches the **acknowledgement stored for a specific packet**.
595
+
596
+ When a packet is processed on the counterparty chain, it sends back an acknowledgement that ZigChain stores. This acknowledgement proves the packet was received and contains information about whether processing succeeded or failed.
597
+
598
+ ## Parameters
599
+
600
+ | Name | Type | Description |
601
+ | --------- | ----------------- | ------------------------------------------------ |
602
+ | portId | string | Port the channel is bound to |
603
+ | channelId | string | Channel identifier |
604
+ | sequence | number \| string | Packet sequence number to query |
605
+
606
+ ## Usage Example
607
+
608
+ ```ts
609
+ const ack = await ibcChannelApi.fetchPacketAcknowledgement('transfer', 'channel-0', 70)
610
+ console.dir(ack, { depth: null })
611
+ ```
612
+
613
+ ## Example Response
614
+
615
+ ```json
616
+ {
617
+ "acknowledgement": "CPdVftUYJv4Y2EUSvyTsdQAe268hI6R333KgqfNkCnw=",
618
+ "proof": null,
619
+ "proof_height": { "revision_number": "2", "revision_height": "4647093" }
620
+ }
621
+ ```
622
+
623
+ ## Response Field Explanation
624
+
625
+ | Field | Description |
626
+ | --------------- | ------------------------------------------------------------------------ |
627
+ | acknowledgement | Base64-encoded acknowledgement data returned by the counterparty chain |
628
+ | proof | Merkle proof (null for simple queries) |
629
+ | proof_height | Block height at which this data was read |
630
+
631
+ ## When to Use
632
+
633
+ * Verifying a specific packet was acknowledged by the counterparty
634
+ * Checking whether a transfer succeeded or failed on the remote chain
635
+ * Building packet status trackers for IBC explorers
636
+ ---
637
+
638
+ # 8️⃣ fetchPacketCommitment
639
+
640
+ ## Method
641
+
642
+ ```ts
643
+ async fetchPacketCommitment(portId: string, channelId: string, sequence: number | string)
644
+ ```
645
+
646
+ ## CLI Equivalent
647
+
648
+ ```bash
649
+ zigchaind query ibc channel packet-commitment <port-id> <channel-id> <sequence>
650
+ ```
651
+
652
+ ## Description
653
+
654
+ Fetches the **packet commitment** stored for a specific outbound packet.
655
+
656
+ When ZigChain sends a packet, it stores a cryptographic hash (commitment) of that packet. This commitment remains on-chain until the packet is acknowledged by the counterparty. If a commitment exists, it means the packet was sent but the acknowledgement has not yet been received back.
657
+
658
+ ---
659
+
660
+ ## Parameters
661
+
662
+ | Name | Type | Description |
663
+ | --------- | ----------------- | -------------------------------------------- |
664
+ | portId | string | Port the channel is bound to |
665
+ | channelId | string | Channel identifier |
666
+ | sequence | number \| string | Packet sequence number to query |
667
+
668
+ ## Usage Example
669
+
670
+ ```ts
671
+ const commitment = await ibcChannelApi.fetchPacketCommitment('transfer', 'channel-0', 55)
672
+ console.dir(commitment, { depth: null })
673
+ ```
674
+
675
+ ## Example Response
676
+
677
+ ```json
678
+ {
679
+ "commitment": "TGCM/XS6O6oh0TgzrQfICRxgJ0Fxb2AerhtOtSfaG3U=",
680
+ "proof": null,
681
+ "proof_height": { "revision_number": "2", "revision_height": "4647094" }
682
+ }
683
+ ```
684
+
685
+ ## Response Field Explanation
686
+
687
+ | Field | Description |
688
+ | ------------ | ------------------------------------------------------------------------ |
689
+ | commitment | Base64-encoded hash of the packet data — proves the packet was committed |
690
+ | proof | Merkle proof (null for simple queries) |
691
+ | proof_height | Block height at which this data was read |
692
+
693
+ ## When to Use
694
+
695
+ * Checking if a specific packet is still awaiting acknowledgement
696
+ * Debugging in-flight or stuck transfers
697
+
698
+ ---
699
+
700
+ # 9️⃣ fetchPacketCommitments
701
+
702
+ ## Method
703
+
704
+ ```ts
705
+ async fetchPacketCommitments(portId: string, channelId: string)
706
+ ```
707
+
708
+ ## CLI Equivalent
709
+
710
+ ```bash
711
+ zigchaind query ibc channel packet-commitments <port-id> <channel-id>
712
+ ```
713
+
714
+ ## Description
715
+
716
+ Fetches **all outstanding packet commitments** on a channel — every packet that has been sent but not yet acknowledged.
717
+
718
+ ## Parameters
719
+
720
+ | Name | Type | Description |
721
+ | --------- | ------ | ------------------------------------------------ |
722
+ | portId | string | Port the channel is bound to (e.g. `'transfer'`) |
723
+ | channelId | string | Channel identifier (e.g. `'channel-0'`) |
724
+
725
+ ## Usage Example
726
+
727
+ ```ts
728
+ const commitments = await ibcChannelApi.fetchPacketCommitments('transfer', 'channel-0')
729
+ console.dir(commitments, { depth: null })
730
+ ```
731
+
732
+ ## Example Response
733
+
734
+ ```json
735
+ {
736
+ "commitments": [
737
+ {
738
+ "port_id": "transfer",
739
+ "channel_id": "channel-0",
740
+ "sequence": "53",
741
+ "data": "o6Kf3yL0iV5BVzwm0O/j8sOHy+bvO0foTqBgBZx0Bt4="
742
+ },
743
+ {
744
+ "port_id": "transfer",
745
+ "channel_id": "channel-0",
746
+ "sequence": "54",
747
+ "data": "Hn9W269hLobcNGLWmTMDXI8ITsXlEUubBdR3pjYOyTI="
748
+ },
749
+ {
750
+ "port_id": "transfer",
751
+ "channel_id": "channel-0",
752
+ "sequence": "55",
753
+ "data": "TGCM/XS6O6oh0TgzrQfICRxgJ0Fxb2AerhtOtSfaG3U="
754
+ }
755
+ ],
756
+ "pagination": { "next_key": null, "total": "3" },
757
+ "height": { "revision_number": "2", "revision_height": "4647094" }
758
+ }
759
+ ```
760
+
761
+ ## Response Field Explanation
762
+
763
+ ### `commitments[]`
764
+
765
+ | Field | Description |
766
+ | ---------- | --------------------------------------------------------------- |
767
+ | port_id | Port this commitment belongs to |
768
+ | channel_id | Channel this commitment belongs to |
769
+ | sequence | Packet sequence number |
770
+ | data | Base64-encoded commitment hash of the packet |
771
+
772
+ ### `fetchPacketCommitment` vs `fetchPacketCommitments`
773
+
774
+ | Feature | fetchPacketCommitment | fetchPacketCommitments |
775
+ | ------------------- | ------------------------- | ------------------------------- |
776
+ | Scope | Single sequence | All outstanding commitments |
777
+ | Use case | Check one specific packet | Overview of all in-flight packets |
778
+
779
+ ---
780
+
781
+ # 🔟 fetchPacketReceipt
782
+
783
+ ## Method
784
+
785
+ ```ts
786
+ async fetchPacketReceipt(portId: string, channelId: string, sequence: number | string)
787
+ ```
788
+
789
+ ## CLI Equivalent
790
+
791
+ ```bash
792
+ zigchaind query ibc channel packet-receipt <port-id> <channel-id> <sequence>
793
+ ```
794
+
795
+ ## Description
796
+
797
+ Checks whether a **specific inbound packet has been received** by ZigChain.
798
+
799
+ A packet receipt is stored on the receiving chain after the packet is processed. This is the definitive proof that ZigChain received and executed a specific packet from the counterparty. Returns `received: true` if the packet was processed, `false` if not.
800
+
801
+ ## Parameters
802
+
803
+ | Name | Type | Description |
804
+ | --------- | ----------------- | -------------------------------------------- |
805
+ | portId | string | Port the channel is bound to |
806
+ | channelId | string | Channel identifier |
807
+ | sequence | number \| string | Packet sequence number to check |
808
+
809
+ ---
810
+
811
+ ## Usage Example
812
+
813
+ ```ts
814
+ const receipt = await ibcChannelApi.fetchPacketReceipt('transfer', 'channel-0', 70)
815
+ console.dir(receipt, { depth: null })
816
+ ```
817
+
818
+ ## Example Response
819
+
820
+ ```json
821
+ {
822
+ "received": true,
823
+ "proof": null,
824
+ "proof_height": { "revision_number": "2", "revision_height": "4647094" }
825
+ }
826
+ ```
827
+
828
+ ## Response Field Explanation
829
+
830
+ | Field | Description |
831
+ | ------------ | ------------------------------------------------------------------ |
832
+ | received | `true` if ZigChain has received and processed this packet |
833
+ | proof | Merkle proof (null for simple queries) |
834
+ | proof_height | Block height at which this data was read |
835
+
836
+ ## When to Use
837
+
838
+ * Verifying an inbound packet was successfully received
839
+ * Confirming an incoming IBC transfer reached ZigChain
840
+ ---
841
+
842
+ # 1️⃣1️⃣ fetchUnreceivedAcks
843
+
844
+ ## Method
845
+
846
+ ```ts
847
+ async fetchUnreceivedAcks(portId: string, channelId: string, sequences: (number | string)[])
848
+ ```
849
+
850
+ ## CLI Equivalent
851
+
852
+ ```bash
853
+ zigchaind query ibc channel unreceived-acks <port-id> <channel-id> <sequences>
854
+ ```
855
+
856
+ ## Description
857
+
858
+ Given a list of packet sequences, returns which ones have **acknowledgements that ZigChain has not yet received back**.
859
+
860
+ This identifies packets that were sent from ZigChain, processed on the counterparty, but whose acknowledgements haven't been relayed back to ZigChain yet. These are packets with commitments still stored on ZigChain waiting to be cleared.
861
+
862
+ ## Parameters
863
+
864
+ | Name | Type | Description |
865
+ | --------- | ----------------------- | -------------------------------------------------------- |
866
+ | portId | string | Port the channel is bound to |
867
+ | channelId | string | Channel identifier |
868
+ | sequences | (number \| string)[] | List of sequence numbers to check for missing acks |
869
+
870
+ ## Usage Example
871
+
872
+ ```ts
873
+ const unreceivedAcks = await ibcChannelApi.fetchUnreceivedAcks(
874
+ 'transfer',
875
+ 'channel-0',
876
+ [53, 54, 71]
877
+ )
878
+ console.dir(unreceivedAcks, { depth: null })
879
+ ```
880
+
881
+ ## Example Response
882
+
883
+ ```json
884
+ {
885
+ "sequences": ["53", "54"],
886
+ "height": { "revision_number": "2", "revision_height": "4647095" }
887
+ }
888
+ ```
889
+
890
+ ## Response Field Explanation
891
+
892
+ | Field | Description |
893
+ | --------- | ---------------------------------------------------------------------------------- |
894
+ | sequences | The subset of queried sequences whose acknowledgements have not yet been received |
895
+ | height | Block height at which this data was read |
896
+
897
+ ## When to Use
898
+
899
+ * Checking which packets need ack relaying
900
+ * Identifying the workload for an IBC relayer
901
+ * Monitoring channel health and ack latency
902
+ * Alerting when acks are pending for too long
903
+
904
+ ---
905
+
906
+ # 1️⃣2️⃣ fetchUnreceivedPackets
907
+
908
+ ## Method
909
+
910
+ ```ts
911
+ async fetchUnreceivedPackets(portId: string, channelId: string, sequences: (number | string)[])
912
+ ```
913
+
914
+ ## CLI Equivalent
915
+
916
+ ```bash
917
+ zigchaind query ibc channel unreceived-packets <port-id> <channel-id> <sequences>
918
+ ```
919
+
920
+ ## Description
921
+
922
+ Given a list of packet sequences, returns which ones have been **committed on the counterparty but not yet received by ZigChain**.
923
+
924
+ This is the inbound counterpart to `fetchUnreceivedAcks` — it identifies packets sent to ZigChain that haven't arrived yet. An empty result means all queried packets have already been received.
925
+
926
+
927
+ ## Parameters
928
+
929
+ | Name | Type | Description |
930
+ | --------- | ----------------------- | --------------------------------------------------------- |
931
+ | portId | string | Port the channel is bound to |
932
+ | channelId | string | Channel identifier |
933
+ | sequences | (number \| string)[] | List of sequence numbers to check for missing receipts |
934
+
935
+ ## Usage Example
936
+
937
+ ```ts
938
+ const unreceivedPackets = await ibcChannelApi.fetchUnreceivedPackets(
939
+ 'transfer',
940
+ 'channel-0',
941
+ [53, 54, 71]
942
+ )
943
+ console.dir(unreceivedPackets, { depth: null })
944
+ ```
945
+
946
+ ## Example Response
947
+
948
+ ```json
949
+ {
950
+ "sequences": [],
951
+ "height": { "revision_number": "2", "revision_height": "4647095" }
952
+ }
953
+ ```
954
+
955
+ ## Response Field Explanation
956
+
957
+ | Field | Description |
958
+ | --------- | -------------------------------------------------------------------------------- |
959
+ | sequences | The subset of queried sequences that have not yet been received by ZigChain |
960
+ | height | Block height at which this data was read |
961
+
962
+ > An empty `sequences` array means all queried packets (`53`, `54`, `71`) have already been received by ZigChain — no inbound delivery is pending.
963
+
964
+ ### `fetchUnreceivedAcks` vs `fetchUnreceivedPackets`
965
+
966
+ | Feature | fetchUnreceivedAcks | fetchUnreceivedPackets |
967
+ | --------- | ------------------------------------ | ------------------------------------ |
968
+ | Direction | Outbound (sent from ZigChain) | Inbound (sent to ZigChain) |
969
+ | Question | Which acks haven't come back yet? | Which packets haven't arrived yet? |
970
+ | Result | Sequences `[53, 54]` pending | Empty — all received |
971
+
972
+ ## When to Use
973
+
974
+ * Checking for packets in transit toward ZigChain
975
+ * Detecting dropped or stuck inbound IBC transfers
976
+
977
+ ---