Privacy Policy

Last updated: 13 September 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; the token is dropped and never stored. We deliberately do not store your Google name, email, or photo.
• 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 and a referral code. We generate a username for you when your account is created, and you can change it 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. If you arrived through someone's referral link, we also record the invitation: which account invited you, and when. That record names both accounts, and Sections 8 and 9 say how long we keep it.
• Content you create: political party names, descriptions, and links.
• 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, and when.
• 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. The ballot is secret: your choice is added to the party's total and no record links it to you (see Section 5).
• 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 accept our Terms and Privacy Policy or give biometric consent, as proof of that consent.
• 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 we record that a copy was made, when, that it was the file, and which parts of the record it carried. 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 — including referral links — 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. referral capture, 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, and because it was briefly available in mid-2026.

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 — every check made during that earlier period was deleted from Didit in September 2026. 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.

We keep our own record of each check made in that period. That record is the status of the check, the status of each step inside it, the provider's reference for the check and for you, and, where the check read one, the expiry date of the identity document — we use that date to tell whether the check that read it is still current. We hold no image of that document and nothing else taken from it. Section 8 says how long we keep the record, and Section 9 says that deleting your account deletes it.

If the escalation is ever offered again, 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 again) 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: the escalation is not offered, and the checks made while it briefly was were deleted from Didit in September 2026. Should it ever be offered again, 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 image and the facial template we compare it against. 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. 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 cancelled, because the new face check is a new consent; deletion is never cancelled this way. Because the ballot is secret, a cast vote cannot be withdrawn, 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. It runs on Baseten in the United States (Sections 6 and 7), which keeps nothing of the 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 and which check decided 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.

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) — two things. Amazon Rekognition Face Liveness, Amazon S3 (reference images), and Amazon Cognito (temporary guest credentials), as our service provider for biometric verification (EU region). And Amazon Simple Notification Service, which carries our operational alerts. 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.
• Thirdweb — executed WDD blockchain withdrawals until 27 August 2026, and received the same data. Thirdweb sends nothing for us now. We still ask Thirdweb what it did with the withdrawals it handled, so that our own record of them is correct.
• 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 Section 5.1 to Baseten and nowhere else.
• Baseten — runs the language model that reviews party registrations (Section 5.1); 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 organisation. 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.
• The ambassador leaderboard. If people create accounts through your referral link, your username, the number of people who joined through that link, and the total WDD you have earned from those invitations appear on the ambassador leaderboard. The leaderboard is shown to anyone signed in to the Service, and the data behind the leaderboard can be read without an account, so treat it as public.
• The person who invited you. If you joined through someone's referral link, that person sees your username, the date you joined through the link, and the party you lead, if you lead one.
• 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. Your ballot is not: no record links your choice to you (Section 5).

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).
• 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 Section 5.1, 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. Withdrawals started before 27 August 2026 were sent by Thirdweb, also a company based in the United States. We send Thirdweb nothing new. We still ask Thirdweb about those older withdrawals, so that our own record of them is correct.
• 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).
• 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 today, because it is not offered and no check can be started. Checks were taken while the route was briefly offered in mid-2026, and what Didit held was deleted in September 2026 (Section 4.2). 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 again, 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. The operational alerts described above are carried under the same agreement, in whichever Amazon region we have configured for those alerts.
• 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.
• Thirdweb: no data processing agreement and no transfer clause of any kind. There is no transfer safeguard in place for this recipient. What Thirdweb holds is the destination address, the amount, the chain and the reference of a withdrawal started before 27 August 2026 — the same facts the blockchain itself publishes. We send Thirdweb nothing new; we only ask it about those withdrawals.

Where an adequacy decision covers a transfer — the European Union and Switzerland each recognise 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, deletes our record of any Didit check, 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.

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 — never which party you voted for. No record anywhere holds your choice (Section 5). 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. We also keep the total you claimed from the basic income and savings features, which the Service no longer offers. This is our record of the WDD we have awarded and the WDD we have paid out (Section 8).
• Your referral code, and the record of who invited you and whom you invited — kept so that each invitation, and the rewards on both sides of that invitation, stay correct. Your entry on the ambassador leaderboard stays as well — the number of people who joined through your referral link, and the total WDD you earned from those invitations (Section 6). The name shown on that entry is the randomly generated username. Accounts deleted before we settled that rule may still show the username the citizen chose, or a name derived from an internal identifier; write to us and we will replace it.
• The evidence of each consent you gave and each one you withdrew — which document, which version, when, and, for consents recorded since we began keeping them, the language and the screen the statement was shown on (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, on the same terms as the leaderboard entry above: for accounts deleted before we settled that rule, the leader name may still be the username the citizen chose, or a name derived from an internal identifier.
• 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 dates on the account itself — when the account was created, when it last changed, when it was deleted, and, if you used the basic income and savings features the Service no longer offers, when basic income was switched on, when you last claimed it, and when your savings account last moved. These are dates, not amounts; the amounts are in your WDD record above.

Those records are pseudonymised, 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, with one exception named above: for accounts deleted before we settled the rule, a leaderboard entry or a party's leader name may still show the username the citizen chose — and a username can be a person's own name (Section 3.1). Almost all of these records stay attached to the same internal identifier, so they can still be read as the records of one account. Two kinds of record are exceptions to that, and both are 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 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).

Votes you have cast stay counted. The ballot is secret, so there is no record of your choice to remove. 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). 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, anonymisation 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).

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. 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.

We hold no email address for you (Section 3.1), so we can only reply to an address you write to us from. There is no other channel: we cannot email you, message you or notify you about anything you did not start.

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 is built for the account that asks for it, 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 has a small limit on how many times a day it can be built. 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, access-controlled storage, and least-privilege access. 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. We hold no email address, no telephone number and no postal address for you, because we deliberately collect none (Section 3.1), and the Service carries no banner or message that could tell you. That is a consequence of collecting so little: we cannot contact you because we never asked you for contact details. 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