diff --git a/proposals/1543-qr_code_key_verification.md b/proposals/1543-qr_code_key_verification.md
index bce5c0a4..690323f6 100644
--- a/proposals/1543-qr_code_key_verification.md
+++ b/proposals/1543-qr_code_key_verification.md
@@ -170,11 +170,6 @@ This proposal defines three verification methods that can be used in
 
 ### QR code format
 
-Note: only one of the following will be supported.  They are all being
-documented here while we determine how well different formats are supported.
-
-#### Binary format
-
 The QR codes to be displayed and scanned using this format will encode binary
 strings in the general form:
 
@@ -221,79 +216,6 @@ Bob's cross-signing key is `1011121314151617...` (which is "EBESExQVFh..." in
 base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
 base64).
 
-#### Base32 format
-
-The QR codes to be displayed and scanned using this format will encode alphanumeric
-strings generated as follows:
-
-1. generate a binary string by concatenating:
-  - the event ID or `transaction_id` of the associated verification
-    request event, encoded as:
-    - two bytes in network byte order (big-endian) indicating the length in
-      bytes of the ID as a UTF-8 string
-    - the ID as a UTF-8 string
-  - the first key, as 32 bytes.  The key to use depends on the mode field as
-    described in step 3:
-    - if "0" or "1", then the user's own master cross-signing public key
-    - if "2", then the current device's device key
-  - the second key, as 32 bytes.  The key to use depends on the mode field:
-    - if "0", then what the device thinks the other user's master
-      cross-signing key is
-    - if "1", then what the device thinks the other device's device key is
-    - if "2", then what the device thinks the user's master cross-signing key
-      is
-  - a random shared secret, as a byte string.  It is suggested to use a secret
-    that is about 8 bytes long.  Note: as we do not share the length of the
-    secret, and it is not a fixed size, clients will just use the remainder of
-    binary string as the shared secret.
-2. encode the above string using unpadded base32 as defined in RFC4648
-3. prepend the resulting string with
-   - the string "MATRIX"
-   - one character indicating the version (must by "2")
-   - one character indicating the QR code verification mode.  May be one of the
-     following values:
-     - "0" verifying another user with cross-signing
-     - "1" self-verifying in which the current device does trust the master key
-     - "2" self-verifying in which the current device does not yet trust the
-           master key
-
-The QR code is then generated using alphanumeric encoding mode.
-
-#### Base64 format
-
-The QR codes to be displayed and scanned using this format will be a string of
-the following form:
-
-- the string "MATRIX"
-- one character indicating the version (must by "2")
-- one character indicating the QR code verification mode.  May be one of the
-  following values:
-  - "0" verifying another user with cross-signing
-  - "1" self-verifying in which the current device does trust the master key
-  - "2" self-verifying in which the current device does not yet trust the
-    master key
-- the event ID or `transaction_id` of the associated verification
-  request event, encoded as:
-  - two bytes in network byte order (big-endian), encoded in unpadded base64 (3
-    characters), indicating the length in bytes of the ID as a UTF-8 string
-  - the ID as a UTF-8 string
-- the first key as unpadded base64 (43 characters).  The key to use depends on
-  the mode field:
-  - if "0" or "1", then the user's own master cross-signing public key
-  - if "2", then the current device's device key
-- the second key as unpadded base64 (43 characters).  The key to use depends on
-  the mode field:
-  - if "0", then what the device thinks the other user's master
-    cross-signing key is
-  - if "1", then what the device thinks the other device's device key is
-  - if "2", then what the device thinks the user's master cross-signing key
-    is
-- a random shared secret, as an ASCII string.  It is suggested to use a secret
-  that is about 11 bytes long.  (This is approximately the length of 8 bytes as
-  a base64 string.)  Note: as we do not share the length of the secret, and it
-  is not a fixed size, clients will just use the remainder of binary string as
-  the shared secret.
-
 ### Message types
 
 #### `m.key.verification.start`