This page provides comprehensive technical documentation for the Interchain Queries module, combining all API specifications, message types, query endpoints, parameters, events, state structures, and CLI commands in a single reference document.
This documentation is verified against the actual module code and proto definitions. All examples are provided for demonstration purposes and may not reflect the current state of the chain.

Table of Contents


Messages

The Interchain Queries module provides the following message types for registering, updating, and managing interchain queries.

MsgRegisterInterchainQuery

Registers a new Interchain Query in the interchainqueries module. This message should only be issued by a smart contract. The calling contract is automatically charged a query registration deposit. The deposit is refunded when the query is removed. Proto Definition:
message MsgRegisterInterchainQuery {
  string query_type = 1;                 // Either "kv" or "tx"
  repeated KVKey keys = 2;               // KV keys (for KV queries only)
  string transactions_filter = 3;        // TX filter (for TX queries only)
  string connection_id = 4;              // IBC connection ID
  uint64 update_period = 5;              // Minimum blocks between updates
  string sender = 6;                     // Message sender address
}

message KVKey {
  string path = 1;                       // Store path (e.g., "bank", "staking")
  bytes key = 2;                         // Key bytes
}
Fields:
  • query_type - The query type identifier: "kv" or "tx"
  • keys - KV-storage keys for KV queries (max: max_kv_query_keys_count param)
  • transactions_filter - JSON filter for TX queries (max: max_transactions_filters param)
  • connection_id - IBC connection ID to the remote chain
  • update_period - Minimal delay between consecutive query executions
  • sender - Address of the message sender
Response:
message MsgRegisterInterchainQueryResponse {
  uint64 id = 1;                         // Assigned query ID
}
Transaction Filter Format: For TX queries, the transactions_filter field expects a JSON array:
[
  {"field": "transfer.recipient", "op": "eq", "value": "cosmos1..."},
  {"field": "tx.height", "op": "gte", "value": 1000000}
]
Supported operators: eq, lt, gt, lte, gte

MsgSubmitQueryResult

Submits the result of an Interchain Query execution to the chain. This message is typically sent by ICQ relayers. Proto Definition:
message MsgSubmitQueryResult {
  uint64 query_id = 1;                   // Query ID
  string sender = 2;                     // Message sender
  string client_id = 3;                  // IBC client ID (deprecated)
  QueryResult result = 4;                // Query result with proofs
}

message QueryResult {
  repeated StorageValue kv_results = 1;  // KV results
  Block block = 2;                       // TX block data
  uint64 height = 3;                     // Remote chain height
  uint64 revision = 4;                   // Chain revision
  bool allow_kv_callbacks = 5;           // Enable KV callbacks
}

message StorageValue {
  string storage_prefix = 1;             // Store name (e.g., "bank")
  bytes key = 2;                         // Key bytes
  bytes value = 3;                       // Value bytes
  tendermint.crypto.ProofOps Proof = 4;  // Merkle proof
}

MsgRemoveInterchainQuery

Removes an Interchain Query and refunds the deposit. Can only be executed by the query owner during the submit timeout, or by anyone after the timeout expires. Proto Definition:
message MsgRemoveInterchainQueryRequest {
  uint64 query_id = 1;                   // Query ID to remove
  string sender = 2;                     // Message sender
}

message MsgRemoveInterchainQueryResponse {}

MsgUpdateInterchainQuery

Updates the parameters of a registered Interchain Query. Can only be executed by the query owner. Proto Definition:
message MsgUpdateInterchainQueryRequest {
  uint64 query_id = 1;                   // Query ID to update
  repeated KVKey new_keys = 2;           // New KV keys
  uint64 new_update_period = 3;          // New update period
  string new_transactions_filter = 4;    // New TX filter
  string sender = 5;                     // Message sender
}

message MsgUpdateInterchainQueryResponse {}

MsgUpdateParams

Updates the module parameters. Can only be executed by the module authority. Proto Definition:
message MsgUpdateParams {
  string authority = 1;                  // Module authority address
  Params params = 2;                     // New parameters
}

message MsgUpdateParamsResponse {}

Queries

The Interchain Queries module provides the following query endpoints for retrieving information.

Params

Fetches the current parameters of the interchainqueries module. Proto Definition:
message QueryParamsRequest {}

message QueryParamsResponse {
  Params params = 1;
}
REST Endpoint: GET /neutron/interchainqueries/params

RegisteredQueries

Retrieves all registered Interchain Queries with optional filtering. Proto Definition:
message QueryRegisteredQueriesRequest {
  repeated string owners = 1;            // Filter by owners
  string connection_id = 2;              // Filter by connection ID
  cosmos.base.query.v1beta1.PageRequest pagination = 3;
}

message QueryRegisteredQueriesResponse {
  repeated RegisteredQuery registered_queries = 1;
  cosmos.base.query.v1beta1.PageResponse pagination = 2;
}
REST Endpoint: GET /neutron/interchainqueries/registered_queries

RegisteredQuery

Fetches details of a specific registered Interchain Query. Proto Definition:
message QueryRegisteredQueryRequest {
  uint64 query_id = 1;                   // Query ID
}

message QueryRegisteredQueryResponse {
  RegisteredQuery registered_query = 1;
}
REST Endpoint: GET /neutron/interchainqueries/registered_query

QueryResult

Retrieves the most recent result of a KV Interchain Query. Proto Definition:
message QueryRegisteredQueryResultRequest {
  uint64 query_id = 1;                   // Query ID
}

message QueryRegisteredQueryResultResponse {
  QueryResult result = 1;
}
REST Endpoint: GET /neutron/interchainqueries/query_result

LastRemoteHeight

Retrieves the most recent height of a remote chain. Proto Definition:
message QueryLastRemoteHeight {
  string connection_id = 1;              // IBC connection ID
}

message QueryLastRemoteHeightResponse {
  uint64 height = 1;                     // Remote chain height
  uint64 revision = 2;                   // Chain revision
}
REST Endpoint: GET /neutron/interchainqueries/remote_height

Parameters

The module maintains the following parameters:
ParameterTypeDefaultDescription
query_submit_timeoutuint641036800Blocks after which anyone can remove a query (~1 month)
query_depositsdk.Coins1000000untrnDeposit required for query registration
tx_query_removal_limituint6410000Max TX queries removed per EndBlock
max_kv_query_keys_countuint6432Maximum keys in a single KV query
max_transactions_filtersuint6432Maximum filters in a single TX query
Proto Definition:
message Params {
  uint64 query_submit_timeout = 1;
  repeated cosmos.base.v1beta1.Coin query_deposit = 2;
  uint64 tx_query_removal_limit = 3;
  uint64 max_kv_query_keys_count = 4;
  uint64 max_transactions_filters = 5;
}

Events

The module emits the following events:

EventTypeNeutronMessage

Event Type: neutron
Attribute KeyAttribute ValueDescription
moduleinterchainqueriesModule name
actionquery_updated | query_removedAction performed
query_id{query_id}Query identifier
connection_id{connection_id}IBC connection ID
owner{owner_address}Query owner (query_updated only)
typekv | txQuery type (query_updated only)
tx_filter{filter_json}TX filter (query_updated only)
kv_key{keys_string}KV keys (query_updated only)
When Emitted:
  • query_updated - When a query is registered or updated
  • query_removed - When a query is removed

State

The module maintains the following state structures:

RegisteredQuery

The primary state object for each registered query: Proto Definition:
message RegisteredQuery {
  uint64 id = 1;                         // Unique query ID
  string owner = 2;                      // Query owner address
  string query_type = 3;                 // "kv" or "tx"
  repeated KVKey keys = 4;               // KV keys
  string transactions_filter = 5;        // TX filter
  string connection_id = 6;              // IBC connection ID
  uint64 update_period = 7;              // Update period
  uint64 last_submitted_result_local_height = 8;    // Last local height
  ibc.core.client.v1.Height last_submitted_result_remote_height = 9;  // Last remote height
  repeated cosmos.base.v1beta1.Coin deposit = 10;   // Deposit amount
  uint64 submit_timeout = 11;            // Submit timeout
  uint64 registered_at_height = 12;      // Registration height
}

Storage Keys

The module uses the following storage keys:
  • RegisteredQueryKey - Stores registered queries by ID
  • RegisteredQueryResultKey - Stores KV query results by ID
  • SubmittedTxKey - Stores submitted TX hashes
  • TxQueryToRemoveKey - Stores TX queries marked for removal
  • LastRegisteredQueryIDKey - Stores last assigned query ID
Note: TX query results are not stored in state; they are passed directly to smart contracts via sudo callbacks.

CLI Commands

CLI commands are available for testing and debugging. Production applications should use CosmWasm smart contracts for better result handling and integration.

Query Commands

# Get module parameters
neutrond query interchainqueries params

# List all registered queries
neutrond query interchainqueries registered-queries \
  --owners neutron1... \
  --connection_id connection-0

# Get specific query details
neutrond query interchainqueries registered-query [query-id]

# Get query result (KV queries only)
neutrond query interchainqueries query-result [query-id]

# Get last remote height
neutrond query interchainqueries query-last-remote-height [connection-id]

Transaction Commands

# Submit query result
neutrond tx interchainqueries submit-query-result [query-id] [result-file] \
  --from [key-name] \
  --gas 10000000

# Remove interchain query
neutrond tx interchainqueries remove-interchain-query [query-id] \
  --from [key-name]

REST Endpoints

The module exposes the following REST endpoints:
MethodEndpointDescription
GET/neutron/interchainqueries/paramsGet module parameters
GET/neutron/interchainqueries/registered_queriesList registered queries
GET/neutron/interchainqueries/registered_queryGet specific query
GET/neutron/interchainqueries/query_resultGet query result
GET/neutron/interchainqueries/remote_heightGet remote height

Error Codes

The module returns the following error codes (from module-reference/x/interchainqueries/types/errors.go):
CodeNameDescription
1100ErrInvalidQueryIDInvalid query id
1101ErrEmptyResultEmpty result
1102ErrInvalidClientIDInvalid client id
1103ErrInvalidUpdatePeriodInvalid update period
1104ErrInvalidConnectionIDInvalid connection id
1105ErrInvalidQueryTypeInvalid query type
1106ErrInvalidTransactionsFilterInvalid transactions filter
1107ErrInvalidSubmittedResultInvalid result
1108ErrProtoMarshalFailed to marshal protobuf bytes
1109ErrProtoUnmarshalFailed to unmarshal protobuf bytes
1110ErrInvalidTypeInvalid type
1111ErrInternalInternal error
1112ErrInvalidProofMerkle proof is invalid
1113ErrInvalidHeaderHeader is invalid
1114ErrInvalidHeightHeight is invalid
1115ErrNoQueryResultNo query result
1116ErrNotContractNot a contract
1117ErrEmptyKeysKeys are empty
1118ErrEmptyKeyPathKey path is empty
1119ErrEmptyKeyIDKey id is empty
1120ErrTooManyKVQueryKeysToo many keys
1121ErrUnexpectedQueryTypeGenesisUnexpected query type

Known Limitations

1. Empty Values in KV Queries

Issue: Due to a bug in ICS23, the module cannot verify proofs for empty or nil values. Impact: KV queries targeting keys with empty values will fail during proof verification. Workaround: Avoid querying keys that might have empty values, or handle missing responses gracefully.

2. Transaction Filter Verification

Issue: TX query filters are applied by relayers, not verified by the module. Impact: The module only verifies that transactions exist, not that they match your filters. Workaround: Always implement proper transaction validation in your smart contract’s sudo callback.

3. Query Deposit Mechanism

Issue: Queries require a deposit to prevent spam. Impact: Must have sufficient funds when registering queries. Workaround: Ensure proper deposit management and query lifecycle handling.

4. Chain Upgrade Compatibility

Issue: Chain upgrades can affect consensus state and proof verification. Impact: Queries might temporarily fail during upgrades. Workaround: Implement proper error handling and retry logic.

Smart Contract Integration

Sudo Callbacks

The module sends sudo messages to smart contracts when query results are available: For KV Queries:
use neutron_sdk::sudo::msg::SudoMsg;

#[entry_point]
pub fn sudo(deps: DepsMut, env: Env, msg: SudoMsg) -> StdResult<Response> {
    match msg {
        SudoMsg::KVQueryResult { query_id } => {
            // Query result is available in module state
            // Use QueryResult endpoint to retrieve it
        }
        // ...
    }
}
For TX Queries:
#[entry_point]
pub fn sudo(deps: DepsMut, env: Env, msg: SudoMsg) -> StdResult<Response> {
    match msg {
        SudoMsg::TxQueryResult { query_id, height, data } => {
            // TX data is passed directly in the callback
            // Verify transactions match your filter criteria
        }
        // ...
    }
}

Query Registration from Contracts

use neutron_sdk::bindings::msg::NeutronMsg;

// Register KV query
let msg = NeutronMsg::RegisterInterchainQuery {
    query_type: "kv".to_string(),
    keys: vec![KVKey {
        path: "bank".to_string(),
        key: Binary::from(key_bytes),
    }],
    transactions_filter: "".to_string(),
    connection_id: "connection-0".to_string(),
    update_period: 100,
};

Best Practices

  1. Deposit Management: Always handle query deposits properly and remove queries when no longer needed
  2. Error Handling: Implement comprehensive error handling for failed sudo callbacks
  3. Gas Optimization: Design efficient query result processing to minimize gas costs
  4. Filter Design: Use specific transaction filters to reduce false positives
  5. Proof Verification: For TX queries, always verify transactions in your contract logic
  6. Connection Selection: Choose stable IBC connections for reliable query execution
For implementation examples and detailed guides, see the How-to Guide and Explanation sections.