Transparency & trust.

Areas of transparency

What is open and how to verify it

We publish metrics, decisions, and change history — not because we have to,
but because trust is built only through verifiability.

Moderation

All moderation decisions are public. Every warning or removal comes with a justification. There is an appeal mechanism.

  • •248 decisions in the last 30 days
  • •94% with no appeals
  • •6 appeals, 2 overturned
Learn more →

Funding

A public report on who funds the project, in what amounts, and how the money is spent.

  • •Current stage: Founders + Grants
  • •No advertising funding
  • •No data monetization
Learn more →

Initiative lifecycle

Every proposal has a public history: from the first draft to the final decision.

  • •12 active proposals
  • •3 completed
  • •100% with a public history

Public metrics

The platform's key metrics are publicly available — no cherry-picking.

  • •847 registered members
  • •34 active issues
  • •1,247 annotations

Versioning

All significant changes to documents and proposals are versioned. Old versions are never deleted.

  • •All versions are kept
  • •A diff between versions is available
  • •Hashes for verification

Future commitments

As the platform grows, we commit to maintaining transparency and expanding public reporting.

  • •Quarterly reports
  • •A public audit annually
  • •An independent oversight board
Learn more →

Verification Layer

How we make results verifiable

Not just «we're transparent». Concrete mechanisms for independent verification.

What is recorded

  • •Every version of a proposal, with a timestamp
  • •Vote results with the list of participants
  • •Moderator decisions with justification
  • •Change history of issue pages
  • •Annotations and their acceptance/rejection
  • •Creation and completion of working groups

What is verified

  • ✓Identity verification of participants (LinkedIn or email)
  • ✓Snapshots of proposals before a vote
  • ✓Final results of working groups
  • ✓Issue Committee decisions

Mechanism

How verification works

Why simply «storing it in a database» is not enough
If the hash sits in an ordinary table next to the results, an administrator could change the results and recompute the hash at the same time. There would be no independent verification.
That is why each snapshot is committed to an append-only audit log with a cryptographic chain of hashes: each entry references the hash of the previous one, so an entry cannot be altered or deleted after the fact without breaking the whole chain. Audit bundles are published for independent verification. External anchoring of hashes in a public timestamp system (OpenTimestamps / Bitcoin) is the next stage.

01

A snapshot is created

Before voting begins, the system records the exact version of the proposal text — with all wording and parameters.

02

A hash is computed

The SHA-256 algorithm generates a unique "digital signature" from the snapshot text — a 64-character string. Changing even one letter yields a different hash.

03

Recorded in the audit log

The hash is added to an append-only audit log, where each new entry references the hash of the previous one. This forms a cryptographic chain: to alter an entry after the fact, you would have to rewrite the entire chain after it.

04

Voting takes place

Voting only opens after the record is committed to the audit log. The result is tied to the same version of the proposal whose hash is already in the log.

05

An audit bundle for verification

After voting ends, an audit bundle is assembled: the snapshot, the hash, the log chain, and the results. Download the bundle, compute SHA-256 of the text, and compare it with the hash — a match means the text was not altered.

06

External anchoring — later

In the next stage, the roots of the audit log will be periodically anchored in a public timestamp system (OpenTimestamps / Bitcoin). This will add an external layer of trust — but the hash chain and public bundles already work today, without a blockchain.

Snapshots

Examples of recorded versions

Inclusive Zoning AZ
v3 · 47 participants
2024-05-20 14:32 UTC
sha256:a3f9...c2b1
🔗Committed to the audit log · entry #845221 · hash in the log chain
School funding reform
v2 · 31 participants
2024-04-15 09:18 UTC
sha256:b7e2...d4c8
🔗Committed to the audit log · entry #839104 · hash in the log chain

Public log

A history of significant actions

Proposal snapshots come with hashes for independent verification.

ℹShowing the last 6 entries. Snapshots come with hashes for independent verification.
Snapshot
Snapshot created before vote
Inclusive Zoning AZ · v3 · @system
2024-05-20 14:32:07 UTC
sha256:a3f9c2b1...
Vote
Vote: Support
Inclusive Zoning AZ · @civic_alex
2024-05-20 15:01:44 UTC
Moderation
Warning: violation of discussion rules
Comment #4821 · @moderator_1
2024-05-19 11:22:33 UTC
Issue status
Status changed: Debate → Drafting
Housing Affordability Arizona · @editor_housing
2024-05-18 09:15:00 UTC
Working group
Working group formed
Housing working group · @mchen_civic
2024-05-10 10:00:00 UTC
sha256:b7e2d4c8...
Snapshot
Snapshot created before vote
School funding reform · v2 · @system
2024-04-15 09:18:22 UTC
sha256:b7e2d4c8...

Recorded outcomes

Results with hashes for independent verification

Inclusionary zoning for affordable housing in Arizona

Approved
47 for12 against8 revise67 participants
Proposal version: v3Time: 2024-05-21 18:00 UTC
Hash: sha256:a3f9c2b1e7d3f0a2b8c9d4e5f6a7b8c9

Expanding the telemedicine program in rural AZ

Needs revision
22 for8 against19 revise49 participants
Proposal version: v1Time: 2024-04-30 12:00 UTC
Hash: sha256:c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9
How to verify a result yourself
  1. Download the audit bundle: the proposal text of the version you want + an export of the corresponding audit log fragment (the «Go to the issue» link).
  2. Compute SHA-256 of the text — for example, with the command echo -n "text" | sha256sum or any online tool.
  3. Compare the resulting hash with the one recorded in the audit log. A match means the text was not changed after it was committed.
  4. Check the chain: for each entry, the prev_hash field must match the hash of the previous entry. Any gap or substitution breaks the chain.
The core guarantee: an append-only audit log + public bundles make after-the-fact tampering detectable. In the next stage, the log roots will be periodically anchored in a public timestamp system — adding an external layer of trust that does not depend on us.

Waitlist

Join at an early stage

The platform is being built. Leave your email to get a personal invite on launch day.

  • Invite on launch day
  • Progress updates
  • A voice in the product

We'll only email you about the launch. Unsubscribe anytime.