diff --git a/2-keypair.typ b/2-keypair.typ
--- a/2-keypair.typ
+++ b/2-keypair.typ
@@ -11,22 +11,22 @@
 capability signatures in section 3.1.
 
 
-They keys are represented as follows:
+The keys are represented as follows:
 
 ```rust
 struct Key {
-    key: [u8; MAX_KEY_SIZE],
-    len: u64,
-    scheme: SigningScheme,
+    buf: [u8; MAX_KEY_SIZE], /// Buffer storing the bytes of keys.
+    len: u64,                /// The length of key in bytes.
+    scheme: SigningScheme,   /// Enum marking what scheme the key is.
 }
 ```
 Since the underlying data is just a byte array, the keys themselves are
 scheme-agnostic, enabling support for multiple cryptograhic schemes, as
-described in @twizzler. This also makes backward compatibility trivial when
-adding new signing schemes.The keys are stored inside of objects, allowing for
-persistent or volatile storage depending on object specification, and allows for
-keys themselves to be treated as any other object and have security policy
-applied to them.
+described in the Twizzler security paper @twizzler. The enum also makes backward
+compatibility trivial when adding new signing schemes. The keys are stored inside
+of objects, allowing for persistent or volatile storage depending on object
+specification, and allows for keys themselves to be treated as any other object
+and have security policy applied to them.
 
 == Abstraction
 Currently we use the Elliptic Curve Digital Signature Algorithm (ECDSA) @ecdsa
@@ -35,8 +35,8 @@
 represented as bytes.
 
 An existing drawback for backward compatibility is the maximum size
-of the buffer we store the key in. Currently we set the maximum size as 256
-bytes, meaning if a future cryptographic signing scheme was to be created with
+of the buffer we store the key in. Currently the maximum size as 256
+bytes, meaning if a future cryptographic signing scheme was to be added with
 a key size larger than 256 bytes, we would have to drop backwards
 compatibility. While this can be prevented now by setting the maximum size to
 something larger, it ends up being tradeoff between possible cryptographic schemes
@@ -45,16 +45,15 @@
 == Compartmentalization
 // how they can be used to sign multiple objects (compartmentalization)
 
-To create an object in twizzler, you specify the ID of a verifying key
-object so the kernel knows which key to use to verify any
-capabilities permitting access to the object. Since keys are represented as objects
-in twizzler, security policy applies on them as well, creating satisfying
-solutions in regards to key management.
+To create an object in Twizzler, you specify the ID of a verifying key object so
+the kernel knows which key to use to verify any capabilities permitting access
+to the object. Since keys are represented as objects, security policy applies on
+them as well, creating satisfying solutions in regards to key management.
 
-Suppose for instance we have Alice on Twizzler, and all users on Twizzler have
-a "user-root" keypair that allows for them to create an arbitrary number of
+Suppose for instance we have Alice on Twizzler, and all users have
+a "user-root" keypair that allows them to create an arbitrary number of
 objects. Also suppose that access to this user-root keypair is protected by
-some login program, where only alice can log in. This means that Alice
+some login program, where only Alice can log in. This means that Alice
 can create new keypair objects from her user-root keypair. Since all
 *her* new keypairs originate from *her* original user-root keypair, only *she* can
 access the keys required to create new signatures allowing permissions into
diff --git a/thesis.pdf b/thesis.pdf
--- a/thesis.pdf
+++ b/thesis.pdf