diff --git a/onepw-protocol.md b/onepw-protocol.md
index ef74b2d..08eee4c 100644
--- a/onepw-protocol.md
+++ b/onepw-protocol.md
@@ -56,7 +56,7 @@ This protocol starts by feeding the password and email address into 1000 rounds
 
 The server uses the email address to look up the database row, extracts authSalt, performs the same stretching as during account creation to obtain "bigStretchedPW" and then "verifyHash", then compares verifyHash against the stored value. If they match, the client has proved knowledge of the password, and the server creates a new session. The server returns the newly-generated sessionToken to the client, along with its account identifier (uid).
 
-In the future, the `/auth/password` endpoint may also accept two-factor authentication data. If so, it is likely to return a "2FA-required" error to the first request, with information on what additional UI should be displayed to solicit the additional data.
+In the future, the `/auth/password` endpoint may also accept two-factor authentication data. If so, it is likely to return a "2FA-required" error to the first request, with information on what additional UI should be displayed to solicit the additional data. The response should also indicate an "account mode", with a known string for this first (one-password) mode. When we add the two-password mode (described below), any account which has been moved to the new mode will return a different string, and then older clients (who don't understand the new mode) should display an error to the user prompting them to use a newer version of the client.
 
 The `/auth/password` call should also include information about the client device, such as a host name, profile name, model number, etc. This will be used to describe the session to the user later, when they enumerate their active sessions (for review and possible revocation).
 
@@ -181,7 +181,7 @@ The device submits `authPW` to the `/account/destroy` endpoint. This request con
   * creates a user account
 * GET /account/devices {sessionToken} () -> list of devices
 * GET /account/keys {keyFetchToken,needs-verf} () -> kA/wrap(kB)
-  * single-use, only if email is verified
+  * single-use, only if email is verified, encrypted results
 * POST /account/reset {accountResetToken} (newAuthPW) -> ok
   * single-use, does not require email to be verified, revoke all tokens for account, send notification email to user
 * POST /account/delete (authPW) -> ok, account deleted
@@ -317,6 +317,26 @@ If an account is configured for a second password, the `/auth/password?service=s
 
 Use of a second password will restore all the security properties of the original protocol: only the scrypt-helper gets the "easy" brute-force attack, and the only "hard" brute-force attacks are available to a malicious active server or a TLS-level eavesdropper on the create-account and forgot-password flows. kA is protected from all eavesdroppers.
 
+# delta from old SRP protocol
+
+The following endpoints are added:
+
+* POST /auth/password
+* POST /password/change/finish
+
+these are removed:
+
+* POST /auth/start
+* POST /auth/finish
+* POST /session/create (since sessionToken comes from /auth/password)
+
+and these endpoints are modified:
+
+* POST /account/create (gets authPW instead of srpV/srpSalt)
+* POST /account/reset (gets authPW instead of wrapKB/srpV/srpSalt, parameters are not encrypted)
+* POST /account/delete (gets authPW instead of HAWK-with-authtoken)
+* POST /password/change/start (gets old/new authPW, not authToken, returns passwordChangeToken instead of accountResetToken, returns old/new stretchWrap)
+
 # Glossary
 
 This defines some of the jargon we've developed for this protocol.