diff --git a/diagrams/encoding_commitment.drawio b/diagrams/encoding_commitment.drawio
new file mode 100644
index 0000000..7b146f0
--- /dev/null
+++ b/diagrams/encoding_commitment.drawio
@@ -0,0 +1,351 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index db84053..22e9b42 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -20,6 +20,7 @@
- [Dual Execution with Asymmetric Privacy](./mpc/deap.md)
- [Encryption](./mpc/encryption.md)
- [MAC](./mpc/mac.md)
+- [Commitments](./mpc/commitments.md)
diff --git a/src/diagrams/encoding_commitment.svg b/src/diagrams/encoding_commitment.svg
new file mode 100644
index 0000000..30afda2
--- /dev/null
+++ b/src/diagrams/encoding_commitment.svg
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/src/mpc/commitments.md b/src/mpc/commitments.md
new file mode 100644
index 0000000..b00da99
--- /dev/null
+++ b/src/mpc/commitments.md
@@ -0,0 +1,12 @@
+# Commitments
+
+Here we illustrate the commitment scheme used to create authenticated commitments to the plaintext in scenarios where a general-purpose [`Notary`](/intro.html#tls-verification-with-a-general-purpose-notary) is used. (Note that this scheme is not used when the `Prover` proves directly to the `Verifier`)
+
+A naive approach of extending the [`Encryption and Decryption`](/protocol/mpc-tls/encryption.html) steps to also compute a commitment (e.g. BLAKE3 hash) using MPC is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
+
+The high-level idea is that the `Prover` creates a commitment to the active plaintext encoding from the MPC protocol used for [`Encryption and Decryption`](/protocol/mpc-tls/encryption.html).
+
+We also hide the amount of commitments (to preserve `Prover` privacy) by having the `Prover` commit to the Merkle tree of commitments.
+
+
+
\ No newline at end of file
diff --git a/src/protocol/notarization.md b/src/protocol/notarization.md
index 0d5f9ec..c08f9d0 100644
--- a/src/protocol/notarization.md
+++ b/src/protocol/notarization.md
@@ -1,15 +1,15 @@
# Notarization
-As part of the TLSNotary protocol, the `Prover` can create authenticated commitments to the plaintext and have the `Notary` sign them without ever seeing the plaintext. This offers a way for the `Prover` to selectively prove the authenticity of arbitrary portions of the plaintext to a different `Verifier` later.
+Even though the `Prover` can prove data provenance directly to the `Verifier`, in some scenarios it may be beneficial for the `Verifier` to outsource the verification of the TLS session to a trusted `Notary` as explained [here](/intro.html#tls-verification-with-a-general-purpose-notary).
-A naive approach of creating such authenticated commitments is to extend the `Encryption and Decryption` steps to also compute a commitment (e.g. BLAKE3 hash) to the plaintext using MPC and have the `Notary` sign that commitment. Unfortunately, such an approach is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
+As part of the TLSNotary protocol, the `Prover` creates authenticated commitments to the plaintext and has the `Notary` sign them without the `Notary` ever seeing the plaintext. This offers a way for the `Prover` to selectively prove the authenticity of arbitrary portions of the plaintext to an application-specific `Verifier` later.
-The high-level idea is that the `Prover` creates a commitment to the encodings from the MPC protocol used for `Encryption and Decryption`. Since those encodings are chosen by the `Notary` and are not known to the `Prover` at the time when she makes a commitment, they can be thought of as *"authenticated plaintext"*.
+Please refer to the [Commitments](/mpc/commitments.md) section for low-level details on the commitment scheme.
## Signing the Session Header
The `Notary` signs an artifact known as a `Session Header`, thereby attesting to the authenticity of the plaintext from a TLS session. A `Session Header` contains a `Prover`'s commitment to the plaintext and a `Prover`'s commitment to TLS-specific data which uniquely identifies the server.
-The `Prover` can later use the signed `Session Header` to prove data provenance to a third-party `Verifier`.
+The `Prover` can later use the signed `Session Header` to prove data provenance to an application-specific `Verifier`.
It's important to highlight that throughout the entire TLSNotary protocol, including this signing stage, the `Notary` does not gain knowledge of either the plaintext or the identity of the server with which the `Prover` communicated.