diff --git a/protocol/protocol.tex b/protocol/protocol.tex
index dfae8773..3922e5c4 100644
--- a/protocol/protocol.tex
+++ b/protocol/protocol.tex
@@ -719,6 +719,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\TAZ}{\termbf{TAZ}}
 \newcommand{\zatoshi}{\term{zatoshi}}
 \newcommand{\zcashd}{\termsf{zcashd}}
+\newcommand{\zebra}{\termsf{zebra}}
 \newcommand{\Makefile}{\texttt{Makefile}\xspace}
 
 \newcommand{\MUST}{\conformance{MUST}}
@@ -959,6 +960,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
 \newcommand{\networks}{\terms{network}}
 \newcommand{\Mainnet}{\term{Mainnet}}
 \newcommand{\Testnet}{\term{Testnet}}
+\newcommand{\settled}{\term{settled}}
 \newcommand{\rpcByteOrder}{\term{RPC byte order}}
 \newcommand{\anchor}{\term{anchor}}
 \newcommand{\anchors}{\terms{anchor}}
@@ -3327,12 +3329,28 @@ absent future consensus changes.}
 In order to choose the \defining{\bestValidBlockChain} in its view of the
 overall \block tree, a node sums the work, as defined in \crossref{workdef}, of
 all \blocks in each \validBlockChain, and considers the \validBlockChain with greatest
-total work to be best. To break ties between leaf \blocks, a node will prefer the
-\block that it received first.
+total work to be best. To break ties between leaf \blocks, a node will prefer the \block
+that it received first.
 
-The consensus protocol is designed to ensure that for any given \blockHeight,
-the vast majority of nodes should eventually agree on their \bestValidBlockChain
-up to that height.
+The consensus protocol is designed to ensure that for any given \blockHeight, the vast
+majority of well-connected nodes should eventually agree on their \bestValidBlockChain
+up to that height. A \fullValidator\footnote{There is reason to follow the requirements
+in this section also for non-full validators, but those are outside the scope of this
+protocol specification.} \SHOULD attempt to obtain candidate \blocks from multiple
+sources in order to increase the likelihood that it will find a \validBlockChain that
+reflects a recent consensus state.
+
+A \networkUpgrade is \defining{\settled} on a given \network when there is a social
+consensus that it has activated with a given \activationBlock hash. A \fullValidator
+that potentially risks \Mainnet funds or displays \Mainnet \transaction information
+to a user \MUST do so only for a \blockChain that includes the \activationBlock of
+the most recent \settled \networkUpgrade, with the corresponding \activationBlock hash.
+Currently, there is social consensus that \Canopy has activated on the \Zcash \Mainnet
+and \Testnet with the \activationBlock hashes given in \crossref{networks}.
+
+A \fullValidator \MAY impose a limit on the number of \blocks it will ``roll back'' when
+switching from one \bestValidBlockChain to another that is not a descendent. For \zcashd
+and \zebra this limit is $100$ \blocks.
 
 
 \vspace{-1ex}
@@ -11250,9 +11268,13 @@ generation \cite[Theorem 4.10]{BGG2017}.
 }
 
 \saplingonward{An implementation of \Zcash that checkpoints on a \block after \Sapling
-\MAY choose to skip verification of \BCTV proofs. In this case, the implementation \MUST
-only accept \blocks that are descendants of the known \Sapling \activationBlock on
-the appropriate \network.}
+\MAY choose to skip verification of \BCTV proofs. Note that in \crossref{blockchain},
+there is a requirement that a \fullValidator that potentially risks \Mainnet funds
+or displays \Mainnet \transaction information to a user \MUST do so only for a
+\blockChain that includes the \activationBlock of the most recent \settled
+\networkUpgrade, with its known \blockHash as specified in \crossref{networks}.
+Since the most recent \settled \networkUpgrade is after the \Sapling \networkUpgrade,
+this mitigates the potential risks due to skipping \BCTV proof verification.}
 
 \introlist
 \lsubsubsubsubsection{Encoding of \BCTVText{} Proofs}{bctvencoding}
@@ -14557,6 +14579,18 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
 \lsection{Change History}{changehistory}
 
 
+\historyentry{2022.3.0}{}
+\begin{itemize}
+    \item In \crossref{blockchain}, define what a \settled \networkUpgrade is,
+          specify requirements for checkpointing, and allow nodes to impose
+          a limitation on rollback depth.
+\sapling{
+    \item In \crossref{bctv}, note that the above checkpointing requirement
+          mitigates the risks of not performing \BCTV \zkProof verification.
+} %sapling
+\end{itemize}
+
+
 \historyentry{2022.2.19}{2022-01-19}
 \begin{itemize}
 \nufive{