> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Honest voting on any website

> A vote confirmed in the voter's messenger and a result that can be checked: what the product already has for it, what this direction still lacks and where its boundary runs.

Online votes — a fan favourite, a contest, an award — are too often decided by whoever bought the
votes. A captcha is solved by a paid service for a fraction of a cent, a mail address costs nothing,
and a social account costs a few cents. The organiser has nothing to answer an accusation with but
a promise.

The direction is a voting widget that can be embedded on any website. Every vote is a Veriqa
confirmation in the voter's messenger — one tap, with no registration, no password and no code to
type — and the result comes with a signed receipt that the voter and a third party can check. In
one line: a vote whose result can be shown, not just promised.

## What it is for

* **The voter** votes without an account, and the receipt lets them check that their vote is in
  the total.
* **The nominee** gets a win that can be proved. A victory nobody can verify is worth little once
  someone says it was bought.
* **The organiser** moves from "trust us" to "check for yourself", and does not have to store
  phone numbers to fight fraud.
* **The sponsor** gets a result that can be audited, and reach measured in people rather than
  clicks.
* **The site developer** embeds a widget instead of building verification, number storage and
  their own anti-fraud.

A campaign that runs in several networks at once gets one more thing. Today the votes from each
network are added up, and the same person counts once per network. A phone number is the one
identifier all the networks share: if the posts in every network lead to one ballot, one person is
one vote whatever the entry point, and the organiser sees how many unique people each network
brought and how far the audiences overlap. The cost is one extra step: a poll built into the
network itself — a channel poll or a Stories sticker — has nowhere to put a confirmation.

## How strong the protection is

No anti-fraud is perfect, and the direction does not claim immunity. It claims fraud that is
**more expensive** than with the methods common on websites today: a captcha or a mail
confirmation costs a fraud farm next to nothing, a social account a few cents, and an identity
anchored to a phone number roughly an order of magnitude more than a social account.

SMS verification uses the same anchor, and against it the protection is on a par. The difference
lies elsewhere: messages in a messenger are not billed per message, and the voter does not retype a
code. The same trade-off as in [Replacing SMS codes](/docs/scenarios/sms-replacement): the phone anchor
at the price of a messenger wherever the audience has one.

## What it builds on

A vote is not a separate product but a confirmation of an action carrying data — which poll and
which choice. That transaction already exists:

1. **Server-to-server confirmation.** The website's server calls
   `POST /api/transaction/confirmation` with a declared action type (`action_type`) and receives
   the channel's deep link and a QR code for the voter. The outcome is read with
   `GET /api/transaction/{id}/result` — `confirmed`, `declined`, `expired` or `failed` — and the
   answer does not disclose who confirmed.
2. **The exact subject in the message.** The poll and the choice travel in typed slots
   (`slot_values`) against the schema of the action type, and the voter sees in the chat what they
   are voting for, with Confirm and Decline buttons.
3. **The phone number as the key.** In WhatsApp the account is the phone number, and the channel
   delivers `phone_number`. Telegram hands over an account identifier rather than a number — see
   the [channel catalogue](/docs/guides/supported-channels).
4. **The audit trail.** The journal is append-only; a deployment can explicitly turn on recording
   the parameters of the confirmed operation, and user identifiers appear in it only masked.

## What does not exist today

* **One person — one vote.** The product confirms an action but neither counts votes nor
  deduplicates them within a poll.
* **A key that does not keep the number.** Deduplication needs the phone, but the record should
  hold a one-way keyed hash, different for every poll, rather than the number itself — the
  approach described in [Resilience to a personal-data leak](/docs/research/leak-resilience). In
  Telegram the number is available only after the user explicitly shares it.
* **A signed receipt and a checkable total.** The voter needs a receipt, and the poll a published
  summary against which the voter checks that their vote is included and a third party checks that
  the total matches the register. The message Veriqa sends after a confirmation is text for the
  user, not an attestation, and the audit trail is not tamper-evident.
* **The anchor level as a property of the poll.** Not a "protected" badge but "collected on an
  anchor costing about this much per identity", together with the checks around the key: virtual
  number ranges, bursts of votes from one network, repeated patterns.
* **The widget and the service behind it.** A widget on an arbitrary website means the voting is
  hosted by Veriqa rather than by the integrator: allowed origins, rate limits, an abuse policy.
* **Email** does not fit this transaction: an address costs nothing, so a vote confirmed by mail
  anchors nothing.

A voting or contest platform that accepts an external OpenID Connect provider can connect Veriqa
as its sign-in method today, like any other OIDC client — see
[SaaS builders](/docs/integrations/saas-builders) for how that connection works. Whether the platform
lets a public audience sign in through an external provider is a question of that platform. The
platform then counts the votes itself, so the anchor and the one-tap confirmation are available
this way, while the receipt and the checkable total are not.

## Where the boundary runs

<Warning>
  A confirmed vote is **attributable**: it is tied to the voter's confirmation. This fits a fan
  favourite, a contest or an award. It does not fit elections or any decision with legal
  consequences, where the secrecy of the ballot matters.
</Warning>

* **Votes bought from real people are not stopped by anything here.** The phone anchor raises the
  price of a vote to the cost of a person's time and stops there.
* **The receipt shifts trust but does not remove it.** It proves that the website did not alter the
  result; it does not prove that Veriqa did not issue fictitious identities.
* **Coverage.** Where a large share of the audience uses none of the supported messengers — in the
  US, for example, no single messenger dominates — the widget cannot be the only way to vote, and
  any fallback without a phone anchor brings the guarantee down to its own level.
* **The receipt is an attestation of the count**, not an electronic signature in the legal sense.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.