diff --git a/proposals/0077-programify-feature-gate.md b/proposals/0077-programify-feature-gate.md
index 3afc6c56d..8d0db11f0 100644
--- a/proposals/0077-programify-feature-gate.md
+++ b/proposals/0077-programify-feature-gate.md
@@ -36,13 +36,13 @@ This is SIMD 1/3 expected for **Multi-Client Feature Gates**. See
 
 ### Proposal
 
-This SIMD outlines a proposal to replace the non-existent system account at
-address `Feature111111111111111111111111111111111111`, which is the owner of
-all feature accounts, with an upgradeable BPF program.
+This SIMD outlines a proposal to replace the non-existent program at address
+`Feature111111111111111111111111111111111111`, which is the owner of all
+feature accounts, with an upgradeable BPF program.
 
 It defines the program's initial functionality - which consists solely of the
-capability to revoke pending feature activations - and an initial
-upgrade control process for managing upgrades of the program.
+capability to revoke pending feature activations - and an initial upgrade
+control process for managing upgrades of the program.
 
 Important note: the process by which core contributors *activate* features
 would remain completely unchanged by this SIMD.
@@ -55,8 +55,8 @@ The most obvious approach is to place a program in charge of these accounts.
 An upgradeable BPF program presents a more logical solution over a native
 program for this task, since it provides a built-in system for upgrades.
 
-In the case of this particular proposal, a BPF program provides the capability
-to revoke pending feature activations.
+In the case of this particular proposal, this BPF program will provide
+engineers the capability to revoke pending feature activations.
 
 Currently, a feature is queued for activation by a keypair holder creating an
 empty account and assigning it to the
@@ -74,7 +74,9 @@ revoking queued features, giving engineers more flexibility and safeguards.
 
 The Feature Gate program could instead be a native program, rather than a BPF
 program. However, this would mean any changes to the program would need to be
-implemented by all validator clients in coordination.
+implemented by all validator clients in coordination. This makes upgrading the
+program to support the complete Multi-Client Feature Gate architecture
+cumbersome and potentially dangerous.
 
 ## New Terminology