diff --git a/docs/versioned_docs/version-v8.5.x/01-ibc/07-proposals.md b/docs/versioned_docs/version-v8.5.x/01-ibc/07-proposals.md
index 9a78f0b2aec..412a8d763aa 100644
--- a/docs/versioned_docs/version-v8.5.x/01-ibc/07-proposals.md
+++ b/docs/versioned_docs/version-v8.5.x/01-ibc/07-proposals.md
@@ -47,7 +47,7 @@ once the proposal passes.
 
 # How to recover an expired client with a governance proposal
 
-See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](/architecture/adr-026-ibc-client-recovery-mechanisms)
+See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md)
 
 > **Who is this information for?**
 > Although technically anyone can submit the governance proposal to recover an expired client, often it will be **relayer operators** (at least coordinating the submission).
diff --git a/docs/versioned_docs/version-v8.5.x/01-ibc/08-relayer.md b/docs/versioned_docs/version-v8.5.x/01-ibc/08-relayer.md
index c6fcda7658c..265c2a15dd7 100644
--- a/docs/versioned_docs/version-v8.5.x/01-ibc/08-relayer.md
+++ b/docs/versioned_docs/version-v8.5.x/01-ibc/08-relayer.md
@@ -21,7 +21,7 @@ slug: /ibc/relayer
 Events are emitted for every transaction processed by the base application to indicate the execution
 of some logic clients may want to be aware of. This is extremely useful when relaying IBC packets.
 Any message that uses IBC will emit events for the corresponding TAO logic executed as defined in
-the [IBC events document](/events/events).
+the [IBC events document](/docs/events/events.md).
 
 In the SDK, it can be assumed that for every message there is an event emitted with the type `message`,
 attribute key `action`, and an attribute value representing the type of message sent