diff --git a/proposals/0133-syscall-get-epoch-stake.md b/proposals/0133-syscall-get-epoch-stake.md
index 2a9841351..8310191be 100644
--- a/proposals/0133-syscall-get-epoch-stake.md
+++ b/proposals/0133-syscall-get-epoch-stake.md
@@ -17,9 +17,9 @@ A syscall to retrieve a vote account's delegated stake for the current epoch.
 ## Motivation
 
 Currently, on-chain programs have no knowledge of the current epoch's stake and
-how much active stake is delegated to a certain vote account.
+how much active stake is delegated to any vote account.
 
-If this data was available for querying by on-chain programs, it would unblock
+If this data were available for querying by on-chain programs, it would unblock
 many use cases, such as validator governance and secondary consensus mechanisms,
 that were previously not possible on Solana.
 
@@ -29,21 +29,20 @@ support for a pending feature gate.
 
 ## Alternatives Considered
 
-An alternative design has been proposed in the past for using an on-chain sysvar
-account to store all of the current epoch's stake. It was proposed in
-[SIMD 0056](https://github.com/solana-foundation/solana-improvement-documents/pull/56).
+[SIMD 0056](https://github.com/solana-foundation/solana-improvement-documents/pull/56)
+proposes using an on-chain sysvar account to store all of the current epoch's
+stake.
 
-Using a sysvar account to store even just the current epoch's stake introduces a
-size limitation on the number of entries that can be stored, which the number of
-validators on Solana could surpass in the future.
+Because account data is finite, using a sysvar account to store even just the 
+current epoch's stake limits the number of entries that can be stored. The
+amount of validators in one Solana cluster could surpass this number in the
+future.
 
-By offering access to this information through only a syscall, we can avoid this
-account maximum size constraint. However, the syscall approach also makes the
-data more cumbersome to retrieve off-chain than the sysvar approach.
-
-While retrieving this data off-chain may not be straightforward, it remains
-entirely feasible. Conversely, on-chain programs currently do not have this
-capability at all.
+Exposing epoch-stake information through a syscall avoids this account maximum
+size constraint. While the syscall approach does not offer the easy off-chain
+retrieval of a sysvar, there are existing ways to get epoch-stake data off
+chain. The priority of a new design should be making the data available to
+on-chain programs.
 
 ## New Terminology
 
@@ -73,18 +72,17 @@ uint64_t sol_get_epoch_stake(
 );
 ```
 
-`var_addr` must be the starting address of at least 8 bytes of writable VM
-memory to store the `u64` response. If not, the syscall will abort the VM with
-an access violation.
+`var_addr` must be the starting address of 8 bytes of writable VM memory to
+store the `u64` response. If not, the syscall will abort the VM with an access
+violation.
 
 If the provided vote address corresponds to an account that is not a vote
 account or does not exist, the syscall will write `0` for active stake. 
 
 ## Impact
 
-This new syscall directly unlocks highly relevant network data for a wide range
-of protocols. Developers seeking to access vote account stake will be positively
-impacted.
+Dapp developers will be able to query vote account stake for the current epoch
+from within on-chain programs.
 
 ## Security Considerations