diff --git a/.github/mergify.yml b/.github/mergify.yml
index 3da50d23931..1ecf029d8f1 100644
--- a/.github/mergify.yml
+++ b/.github/mergify.yml
@@ -66,14 +66,14 @@ pull_request_rules:
       backport:
         branches:
           - 08-wasm/release/v0.1.x+ibc-go-v8.0.x-wasmvm-v1.5.x
-  - name: backport patches to v0.2.x wasm ibc-go v8.2.x & wasmvm 2.0.x branch
+  - name: backport patches to v0.2.x wasm ibc-go v8.3.x & wasmvm 2.0.x branch
     conditions:
       - base=main
-      - label=backport-wasm-v0.2.x+ibc-go-v8.2.x-wasmvm-v2.0.x
+      - label=backport-wasm-v0.2.x+ibc-go-v8.3.x-wasmvm-v2.0.x
     actions:
       backport:
         branches:
-          - 08-wasm/release/v0.2.x+ibc-go-v8.2.x-wasmvm-v2.0.x
+          - 08-wasm/release/v0.2.x+ibc-go-v8.3.x-wasmvm-v2.0.x
   - name: backport patches to v7.2.x branch
     conditions:
       - base=main
diff --git a/docs/docs/03-light-clients/04-wasm/03-integration.md b/docs/docs/03-light-clients/04-wasm/03-integration.md
index 2fc65155551..33fd75fad9d 100644
--- a/docs/docs/03-light-clients/04-wasm/03-integration.md
+++ b/docs/docs/03-light-clients/04-wasm/03-integration.md
@@ -129,7 +129,7 @@ When it comes to instantiating `08-wasm`'s keeper there are two recommended ways
 
 ### If `x/wasm` is present
 
-If the chain where the module is integrated uses `x/wasm` then we recommend that both `08-wasm` and `x/wasm` share the same Wasm VM instance. Having two separate Wasm VM instances is still possible, but care should be taken to make sure that both instances do not share the directory when the VM stores blobs and various caches, otherwise unexpected behaviour is likely to happen (from `x/wasm` v0.51 and `08-wasm` v0.2.0.0+ibc-go-v8.2-wasmvm-v2.0 this will be forbidden anyway, since wasmvm v2.0.0 and above will not allow two different Wasm VM instances to shared the same data folder).
+If the chain where the module is integrated uses `x/wasm` then we recommend that both `08-wasm` and `x/wasm` share the same Wasm VM instance. Having two separate Wasm VM instances is still possible, but care should be taken to make sure that both instances do not share the directory when the VM stores blobs and various caches, otherwise unexpected behaviour is likely to happen (from `x/wasm` v0.51 and `08-wasm` v0.2.0+ibc-go-v8.3-wasmvm-v2.0 this will be forbidden anyway, since wasmvm v2.0.0 and above will not allow two different Wasm VM instances to shared the same data folder).
 
 In order to share the Wasm VM instance please follow the guideline below. Please note that this requires `x/wasm` v0.41 or above.
 
diff --git a/docs/docs/03-light-clients/04-wasm/09-migrations.md b/docs/docs/03-light-clients/04-wasm/09-migrations.md
index ff4800e74ec..1acc23d441a 100644
--- a/docs/docs/03-light-clients/04-wasm/09-migrations.md
+++ b/docs/docs/03-light-clients/04-wasm/09-migrations.md
@@ -15,7 +15,7 @@ This guide provides instructions for migrating 08-wasm versions.
 
 In the 08-wasm versions compatible with ibc-go v7.3.x and above from the v7 release line, the checksums of the uploaded Wasm bytecodes are all stored under a single key. From ibc-go v8.0.x the checksums are stored using [`collections.KeySet`](https://docs.cosmos.network/v0.50/build/packages/collections#keyset), whose full functionality became available in Cosmos SDK v0.50. There is therefore an [automatic migration handler](https://github.com/cosmos/ibc-go/blob/57fcdb9a9a9db9b206f7df2f955866dc4e10fef4/modules/light-clients/08-wasm/module.go#L115-L118) configured in the 08-wasm module to migrate the stored checksums to `collections.KeySet`.
 
-## From v0.1.0+ibc-go-v8.0-wasmvm-v1.5 to v0.2.0-ibc-go-v8.2-wasmvm-v2.0
+## From v0.1.0+ibc-go-v8.0-wasmvm-v1.5 to v0.2.0-ibc-go-v8.3-wasmvm-v2.0
 
 The `WasmEngine` interface has been updated to reflect changes in the function signatures of Wasm VM: