diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md
index 0944c0e889..0b825c4b56 100644
--- a/book/src/SUMMARY.md
+++ b/book/src/SUMMARY.md
@@ -24,7 +24,7 @@
 
 - [Proposed Architectural Changes](proposals.md)
   - [Ledger Replication](ledger-replication.md)
-  - [Secure Enclave](enclave.md)
+  - [Secure Vote Signing](vote-signer.md)
   - [Staking Rewards](staking-rewards.md)
   - [Fork Selection](fork-selection.md)
   - [Blocktree](blocktree.md)
diff --git a/book/src/vote-signer.md b/book/src/vote-signer.md
index 5af1ec56af..d5514154f7 100644
--- a/book/src/vote-signer.md
+++ b/book/src/vote-signer.md
@@ -1,9 +1,9 @@
 # Secure Vote Signing
 
-The gaol of this design is to address the following challenges with voting:
+The goal of this design is to address the following challenges with voting:
 
-* Validators execute untrusted code in a potentially insecure VM.
-* Validators sign the result of their work and submit consensus votes.
+* A validator execute untrusted code in a potentially insecure VM.
+* A validator signs the result of its work and votes on a fork.
 * Votes that violate consensus rules could be used to slash the stake used in the vote.
 
 Every node contains an asymmetric key that's used for signing and verifying the
@@ -19,40 +19,42 @@ protection. An enclave can be used to generate an asymmetric key and keep the
 private key in its protected memory. It can expose an API that user (untrusted)
 code can use for signing the transactions.
 
-## Vote Signers, Validators and Stake Owners
+## Vote Signers, Validators and Stakeholders
 
-A validator is a fullnode that is connected to the cluster and
-executes transactions.  A validator computes all the possible forks
-that are concurrently active in the cluster.  A validator picks the
-best possible fork to vote and requests the vote signer to sign the
-vote.
+A validator is a role of a fullnode and validates transactions.
+When it receives multiple blocks for the same slot, the validator
+tracks all possible forks until it can determine a "best" one.
+A validator selects the best fork by submitting a vote to it. When
+voting it utilizes a *vote signer* to minimize the possibility of
+its vote inadvertently violating a consensus rule and getting the
+stakeholder's stake slashed.
 
 A vote signer evaluates the vote proposed by the validator and signs
 the vote only if it does not violate a slashing condition.  A vote
-signer only needs to maintain minimum state regarding the votes it
+signer only needs to maintain minimal state regarding the votes it
 signed, and the votes signed by the rest of the cluster.  It doesn't
 need to process a full set of transactions.
 
-A stake owner is an identity that has control of the staked capital.
-The stake owner can delegate their stake to the vote signer.  Once
+A stakeholder is an identity that has control of the staked capital.
+The stakeholder can delegate its stake to the vote signer.  Once
 a stake is delegated, the vote signer votes represent the voting
 weight of all the delegated stakes, and produce rewards for all the
 delegated stakes.
 
-A single validator could do work for multiple vote signers.  For a
-single vote signer to observe votes from multiple validators and
-only vote if M/N agree. For a single vote signer to be delegated
-multiple stakes. For a single stake owner to delegate a portion of
-the stake to multiple vote signers.
+A single validator could operate on behalf of multiple vote signers.
+If a single vote signer observes votes from multiple validators, it
+may choose to vote only if some percentage agree. A single vote
+signer may be delegated multiple stakes.  A single stakeholder may
+delegate portions of its stake to multiple vote signers.
 
-For simplicity, the intial rollout should focus on the following
+For simplicity, the initial rollout should focus on the following
 configuration:
 
 * 1:1 relationship between validator and vote signer.  The validator
 can use the vote signer's public key as its identity.  This key
 should have some sols to pay for execution of votes.
 
-* Stake Owner can delegate the entire stake to a single vote signer.
+* Stakeholder can delegate the entire stake to a single vote signer.
 And a vote signer may have more than 1 stake delegated to them.
 The vote signer may need to submit multiple votes to register a
 vote with a stake public key that does not fit into a single
@@ -70,8 +72,8 @@ transaction.
 2. The node performs attestation of the enclave (e.g using Intel's IAS APIs)
     * The node ensures that the Secure Enclave is running on a TPM and is
       signed by a trusted party
-3. The owner of the node grants ephemeral key permission to use its stake. This
-   process is TBD.
+3. The stakeholder of the node grants ephemeral key permission to use its stake.
+   This process is TBD.
 4. The node's untrusted, non-enclave software calls trusted enclave software
    using its interface to sign transactions and other data.
     * In case of vote signing, the node needs to verify the PoH. The PoH