Privacy policy

Who we are

UDAO SkillsValley AG, the operator named in the imprint at the foot of this document, decides what is held about you and why. Campaign is its platform.

Write to hello@udao.org with a question about this policy, or to make any of the requests further down. A product address on this domain is planned and this one answers until it exists.

What we hold, and why

Everything in this list is held because the product cannot do what you asked of it otherwise: sign you in, pay you, tell you what happened, and prove afterwards that what was paid was owed.

Your wallet address

It is your account. You sign in by signing a message with it, and it is the address a reward is paid to. Nothing else identifies you to us at sign-in: there is no password and no password material is held.

The email addresses you have verified

Used to reach you with notifications, to join a campaign you were invited to, and to match a completion a partner reports. An organization's report about any of them reaches your place on its campaign, so it can learn that an address it already holds is yours there. It reads no other address of yours, except the one your place is linked to once you tell it you've finished. Each address is stored beside a keyed hash of itself, and the hash rather than the address is what crosses to a partner feed. An address is either one you proved with a one-time code or one the sign-in provider verified for you.

The name you choose for your certificates

Printed on a certificate issued to you and nowhere else. You set it before your first certificate, and you can change it or remove it at any time.

Your passport and what it shows

A handle, a picture used inside the product, and which of your certificates the page shows. A passport is unlisted until you list it, and a certificate is on it only where you have said so.

The campaigns you joined, and each place

Which campaign you joined and when, what state your place is in, which of your verified addresses it is linked to, and the channel the join arrived through: a shared link, a code, an embed card, a link a partner put in its own product, or none of those. The channel is read from the link you used and never from a referrer. The place also carries the result of the screening step, which today is answered by a stand-in that passes everybody, refuses nobody and records no country: the only country held anywhere on this platform is an organization's own, in the row below.

An organization's details, its domain proof and its members

The name, the address slug, the country, the proved domain with how and when it was proved, a new name or website while it waits for our review, and the wallet that owns the organization's account, together with who its members are and the role each holds. Where the domain was proved by a code sent to an address at it, that address is kept with the proof, and each attempt keeps the address the code went to and who asked for it; the code itself is never stored. A member is a person, so this is personal data about the people who run an organization. Each member is held with the verified address they joined with, which the organization's owners see; a verifier or developer sees their own.

An address invited to an organization

An owner of an organization types an address to invite somebody to its team. The address is held in clear while the invitation is open and then only a keyed hash of it, which is what an acceptance is checked against. It is sent the invitation, and a one-time code if its holder accepts from an address we have not checked by code since the invitation was sent. Only that organization's owners can read the address back.

The addresses an organization invites to a campaign

An organization types addresses into a campaign invitation list. Each address is held in clear until the person joins, is removed, or the campaign settles; from that moment only a keyed hash of it is kept, which is the value a join is checked against. A campaign that is canceled or closed rather than settled keeps its list until an owner removes the addresses. The list is read at the join and nowhere else, and the organization's own owners are the only people who can read the addresses back.

The outcomes reported for you, and the decisions on them

What was completed, when, under which campaign, and the decision made on it with the verifier's note. A decision is never edited: a new record supersedes the old one and the chain of them is kept, which is how a refusal stays answerable. The organization running the campaign reads your place, the outcome and its decision. If you tell it you've finished, it also sees when you did and the address your place is linked to, until it decides.

A per-partner hash of a verified address

Where a partner names you by a hash instead of an address, the hash is computed under a salt derived for that one partner's credential. It means nothing to another partner and nothing to anybody who does not hold that salt.

What you write in a case

What you and the organization write to each other when you open a case about a decision, and anything you attach to it.

Your payout records

Which place was reserved and released for you, the amount, the fee taken from it, and the transaction that paid it.

Your certificates

The title and subject, the organization that issued it, whether you said yes to adding it to the public record and the words you were shown when you did, which are kept until you ask for deletion, and whether it has been revoked. A revoked certificate is shown as revoked rather than removed.

Your notifications and your preferences for them

What we sent you, in the product and by mail, and which categories you have switched off. Money and verification categories cannot be switched off, because a person whose reward failed has to be told. Campaign sends no marketing.

The audit log

Who did what, to what, and when: an attestation decision, a role change, a terms signature, a screening override, and every act of the platform on an organization. It is append-only and the actor is named in it, the platform included. It is how a decision about your reward stays reproducible.

Your acceptance of the terms

The signed message, the signature, the version of the terms you accepted and the build of the site that showed it to you. It is append-only, so what you agreed to cannot be rewritten afterwards.

Short-lived plumbing that makes a request work

A sign-in nonce bound to your address for ten minutes and spent once; a single-use code that loads your status card inside a partner's page for ten minutes; and the counters that bound how fast a partner's server may call us. None of it outlives the request it exists for.

Visit counters

Per campaign, per day, per channel, a count of page requests. They count requests and not people, and they hold nothing about you: no address, no identifier, no location.

Some of this is written to a public blockchain, which is Polygon. What goes there is your wallet address and the amounts paid to it; and, for a certificate you said yes to adding to the public record, a reference to it at an address of its own, separate from your wallet and its payments, and used for nothing else: never your name, never an email address, never anything you wrote in a case. A certificate goes there only on your own yes, one certificate at a time, and we send it; nothing is added without that yes, and the organization that issued it cannot add it.

Anyone can read what is on the chain, and nobody can change or remove it, ourselves included. Hiding a certificate on your passport takes it off our pages, and does not take it off the public record once you added it. A request under this policy reaches what is in our own database and does not reach the chain. That is true before you are paid anything, which is why it is written here and not further down.

Who processes it for us

Six parties handle some of this on our behalf, and each of them is here because the product runs on it or the code names it. The public chain is listed under them, because what reaches it is nobody else's to handle.

Our database is in Zurich, Switzerland, and our servers run in Frankfurt, Germany. Some of the companies below are in the United States or reach the data from there, so each row names where your data goes and the basis Swiss law gives for sending it there.

Vercel

Hosting. The site and its servers run there, so every request you make reaches us through it.

Where:

Frankfurt, Germany, for the servers. A request first reaches Vercel's network at its point nearest you, which may be in another country. Vercel, Inc. is in the United States and can reach the data from there, where its data processing terms place its main processing facilities. Vercel does not publish where it keeps its request logs.

Basis:

Germany is on the Federal Council's list of countries with adequate protection (FADP Article 16(1)), and Vercel, Inc. is certified under the Swiss-U.S. Data Privacy Framework, which the Federal Council recognizes (FADP Article 16(1)).

Supabase

The database and its backups. Everything named in the list above is stored there.

Where:

Zurich, Switzerland, for the database and its backups. Supabase Pte. Ltd., the company we contract with, is in Singapore, and Supabase, Inc. is in the United States; both can reach the data from there to run the service.

Basis:

The data is stored in Switzerland. Where Supabase reaches it from abroad, the standard contractual clauses in Supabase's data processing terms apply, with their Swiss paragraph, and they form part of the terms we accepted (FADP Article 16(2)⁠(d)).

SendGrid

Mail. A notification, a one-time code, a campaign invitation and a team invitation are sent through it, so it handles the address the message goes to and what the message says: a reward's amount in a campaign invitation and in the mail that says a reward was paid, and never a wallet address.

Where:

The United States and the European Union, where the mail is routed and sent. Twilio Inc., which runs SendGrid, is in the United States.

Basis:

The standard contractual clauses in Twilio's data protection addendum (FADP Article 16(2)⁠(d)).

thirdweb

Wallets and sign-in, and the network fee of a payment you collect yourself. Where you sign in by email rather than with your own wallet, it is the provider that holds that account.

Where:

The United States, where Non-Fungible Labs, Inc., the company behind thirdweb, is and processes what it is sent.

Basis:

Sending it what it needs is directly connected with the service you asked us for: signing you in, and paying the fee of a payment you collect (FADP Article 17(1)⁠(b)).

QuickNode

Chain reads and the submission of our transactions. It answers what the public chain already says and it is the endpoint every transaction we send is broadcast through, a certificate added on its holder's yes among them, and we send it no personal data beyond the addresses the chain itself carries. No second endpoint stands behind it today: where it cannot be reached, chain reads and the transactions we send wait until it answers again.

Where:

The United States, where Quiknode, Inc. is. Its network is spread around the world, so a request may be answered in another country, and QuickNode does not publish which countries its servers are in.

Basis:

Sending it the addresses and the transactions it carries is directly connected with the service you asked us for: paying your reward, and adding a certificate on your yes (FADP Article 17(1)⁠(b)).

Stripe

Card payments for a certificate plan. When an organization's owner chooses a plan on Campaign, the link to Stripe's page carries the organization's reference and the email address that owner verified first, so the page opens with it filled in. Stripe takes the card and the billing details on its own page and tells us which plan an organization bought; we keep Stripe's customer and subscription references and never a card number.

Where:

Ireland, where Stripe Payments Europe, Limited, the company we contract with, is. It passes the data to Stripe's company in the United States, and from there to the companies Stripe works with in other countries.

Basis:

Ireland is on the Federal Council's list of countries with adequate protection (FADP Article 16(1)). Stripe's United States company is certified under the Swiss-U.S. Data Privacy Framework, which the Federal Council recognizes (FADP Article 16(1)), and where that certification does not apply, the standard contractual clauses in Stripe's data transfers addendum, adapted for Switzerland, do (FADP Article 16(2)⁠(d)).

The Polygon network

The public chain. It is not a processor anybody could instruct: what reaches it is public and cannot be removed, which the section above says plainly.

Where:

Nodes run by many independent operators in many countries.

Basis:

A certificate goes there only on its holder's explicit yes (FADP Article 17(1)⁠(a)); a payment's addresses go there because paying the reward needs it (FADP Article 17(1)⁠(b)).

That is the whole list. There is no analytics vendor, no advertising vendor, no data broker and no tracking product of any kind behind this site.

How long we keep it

Each period below is the one the code enforces, not an intention.

Your session

A signed cookie that lives seven days. Signing out ends it at once, and so does Sign out everywhere on your profile, which ends every session you have open at once.

A one-time code

Spent once, and ten minutes at the outside. The code itself is never stored: what is held is a keyed value the typed code is checked against.

A sign-in nonce, or the code that loads a card in a partner's page

Ten minutes, and it is spent the first time it is used.

An invited address

Held in clear until the person joins, is removed, or the campaign settles, and after that only the keyed hash remains. The hash means nothing to anybody who does not hold the key it was computed under, and that key is held by us alone and never leaves. A campaign that is canceled or closed rather than settled keeps its list until an owner removes the addresses.

An address invited to a team

Held in clear until the person accepts or declines, the organization revokes the invitation, or it expires seven days after its last message (or after it was written, if no message went); after that only the keyed hash remains. Where its holder accepts with a one-time code, the record of that code (who asked, and with which of their addresses; never the code itself) is deleted seven days after it was written.

Evidence, outcomes, payout records and certificates

Kept for as long as the campaign's record must exist: they are the record a reward was paid against. The evidence and the outcomes are append-only, so a decision is superseded and never edited; the payout records and the certificates are kept and never deleted, and a certificate that is taken back is shown as revoked rather than removed. No shorter period is set today. Setting one is a material change, and this policy would say so before it took effect.

The audit log and your acceptance of the terms

Kept. Both refuse an update and a delete at the database itself, because a record that could be rewritten would prove nothing.

The two cookies that remember what you have put behind you

They live one year and carry a list of organization identifiers and nothing about you.

What is on the chain

For as long as the network exists. Nobody can remove it, ourselves included, and no request under this policy reaches it.

Cookies

Four, and every one of them is needed for something you asked the product to do.

__Host-campaign_session

The signed session, seven days. It is readable by the server alone, it is accepted only from this exact host, and it carries an identifier, your wallet address and two timestamps.

__Host-campaign_email_challenge

Holds the one-time code challenge while you type the code, ten minutes. Readable by the server alone, and gone the moment the address is verified.

campaign_checklist_dismissed

Remembers that you put the getting-started checklist behind you, one year. A list of organization identifiers, nothing more.

__Host-campaign_org

Remembers which of your organizations Campaign shows, one year. One organization identifier, checked against your membership on every page, and cleared when you sign out.

Beside those five, signing in with the wallet provider leaves that provider's own connection state in your browser's storage rather than in a cookie. It is what keeps your wallet connected as you move between pages, and signing out removes it.

There is no analytics cookie, no advertising cookie and no third-party cookie on this site, and nothing in that storage is there to watch you, so there is no consent banner: there is nothing here to ask you to agree to.

Your rights

Under the Swiss Federal Act on Data Protection you can ask for a copy of what we hold about you, ask for a correction, ask for deletion, and object to a particular use. Where the European rules apply to you as well, the same requests are honored under them.

Write to hello@udao.org from an address you have verified, or from any address if you tell us your wallet address, and we answer within 30 days.

What deletion does not reach, said here rather than in a footnote. What is on the chain cannot be deleted by anybody, ourselves included, so a deletion reaches our database and not the public record of a payment. Money that has been committed and the integrity of a certificate are the two carve-outs the rules behind this product name: the evidence a reward was paid against, the payout record and the certificate are kept, because they are the proof that what was paid was owed and the proof that a certificate means what it says. And the audit log and your acceptance of the terms are never removed at all: the database itself refuses an update and a delete on both, which is the answer the section above gives as well. A deletion does reach every record we keep that connects you to a certificate you added to the public record: the reference stays there, without your name or any address of yours. When we answer we say exactly which records those are and what was deleted.

Changes to this policy

A material change to this policy is announced 30 days before it takes effect, by mail to the addresses you have verified and on the platform itself.

The version and the date at the head of this document say which text you are reading. This one is a draft: it is written from the product and its own documents, and no lawyer has read it yet.

Which law applies

Swiss substantive law applies to this policy and to the handling it describes, and the courts of Zug have exclusive jurisdiction. Where the European Union's General Data Protection Regulation applies to you, it applies as well, and nothing in this clause sets it aside.

Imprint

The operator named in the block at the foot of this document is the entity this draft names, and it is confirmed before public launch. This draft is not legal advice and has not been reviewed by counsel.