diff --git a/69.md b/69.md
index dbc5339a..0dcc798a 100644
--- a/69.md
+++ b/69.md
@@ -1,33 +1,41 @@
 # Poll event
 
+A poll note is a nostr event type (kind 6969) for conducting polls, containing predefined voting options, which users may vote on via zaps.
+
 ## Purpose
 
-- define new standardized event kind for voting polls
+* define new standardized event kind for voting polls
 
-## Poll format
+## Poll format (RFC)
 
-```json
-{
-  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized poll event data>
-  "pubkey": <32-bytes lowercase hex-encoded public key of the poll event creator>,
-  "created_at": <unix timestamp in seconds>,
-  "kind": 6969,
-  "tags": [
-    ["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
-    ["p", <32-bytes hex of the key>, <recommended relay URL>],
-  ],
-  "content": <arbitrary string>,
-  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
-}
-```
+Should a poll be self-contained in a single event (including its voting options) or be a parent event (#0) with separate (but linked) child voting option events (#1, #2, #3, #n), each referencing the parent poll event?
+
+#### Self-contained poll event
+
+* Pros:
+    * likely results in better UX by providing compact, widget-style notes immediately recognizable as unique poll type
+    * promotes more uniform implementation across clients
+* Cons:
+    * increased poll event complexity, owing to internally nested voting options (each necessarily containing their own zap requirements)
+    * potentially increased difficulty of client implementation
+
+#### Single parent poll event with linked child voting option events
+
+* Pros:
+    * better alignment with existing event (specifically zap) structures
+    * potential for backward compatibility with clients uncompliant with polling events, i.e. non-compliant clients could handle poll event chains same as existing threads
+    * possibly simplifies implementation by clients?
+* Cons:
+    * introduces possibility for fragmentation of polls, e.g. separation or loss of child voting options
+    * increased potential for non-uniform implementation of polling UI/UX across clients
   
 ## TODO
 
-- define basic polling features
-- define basic polling format
-- outline polling NIP
-- publish RFC to nostr dev community
-- implement polls in 1 relay
-- implement polls in 2 clients
-- send pull request to nostr-protocol/NIPs
-- merge with nostr-protocol/NIPs
+* define basic polling features
+* define basic polling format
+* outline polling NIP
+* publish RFC to nostr dev community
+* implement polls in 1 relay
+* implement polls in 2 clients
+* send pull request to nostr-protocol/NIPs
+* merge with nostr-protocol/NIPs