Technology & trust
How participation is saved today, and how verification is planned.
Sample polls use browser storage. Published article polls use a shared voting database, reviewed AI questions and server-side vote validation. Blockchain verification and an independent security audit are not yet implemented.
From one tap to a result.
Explore what happens at each step.
The checks used by published article polls today. Process illustration · widths do not represent traffic or pass rates.
One tap
A reader chooses an option on a published question. The article widget and Tokensensus call the same voting API.
A supported choice and a browser identifier enter the API.
Sample polls on the home page use browser storage and do not enter this server flow.
The plan: a record you can check.
Base + a Solidity registry would hold batch commitments. A private receipt and Merkle proof would let you check that your vote was included. Base Sepolia testing comes first.
PLANNED · NOT CONNECTEDExplore the full architecture and sample demo
How a vote is recorded
Proposed verification layer · Receipts, contract and proof verification are not connected yet.
Your choice
Submit an answer with the question and choice version. The proposed flow does not require a wallet or a gas payment from the participant.
What a proof can—and can’t—tell you
An inclusion proof checks one record against one committed batch. Unique participants, missing votes, correct tallies and the operator’s handling of private data need separate controls and review.
We do not describe this prototype as tamper-proof or fully anonymous.
What is implemented today?
- Choose an option to see the result.
- Submitted choices and input formats are validated.
- A local duplicate guard prevents repeating a choice in this browser’s current saved state.
- No name is displayed beside a choice.
- Publisher access requires authentication. Questions require review before publication, and published choices cannot be changed.
- Questions are prepared only for articles selected by the newsroom.
- Article votes: one record per question and browser identifier, with atomic duplicate handling and request limits. This does not verify one person per vote.
Browser storage can be edited or cleared. These controls do not verify unique people or provide cryptographic anonymity.
How would records be protected?
- Inclusion: a personal receipt and Merkle proof check whether your record belongs to a committed batch.
- Changes: a Solidity registry designed to prevent overwriting batch roots provides a reference for checking committed records.
- Privacy: only batch commitments and minimal metadata would be public. Names, raw votes and secret salts stay off-chain.
The backend would need validation, abuse controls, private storage, durable receipts and confirmation tracking. These are planned protections, not live guarantees.
What needs to happen before launch?
- Extend the article participation API with stronger abuse controls, salted commitments, durable receipts and registry permissions.
- Test proof verification, duplicate batches, confirmation delays, retries and failure recovery on Base Sepolia.
- Publish the contract address, verification instructions, audit findings and operational policies.
Contract address: not deployed. Independent security audit: not completed.
Technical references
These documents explain the underlying technologies. They are not an audit or endorsement of this application.