---
title: "ChannelOpenTry defines a rpc handler method for MsgChannelOpenTry."
method: POST
path: "/ibc.core.channel.v1.Msg/ChannelOpenTry"
tags: ["Msg"]
---

# ChannelOpenTry defines a rpc handler method for MsgChannelOpenTry.

`POST /ibc.core.channel.v1.Msg/ChannelOpenTry`

## Request body

- object — MsgChannelOpenInit defines a msg sent by a Relayer to try to open a channel on Chain B. The version field within the Channel field has been deprecated. Its value will be ignored by core IBC.
  - `port_id` string
  - `previous_channel_id` string — Deprecated: this field is unused. Crossing hello's are no longer supported in core IBC.
  - `channel` object — Channel defines pipeline for exactly-once packet delivery between specific modules on separate blockchains, which has at least one end capable of sending packets and one end capable of receiving packets.
    - `state` 'STATE_UNINITIALIZED_UNSPECIFIED' | 'STATE_INIT' | 'STATE_TRYOPEN' | 'STATE_OPEN' | 'STATE_CLOSED' | 'STATE_FLUSHING' | 'STATE_FLUSHCOMPLETE' — State defines if a channel is in one of the following states: CLOSED, INIT, TRYOPEN, OPEN, FLUSHING, FLUSHCOMPLETE or UNINITIALIZED. - STATE_UNINITIALIZED_UNSPECIFIED: Default State - STATE_INIT: A channel has just started the opening handshake. - STATE_TRYOPEN: A channel has acknowledged the handshake step on the counterparty chain. - STATE_OPEN: A channel has completed the handshake. Open channels are ready to send and receive packets. - STATE_CLOSED: A channel has been closed and can no longer be used to send or receive packets. - STATE_FLUSHING: A channel has just accepted the upgrade handshake attempt and is flushing in-flight packets. - STATE_FLUSHCOMPLETE: A channel has just completed flushing any in-flight packets.
    - `ordering` 'ORDER_NONE_UNSPECIFIED' | 'ORDER_UNORDERED' | 'ORDER_ORDERED' — - ORDER_NONE_UNSPECIFIED: zero-value for channel ordering - ORDER_UNORDERED: packets can be delivered in any order, which may differ from the order in which they were sent. - ORDER_ORDERED: packets are delivered exactly in the order which they were sent
    - `counterparty` object
      - `port_id` string — port on the counterparty chain which owns the other end of the channel.
      - `channel_id` string
    - `connection_hops` string[]
    - `version` string
    - `upgrade_sequence` string, uint64
  - `counterparty_version` string
  - `proof_init` string, byte
  - `proof_height` object — Normally the RevisionHeight is incremented at each height while keeping RevisionNumber the same. However some consensus algorithms may choose to reset the height in certain conditions e.g. hard forks, state-machine breaking changes In these cases, the RevisionNumber is incremented so that height continues to be monitonically increasing even as the RevisionHeight gets reset
    - `revision_number` string, uint64
    - `revision_height` string, uint64
  - `signer` string

## Response `200`

A successful response.

## Other responses

- `default` — An unexpected error response.

## Changes

- **2024-07-11** `ca7e84576c8e` — 1 info
  - endpoint added
- **2024-05-15** `41fb8b09e244` — 1 breaking
  - api path removed without deprecation
- **2024-02-23** `54713b4a9d25` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/pokt-network/apis/http-api-console/changes/ibc.core.channel.v1.Msg/ChannelOpenTry/post.md)

---

[API](https://skmtc.dev/pokt-network/apis/http-api-console.md) · [All operations](https://skmtc.dev/pokt-network/apis/http-api-console/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/pokt-network/http-api-console/revisions/ca7e84576c8e/schema)