diff --git a/MIPS/mip-zkapps.md b/MIPS/mip-zkapps.md
index 3a12e67..91b5330 100644
--- a/MIPS/mip-zkapps.md
+++ b/MIPS/mip-zkapps.md
@@ -441,7 +441,58 @@ blocks. For a failing zkApp, the only affected account is the fee payer.
 
 ### Impact On Other Protocol Components 
 
-**TODO(#17): Impact on Other Components**
+#### Snarked Ledger
+
+A snarked ledger corresponds to the ledger state after all transactions in a
+scan-state tree are fully snarked i.e., the sequence of transactions are
+recursively proven. As the chain progresses and transactions are snarked, there
+is a new snarked ledger everytime a sequence of transactions is fully snarked
+and this state is updated in the protocol state. With the two-pass application
+model there will be two ledger states corresponding to a scan state tree- first
+pass ledger and second pass ledger. When there are transactions from a block
+overflowing to a new scan state tree (as shown below), the second pass ledger of
+the first tree is assumed to be true provided ledger state after applying the
+remainder of the block's transaction in the second tree are true. Due to this
+impending assumption that is validated only in the SNARK proof of the second
+tree, first pass ledger is deemed as fully snarked and used as the snarked
+ledger everywhere else in the protocol.
+
+
+Having first-pass ledger as snarked ledger means that a snarked ledger may
+correspond to a set of transactions that aren't fully applied and/or it may
+include transactions that were applied partially (first-pass) in the previous
+snarked ledger and fully applied (first-pass and second-pass) in the current
+one.
+
+For example, say, transactions `T1`s from a block split across two scan-state trees. `T10` and `T11` from the first tree are applied partially (first pass) to `Tree1`'s snarked ledger. The snarked ledger for `Tree2` will extend `Tree1`'s snarked ledger by applying first pass of `T12`, `T13` and then second pass of `T10`, `T11`, `T12`, and `T13`.
+
+            Tree1                  Tree2
+
+             M4                      M5
+       M0          M1           M2        M3
+    T00   T01  T10   T11    T12   T13  T20   T21
+
+#### Epoch Ledgers
+
+Snarked ledgers are used as epoch ledgers or staking ledgers for vrf
+evaluations. These will now be first-pass ledgers as described
+[above](#snarked-ledger).
+
+#### Bootstrap
+
+The data downloaded during bootstrap will now include the newly added fields to
+the protocol state. To validate the protocol state at the root block (finalized
+as per the consensus constant `k`) by generating staged ledger (second pass
+ledger) from the root's snarked ledger (first pass ledger) will now require
+partially applied transactions from the previous snarked ledger. This can be
+stored as part of the scan state data structure.
+
+#### Persisted transition frontier data
+
+Transition frontier data persisted in the config directory will include newly
+added zkapp transactions in blocks, partially applied transactions from previous
+snarked ledger, and statement of the most recent snarked ledger added to the
+blockchain state.
 
 ### Performance Impact
 
@@ -471,7 +522,15 @@ system in the new one or providing maps from the old to the new.
 
 ### Transaction Replay Attacks
 
-**TODO(#9): Transaction Replay Attacks**
+To prevent replaying zkapp transactions, account updates are successfully
+applied if at least one of the following conditions is true:
+
+1. An account update increments its account's nonce and applies a precondition
+   to constrain the previous nonce to some fixed value
+2. An account uses the full transaction commitment (essentially depending on the
+   fee payer's nonce) and isn't the fee payer themselves
+3. An account update doesn't use a signature at all and therefore allows zkApp
+   applications to specify their own replay protection logic
 
 ### Known DDoS Vulnerability Mitigations