diff --git a/supporting-docs/guides/2016-10-18-e2e_implementation.rst b/supporting-docs/guides/2016-10-18-e2e_implementation.rst
index 60a5e15bc..7ea0fd721 100644
--- a/supporting-docs/guides/2016-10-18-e2e_implementation.rst
+++ b/supporting-docs/guides/2016-10-18-e2e_implementation.rst
@@ -12,6 +12,8 @@ support for end-to-end encryption. It is highly recommended that readers
 be familiar with the Matrix protocol and the use of access tokens before
 proceeding.
 
+.. contents::
+
 The libolm library
 ------------------
 
@@ -45,12 +47,11 @@ response; a client is also free to generate its own ``device_id`` or, as
 above, reuse a device, in which case the client should pass the
 ``device_id`` in the request body.
 
-The lifetime of devices and ``access_token``\ s (technically: chains of
-``refresh_token``\ s and ``access_token``\ s), are closely related. In
+The lifetime of devices and ``access_token``\ s are closely related. In
 the simple case where a new device is created each time you log in,
 there is a one-to-one mapping between a ``device_id`` and an
-``access_token`` chain. If a client reuses a ``device_id`` when logging
-in, there will be several ``access_token`` chains associated with a
+``access_token``. If a client reuses a ``device_id`` when logging
+in, there will be several ``access_token``\ s associated with a
 given ``device_id`` - but still, we would expect only one of these to be
 active at once (though we do not currently enforce that in Synapse).
 
@@ -614,8 +615,8 @@ relevant user's devices (using the wildcard ``*`` in place of the
 ``device_id``) via ``PUT
 /_matrix/client/unstable/sendToDevice/m.new_device/<txnId>.``
 
-Handling an m.new_device event
--------------------------------
+Handling an ``m.new_device`` event
+----------------------------------
 
 As with ``m.room_key`` events, these will appear in the ``to_device``
 section of the ``/sync`` response.