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. Polls may include multiple recipients which participants may choose from when zapping their votes. Poll results should be blinded, until after users have voted. Polls should specify a `closed_at` time, after which results be unblinded, closed to new votes, and the tally considered final. Polls may specify either `value_maximum` or `value_minimum` satoshi valuations for determining which zaps are included in the tally. Polls may also specify a `consensus_threshold` for assessing the state of consensus.
The purpose of poll notes is to conduct quantitative public opinion polls over nostr by requiring voters pay to participate. By tying results to real satoshi valuations, nostr polls intend to provide superior signal compared to other free polling models. Imposing real monetary costs for participation should also discourage undesired attempts to sway results.
Pollers may specify multiple `p` keys, to allow participants to choose which recipient they zap, regardless of their vote choice. The option for such distribution of funds should also incentivize participation by increasing voter optionality, poller authenticity, and legitimacy of results by mitigating certain unauthentic attack vectors.
By including a `value_maximum` limit, polls can stop single 'whale' votes discounting many smaller 'shrimp' votes. Likewise, by including a `value_minimum` limit, polls can make automated low-value vote flooding attacks prohibitively expensive. However, both limits remain optional to allow for freedom in poll design.
By setting `value_maximum` and `value_minimum` equal, a more traditional style poll may be designed, which weights each vote equal and limits each participant to a single vote.
The optional `consensus_threshold` is intended as a simple 'measuring bar', defined as the minimum percentage for any single `poll_option`'s percentage of the total tally to attain poll consensus status.
A careful balancing of all poll attributes should enable pollers to conduct tailored polls that deliver meaningful and valuable outcomes.
Poll options are voted on by sending [zap events](57.md) (referencing the original poll event's `e` and `p` values) that indicate their chosen vote option in a `poll_option` tag. To ensure all eligible votes are included in the tally, all `e` and `p` tags must specify the same primary hosting relay.
Polls results are tallied by summing the exact satoshi values from all eligible zaps for each `poll_option`. The total tally is the sum of all individual `poll_option` tallies, and `poll_option` results are calculated by their percentage of the total tally value.
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.
