diff --git a/01.md b/01.md
index d32903b9..003c0ca1 100644
--- a/01.md
+++ b/01.md
@@ -16,7 +16,7 @@ The only object type that exists is the `event`, which has the following format
 
 ```json
 {
-  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
+  "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": <integer>,
diff --git a/69.md b/69.md
index e66c7832..6ddfe0f1 100644
--- a/69.md
+++ b/69.md
@@ -1,5 +1,7 @@
 # Poll event
 
+`draft` `optional` `author:toadlyBroodle`
+
 A poll note is a [nostr event](01.md) (kind `6969`) for conducting paid polls. A poll presents two or more voting options, which participants my vote on by sending regular [zap events](57.md) which include an additional `poll_option` vote tag. Poll results may be blinded, until after users have voted. Polls may specify a `closed_at` time, after which results should be unblinded, closed to new votes, and the tally considered final. Poll options may be tallied by either satoshi `value` or vote `count`. Polls may additionally specify a `consensus_threshold`.
 
 ## Purpose
@@ -15,12 +17,12 @@ A poll event:
 * MUST specify a primary `tally_method`: either `value` OR `count`
 * SHOULD specify a `closed_at` time:
   * a `closed_at` value of less than or equal to the `created_at` field indicates a poll SHOULD NOT be closed.
-* MAY include a `consensus_threshold` integar (0-100), representing a percentage threshold for any single vote option to achieve poll consensus
+* MAY include a `consensus_threshold` (0-100), representing a percentage threshold for any single vote option to achieve poll consensus
   * a `consensus_threshold` of '0' indicates no threshold is specified.
 
 ```json
 {
-  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
+  "id": <32-bytes lowercase hex-encoded sha256 of the serialized event data>
   "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": 6969,
@@ -39,12 +41,11 @@ A poll event:
 
 ## Zap vote format
 
-Poll options are voted on by sending [zap events](57.md) (to the original poll event) which include 1 additional `poll_option` tag within their otherwise standard [json structure](57.md#the-zap-note). 
+Poll options are voted on by sending [zap events](57.md) (to the original poll event) which include 1 additional `poll_option` tag in the zap request event. 
 
-Zap vote events (kind `9734` and `9735`): 
+The zap request event (kind `9734`): 
 * MUST include exactly 1 `poll_option` tag
-* MUST reference the vote option by its corresponding integar `n`, chosen from the original poll event's list of predefined `polling_options`
-* MUST transmit the exact `poll_option` between kind `9734` and `9735`
+* MUST reference the vote option by its corresponding integer `n`, chosen from the original poll event's list of predefined `polling_options`
 
 ```json
 "tags": [
@@ -70,8 +71,8 @@ A tallying client:
   * MUST NOT count votes from anonymous users
   * MUST treat the vote option with the most unique votes as the winning option
 * when a `closed_at` time is specified, clients:
-  * MUST NOT include late votes recieved after `closed_at` time
-  * SHOULD publicly blind results until after a user's vote has been recieved
+  * MUST NOT include late votes received after `closed_at` time
+  * SHOULD publicly blind results until after a user's vote has been received
   * SHOULD publicly display results after the `closed_at` time has passed
 * when a `closed_at` time is NOT specified (is less than or equal to `created_at`), clients:
   *  SHOULD include all votes in tallies
@@ -83,12 +84,11 @@ After the above rules are applied and clearly rendered, a tallying client:
   * MUST indicate the state of consensus by displaying its value relative to the final percentage of the winning vote
 * MAY display the secondary tally method result, for statistical purposes, along with other associated poll metrics and comments
 
-Strict adherence to these requirements should enable a standardized means of quantitatively assessing the distribution of opinion regarding a poll's content amongst poll participants, determining a winning outcome, and possibly acheiving consensus. However, until this protocol is further tested, refined, and proven robust, polls should probably not be considered authoritative nor binding.
+Strict adherence to these requirements should enable a standardized means of quantitatively assessing the distribution of opinion regarding a poll's content amongst poll participants, determining a winning outcome, and possibly achieving consensus. However, until this protocol is further tested, refined, and proven robust, polls should probably not be considered authoritative nor binding.
 
 ## TODO
 
-* refine standardized polling formats based on dev feedback
-* send pull request (RFC) to nostr-protocol/NIPs
+* refine NIP#69 based RFC feedback
 * implement polls in 1 relay
 * implement polls in 2 clients
 * merge with nostr-protocol/NIPs