diff --git a/lib/browserid/fake_verification.js b/lib/browserid/fake_verification.js
index 8c7194d2b87af824b2355ceb45248e52c9844ae7..6aa1618872d7b85a90b43da368c3fe6977df4667 100644
--- a/lib/browserid/fake_verification.js
+++ b/lib/browserid/fake_verification.js
@@ -59,7 +59,6 @@ if (!/^test_/.test(c)) {
 exports.addVerificationWSAPI = function(app) {
   app.get('/wsapi/fake_verification', function(req, res) {
     var email = url.parse(req.url, true).query['email'];
-    console.log(email);
     db.verificationSecretForEmail(email, function(secret) {
       if (secret) res.write(secret);
       else res.writeHead(400, {"Content-Type": "text/plain"});
diff --git a/lib/load_gen/signup.js b/lib/load_gen/signup.js
index 12af0e90b1463be074fb6473b9577865bf951508..fc6548d7776d748f424d46365c5c1c78a754c740 100644
--- a/lib/load_gen/signup.js
+++ b/lib/load_gen/signup.js
@@ -46,30 +46,22 @@ exports.startFunc = function(cfg, cb) {
   // A new user signing up for browserid looks like this in terms of
   // network transactions:
   //
-  // 1. RP includes include.js 
+  // 1. RP includes include.js
   // 2. users' browser loads all code associated with dialog
-  // 3. in page javascript calls CSRF to get a CSRF token
+  // 3. in page javascript calls /wsapi/session_context to get a CSRF token
   // 4. /wsapi/have_email is called some number of times to give feedback as the
   //    user types in their email address
   // 5. /wsapi/stage_user is called to stage the user for creation when the
   //    user clicks "continue" after having chosen a password
-  // 6. /wsapi/registration_status is called once for each second it takes the
+  // 6. /wsapi/user_creation_status is called once for each second it takes the
   //    user to go to their email and click on the verification link
   // 6.5. in the load testing environment, we make a call to the server to get
   //    the email verification token
-  // 7. /prove is called on the server, passing in the authentication token
-  // 8. /manage is called on the server as the user's page transitions from
-  //    the verify screen to the manage screen.
-  // 9. /wsapi/sync_emails is called from the client (XXX: this is probably a bug,
-  //    there's no utility to this)
-  // 10. /wsapi/set_key is called from the client to inform the server of the
-  //    user's public key (XXX: this will go away when we migrate to certificates
-  //    and instead, the server will be asked to sign the user's public key.)
-  // 11.  the RP will call /verify to verify a generated assertion
-
-  // XXX: for now this is *api only*,  that is we omit steps above that would just be
-  // the serving of static pages.  it is unknown to me whether static page simulation
-  // is useful.
+  // 7. /wsapi/email_for_token is called (by the landing page)
+  // 8. /wsapi/session_context is called again (by the landing page)
+  // 9. /wsapi/complete_user_creation is called (by the landing page)
+  // 10. /wsapi/cert_key is called by the dialog
+  // 11. /verify is invoked
 
   // get a user
   var user = userdb.getNewUser();