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

# ChannelUpgradeConfirm defines a rpc handler method for MsgChannelUpgradeConfirm.

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

## Request body

- IbcCoreChannelV1MsgChannelUpgradeConfirm
  - `channel_id` string
  - `counterparty_channel_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.
  - `counterparty_upgrade` IbcCoreChannelV1Upgrade — Upgrade is a verifiable type which contains the relevant information for an attempted upgrade. It provides the proposed changes to the channel end, the timeout for this upgrade attempt and the next packet sequence which allows the counterparty to efficiently know the highest sequence it has received. The next sequence send is used for pruning and upgrading from unordered to ordered channels.
    - `fields` IbcCoreChannelV1UpgradeFields — UpgradeFields are the fields in a channel end which may be changed during a channel upgrade.
      - `connection_hops` string[]
      - `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
      - `version` string
    - `next_sequence_send` string, uint64
    - `timeout` IbcCoreChannelV1Timeout — Timeout defines an execution deadline structure for 04-channel handlers. This includes packet lifecycle handlers as well as the upgrade handshake handlers. A valid Timeout contains either one or both of a timestamp and block height (sequence).
      - `height` IbcCoreClientV1Height — 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_height` string, uint64
        - `revision_number` string, uint64
      - `timestamp` string, uint64
  - `port_id` string
  - `proof_channel` string, byte
  - `proof_height` IbcCoreClientV1Height — 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_height` string, uint64
    - `revision_number` string, uint64
  - `proof_upgrade` string, byte
  - `signer` string

## Response `200`

A successful response.

- IbcCoreChannelV1MsgChannelUpgradeConfirmResponse
  - `result` 'RESPONSE_RESULT_TYPE_UNSPECIFIED' | 'RESPONSE_RESULT_TYPE_NOOP' | 'RESPONSE_RESULT_TYPE_SUCCESS' | 'RESPONSE_RESULT_TYPE_FAILURE' — - RESPONSE_RESULT_TYPE_UNSPECIFIED: Default zero value enumeration - RESPONSE_RESULT_TYPE_NOOP: The message did not call the IBC application callbacks (because, for example, the packet had already been relayed) - RESPONSE_RESULT_TYPE_SUCCESS: The message was executed successfully - RESPONSE_RESULT_TYPE_FAILURE: The message was executed unsuccessfully

## Other responses

- `default` — An unexpected error response.

## Changes

- **2025-03-27** `4f349536c8f3` — 1 info
  - endpoint added
- **2025-02-24** `2ab9d24288c2` — 1 breaking
  - api path removed without deprecation
- **2024-08-14** `21c607e4fa20` — 1 info
  - endpoint added
- **2024-07-31** `19416a3f0cd1` — 1 breaking
  - api path removed without deprecation
- **2024-07-11** `ca7e84576c8e` — 1 info
  - endpoint added

[Full history](https://skmtc.dev/pokt-network/apis/http-api-console/changes/ibc.core.channel.v1.Msg/ChannelUpgradeConfirm/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.dev/pokt-network/apis/http-api-console/revisions/671fab54b729?raw)