diff --git a/book/src/credit-only-credit-debit-accounts.md b/book/src/credit-only-credit-debit-accounts.md
index ee25291c6b78d1..99befb797d25a8 100644
--- a/book/src/credit-only-credit-debit-accounts.md
+++ b/book/src/credit-only-credit-debit-accounts.md
@@ -3,7 +3,7 @@
 This design covers the handling of credit-only and credit-debit accounts in the
 [runtime](runtime.md).  Accounts already distinguish themselves as credit-only or
 credit-debit based on the program ID specified by the transaction's instruction.
-Programs must treat accounts that are not owned by them as credit only.
+Programs must treat accounts that are not owned by them as credit-only.
 
 To identify credit-only accounts by program id would require the account to be
 fetched and loaded from disk.  This operation is expensive, and while it is
@@ -27,9 +27,9 @@ credit-only accounts have the following properties:
 
 * Can be deposited into:  Deposits can be implemented as a simple `atomic_add`.
 
-* credit-only access to user data.
+* credit-only access to account data.
 
-Instructions that debit or modify the credit-only account user data will fail.
+Instructions that debit or modify the credit-only account data will fail.
 
 ## Account Lock Optimizations
 
@@ -47,10 +47,10 @@ An ideal design would cache the credit-only accounts while they are referenced b
 any transaction moving through the runtime, and release the cache when the last
 transaction exits the runtime.
 
-## Credit-only accounts and read-only account userdata
+## Credit-only accounts and read-only account data
 
-Credit-only account userdata can be treated as read-only. Credit-debit
-account userdata is treated as read-write.
+Credit-only account data can be treated as read-only. Credit-debit
+account data is treated as read-write.
 
 ## Transaction changes