diff --git a/KIPs/kip-149.md b/KIPs/kip-149.md
index 797bf4e..3b97b84 100644
--- a/KIPs/kip-149.md
+++ b/KIPs/kip-149.md
@@ -25,9 +25,9 @@ Currently, Klaytn has multiple [system contracts](#definitions), but they are de
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
-This standard defines the separation of data and logic contracts in system contracts, and every system contract should be developed and deployed under this standard. This method, often called the proxy pattern, allows the change of the logic contract while keeping the data, which can greatly reduce the cost of contract updates. Upgrading a logic contract will not affect the Registry since the Registry only holds the address of the proxy(data) contract. Delegating ownership of a proxy contract to a governance contract can solve the centralized and potential private key loss issues.
+If a system contract implements a proxy pattern for upgradeability, it must follow the separation of data and logic contracts as defined in this standard. This method, often called the proxy pattern, allows the change of the logic contract while keeping the data, which can greatly reduce the cost of contract updates. Upgrading a logic contract will not affect the Registry since the Registry only holds the address of the proxy(data) contract. Delegating ownership of a proxy contract to a governance contract can solve the centralized and potential private key loss issues.
 
-Between the popular proxy patterns `Transparent` and `UUPS`, all system contracts must be developed and validated based on the [`UUPS`](https://eips.ethereum.org/EIPS/eip-1822) proxy pattern.
+For system contracts that implement the proxy pattern, they must be developed and validated based on the [`UUPS`](https://eips.ethereum.org/EIPS/eip-1822) proxy pattern rather than the `Transparent` pattern.
 
 ### Definitions
 
@@ -162,7 +162,7 @@ When upgrading a system contract, its logic contract will be changed by governan
 
 #### Replace System Contracts
 
-If current system contract updates can’t be done by upgrading the logic contract, it must be replaced with the newly deployed system contract. The predecessor doesn’t need to be explicitly deprecated since a new system contract will implicitly replace and deprecate it. The replacement process is the same as the initial registration for the system contract except for having a predecessor.
+If current system contract updates can’t be done by upgrading the logic contract (e.g., not compatible storage layout or immutable contract), it must be replaced with the newly deployed system contract. The predecessor doesn’t need to be explicitly deprecated since a new system contract will implicitly replace and deprecate it. The replacement process is the same as the initial registration for the system contract except for having a predecessor.
 
 ![](../assets/kip-149/ReplacementProcess.png)