diff --git a/xmtp_mls/IDENTITY.md b/xmtp_mls/IDENTITY.md
index 0ef2f23e7..d57ba4901 100644
--- a/xmtp_mls/IDENTITY.md
+++ b/xmtp_mls/IDENTITY.md
@@ -83,6 +83,7 @@ In XMTP there is no need for a centralized authentication service to validate cr
 
 Credential validation must be performed by clients at the [events described by the MLS spec](https://www.rfc-editor.org/rfc/rfc9420.html#name-credential-validation) as follows:
 
+1. Verify that the referenced `installation_public_key` has not been revoked (see [Installation revocation](#installation-revocation))
 1. Verify that the referenced `installation_public_key` matches the `signature_key` of the leaf node.
 1. Derive the association text using the `association_text_version`, `creation_iso8601_time`, `installation_public_key`, with a label of `Grant Messaging Access`.
 1. Recover the wallet public key from the recoverable ECDSA `signature` on the association text.
@@ -115,16 +116,19 @@ Users may revoke an installation as follows:
    ```
 
 1. The app publishes the revocation to the server. The server will provide all identity updates (registrations and revocations) for a given wallet address to any client that requests it.
+1. The installation performing the revocation enumerates all known groups that it is a member of, and submits proposals to remove the revoked installation. Additional removals may also occur via the process described in [Installation synchronization](#installation-synchronization).
 
-Validation of revocations is identical to the process described in [Credential Validation](#credential-validation), except that a label of `Revoke Messaging Access` is used.
+Validation of revocation payloads is identical to the process described in [Credential Validation](#credential-validation), except that a label of `Revoke Messaging Access` is used.
 
 Once an installation is revoked, it cannot be re-registered or re-provisioned. The time displayed on the revocation is for informational purposes only.
 
+Revocations may not apply immediately on all groups. In order to ensure transcript consistency, payloads from revoked installations are considered valid if they were published before the installation was removed from the group.
+
 ### Installation synchronization
 
 At any time in the course of a conversation, the list of valid installations for the participating wallet addresses may change via registration or revocation.
 
-Clients must perform the following validation prior to publishing each payload on the group:
+Clients must perform the following validation prior to publishing each payload on the group, as well as periodically:
 
 1. Assemble a list of wallet addresses in the conversation from the leaf nodes.
 1. Fetch all identity updates on those wallet addresses.
@@ -134,10 +138,6 @@ Clients must perform the following validation prior to publishing each payload o
 
 XMTP clients may perform performance optimizations, such as caching installation lists with a short TTL.
 
-To support revocations (Q2+ 2024), clients must additionally perform the following validation on receiving each payload in the group:
-
-1. Query the server for identity updates on the sending wallet address and verify that the sending installation has not been revoked.
-
 An open area of investigation is ensuring transcript consistency in the face of revoked clients. If the server can maintain a strict ordering between revocations and payloads in the conversation (especially commits performed by the revoked clients), then all participants can achieve consensus on whether a payload from the revoked client should be applied or not.
 
 ### Server trust