diff --git a/book/src/dev/rfcs/0009-zebra-client.md b/book/src/dev/rfcs/0009-zebra-client.md
index f157ad351..4583a8631 100644
--- a/book/src/dev/rfcs/0009-zebra-client.md
+++ b/book/src/dev/rfcs/0009-zebra-client.md
@@ -201,6 +201,8 @@ Support for sending tx's via _non-privileged_ RPC endpoints, or via Stolon:
 - zebra-cli talks to the subcomponent running in zebrad
     - (can use servo/bincode to communicate with zebrad)
     - via the privileged (and possibly the unprivileged) RPC endpoints
+    - can use [cap-std](https://blog.sunfishcode.online/introducing-cap-std/)
+      to restrict filesystem and network access for zebra-client
 
 ## Task isolation in Tokio
 - TODO: fill in
@@ -296,6 +298,9 @@ Supporting a wallet assumes risk.  Effort required to implement wallet functiona
 # Future possibilities
 [future-possibilities]: #future-possibilities
 
+- [BlazeSync algorithm](https://forum.zcashcommunity.com/t/zecwallets-blazesync-sync-entire-chain-in-60s/39447)
+  for fast syncing, like Zecwallet
+
 - mandatory sweeps for legacy keys
     - blazingly fast wallet startup, to match `zebrad`'s blazingly fast sync
     - generate unified address from a new seed phrase (or one provided by the user)
@@ -313,6 +318,8 @@ Supporting a wallet assumes risk.  Effort required to implement wallet functiona
 - split `Client` component into subprocess
     - this helps somewhat but the benefit is reduced by our prexisting memory safety, thanks to Rust
     - not meaningful without other isolation (need to restrict `zebrad` from accessing viewing keys on disk, etc)
+    - could use [cap-std](https://blog.sunfishcode.online/introducing-cap-std/)
+      to restrict filesystem and network access for zebra-client
     - instead of process isolation, maybe you actually want the Light Client
 Protocol, or something similar?