@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.
- package/README.md +1 -1
- package/dist/auth/ChainAuthApi.d.ts +0 -3
- package/dist/auth/ChainAuthApi.d.ts.map +1 -1
- package/dist/auth/ChainAuthApi.js +0 -26
- package/dist/auth/ChainAuthApi.js.map +1 -1
- package/dist/bank/ChainBankApi.d.ts +0 -9
- package/dist/bank/ChainBankApi.d.ts.map +1 -1
- package/dist/bank/ChainBankApi.js +0 -18
- package/dist/bank/ChainBankApi.js.map +1 -1
- package/dist/circuit/ChainCircuitApi.d.ts.map +1 -1
- package/dist/circuit/ChainCircuitApi.js.map +1 -1
- package/dist/client/http.d.ts +1 -0
- package/dist/client/http.d.ts.map +1 -1
- package/dist/client/http.js +10 -0
- package/dist/client/http.js.map +1 -1
- package/dist/dex/ChainDexApi.d.ts.map +1 -1
- package/dist/dex/ChainDexApi.js.map +1 -1
- package/dist/distribution/ChainDistributionApi.d.ts +47 -0
- package/dist/distribution/ChainDistributionApi.d.ts.map +1 -0
- package/dist/distribution/ChainDistributionApi.js +74 -0
- package/dist/distribution/ChainDistributionApi.js.map +1 -0
- package/dist/distribution/types.d.ts +71 -0
- package/dist/distribution/types.d.ts.map +1 -0
- package/dist/distribution/types.js +2 -0
- package/dist/distribution/types.js.map +1 -0
- package/dist/evidence/ChainEvidenceApi.d.ts +15 -0
- package/dist/evidence/ChainEvidenceApi.d.ts.map +1 -0
- package/dist/evidence/ChainEvidenceApi.js +22 -0
- package/dist/evidence/ChainEvidenceApi.js.map +1 -0
- package/dist/evidence/types.d.ts +15 -0
- package/dist/evidence/types.d.ts.map +1 -0
- package/dist/evidence/types.js +2 -0
- package/dist/evidence/types.js.map +1 -0
- package/dist/feegrant/ChainFeegrantApi.d.ts +22 -0
- package/dist/feegrant/ChainFeegrantApi.d.ts.map +1 -0
- package/dist/feegrant/ChainFeegrantApi.js +32 -0
- package/dist/feegrant/ChainFeegrantApi.js.map +1 -0
- package/dist/feegrant/types.d.ts +17 -0
- package/dist/feegrant/types.d.ts.map +1 -0
- package/dist/feegrant/types.js +2 -0
- package/dist/feegrant/types.js.map +1 -0
- package/dist/ibc/ChainIbcApi.d.ts +55 -0
- package/dist/ibc/ChainIbcApi.d.ts.map +1 -0
- package/dist/ibc/ChainIbcApi.js +82 -0
- package/dist/ibc/ChainIbcApi.js.map +1 -0
- package/dist/ibc/ibcChannel/ChainIbcChannelApi.d.ts +55 -0
- package/dist/ibc/ibcChannel/ChainIbcChannelApi.d.ts.map +1 -0
- package/dist/ibc/ibcChannel/ChainIbcChannelApi.js +82 -0
- package/dist/ibc/ibcChannel/ChainIbcChannelApi.js.map +1 -0
- package/dist/ibc/ibcChannel/types.d.ts +106 -0
- package/dist/ibc/ibcChannel/types.d.ts.map +1 -0
- package/dist/ibc/ibcChannel/types.js +2 -0
- package/dist/ibc/ibcChannel/types.js.map +1 -0
- package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.d.ts +14 -0
- package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.d.ts.map +1 -0
- package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.js +38 -0
- package/dist/ibc/ibcChannelV2/ChainIbcChannelV2.js.map +1 -0
- package/dist/ibc/ibcChannelV2/types.d.ts +26 -0
- package/dist/ibc/ibcChannelV2/types.d.ts.map +1 -0
- package/dist/ibc/ibcChannelV2/types.js +3 -0
- package/dist/ibc/ibcChannelV2/types.js.map +1 -0
- package/dist/ibc/ibcClient/ChainIbcClientApi.d.ts +15 -0
- package/dist/ibc/ibcClient/ChainIbcClientApi.d.ts.map +1 -0
- package/dist/ibc/ibcClient/ChainIbcClientApi.js +39 -0
- package/dist/ibc/ibcClient/ChainIbcClientApi.js.map +1 -0
- package/dist/ibc/ibcClient/types.d.ts +53 -0
- package/dist/ibc/ibcClient/types.d.ts.map +1 -0
- package/dist/ibc/ibcClient/types.js +2 -0
- package/dist/ibc/ibcClient/types.js.map +1 -0
- package/dist/ibc/ibcConnection/ChainIbcConnectionApi.d.ts +11 -0
- package/dist/ibc/ibcConnection/ChainIbcConnectionApi.d.ts.map +1 -0
- package/dist/ibc/ibcConnection/ChainIbcConnectionApi.js +24 -0
- package/dist/ibc/ibcConnection/ChainIbcConnectionApi.js.map +1 -0
- package/dist/ibc/ibcConnection/types.d.ts +18 -0
- package/dist/ibc/ibcConnection/types.d.ts.map +1 -0
- package/dist/ibc/ibcConnection/types.js +2 -0
- package/dist/ibc/ibcConnection/types.js.map +1 -0
- package/dist/ibc/types.d.ts +106 -0
- package/dist/ibc/types.d.ts.map +1 -0
- package/dist/ibc/types.js +2 -0
- package/dist/ibc/types.js.map +1 -0
- package/dist/ibc-transfer/ChainIbcTransferApi.d.ts +12 -0
- package/dist/ibc-transfer/ChainIbcTransferApi.d.ts.map +1 -0
- package/dist/ibc-transfer/ChainIbcTransferApi.js +30 -0
- package/dist/ibc-transfer/ChainIbcTransferApi.js.map +1 -0
- package/dist/ibc-transfer/types.d.ts +26 -0
- package/dist/ibc-transfer/types.d.ts.map +1 -0
- package/dist/ibc-transfer/types.js +2 -0
- package/dist/ibc-transfer/types.js.map +1 -0
- package/dist/index.d.ts +26 -0
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +26 -0
- package/dist/index.js.map +1 -1
- package/dist/interchain-accounts/ChainInterChainAccApi.d.ts +9 -0
- package/dist/interchain-accounts/ChainInterChainAccApi.d.ts.map +1 -0
- package/dist/interchain-accounts/ChainInterChainAccApi.js +16 -0
- package/dist/interchain-accounts/ChainInterChainAccApi.js.map +1 -0
- package/dist/interchain-accounts/types.d.ts +12 -0
- package/dist/interchain-accounts/types.d.ts.map +1 -0
- package/dist/interchain-accounts/types.js +2 -0
- package/dist/interchain-accounts/types.js.map +1 -0
- package/dist/networks/endpoints.js +2 -2
- package/dist/networks/endpoints.js.map +1 -1
- package/dist/runtime/ChainRuntimeApi.d.ts +12 -0
- package/dist/runtime/ChainRuntimeApi.d.ts.map +1 -0
- package/dist/runtime/ChainRuntimeApi.js +16 -0
- package/dist/runtime/ChainRuntimeApi.js.map +1 -0
- package/dist/runtime/types.d.ts +4 -0
- package/dist/runtime/types.d.ts.map +1 -0
- package/dist/runtime/types.js +2 -0
- package/dist/runtime/types.js.map +1 -0
- package/dist/staking/ChainStakingApi.d.ts +1 -5
- package/dist/staking/ChainStakingApi.d.ts.map +1 -1
- package/dist/staking/ChainStakingApi.js +9 -7
- package/dist/staking/ChainStakingApi.js.map +1 -1
- package/dist/tokenwrapper/ChainTokenWrapperApi.d.ts +19 -0
- package/dist/tokenwrapper/ChainTokenWrapperApi.d.ts.map +1 -0
- package/dist/tokenwrapper/ChainTokenWrapperApi.js +26 -0
- package/dist/tokenwrapper/ChainTokenWrapperApi.js.map +1 -0
- package/dist/tokenwrapper/types.d.ts +15 -0
- package/dist/tokenwrapper/types.d.ts.map +1 -0
- package/dist/tokenwrapper/types.js +2 -0
- package/dist/tokenwrapper/types.js.map +1 -0
- package/dist/txs/ChainTxsApi.d.ts +12 -0
- package/dist/txs/ChainTxsApi.d.ts.map +1 -0
- package/dist/txs/ChainTxsApi.js +17 -0
- package/dist/txs/ChainTxsApi.js.map +1 -0
- package/dist/txs/types.d.ts +22 -0
- package/dist/txs/types.d.ts.map +1 -0
- package/dist/txs/types.js +5 -0
- package/dist/txs/types.js.map +1 -0
- package/dist/upgrade/ChainUpgradeApi.d.ts +22 -0
- package/dist/upgrade/ChainUpgradeApi.d.ts.map +1 -0
- package/dist/upgrade/ChainUpgradeApi.js +40 -0
- package/dist/upgrade/ChainUpgradeApi.js.map +1 -0
- package/dist/upgrade/types.d.ts +24 -0
- package/dist/upgrade/types.d.ts.map +1 -0
- package/dist/upgrade/types.js +5 -0
- package/dist/upgrade/types.js.map +1 -0
- package/dist/validator-set/ChainCometValidator.d.ts +8 -0
- package/dist/validator-set/ChainCometValidator.d.ts.map +1 -0
- package/dist/validator-set/ChainCometValidator.js +15 -0
- package/dist/validator-set/ChainCometValidator.js.map +1 -0
- package/dist/validator-set/ChainValidator.d.ts +8 -0
- package/dist/validator-set/ChainValidator.d.ts.map +1 -0
- package/dist/validator-set/ChainValidator.js +15 -0
- package/dist/validator-set/ChainValidator.js.map +1 -0
- package/dist/validator-set/types.d.ts +18 -0
- package/dist/validator-set/types.d.ts.map +1 -0
- package/dist/validator-set/types.js +2 -0
- package/dist/validator-set/types.js.map +1 -0
- package/dist/wasm/ChainWasmApi.d.ts +57 -0
- package/dist/wasm/ChainWasmApi.d.ts.map +1 -0
- package/dist/wasm/ChainWasmApi.js +78 -0
- package/dist/wasm/ChainWasmApi.js.map +1 -0
- package/dist/wasm/types.d.ts +77 -0
- package/dist/wasm/types.d.ts.map +1 -0
- package/dist/wasm/types.js +2 -0
- package/dist/wasm/types.js.map +1 -0
- package/docs/auth.md +438 -72
- package/docs/bank.md +782 -123
- package/docs/block-results.md +328 -21
- package/docs/block.md +325 -38
- package/docs/circuit.md +164 -35
- package/docs/dex.md +313 -63
- package/docs/distribution.md +772 -0
- package/docs/evidence.md +194 -0
- package/docs/factory.md +308 -62
- package/docs/feegrant.md +206 -0
- package/docs/gov.md +364 -0
- package/docs/ibc/ibcChannel.md +977 -0
- package/docs/ibc/ibcClient.md +771 -0
- package/docs/ibc/ibcConnection.md +214 -0
- package/docs/ibc-transfer.md +463 -0
- package/docs/interchain-accounts.md +223 -0
- package/docs/mint.md +270 -0
- package/docs/runtime.md +120 -0
- package/docs/slashing.md +287 -0
- package/docs/staking.md +756 -0
- package/docs/tokenwrapper.md +294 -0
- package/docs/txs.md +447 -0
- package/docs/upgrade.md +356 -0
- package/docs/validator-set.md +177 -0
- package/docs/wasm.md +916 -0
- 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
|
+
---
|