diff --git a/book/src/frost.md b/book/src/frost.md
index dd7591ee..dbdbb4f7 100644
--- a/book/src/frost.md
+++ b/book/src/frost.md
@@ -83,6 +83,16 @@ is still free to start the process with only 2 participants if they wish.
 Signature verification is carried out as normal with single-party signatures,
 along with the signed message and the group verifying key as inputs.
 
+## Refreshing
+
+Refreshing shares starts with a Trusted Dealer who calculated a zero key to
+send to each participant who can then refresh their shares and create a new
+key package.
+
+```admonish note
+This is also possible via Distributed Key Generation but this has not yet been
+implemented.
+```
 
 ## Ciphersuites
 
diff --git a/book/src/tutorial/refreshing.png b/book/src/tutorial/refreshing.png
new file mode 100644
index 00000000..e69de29b
diff --git a/book/src/tutorial/refreshing_shares.md b/book/src/tutorial/refreshing_shares.md
new file mode 100644
index 00000000..cf898b83
--- /dev/null
+++ b/book/src/tutorial/refreshing_shares.md
@@ -0,0 +1,28 @@
+# Refreshing Shares using a Trusted Dealer
+
+The diagram below shows the refresh share process. Dashed lines
+represent data being sent through an [authenticated and confidential communication
+channel](https://frost.zfnd.org/terminology.html#peer-to-peer-channel).
+
+<!-- ![Diagram of Refreshing shares, illustrating what is explained in the text](refreshing.png) -->
+
+The Trusted Dealer needs to first run `calculate_zero_key` where the new SecretShares are generated and then verified.
+This is done with
+[`KeyPackage::try_from()`](https://docs.rs/frost-core/latest/frost_core/frost/keys/struct.KeyPackage.html#method.try_from):
+`caluclate_zero_key` returns a new SecretShare and PublicKeyPackage
+Each new `SecretShare` and `PublicKeyPackage` must then be sent via an [**authenticated** and
+**confidential** channel
+](https://frost.zfnd.org/terminology.html#peer-to-peer-channel) for each
+participant, who must verify the package to obtain a `KeyPackage` which contains
+their signing share, verifying share and group verifying key. 
+
+Each Participant then runs `refresh_share` to generate a new `KeyPackage`.
+
+```admonish danger
+The refreshed `KeyPackage` contents must be stored securely and the original 
+`KeyPackage` should be deleted. For example:
+
+- Make sure other users in the system can't read it;
+- If possible, use the OS secure storage such that the package
+  contents can only be opened with the user's password or biometrics.
+```