Privacy Policy

Last updated: 12 October 2026

1. Who We Are

World Republic ("World Republic," "we," "us," or "our") operates the World Republic application and website at https://www.worldrepublic.org (the "Service"). The same application is also served under a second name, Raised by Humanity, at https://www.raisedbyhumanity.org. That site runs the same software, uses the same accounts and the same database, and is operated by us. In this policy "the Service" means both sites, and this policy applies on both. World Republic is a Swiss association (Verein) under Art. 60 et seq. of the Swiss Civil Code with its seat in Zug, Switzerland. It has legal personality under Art. 60(1) of the Civil Code and is not entered in the commercial register. The Service is administered from Hungary by our board, so for the purposes of the EU General Data Protection Regulation (GDPR) World Republic is established in the European Union, and our lead supervisory authority there is the Hungarian National Authority for Data Protection and Freedom of Information (NAIH).

For most processing described below we are the data controller. For identity verification, we are the controller and Amazon Web Services acts as our processor / service provider. A second provider, Didit, is named below for an escalation route that is not currently offered — see Section 4.2.

• Privacy contact: privacy@worldrepublic.org
• Contact in the European Union: Balázs Kónya, board member, 3626 Hangony, Dózsa György út 5., Hungary (privacy@worldrepublic.org)

2. Scope

This policy applies to everyone who uses the Service, worldwide. Where local law gives you additional rights — including the EU and UK GDPR, the revised Swiss Federal Act on Data Protection (revFADP), the California Consumer Privacy Act as amended by the CPRA, and U.S. state biometric laws (Illinois BIPA, Texas CUBI, Washington) — those rights are described in Section 10.

World Republic currently runs non-binding test elections. We are not yet enrolling members; participation is experimental.

3. Information We Collect

3.1 Information you provide

• Account information: if you sign in with Google, we receive an authentication token and your Google account identifier. We keep the identifier, which is what links your account to your Google sign-in. We do not store your Google name, email, or photo, and we do not keep the token, which contains them.
• Passkey credentials: if you use a passkey (WebAuthn), we store the public key credential, an identifier, and the device metadata needed to authenticate you.
• Profile information: a username, which we generate when your account is created and you can change at any time in your account settings. Your username is published wherever you appear in the Service — see Section 6 — so if you set it to your own name, your own name is what is published. We also generate a referral code for each account; nothing in the Service uses it.
• Content you create: political party names, descriptions, and links.
• A report about a party: if you report a party's registry entry, we keep which party, which ground you chose, what you wrote, and the time. On most grounds we also ask for your name and an email address, because the law that requires us to accept your report also requires us to confirm we have it and to tell you what we decided — and we have no other way to reach you. On one ground we ask for neither, and keep neither: a report that the content is child sexual abuse material. If you are signed in we also record which account filed it. This is the one place we hold an email address you gave us; Section 8 says for how long, and Section 10.1 says what we do and do not use it for.
• Age confirmation: that you confirmed you are 18 or older, and when. We ask this once, before identity verification. We do not ask for your date of birth and do not store one — only that the confirmation was given, the age it was given against, and the time.
• Review outcome for your party: whether the automated review in Section 5.1 listed your party by default or set it aside as spam, the ground it gave, which of its two checks (or which person) decided, which model decided where a model did, and when.
• Whether your party says what it wants for AI: whether your party's name or description says what it wants for artificial intelligence, as the review in Section 5.2 read it; the line it gave, which can quote your own words; what gave the answer (the automatic classifier or a person); which model, where a model answered; and when.
• A decision to take your party down: separately from the review above, a party whose content we judge unlawful can be taken out of the registry altogether — its page stops opening for anyone, it cannot be found, and it cannot receive votes. This is a different and much heavier measure than the review outcome above, which only affects whether a party is listed by default. Where we do it, we keep the date, the legal basis we relied on, our own written reason for why that basis applies to your party, whether someone's report or our own review prompted it, and a label for whoever decided. You are shown all of that except the last, in the Service, on your party's own page — which still opens for you even though it opens for nobody else. We do not name the individual who decided, and we do not tell you who reported you, if anyone did.
• Voting record: that you voted in a given test election, and when. Not which party you voted for. In this policy your ballot is the choice you cast in a test election. Your ballot is private: your choice is added to the party's total and is not stored with your account. Apart from the confirmation your own device shows as you vote, no screen in the Service shows how you voted, and we do not publish it. In some cases, someone with direct access to our database (Section 11), or to a copy of it, can still link a ballot to the person who cast it. Section 5.3 says when, and for how long.
• Transaction details: when you withdraw WDD, the destination wallet address, amount, and selected chain.

3.2 Identity verification and biometric data

To keep test elections fair (one verified person, one vote) and to prevent fraud and duplicate accounts, we verify that you are a unique, live, real person. See Section 4 for the full, separate explanation of biometric data — please read it carefully.

3.3 Information collected automatically

• Device and log information: device and browser type, operating system, and similar technical data.
• IP address: we process your IP address to enforce rate limits and prevent abuse (stored short-term in our rate-limit records). We also store your IP address and browser user-agent as part of a consent record when you first agree to our Terms and acknowledge this policy, or when you give biometric consent, as proof of that agreement or consent. Your IP address and browser user-agent are also recorded in the security records described in Section 8: when your device starts the liveness check in a face check, and each time you download your face-check images.
• Usage information: features used and actions taken within the Service.
• Copies of your data: when you download the machine-readable file described in Section 10.1, or your face-check images, we record that a copy was made, when, which of the two it was, and which parts of the record it carried (for the images, the verification part they belong to). For the images the record is made when the download starts, so one that then fails on your device still appears in the list and counts toward the limit. We keep it so that every device you are signed in on reads the same list — it is the only way we have of telling you that somebody with your session took a copy of everything, since we hold no address to tell you at. Reading the copy on screen is not recorded; what the list catches is the copy that leaves the device.
• Performance measurement: we measure how quickly pages load and respond on your device (Core Web Vitals) and send those timings to our hosting provider, along with the page's route and coarse device, connection and country information derived from the request. This is cookieless, stores nothing on your device, and is not linked to your account. The address reported is reduced to the page path before it leaves your device, so query strings are not sent.

3.4 Cookies and local storage

We use only strictly necessary and functional cookies and local storage:

• Authentication and security (session and account-linking cookies).
• Preferences (e.g. your selected language).
• Functional state (e.g. return-to-page after verification).
• A copy of your account screen, kept so that the Service can draw it again at once when you come back. It holds what that screen shows: your WDD balance, your recent transactions — including the destination wallet address and the chain of each withdrawal you made — and whether your account is verified or your face liveness check was refused. Signing out replaces it with an empty copy. Until you sign out it stays on the device, so sign out if other people use that device.

We do not use advertising cookies, and we run no advertising or cross-site tracking SDKs. We do run one cookieless performance-measurement SDK (Vercel Speed Insights) to measure page-loading speed: it sets no cookies, stores nothing on your device, and does not identify you — see §3.3.

4. Biometric Data (Face Liveness) — Please Read

To vote in a test election, and to register a party, you must complete a face liveness check. This policy calls that check the face check. The face check processes biometric data, which is sensitive / special-category personal data. We want to be fully transparent about it.

4.1 What happens

• Your device captures a short live facial video, which is processed by Amazon Web Services (AWS) Amazon Rekognition Face Liveness to confirm a real, live person is present (anti-spoofing).
• AWS stores a reference facial image for the session. AWS stores that image whether the check passes or fails, so a check that did not pass still leaves an image. You can have that image destroyed at any time (Section 4.4).
• If the check succeeds, we add a facial vector (template) made from that image to a secure AWS Rekognition collection. A check that is refused as a duplicate adds no vector to the collection.
• We use that collection to run a one-to-many comparison against other users' facial vectors to check whether the same face is already verified on another account.

The refusal is automatic. If the comparison finds a match, verification for that account is refused at that moment, by the comparison itself, and no person takes part in the decision. The only thing weighed is how closely the facial vector made from your scan resembles a vector already in the collection, measured against a single fixed similarity threshold; nothing else about you enters it. A refused account cannot vote in test elections or register a party, and the refusal stands for that account unless a person changes it.

You can ask a person to look at it. Write to privacy@worldrepublic.org, or ask in our Help Community, and we will answer within one month. A person compares the reference image from your check with the one held for the account it matched, where both still exist — either image may already have been destroyed under Section 4.5 — and can reverse the refusal and verify you.

If the images are gone, that is not the end of it. Where the face your check matched has since been destroyed — because that account was deleted, or because the person behind it withdrew their consent — a person can instead lift the refusal so that you may take the check again. That is not a decision that you are verified: the new check runs in full, against the same comparison, and can refuse you again. So that both routes are possible, we keep the record of the match with the refused check: which account was matched, and how close the comparison was (Section 8).

4.2 Escalation to Didit

This route is not currently offered, and no check can be started. It is described here because it is designed.

The idea is an escalation to Didit, an identity-verification provider, for someone the face check refuses in error — a false duplicate match between people who look alike. It would ask for your explicit consent and have Didit check a document and a selfie on our behalf.

Today none of that runs: the Service has no screen that offers it, and the route that would start a check refuses every request. Didit holds no verification data of ours. If you were declined by the face check, the route open to you is the one in Section 4.1: ask in our Help Community, and a person can look at both records and reopen verification.

If the escalation is ever offered, this Section will say what it collects and what we receive before it does.

4.3 Service-provider notice (AWS and Didit)

World Republic uses service providers for identity-verification services. Biometric identifiers and biometric information ("biometric data"), specifically scans of your facial geometry and the related facial images and templates, may be collected, stored, and used by these service providers (AWS; and Didit, if the escalation in Section 4.2 is ever offered) on World Republic's behalf for the purpose of verifying that you are a unique, live, real person and preventing duplicate or fraudulent accounts. World Republic destroys the biometric data AWS stores on its behalf when the initial purpose for collecting it has been satisfied, when you request deletion, or earlier if required by law. Didit holds no biometric or identity data of ours, because the escalation is not offered. Should it ever be offered, the terms on which Didit may hold and must delete that data will be settled and stated here first. Biometric data may be transmitted between World Republic and its service providers as necessary to provide this service.

4.4 Your consent and choice

Two things sit under this check, and we name both.

The check itself is necessary for the service you ask us for. A test election in which one verified person has one vote cannot be run unless each voter is shown to be enrolled once, and we have no less intrusive way to show that today. Because the check processes biometric data, a second thing is needed as well: your explicit, opt-in consent, which is the condition we rely on for the biometric data itself. We request that consent at the start of the face check, and we process no biometric data without it.

What declining costs you. The face check is today the only route to voting. If you decline it, you cannot vote in a test election, and you cannot register a new party. It costs you nothing else: you can still hold WDD, withdraw WDD, lead a party you registered before, and use the rest of the Service. Before any election whose result binds anyone, we will offer a route to voting that does not use a face check.

You can withdraw that consent at any time, and you do not have to delete your account to do it. In the app, open Account → Verification → Delete my face data. Withdrawing takes effect immediately and destroys both the reference images and the facial template we compare against. If you want a copy of the images, download them first, from the same screen (Section 10.1). Your account, your WDD balance, any party you lead and any vote you have already cast are unaffected. You will not be able to vote again until you complete a new face check, which you are free to do at any time — unless your check has already been refused as a duplicate of another account (the automatic refusal described in Section 4.1). Withdrawing destroys the data but does not change that decision; contact privacy@worldrepublic.org to contest it.

One exception, and it is the same one Section 4.5 describes for account deletion: if a test election you have voted in is still open when you withdraw, your consent ends at once but the biometric data itself is destroyed when that election closes — unless you complete a new face check before then, in which case that new consent stands and nothing is destroyed. As Section 4.5 sets out, the destruction never waits more than fourteen days: an election that closes more than fourteen days after you withdraw does not hold the destruction at all. You can also delete your whole account instead (Section 9), or contact us to exercise any of the rights in Section 10.

4.5 Retention and destruction

We retain biometric data only as long as needed for verification and anti-duplication. We destroy it when the purpose is satisfied, on your deletion request, when your account is deleted, or three years after your last interaction with the Service — whichever occurs first. One record is kept longer: the security-log entry described in Section 1 of our Biometric Retention and Destruction Policy, which notes the positions of your eyes, nose and mouth and the angle of your head. Our written Biometric Retention and Destruction Policy sets out each of those triggers in full, and Section 2 of that policy lists what counts as an interaction. Destruction includes deleting the AWS reference image (Amazon S3) and the facial vector (Rekognition collection).

One exception, bounded and stated here because you should know it before you act: if you delete your account — or withdraw your biometric consent under Section 4.4 — while a test election you have voted in is still open, we keep your biometric data until that election closes and destroy it then. If you withdrew and then verify again before the election closes, the pending destruction is canceled, because the new face check is a new consent; deletion is never canceled this way. A cast vote cannot be taken back out of the party's total, so it stays counted, and the face check is the only thing that stops the same person from verifying a new account and voting a second time in the same election. The delay never exceeds the election's remaining window and never exceeds fourteen days: an election that closes more than fourteen days after you act does not hold the destruction at all. Nothing else about the deletion waits.

4.6 Where biometric data is processed

Your facial templates and reference images are processed and stored by AWS in the European Union (Ireland). Associated verification metadata (for example, confidence scores and storage references) is held in our primary database (see Section 7).

5. How We Use Information and Our Legal Bases

5.1 Automated review of party registrations

When you register a party or edit it, a program reviews it before it is listed by default. No person takes part in that step.

• What it reads: the party's name, description, website link and the leader's username — nothing else about you.
• What it decides: whether the party appears in the default lists, search and the election's list of parties, or is set aside as spam. A party set aside is not removed: it stays at its own address, can be found by choosing to show all parties, and can be voted for.
• The grounds: advertising for something outside the Service (including impersonating the Service or an established party), offering individual payment for votes, incitement to violence, and obscenity. Political views are never a ground, and the review must quote what it flags.
• How it decides: a large language model, GLM-5.3 Flash by Z.ai, applies those rules to the text. When that model is unavailable the same rules are applied by GLM-5.3, by the same maker. Both run on Baseten in the United States (Sections 6 and 7), which keeps nothing of either request once it is answered and does not train on it. A second, fixed rule compares the party's name with established parties' names. The outcome, its ground, which check decided and — where a model decided — which of the two models are kept with the party (Section 8).
• Why a program may decide it: a registry in which each listing is a genuine party registration is part of the service you register a party for, and that is what allows this decision to be made by a program. A party registration also expresses political opinions. The decision is never taken on those opinions — the grounds above are things a registration does, not things it is about, and a registration is never flagged for what it argues for. Those opinions are read only because they sit in the text being checked, and you make them public yourself by registering the party for publication in the public registry. You do not have to register a party to vote, to hold WDD, or to use anything else.
• Your options: the party's leader sees the outcome and the ground on the party's page. Editing the party resubmits it for review. You can ask a person to review the outcome through the Help Community linked from that notice, or by writing to privacy@worldrepublic.org.

5.2 Whether a party says what it wants for AI

Raised by Humanity is a campaign about how artificial intelligence should be governed. To tell which parties take a position on it, the same request that carries the review in Section 5.1 also asks a second, separate question.

• What it asks: whether someone who follows the public debate about AI could tell, from the party's name or description, what the party wants for AI — how it should be built, used, shared, limited or governed. Any position counts, for or against, and none counts for more than another. A party does not have to use the word "AI". Mentioning AI, or using or selling it, is not a position.
• What it reads: the same fields as Section 5.1, in the same request — the party's name, description, website link and the leader's username. Nothing more is sent, and it is sent nowhere else.
• What it records: the answer — says what it wants for AI, or does not — with one line quoting the words it relied on, the model that answered and when. It is kept with the party (Section 8).
• What it changes: one view, and only for a reader who asks for it. Turning on "Only AI governance parties" in the parties list or in an election's list of parties shows just the parties whose answer is that they say what they want for AI. It is off unless the reader turns it on. The answer has no part in the review in Section 5.1. Without that filter it changes nothing anyone sees, including the default lists, search and an election's list of parties, and it never affects a vote. If that changes, this section will say so from the day it does.
• How it decides: the same models as Section 5.1 — GLM-5.3 Flash by Z.ai, or GLM-5.3 when that model is unavailable — run on Baseten in the United States, which keeps nothing of the request once it is answered and does not train on it.
• Your options: every edit to the party asks the question again, and its answer replaces the old one. The answer is in the copy of your data the Service gives you (Section 10). You can ask a person to review it, or object to it, by writing to privacy@worldrepublic.org. If the answer is that your party does not say what it wants for AI, your party's card says so while you have that filter on.
• Why it may read a political position: this is the one place the Service reads what a party argues for rather than only what it does. It reads only the words the party itself published, about one subject, and treats every position on that subject alike. You make those words public yourself by registering the party for publication in the public registry. You do not have to register a party to vote, to hold WDD, or to use anything else.

5.3 Your ballot

When you vote, our server receives who you are and your choice together, because it has to check that you may vote and then count the vote. It stores the two apart, in three records saved together: a record that you voted in that election, and when; a record of your consent to count your vote, which names the election and the day; and one more vote added to the party's total. No record stores your choice with your account. In some cases your ballot can still be linked to you, and this Section says when.

• While an election is open. Our database marks each change it saves with a reference number. All three records are saved in the same change, so they carry the same number. So while an election is open, someone with direct access to our database (Section 11) could find out who cast the most recent ballot for each party, and, by watching the totals change, who cast each ballot during that time. With tools that read the database's storage directly, they could also find out who cast other recent ballots, from older versions of the totals that the database has not yet cleared. Our test elections take ballots for three days, and the Service never takes ballots in an election for longer than fourteen days.
• After it closes. Shortly after an election closes, usually within minutes, we rewrite its totals in a separate change. After that, no record in our main database, the one the Service runs on, links a ballot to the person who cast it. Older versions of the totals can stay in the database's storage until they are overwritten, and those same tools can still read them.
• In our provider's recovery history and backups. Our database provider keeps a recovery history of the database, which we currently set to about six hours. It can link any ballot cast in that time, and it can bring back the totals as they were before we rewrote them, with the links they held. The provider also keeps backups of its own, which it states it keeps for 30 days; we have not yet confirmed with it what those backups cover. Those backups, and any copy of our database (Section 11) made before the totals were rewritten, keep these links until they expire or are deleted, and a copy we delete can remain in those backups until they expire.
• In what we publish. We publish each party's total once the election has closed (Section 6); while it is open, we show only how many ballots have been cast in all. If everyone in an election votes for the same party, the totals show how each of them voted to anyone who knows they voted. And when very few people vote, someone who knows how the others voted can work out the rest.

Nothing in the Service uses any of this to link a ballot to the person who cast it.

Because your choice reveals a political opinion, we ask for your explicit consent before we count it. The screen where you cast your vote has an unticked box asking for that consent, in each test election, and it must be ticked before the vote is cast; our server refuses a ballot without it. We record that consent with the election, the version and the language of the words you ticked, and the day. We record no IP address or browser with it, and only the day, because it is saved at the same moment as the record that you voted, and an exact time would be a second record of when you voted. You can withdraw that consent (Section 10).

6. How We Share Information

We do not sell your personal information. This Section sets out who receives information about you, and in what capacity. Some of it is handled for us by service providers, on our instructions and for no purpose of their own. Some of it reaches a company that decides for itself what to do with that information, and this Section names those recipients. Some of it we must disclose to comply with the law, and in a merger, acquisition or asset transfer what we hold would pass to the buyer, subject to lawful safeguards — except your biometric data, which never passes that way. And some of it the Service publishes to other people.

Service providers acting for us. These providers process information on our instructions and for no purpose of their own. Didit is named in the list below for completeness only, and processes nothing for us today:

• Google Workspace — hosts our mailboxes, among them privacy@worldrepublic.org and legal@worldrepublic.org. Anything you write to us at either address, and anything you send with it — including whatever you send to show that a request is yours (Section 10.3) — is processed by Google as our provider. The operational alerts described in the Amazon Web Services entry below are delivered by email as well, and one of the addresses they reach is on our own domain. So an alert that carries a destination wallet address is processed by Google too. Signing in with Google is a different relationship, and this Section sets that relationship out below.
• Amazon Web Services (AWS) — four things. Amazon Rekognition Face Liveness, Amazon S3 (reference images), and Amazon Cognito (temporary guest credentials), as our service provider for biometric verification (EU region). Amazon Simple Notification Service, which carries our operational alerts. AWS CloudTrail, which keeps the security audit log of our cloud accounts and our record of access to face-check images (Section 8). And Amazon Simple Email Service, which carries the two messages we owe somebody who reports a party — that we have the report, and what we decided. Those messages go to the address that person gave us and carry the party's name, the date, and a reference; they never carry the ground that was chosen or what the person wrote. An alert tells us that something needs attention — for example a withdrawal that has gone wrong, an account that has reached one of the limits we set on how often it may act, a party registration the automated review could not read, or a destruction of biometric data that did not complete. Those are examples, and not the whole list. An alert can carry a destination wallet address, the amount and chain of a withdrawal and the reference we give that withdrawal in our own records, the internal identifier of an account, and the identifier of a party. Where a transfer was sent, an alert can also carry the hash of that transaction on the blockchain and the reference the payment provider gave it. An alert never carries a party's own name or description, and never carries what the automated review said about it.
• Didit — identity verification on escalation. Not currently offered and holding no data of ours (Section 4.2). See Didit's Verification Privacy Notice and End User Terms for Identity Verification.
• Coinbase — executes WDD blockchain withdrawals; receives the destination address, the amount, the chain, and the reference we give that withdrawal in our own records, and nothing else.
• Neon — database hosting for Service data. Our database runs in Singapore, and Neon processes in the United States as well (Section 7).
• Vercel — application hosting, infrastructure logs, and cookieless performance measurement. Our application runs in Singapore, and Vercel processes in the United States as well (Section 7). Its AI Gateway also carries the party-review request in Sections 5.1 and 5.2 — one request — to Baseten and nowhere else.
• Baseten — runs the language models that review party registrations (Sections 5.1 and 5.2); receives the party's name, description, link and leader username, keeps none of it once the request is answered, and does not train on it (United States).

A current list of sub-processors is available on request.

Google, when you sign in. Signing in with Google is an exchange between you and Google, and Google decides for itself what to do with that exchange. Google is not acting only on our instructions here, so Google is not our service provider for this. We receive an authentication token and an identifier for your Google account, and we keep only the identifier (Section 3.1). What Google does with a sign-in is governed by Google's own privacy policy (policies.google.com/privacy).

Our Help Community. Sections 4.1 and 5.1 point you to our Help Community if you want a person to look at an automated decision. That community is a public channel on Telegram. What you write there is read by Telegram and by everyone else in that channel. We do not control that channel. If you would rather not write in public, write to privacy@worldrepublic.org instead: that route reaches the same person, and Section 10.1 sets it out.

Disclosures required by law, and if the Service passes to another organization. We may disclose information to comply with law or valid requests by public authorities. We may also disclose information in a merger, acquisition, or asset transfer (subject to lawful safeguards). Your biometric data is never part of such a transfer. We do not sell, lease, trade or otherwise profit from it, and we do not pass it to a buyer with the rest of what we hold. Apart from the provider that stores it for us and on our instructions (Section 4.3), we disclose biometric data only where you consent to it, where a law requires it, or where a valid warrant or subpoena compels it. A merger, an acquisition and an asset transfer are none of those.

Published by the Service. Some of what you do is shown to other people. This is not sharing with a provider. It is publication, and it cannot be undone by asking a provider to stop:

• The party registry. If you register a party, the party's name, description, link, your username and the total WDD the party has been awarded in subsidies are published in the registry. The registry is open: anyone can read it without an account, and search engines can index it.
• Withdrawals. A WDD withdrawal is a public blockchain transaction. The destination address, the amount, the chain, the time, and the reference we give that withdrawal in our own records are published on the blockchain, not by us, and nobody can remove them. We write that reference into the transaction so that a withdrawal can be proved to have been made once and only once. The reference is not the identifier of your account. Each withdrawal has its own reference, and a reference belongs to one withdrawal only. To check that a withdrawal was made, we ask a public blockchain service to look the transaction up for us. Those services see what the blockchain already publishes — the address, the amount and the reference — and nothing else we hold about you.
• Election results. Each party's vote total is published once the election has closed. While an election is open, no party's total is shown, only how many ballots have been cast in all. We publish only totals, never an individual ballot. If everyone voted for the same party, the totals can still show how you voted to someone who knows that you voted; and if very few people voted, to someone who also knows how the others voted (Section 5.3). Section 5.3 says when a ballot can be linked to you in our database.

Your username is the name that appears in all of this, and you choose it (Section 3.1).

7. International Data Transfers

Our seat is in Switzerland, which benefits from an EU adequacy decision, and we are also established in the European Union (Section 1). Your data is processed in more than one country:

• Biometric data (facial templates and reference images) is processed and stored by AWS in the European Union (Ireland).
• The security audit log of our cloud accounts, and our record of access to face-check images (Section 8): the entries about you are kept in the European Union — in Ireland, where the face check runs, and in Germany, where we keep our copies.
• Account and application data is held in our database at Neon and served by Vercel. Both run in Singapore, and part of this data reaches the United States as well: Vercel's data processing agreement states that its primary processing facilities are in the United States, and Neon contracts through a United States parent company whose terms name a United States provider for infrastructure monitoring. What travels that way is request and server logs — your IP address, your browser user-agent, the page you asked for, and, in some error records, the internal identifier of an account.
• Party registrations under review (name, description, link, leader username) are sent to Baseten in the United States for the automated review in Sections 5.1 and 5.2, and are not stored there.
• Withdrawal details — the destination address, the amount, the chain, and the reference we give that withdrawal in our own records — go to Coinbase, a company based in the United States. We have not established in which countries Coinbase itself processes that data.
• Operational alerts are carried by Amazon Simple Notification Service (Section 6), and an alert can carry a destination wallet address, the amount and chain of a withdrawal and the reference we give that withdrawal in our own records, the internal identifier of an account, and the identifier of a party. Where a transfer was sent, an alert can also carry the hash of that transaction on the blockchain and the reference the payment provider gave it. An alert never carries a party's own name or description, and never carries what the automated review said about it. That service runs in whichever Amazon region we have configured for it, and that region may be outside the European Union. The alert is then delivered by email, and one of the addresses it reaches is on our own domain, which Google Workspace hosts in the United States (Section 6).
• Messages to somebody who reported a party are carried by Amazon Simple Email Service in the European Union (Ireland) — the same region as the biometric data, under the same agreement.
• Sign-in data goes to Google, which processes that data in the United States and in other countries.
• The identity-document escalation in Section 4.2 sends nothing anywhere, because it is not offered and no check can be started. The Didit company that contracts with customers in Europe is Didit Identity Spain, S.L., and Didit states that its main processing systems are inside the European Economic Area. That statement is Didit's own, and we have not confirmed it ourselves. Before the route is offered, we will confirm in this Section where a check would be processed, and name the safeguard that covers it.
• What you write to privacy@worldrepublic.org or to legal@worldrepublic.org is processed in the United States by Google Workspace (Section 6).

Singapore is not covered by an EU or Swiss adequacy decision, and the United States is covered only for recipients certified under the Data Privacy Framework. We do not rely on one safeguard for all of these transfers. We would rather tell you which safeguard covers which recipient than name an instrument we do not hold:

• Vercel, and Baseten through Vercel's gateway: the European Commission's Standard Contractual Clauses and the United Kingdom's International Data Transfer Addendum, both incorporated in Vercel's data processing agreement. We have not established whether that agreement also carries the complement Swiss law requires. We hold no separate agreement with Baseten.
• Google, for our mailboxes: Google's standard Workspace terms, which incorporate Google's data processing addendum and the Standard Contractual Clauses.
• Google, for sign-in: none of our own. Google decides for itself how it handles a sign-in, so Google is not acting only on our instructions here, and we hold no data processing agreement with Google for sign-in. Google states that it is certified under the EU–US Data Privacy Framework. We have obtained no separate instrument for this transfer.
• AWS: the AWS data processing agreement. Your biometric data is held in the European Union (Ireland) and is not transferred out of the European Union at all. When you download a copy of your own face-check images (Section 10.1), your browser fetches them directly from AWS in the European Union (Ireland), wherever you are: they do not pass through our servers, and we keep no copy of what you download. The operational alerts described above are carried under the same agreement, in whichever Amazon region we have configured for those alerts. The messages we send to somebody who reported a party are carried under that same agreement, in the European Union (Ireland).
• Neon: Neon's standard terms, which apply automatically when we use Neon. The transfer clauses for that contract sit in the terms of Neon's parent company, and we have not yet obtained them.
• Coinbase: Coinbase's standard developer terms. We understand those terms to carry a transfer appendix, and we have not yet confirmed it.

Where an adequacy decision covers a transfer — the European Union and Switzerland each recognize the other — we rely on that decision, and no further instrument is needed.

Two more things you should know rather than have to assume. We have not carried out a transfer impact assessment for any of the transfers named above. We rely on no supplementary measures beyond the security measures in Section 11. We are working to put the missing instruments in place, and we will update this Section as each one is in place.

You can ask us for a copy of the safeguards named above. Write to privacy@worldrepublic.org (Section 10.1).

8. Data Retention

9. Account Deletion

You can delete your account in the Service. Deletion destroys the biometric data AWS holds on our behalf and removes your verification records. It destroys your sign-in credentials — the link to your Google account, and any passkey — so that the account cannot be signed in to again. If you sign in again afterwards, you get a new and empty account. It replaces your username with a randomly generated one, and it removes the IP address and device details kept with your consent records. Within our database, these changes are made to our main database, the one the Service runs on. Our database provider keeps a recovery history of the database, which we currently set to about six hours, and backups of its own, which it states it keeps for 30 days; we have not yet confirmed with it what those backups cover. What we delete stays in that history and those backups until they expire. We make a copy of our database only to test a change to the Service or to recover from a fault, and we delete it when that work ends. A copy made before you deleted your account keeps what it held until it is deleted, and after that it can remain in the provider's backups until they expire. The same is true of every record that Section 8 says we delete from our database.

Deleting your account also forfeits your WDD balance and cancels your reward streams — the rewards that were still being released to you. That is a term of the Terms of Use rather than a privacy matter, and Section 8.5 of the Terms of Use sets it out. If you want to keep your balance, withdraw it before you delete your account. You do not have to delete your account to have your biometric data destroyed: Section 4.4 describes that separate route, and using that route leaves your WDD balance untouched.

Deletion does not remove everything, and we would rather name what is left than call it anonymous. Your account has an internal identifier that we do not delete, and almost all of these records stay attached to that identifier:

• That you voted in each test election, and when — not which party you voted for, which is not stored with your account. Section 5.3 says when a ballot can still be linked to the person who cast it. The record that you voted is kept so that each election's turnout stays true.
• Your WDD record — each reward awarded to you, held as the stream that released it into your balance, every change to that stream, and each withdrawal you made: the destination wallet address, the amount and the chain, and, where a withdrawal could not be sent, the record of that attempt. Your balance is set to zero and your reward streams are removed, but the record of what was awarded and what was paid out stays. This is our record of the WDD we have awarded and the WDD we have paid out (Section 8).
• The referral code generated for your account, which nothing in the Service uses (Section 3.1).
• The evidence of each consent you gave and each one you withdrew — which document, which version, when, the language and the screen the statement was shown on, and, for consent to count a vote, which election (Section 8).
• That you confirmed you were 18 or older, and when — kept as the evidence that we asked and that you answered (Section 3.1). We hold no date of birth, so there is no date of birth to remove.
• A party you registered, which stays in the registry. The randomly generated username replaces the username you chose as that party's leader name.
• Operational alerts about something that went wrong, and the copies of them in the mailboxes that receive them — an alert can carry a destination wallet address, the amount and chain of a withdrawal and the reference we give that withdrawal in our own records, the internal identifier of an account, and the identifier of a party. Where a transfer was sent, an alert can also carry the hash of that transaction on the blockchain and the reference the payment provider gave it. An alert never carries a party's own name or description, and never carries what the automated review said about it. An alert is a message about one event rather than a record kept under your account, so it carries whichever of those identifiers that event had. Deleting your account does not delete these (Section 8).
• Server and error logs, which our hosting and database providers keep for a period we do not control. A log line can carry the internal identifier of your account, the address a request came from and the page it asked for. Deleting your account does not delete these logs (Section 8).
• The security audit log of our cloud accounts, and our record of access to face-check images (Section 8, which says how long each is kept). Their entries can carry the internal identifier of your account or name one of your face-check sessions. The entries for your face checks can also carry an identifier AWS assigned to your browser. The entries for your liveness checks and for your own downloads of your face-check images also carry the IP address and browser user-agent, and the entry for adding your face to the collection notes where your eyes, nose and mouth sit in the reference image and the angle of your head, never the image or the template. The destruction of your face data that deletion starts adds entries of its own, and deleting your account does not delete any of these entries.
• The dates on the account itself — when the account was created, when it last changed, and when it was deleted.

Those records are pseudonymized, not anonymous, and the difference is worth stating. None of them carries your email address. None of them carries your name or the username you chose. Almost all of these records stay attached to the same internal identifier, so they can still be read as the records of one account. Some kinds of record are exceptions to that, and each is named above: an operational alert is a message about one event rather than a record kept under an account, and a server or error log line, or an entry in the security audit log or our record of access to face-check images, carries the internal identifier only some of the time. A destination wallet address is more than a pseudonymous identifier: it is a permanent identifier on a public blockchain, and anyone who already knows an address of yours can see the payments made to that address. Calling these records anonymous would not be true, so we do not call them that.

You can save a copy of your data before you delete your account, and it is worth doing first (Section 10.1). Once the account is deleted that route is gone: the copy is built for an account that is signed in, and a deleted account cannot be signed in to. We would also have no way afterwards to satisfy ourselves that a request about a deleted account comes from the person whose account it was (Section 10.3). The in-app copy does not carry your face-check images; they are a separate download, under Account → Verification, and like the copy they cannot be downloaded once the account is deleted.

Votes you have cast stay counted. Your choice is part of the party's total and is not stored with your account, so there is nothing of it that we can remove separately. Deleting your account records your consent to their counting as withdrawn, on that day. If a test election you voted in is still open when you delete, your biometric data is destroyed when that election closes rather than immediately (see Section 4.5).

10. Your Rights

Depending on where you live, you may have the rights below. Exercising them normally costs you nothing (Section 10.5), and you will not be treated differently for exercising them.

• EU/EEA and UK (GDPR / UK GDPR): access, rectification, erasure, restriction, portability, objection, and withdrawal of consent. Where a decision about you was reached by automated means alone and has a significant effect on you — the refusal described in Section 4.1, and the listing decision in Section 5.1 — you also have the right to obtain human intervention on our part, to express your point of view, and to contest the decision; write to privacy@worldrepublic.org. We reach both of those decisions by automated means because each decision is necessary for the service you asked us for. For the refusal, that service is a test election in which one verified person has one vote. For the listing decision, that service is a registry in which each listing is a genuine party registration. The refusal decides on special-category data — your biometric data — and the condition we rely on for that is the explicit consent you give at the face check (Section 4.4). The listing decision is never taken on the political opinions a registration expresses; those opinions are read only as part of the text being checked, and you make them public yourself by registering the party for publication (Section 5.1). The answer in Section 5.2 is different in both respects: it does read the position a party publishes about AI, and it changes nothing about how your party is shown unless a reader asks to see only the parties that say what they want for AI (Section 5.2). You can ask a person to review it, and you can object to it, because we rely on our legitimate interest for it (Section 10.6). You may complain to your local supervisory authority; for EU GDPR purposes our lead supervisory authority is the Hungarian NAIH (Section 14).
• Switzerland (revFADP): access, rectification, deletion, data portability (Art. 28 revFADP), objection, and the right to complain to the Federal Data Protection and Information Commissioner (FDPIC). For the automated refusal described in Section 4.1, you can also state your position and ask for the decision to be reviewed by a person.
• Brazil (LGPD): confirmation that we process your data, access, correction, anonymization or deletion, portability, information about who we have shared your data with, and withdrawal of consent.
• California (CCPA/CPRA): know, delete, correct, opt out of sale/sharing (we do not sell or share), and limit the use of sensitive personal information (which includes biometric data).
• Biometric laws (Illinois BIPA, Texas CUBI, Washington): we obtain your consent before collecting biometric data, never sell, lease, trade or otherwise profit from it, and follow a written retention and destruction schedule. It is never part of a merger, acquisition or asset transfer (Section 6).

You can withdraw your consent to the counting of your ballot (Section 5.3) at any time: in the app, open Account → Verification → Withdraw my vote consent. Withdrawing covers every election you have voted in, and we record the day you withdraw it (Section 8). Withdrawing does not affect the lawfulness of counting your votes before you withdrew. A vote already counted stays in the party's total: your choice is part of that total and is not stored with your account, so there is nothing of it that we can remove separately (Section 9). Withdrawing does not shorten the times in Section 5.3 during which a ballot can still be linked to you. Your next vote asks for your consent again.

10.1 How to exercise them

There are two routes. The first answers access and portability on the spot, without asking anybody.

• In the app. Open your account settings; under Account there is a row called Your data. It builds a copy of everything we hold about you that we can reach from your account — a page you can read, and a machine-readable file you can hand to another service. It is built at the moment you ask, for the account that is asking, and it is stored nowhere: we keep no copy of it and there is no link anyone else could be sent. That is our answer to access and to portability, and you do not have to ask us for it. It does not carry the images your face checks left with us: they stay out of a file built to be handed on. Download them instead from Account → Verification, where they come as a file of their own — every image held under your own face checks, and never one held under anybody else's. Deleting your account is on the same screen.
• In writing. Everything else — rectification, restriction, objection, a question about data held by our providers (Sections 4.3 and 6), or a complaint about a decision — goes to privacy@worldrepublic.org.

Signing in leaves us no email address for you (Section 3.1), so we can normally only reply to an address you write to us from. There is one exception, and it is narrow. If you report a party, we keep the address you gave on that report, and we use it for that report and nothing else: to confirm we have it, and to tell you what we decided. We do not use it to answer a different question, to tell you about a change to this policy, or to send you anything you did not ask for. It is also part of the record of the decision, which is why Section 8 keeps it rather than dropping it once both messages have gone.

10.2 How long we take

Balázs Kónya, board member, is accountable for answering requests sent to privacy@worldrepublic.org, within the periods set out below. We do not promise a shorter internal deadline than the law requires: a target nobody operates is worse than the statutory one met, and the periods below are what we work to.

Time runs from the day your request reaches us — not from the day we finish identifying you, and not from the day we find what you asked for. Under the GDPR and the UK GDPR we answer without undue delay and in any event within one month of receipt. Where a request is complex, or where you have made several, we may take up to two further months; we will tell you within the first month that we are doing so, and why.

Where the law where you live sets something different, that is what we do:

• United Kingdom. If we reasonably need more information to identify you or to find what you have asked for, the clock pauses from the day we ask until the day you answer. We will ask only where we genuinely cannot proceed without it.
• Brazil. We confirm whether we process your data and give you access to it in a simplified form immediately, and in full within 15 days of your request.
• Switzerland. We answer within 30 days as a rule. The answer carries what Art. 25(2) revFADP requires it to carry, including the recipients or categories of recipient your data goes to and, where it goes abroad, which country and the safeguards we rely on — Sections 6 and 7 set both out in advance.
• California. We confirm receipt within 10 business days and answer within 45 days, which we may extend once by a further 45 days if we tell you why.

10.3 How we know it is you

We hold no identity document for you and no address on file, so the ladder below is what we have. We work down it and stop at the first step that identifies you.

1. Your signed-in account. The copy in the app, and the download of your face-check images, are built for the account that asks for them, in the moment it asks. Nothing identifies you better, which is why it is the first route in Section 10.1 rather than a convenience.
2. A passkey registered to that account. If you cannot reach the app, we may ask you to complete a passkey sign-in against a credential the account already holds.
3. The Google account linked to it. If you signed in with Google, we may ask you to show control of that account by signing in with it.
4. More information. If none of those is possible, we may ask you for further information we reasonably need to be satisfied the request is yours, and for no more than that.
5. A written refusal. If we still cannot be satisfied, we will tell you so in writing, within the time in Section 10.2, with our reasons and with the complaint route in Section 10.4. We would rather refuse a request we cannot place than answer it to the wrong person.

We will never accept a wallet address as proof of who you are. Withdrawals are made on public blockchains, so an address you have used is something anyone reading the chain can name; knowing it proves nothing, and signing a message from it would prove control of a key rather than of this account.

We will also not ask you for an identity document in order to answer a request. We hold no identity document to compare it against, so it would tell us nothing and would cost you more than the request is worth.

10.4 If we refuse

If we do not act on your request we will tell you why, within the time in Section 10.2, and we will tell you what to do next. You can complain to the data protection authority where you live — for EU purposes the Hungarian NAIH, in Switzerland the FDPIC, in the United Kingdom the ICO (Section 14) — and you can go to court. Neither depends on our agreement.

In the United Kingdom you also have the right to complain to us directly. We will acknowledge a complaint within 30 days and tell you the outcome without undue delay. Complaining to us is not a condition of complaining to the ICO.

10.5 What it costs

Nothing. Where a request is manifestly unfounded or excessive — in particular where it repeats one we have already answered — the law allows us to charge a reasonable fee or to decline, and if we ever do either we will say which and why. We would rather decline one request with reasons than put a price on the rest.

The machine-readable file and the download of your face-check images share a small limit on how many copies can be made in any 24 hours. That is not a fee and it is not about capacity: it is there so that somebody who gets hold of your session cannot quietly take your whole record away again and again. It never stops you reading the copy on screen, and it never stops you writing to us.

10.6 Two rights we do by hand

Access, portability and deletion are in the app and need no request. Restriction and objection are not. We hold no switch that suspends processing of one part of your record while leaving the rest working, so a request to restrict or to object is carried out by us, by hand, case by case, within the times in Section 10.2. Write to us, say what you want stopped and what it is about your situation that makes it matter, and we will weigh it and tell you what we did. We would rather tell you this is manual than let you infer it from how long it takes.

11. Security

We use TLS in transit and access-controlled storage. Direct access to our database is limited to the people we authorize to run the Service, our database and hosting providers, and the software we use to run the Service. We make a copy of our database only to test a change to the Service or to recover from a fault, and we delete it when that work ends. A copy holds the same data, and Section 9 says how long it keeps what we delete. No system is perfectly secure, but we work to protect your data.

12. Children

The Service is for adults 18 or older. Before we verify your identity we ask you to confirm you are 18 or older, and we do not verify anyone who does not. We record only that the confirmation was given and when; we do not ask for your date of birth.

We do not knowingly collect data from anyone under 18. If we learn that we hold data about a person under 18, we close their account and destroy their biometric data as Section 2 of our Biometric Retention and Destruction Policy sets out. If you believe someone under 18 has an account, contact privacy@worldrepublic.org.

13. Changes

We may update this policy. When we do, we publish the new text on this page and revise the "Last updated" date above. A change to this policy takes effect when we publish it. This policy describes what we actually do with your data, so it has to become true at the same moment the thing it describes becomes true; holding a change back for a month would only mean this policy was wrong for a month. That is not the same as the Terms of Use. The Terms of Use are the agreement between you and us, and Section 14 of the Terms of Use gives you 30 days before a material change to that agreement applies to you.

One change is slower on purpose. If we ever lengthen the period we keep biometric data, the longer period does not apply to data we already hold until the change has been published for 30 days. Section 6 of the Biometric Retention and Destruction Policy sets that out, and it governs the period stated in Section 4.5 and in the retention table in Section 8.

We cannot send you a notice when this policy changes. Signing in leaves us no email address, no telephone number and no postal address, because we deliberately keep none (Section 3.1), and the Service carries no banner or message that could tell you. If you have reported a party we hold the address you gave on that report — and we will not use it for this, or for anything but that report (Section 10.1). That is a consequence of keeping so little: apart from an address given on a report, we hold no contact details for you. Section 10.1 says the same thing about everything else — we can only reply to an address you write to us from. So this page is the notice: the current text is always here, and the date above is the date on which we last changed this policy.

This policy is written in English, and we publish it in other languages. The version that applies to you is the version in the language the Service showed you. Where that version and the English text differ, the meaning that is better for you applies.

14. Contact

• Privacy: privacy@worldrepublic.org
• Contact in the European Union: Balázs Kónya, board member, 3626 Hangony, Dózsa György út 5., Hungary (privacy@worldrepublic.org)
• EU lead supervisory authority: Hungarian National Authority for Data Protection and Freedom of Information (NAIH), Budapest — naih.hu
• Swiss supervisory authority: Federal Data Protection and Information Commissioner (FDPIC), Bern
• UK supervisory authority: Information Commissioner's Office (ICO), Wilmslow — ico.org.uk