diff --git a/protocols/BTP.md b/protocols/BTP.md
index a8832ed02f1d6779b68263633607a7f4a6c27228..5892c20593bd5fdf977a9ec0649b423cac297f0b 100644
--- a/protocols/BTP.md
+++ b/protocols/BTP.md
@@ -4,7 +4,7 @@
 
 Bramble Transport Protocol (BTP) is a transport layer security protocol suitable for delay-tolerant networks. It provides a secure channel between two peers, ensuring the confidentiality, integrity, authenticity and forward secrecy of their communication across a wide range of underlying transports.
 
-BTP's main components are a time-based key management protocol and a wire protocol for securely transporting streams of data.
+BTP's main components are a time-based key management protocol and a wire protocol for securely carrying streams of data.
 
 BTP can operate over any transport that can deliver a stream of bytes from one device to another on a best-effort basis, meaning that streams may be delayed, lost, reordered or duplicated. The underlying transport is not required to provide any security properties.
 
@@ -36,7 +36,7 @@ BTP is unusual in that it provides forward secrecy even for transports where one
 
 -   **Confidentiality**
 
-    The adversary should not be able to learn what data is being transported by the protocol.
+    The adversary should not be able to learn what data is being carried by the protocol.
 
 -   **Integrity**
 
@@ -48,7 +48,7 @@ BTP is unusual in that it provides forward secrecy even for transports where one
 
 -   **Forward Secrecy**
 
-    The adversary should not be able to learn what data was transported by the protocol if, at some later time, the adversary compromises one or both of the peer devices.
+    The adversary should not be able to learn what data was carried by the protocol if, at some later time, the adversary compromises one or both of the peer devices.
 
 The protocol is not required to conceal the identities of the communicating parties or the fact that they are communicating.
 
@@ -128,13 +128,13 @@ BTP uses a time-based key management protocol to derive a series of **temporary
 
 BTP has two key management modes, which are suitable for different purposes.
 
-**Dynamic mode** provides forward secrecy for the data being transported, but requires the peers to delete the root key, and any information that could be used to re-derive it, before the temporary keys are used. Dynamic mode requires the peers to agree on a timestamp, **T**, which must be in the past according to both peers' clocks.
+**Rotation mode** provides forward secrecy for the data being carried, but requires the peers to delete the root key, and any information that could be used to re-derive it, before the temporary keys are used. As well as the root key, rotation mode requires the peers to agree on a timestamp, **T**, which must be in the past according to both peers' clocks.
 
-**Static mode** does not provide forward secrecy for the data being transported, but allows the peers to retain the root key or information that could be used to re-derive it. Static mode does not require a timestamp.
+**Handshake mode** does not provide forward secrecy for the data being carried, but allows the peers to retain the root key or information that could be used to re-derive it. Handshake mode does not require a timestamp.
 
-These modes are intended to be complementary. Static mode can be used to bootstrap dynamic mode by transporting the messages of a key agreement protocol that establishes a root key and timestamp for dynamic mode.
+These modes are intended to be complementary. Handshake mode can be used to bootstrap rotation mode by carrying the messages of a key agreement protocol that establishes a root key and timestamp for rotation mode.
 
-The establishment of root keys and timestamps is not handled by BTP itself. BTP is designed to be used with a separate key agreement protocol that securely establishes the initial state.
+The establishment of root keys and timestamps is not handled by BTP itself. BTP is designed to be used with a separate key agreement protocol that securely establishes the initial state. A key agreement protocol for rotation mode must use ephemeral keys, or a combination of static and ephemeral keys, such that the root key cannot be re-derived from information retained by the peers. A key agreement protocol for handshake mode may use static keys, as it is not necessary to prevent the root key from being re-derived.
 
 ### 2.2 Key Derivation Function
 
@@ -150,9 +150,9 @@ The length of each period is D + L seconds, where D is the maximum expected diff
 
 This ensures that if the sender starts sending a stream in period P0 according to the sender's clock, and if D and L are not exceeded, then the recipient will start receiving the stream in period P1 according to the recipient's clock, where abs(P1 - P0) <= 1. In other words, the recipient only needs to retain the temporary keys for the previous, current and next periods.
 
-### 2.4 Key Derivation for Dynamic Mode
+### 2.4 Key Derivation for Rotation Mode
 
-In dynamic mode, BTP achieves forward secrecy by periodically rotating and deleting the temporary keys. The key derivation function is deterministic, so peers that start from the same root key and timestamp will derive the same temporary keys for each time period. Forward secrecy relies on the one-way nature of the key derivation function: the keys of an earlier period cannot be re-derived from those of a later period.
+In rotation mode, BTP achieves forward secrecy by periodically rotating and deleting the temporary keys. The key derivation function is deterministic, so peers that start from the same root key and timestamp will derive the same temporary keys for each time period. Forward secrecy relies on the one-way nature of the key derivation function: the keys of an earlier period cannot be re-derived from those of a later period.
 
 ##### Initial Keys
 
@@ -162,7 +162,7 @@ For each transport, each peer derives four initial keys from the root key. Alice
 
 - outgoing\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_TAG\_KEY", transport\_id)
 
-- outgoing\_header\_key := KDF(root\_key, "org.briarproject.bramble.transports/ALICE\_HEADER\_KEY", transport\_id)
+- outgoing\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_HEADER\_KEY", transport\_id)
 
 - incoming\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_TAG\_KEY", transport\_id)
 
@@ -200,29 +200,29 @@ The temporary keys for each time period P are derived from the previous period's
 
 To ensure forward secrecy, keys must be deleted when they are no longer needed. The outgoing keys for period P must be deleted at the end of period P, while the incoming keys for period P must be deleted at the end of period P + 1.
 
-### 2.5 Key Derivation for Static Mode
+### 2.5 Key Derivation for Handshake Mode
 
-In static mode, BTP does not provide forward secrecy. The temporary keys for any period can be derived from the root key, which is retained by the peers.
+In handshake mode, BTP does not provide forward secrecy. The temporary keys for any period can be derived from the root key, which is retained by the peers.
 
 Alice derives her temporary keys for each time period P as follows:
 
-- outgoing\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_STATIC\_TAG\_KEY", transport\_id, int\_64(P))
+- outgoing\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_HANDSHAKE\_TAG\_KEY", transport\_id, int\_64(P))
 
-- outgoing\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_STATIC\_HEADER\_KEY", transport\_id, int\_64(P))
+- outgoing\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_HANDSHAKE\_HEADER\_KEY", transport\_id, int\_64(P))
 
-- incoming\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_STATIC\_TAG\_KEY", transport\_id, int\_64(P))
+- incoming\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_HANDSHAKE\_TAG\_KEY", transport\_id, int\_64(P))
 
-- incoming\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_STATIC\_HEADER\_KEY", transport\_id, int\_64(P))
+- incoming\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_HANDSHAKE\_HEADER\_KEY", transport\_id, int\_64(P))
 
 Bob derives his temporary keys as follows:
 
-- outgoing\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_STATIC\_TAG\_KEY", transport\_id, int\_64(P))
+- outgoing\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_HANDSHAKE\_TAG\_KEY", transport\_id, int\_64(P))
 
-- outgoing\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_STATIC\_HEADER\_KEY", transport\_id, int\_64(P))
+- outgoing\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/BOB\_HANDSHAKE\_HEADER\_KEY", transport\_id, int\_64(P))
 
-- incoming\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_STATIC\_TAG\_KEY", transport\_id, int\_64(P))
+- incoming\_tag\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_HANDSHAKE\_TAG\_KEY", transport\_id, int\_64(P))
 
-- incoming\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_STATIC\_HEADER\_KEY", transport\_id, int\_64(P))
+- incoming\_header\_key := KDF(root\_key, "org.briarproject.bramble.transport/ALICE\_HANDSHAKE\_HEADER\_KEY", transport\_id, int\_64(P))
 
 Thus Alice's outgoing keys for each transport are the same as Bob's incoming keys, and vice versa.