diff --git a/TODO.md b/TODO.md
index ed1b649..938b509 100644
--- a/TODO.md
+++ b/TODO.md
@@ -4,11 +4,31 @@
 It's not out yet, and not everything has a beta release yet, but we should continue tracking the
 status of 4.0 and update our libraries as we can.
 
+## Sled 1.0
+As of the time of writing, the official Sled 1.0 release date is in two days. I'm not sure how much
+the API will change, but I can assume there will be changes around flushing and transactions, as
+those have been the subjects of recent PRs against Sled. Most of the other PRs against Sled in the
+last month or so have been about reducing memory usage by employing a variety of fancy techniques
+backed by whitepapers.
+
 ## Async
 A lot of logic in the Profiles and Submissions modules synchronously accesses Sled, which is an
 issue because Sled is potentially blocking. All of the Big Dangers (transactions) are safely on a
 threadpool already, but a couple iterations are currently occuring directly on the Arbiters.
 
+## Thread-safety
+A lot of cloning of tree stores is done because the State object itself isn't Send or Sync, which is
+caused by it containing an Actix Web Client. This could easily be changed by just putting the Client
+into it's own `.data` on the Application, and then State could be passed around between threads in
+it's own `Arc`. This would probably marginally improve performance, since we'd not be `Clone`ing an
+imperial tonne of sled Trees every time we wanted to do something on a threadpool. It would also
+eliminate the need to separate the `State` type and the `Context` type in hyaenidae-profiles, and we
+could get rid of that distinction.
+
+It would also mean we could construct the state Just Once :tm: and pass it or clone it around to
+each thread that needs it, rather than instantiating the state uniquely for each thread. This would
+give us the benefit of not panicking in the background jobs constructor.
+
 ## Organization
 A lot of modules in hyaenidae-server have circular dependencies, and a few are more than a thousand
 lines long, each. These should be separated where possible into smaller modules which create a