Completed various TODOs.
diff --git a/TODO b/TODO
index 4f1e4c0..8af1502 100644
--- a/TODO
+++ b/TODO
@@ -1,40 +1,25 @@
-- The consumer code needs a much cleaner abstraction
-    In the end, it's two-phase, e.g. receive message, ack message, perhaps we make this a
-    first-class citizen in the API on the consumer side where the consumer calls:
-    Receive() and gets the sequence of the message in question (or a specific value for
-    gating/idling?) and then calls Ack/Confirm etc with the message sequence?
-
 - Wireup DSL
+
 - Rewrite all code test first (including diamond pattern)
+
 - Benchmark code (go test -bench=.) (with GOMAXPROCS=2 if env GOMAXPROCS=1)
+
 - Squeeze little bits of performance here and there by trying a few different things
 	e.g. pointers vs structs, padding, etc.
-- Investigate ways to utilize an int32 under the hood but have it be exposed as an int64?
-   e.g. utilizing two int32s? This would allow us to remove the atomic statements surrounding
-   i386 and ARM architecutes, but may be more effort than it's worth for our particular
-   use case...
-- Understand why "slower" consumer code is faster and more consistent when performing single-item
-	publishes
 
 - Cursors should probably all be created at the same time in wireup to keep them as close together as possible:
   https://news.ycombinator.com/item?id=7800825
 
-- I need to get some help doing some low-level profiling the application to find out where
-  the bottlenecks are and determining how the Go scheduler is hindering performance, if at all.
-
-- More assertive tests on CPU ordering, e.g. claim a slot which has multiple values
-  perform a computation on the sequence in some deterministic way and store each computation
-  as one of the values. Then on the reader side assert that the struct values are correct
-  for that given sequence.
-
 - Integration suite that can exercise the Disruptor code on:
   1. Multiple Go runtime versions, e.g. (1.1, 1.2, 1.3, etc.) (plus point releases and the latest tip)
   2. Multiple CPU architectures: ARM, i386, AMD64
   3. Multiple operation systems: Linux, OSX, Windows, etc.
   Ideally each of the above combinations would be an individual exercise
 
-- contributors
-- license
-- readme (Github markdown?)
+- Contributors
+
+- License
+
+- Readme (Github markdown?)
 
 - Website with cool images and documentation? (e.g. GoConvey)
\ No newline at end of file