diff --git a/docs/docs/features/partial-set-security.md b/docs/docs/features/partial-set-security.md
index b8440cf4a4..8bebaa7c7d 100644
--- a/docs/docs/features/partial-set-security.md
+++ b/docs/docs/features/partial-set-security.md
@@ -25,4 +25,4 @@ Both Opt In and Top N chains currently require a governance proposal to be added
 For Top N chains, this is also the long term vision for how they are launched.
 
 For Opt In chains, this is a temporary measure to prevent issues around chain ID squatting. Eventually, the plan is to allow launching Opt In chains permissionlessly without going through governance, with quality control being handled by the market of validators deciding which chains they would like to validate on.
-:::
\ No newline at end of file
+:::
diff --git a/docs/docs/features/power-shaping.md b/docs/docs/features/power-shaping.md
index b6ee2b5bdf..74248a6dbb 100644
--- a/docs/docs/features/power-shaping.md
+++ b/docs/docs/features/power-shaping.md
@@ -18,4 +18,4 @@ Note that this is a soft cap, and the actual power of a validator can exceed thi
 
 All these mechanisms are set by the consumer chain in the `ConsumerAdditionProposal`. They operate *solely on the provider chain*, meaning the consumer chain simply receives the validator set after these rules have been applied and does not have any knowledge about whether they are applied.
 
-Each of these mechanisms is *set during the consumer addition proposal* (see [Onboarding](../consumer-development/onboarding.md#3-submit-a-governance-proposal)), and is currently *immutable* after the chain has been added.
\ No newline at end of file
+Each of these mechanisms is *set during the consumer addition proposal* (see [Onboarding](../consumer-development/onboarding.md#3-submit-a-governance-proposal)), and is currently *immutable* after the chain has been added.