EarnHub Privacy Policy

This Policy will be published at https://earnhub.space/legal/privacy and referenced from the EarnHub Android app and its Google Play listing. It is one document for all three audiences of the Platform: Clients, Agents, and website visitors.

Amended 2026-08-25 on two points where the text had gone out of date or was silent. (a) The mail processor changed. Until 2026-08-24 all Platform email left through a single Google account; since that date it is sent through Resend (Plus Five Five, Inc., United States) over its HTTP API, with one sender address per audience. Sections 10, 11 and 12 are corrected accordingly; the superseded Gmail line is kept, struck through, in the Section 10 table because it explains the historical mail archive. (b) The company-verification (KYB) correspondence with third parties is now stated as its own disclosure, in a new Section 9.8 — we write to a person at an outside company, name our Client to them, and keep their reply. The former Section 9.8 ("What we do not do") is renumbered 9.9.

Amended 2026-09-09 on one point. A disclosed recipient was removed. Until this date the Section 10 table named Binance (crypto exchange) as receiving Agent payout details. That disclosure was made defensively, because the Platform's code contained a payout route that would have sent them: no payout was ever made through it and no Agent data ever reached Binance — the route carried zero withdrawals in the Platform's entire history, was closed on 2026-08-30, and was removed from the code, the database and the configuration on 2026-09-09, together with the credentials that would have addressed it. The row is deleted rather than struck through, and the distinction is deliberate: a struck-through row in that table means "this transfer happened and has ended" — as the superseded Gmail line does — and this transfer never happened. Agent payouts are made only over the public blockchain networks named in the row that followed it.

Amended 2026-09-14 on one point. Account deletion got its own section. Section 13.3 now says, in one place, how an Agent deletes their account in the app and how a person without the app requests it by email, and what is kept afterwards — it is the account-deletion resource the Google Play listing links to. Nothing about what is deleted or kept changed; the text was already in 13.2 and Section 12.

Amended 2026-09-14 on a second point. What a restricted account leaves behind. If an account is frozen or blocked at the moment it is deleted, we now keep a small record that lets us apply the same restriction if the same phone number or email address registers again — one-way hashes of that number and address, not the values themselves, plus the restriction, the reason we gave you and the date. Sections 12 and 13.3 say so. For every other account nothing changed: deletion leaves nothing behind that this record describes.

Amended 2026-09-15 on one point. What the support desk keeps. The Section 12 table now carries a row for the support desk: every letter to support@mail.earnhub.space and our answers are stored in full on our own systems for as long as the account they concern is a matter of record, and are not deleted with the account; an attachment stays with the email provider for its 30 days unless an operator keeps it as the evidence behind a decision about an account, in which case that one file is copied to our own storage and kept with the thread. The desk itself has existed since 2026-09-04 and was named in Sections 1, 13 and 18; its retention was not stated.

Amended 2026-09-24 on three points. (a) SMS Test results stay with the Client when you delete your account. Since 2026-09-23 the results of SMS Tests you delivered — including the phone number that received the message, the sender and the message text — remain part of the commissioning Client's records after your account is deleted, as the results of every other Task always have; Sections 12, 13.2 and 13.3 no longer list "SMS Test history" among what deletion removes. (b) What the app reports about itself. A new Section 3.10 describes the technical events the Android app sends about its own operation and, from the version of the app that adds it, the crash reports it sends to Google's Firebase Crashlytics; Sections 6, 9.9, 10 and 12 follow. (c) Our event records. Sections 12, 12.2, 13.2 and 13.3 described an "analytics event store" with no expiry that account deletion did not reach. That store was retired in September 2026. Its successor, the event journal described in Section 3.8, is kept for 12 months in our database and afterwards only in an archive from which email addresses, IP addresses, phone numbers, message texts and wallet addresses are removed, and deleting your account erases your entries from it.

Amended 2026-09-26 on five points. (a) Observed OTP Reports. A new kind of Task — you ask a service for a one-time code and report how it arrived — is described in Sections 2, 3.4, 8, 9.4, 9.5, 12 and 13: what a report carries (the channel, the code you type, your comment, three times stamped by our servers, and your screenshots or screen recordings, which show everything that was on your screen), that the Client receives the code and the captures no earlier than 30 minutes after you send the report, and how long each is kept. (b) Who runs the automated checks. Section 10 now names every provider that receives content for them: DeepInfra, reached directly; Google, which hosts the Gemini models; OpenAI, for the text of a Task; and Alibaba Cloud, which receives identity documents only when the first route of a check fails. (c) What the app reports about itself. Section 3.10 lists everything the app's technical events can carry — including, when something fails, the names of the app's screens you passed through just before — and says what we never record and never do with them. (d) Push notifications. From the version of the app that adds them, notices reach your phone through Google's Firebase Cloud Messaging; Sections 3.10, 9.9, 10 and 12 describe the identifier and the operator topics this involves. Section 3.9 also now says that the app asks for the camera and precise location when you take a photo or a video for a Task. (e) How an Observed OTP Report is checked. Section 8 now says that the check judges a report on its screenshots — a screenshot is always required, and a screen recording is checked only for showing the Task — and that it writes down the code it read off your screenshots and compares it with the codes you reported before for the same service; Section 12 says how long that record is kept. Section 3.4 no longer asks you to crop your captures: it asks you not to send anything in them that you would not want others to see.

Amended 2026-09-27 on one point. The content check listens to the soundtrack of a Client's video. Section 8.1 now says that when a Client uploads a video to be shown to Agents — a file for a Task, an example in a Task's description or a chat attachment — the automated moderation model also listens to its soundtrack, in a check of its own, and that a silent soundtrack is not sent; an Agent's video, and a video a Client provides for verification, is checked for content safety on its frames only, as before.

Amended 2026-09-28 on one point. An Agent's video is heard when a Client hands it on. Section 8.1 now says that when a Client puts a video an Agent delivered into a Task, to be shown to other Agents, the automated moderation model also listens to its soundtrack, once, before those Agents receive it; a silent soundtrack is not sent. Until a Client does that, an Agent's video is checked for content safety on its frames only, as before. If the soundtrack does not pass, the video is not given to other Agents; the Client who received it keeps it.

Amended 2026-09-29 on one point. Two more details the app reports about itself. Section 3.10 now says that each time the app looks for an SMS Test's message it also reports how many of the messages it found came before the test started by the phone's own clock, and how far that clock was from ours; and that when an upload fails and the app tries it again, the failed attempt is reported — which part of the file, which attempt, how much had been sent and the kind of failure.

Amended 2026-09-29 on a second point. DeepInfra is now the first route of more checks. Since 2026-09-26 the check of chat messages, the launch check of a Task, the checks of Agent submissions and of Observed OTP Reports, and the logo check first go to Google's Gemma model hosted by DeepInfra, which we reach directly, instead of through OpenRouter; OpenRouter remains their fallback. The Section 10 table is corrected: DeepInfra is the first route of every automated check except file moderation and company (KYB) research.

Amended 2026-10-01 on five points. (a) What we keep about a Task's launch check and about a restricted company account. Section 12 now says that the record of each check of a Client's Task before it runs, and the history of every freeze or block of a company's account, are kept for as long as the Platform operates: they are the record behind decisions about accounts. (b) Your phone's model and time zone come from the app. Sections 3.1 and 9.3 no longer list them among the attributes you choose to provide: from the version of the app that reports them, the app tells us your phone's model and its time zone, and they are attributes the Platform derives. (c) App permissions. Section 3.9 now says when the app asks for each: notifications once, when you first open the app after signing in; the camera when you take a photo or a video for a Task; your location only for a Task whose files must carry one, and your precise location only where the Task names a place to be near. (d) Push notifications after you are signed out. Sections 3.10 and 12 now say that notices stop reaching your phone however you were signed out — in the app, by your session expiring, or by us, a block of your account included — and when the identifier is deleted. (e) Observed OTP Reports. Sections 3.4 and 9.4 now say that before your first report the app tells you, once, that the Client receives your screenshots and recordings.

Amended 2026-10-06 on six points. (a) Identity verification and app updates in the app's technical events. Section 3.10 now lists what the app reports while you go through identity verification — that you opened a step, that a capture failed or was tried again and at which stage, that you left a step unfinished — and that it asked you to update it. (b) A request's identifier. Each request the app makes now carries a random identifier made for that one request, which our servers write into their own record of it; a technical event about a failed request carries the same identifier, so the two records can be matched (Section 3.10). (c) The identifier of a launch is kept with the events not yet sent. Section 3.10 used to say that the random identifier of one launch of the app is never stored on your phone; it is now kept in the app's encrypted storage beside that launch's events, and only until they are sent. (d) The mobile network. From the version of the app that adds it, every technical event also says which mobile network your phone's data connection is registered on — which shows the country that network is in — and whether the phone is roaming (Section 3.10). (e) How long our event records are kept. Section 12 now says that the event journal (Section 3.8) is kept seven days in our database, not twelve months, and that every entry of the journal and every technical event of the app first passes through our event log, which keeps it as received for nine days; deleting your account now erases the app's technical events from our database too (Sections 13.2 and 13.3). (f) Notifications and consent. Section 12 now says that the notices in your in-app inbox are kept for about two to three months, not one, and that deleting an account does not delete them sooner; Section 7.2 now says that you withdraw consent by deleting your account, in the app or by writing to the support mailbox.

Amended 2026-10-07 on two points. (a) Your in-app notices go with your account. Section 12 used to say that deleting an account leaves the notices in its in-app inbox until their month is dropped; deleting an account now deletes them, and the record of which of them were read, with it — an Agent's within minutes of the deletion, a Client seat's at the moment the seat is deleted (Sections 12, 13.2 and 13.3). (b) Who did what on a Task. Section 12 now says that the record of what was done on a Task — by the Client's seats and by EarnHub staff, staff named by their work address — is kept as long as the Task, and a deleted draft's for our support's record.

Amended 2026-10-09 on three points. (a) A Task aimed at an answer kept on your phone. Section 7.3 now says what else protects you when a fully verified Client aims a Task at your religion, political views or marital status: such a Task runs only when at least 20 Agents who are asked the question fit its other conditions — and an Agent that Client has chosen to ignore is not counted among them — so that an answer cannot point at one person; its results never say who answered; the work you do on it moves none of the statistics Clients see about you, while you are paid for it as for any Task; and while it runs our staff can see what it aims at and who took it. (b) How recently you were in the app. Clients now see it only to the day, as of the start of the current day (UTC), for every Agent — never the time of day (Sections 7.3 and 9.3). (c) Our web server's error log. Section 12.2 no longer speaks of a frozen archive of old access logs, which is gone; it now says that the web server's error log, which can hold a visitor's IP address and the address of the page asked for, is not yet limited in time.

Amended 2026-10-09, a second time, on two points. (a) A Task that asks about you. A new Section 7.4 says what happens when a Client's own Task asks you about your health, your faith, your political views, your family (your marital or relationship status, or something sensitive about a relative), your ethnic origin, your sex life or a criminal record — a survey for a drug developer about your symptoms, for example. Our check of every Task before it runs marks such a Task; only a fully verified (Pro+) Client may run it; you are told what it will ask about and asked to agree before you take it, every time; its results reach the Client without saying who answered, under the same rules as in Section 7.3; and we do not copy your answers into our event records. Section 7.1 lists these answers among the sensitive data we process. (b) Our event records. Section 12 now says that the event journal (Section 3.8) and the app's technical events (Section 3.10) are kept while your account exists: before reaching our database every entry passes through our event log, which keeps it for nine days, and the database is backed up every night, encrypted, each backup deleted 21 days after it was made. Deleting your account erases your entries from our database within minutes, from our event log within nine days and from our backups within 21 days (Sections 12, 13.2 and 13.3).

Amended 2026-10-10 on one point. An Observed OTP Report is taken on one of your phone numbers, and the Client receives it. When you take an Observed OTP Report you now pick one of your SIMs on a network the Client chose — on any network we know, when it chose none — and you ask the service for the code on that number; a Task aimed at networks none of your SIMs is on is not offered to you. We record the number and its network with the report, and the Client who ordered the Task receives them with it at once, as it receives the number of an SMS Test — except on a Task whose results never say who answered. Our automated check refuses a report whose screenshots plainly show the code going to another number, or arriving on another network's SIM (Sections 2, 3.3, 3.4, 8 and 9.4). Until this date the Policy said that we never receive your phone number with a report and that we do not pass it to the Client; both statements are replaced.

Amended 2026-10-12 on one point. Our support staff may read what the app reported about its own running on your phone, when you tell us about a fault. The technical events of Section 3.10 were read only by our engineers; from this date a member of our support staff may also read the ones from your account, one Agent at a time, to answer a fault you reported to us — «my answer would not send» is answered from what your phone recorded. They are never read across Agents and, as before, never used to decide anything about you (Section 3.10).

1. Who we are

1.1. The EarnHub platform is operated by [ENTITY LEGAL NAME], a company incorporated in the RAK Digital Assets Oasis free zone, Ras Al Khaimah, United Arab Emirates ("EarnHub", "we", "us", "our").

1.2. For the purposes of United Arab Emirates Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (the "PDPL"), we are the controller of the personal data described in this Policy, except where Section 4.3 says otherwise (data uploaded by Clients, for which the Client is the controller and we act as processor).

1.3. We are a small company. All privacy requests are handled by our team through a single support mailbox: support@mail.earnhub.space (Section 18). We do not currently have a dedicated Data Protection Officer.

2. Definitions

• "Agent" — a natural person who uses the EarnHub Android app to perform paid Tasks.
• "Client" — a company (and the natural persons acting for it) that uses the web Portal at earnhub.space to create Tasks and receive results.
• "Task" — a paid micro-job on the Platform: an SMS Test, an Observed OTP Report, or a generic task (for example, collecting photos or data, or processing data supplied by a Client).
• "SMS Test" — a Task in which an Agent receives a real SMS message (typically a one-time code) on their own SIM card so that a Client can measure SMS deliverability. The app reads the message itself (Section 3.4).
• "Observed OTP Report" — a Task taken on one of the Agent's phone numbers, in which the Agent asks a service from our catalogue for a one-time code — usually with that number, or with their account on that service — and reports how and when it arrived — the channel, the code as they received it, and screenshots or a screen recording as proof — or that it did not arrive (Section 3.4).
• "ERN" — the Platform's internal credit unit, with a displayed exchange rate to USDT.
• "Platform" — the EarnHub services collectively: the Client Portal (earnhub.space), the Android app for Agents, the public websites on earnhub.app and earnhub.io, and the supporting backend services.
• "PDPL" — UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data.
• "Sensitive Personal Data" — data given special protection by the PDPL, including biometric data, health data, and data revealing religious beliefs or political views.
• "Verification" — the identity (KYC) and company (KYB) checks described in Sections 3.2 and 4.2.

3. Personal data we process about Agents

We collect the following categories of personal data from and about Agents. We collect what is listed here and nothing beyond it; where a category is optional, we say so.

3.1. Account and profile data

• Account identity: email address, username, password (stored only as a salted hash), interface language, app version, account settings; if you sign in with Google, the Google account identifier Google provides to us.
• Profile and targeting attributes you choose to provide in the verification questionnaire, used to match you with Tasks: age, gender, region, education, employment, height, weight, clothing size, spoken languages and native language, your profession, your household's income range (asked from the Pro level), your pets, the transport you use, your type of housing, the devices you have at home, and the messengers and social apps you use. Each question says under it which kind of Task needs it; every one is optional, and you can remove an answer you gave at any time. The Platform also derives some attributes itself: your country, your mobile operator, your phone's model and its time zone (which the app reports, from the version of the app that does so), and your activity and earnings statistics. We do not ask for, and do not hold, your religion, your political views or your marital status — if the app asks them, the answer stays on your phone (Section 7.3). See Section 9.3 on how Clients see these attributes.
• Two-factor authentication data: if you enable 2FA, the TOTP seed for your authenticator app.

3.2. Identity verification (KYC) data — including biometric data

If you apply for a Verification level, we process, depending on the checks that level requires:

• Identity documents: photographs of the front and back of your ID document, and a proof of address document; the text we extract from them (name, document number, address), which we store encrypted.
• Liveness video: a short video of your face recorded during the guided liveness check.
• Face embeddings: a numerical template derived from your face image, which we use to verify that your ID matches you and to detect duplicate accounts (your template is compared against other Agents' templates for this purpose). Face embeddings and liveness video are biometric data and are Sensitive Personal Data under the PDPL. See Section 7.
• Phone verification data: your phone number, and — depending on the method — an automated verification call, or your Telegram account identifier if you verify by sharing your contact through Telegram.

3.3. Phone, SIM and device data

To run SMS Tests and Observed OTP Reports we need to know which SIM cards and operators you use. The app sends us, for each SIM you register: phone number, operator and carrier name, carrier identifiers (MCC/MNC), SIM and network country, SIM slot and subscription identifiers, and roaming status. We also process your device model, app version and language.

3.4. One-time codes: SMS Tests and Observed OTP Reports

SMS Tests. When you take an SMS Test, the app — using the Android SMS permission you grant — reads the most recent messages received on your phone after the moment the test started (up to about ten messages), and shows them to you on your device so you can pick out the test message. That on-device list is filtered by time and — on most phones — by the SIM you connected, not by sender: on some phones the list can also include messages arriving on your other SIM, and a personal message that happens to arrive during a test can appear in it; the list itself is never sent to us — only how many messages it held (Section 3.10). Only the message you select — its text, sender identifier and timestamp — is transmitted to us and stored as part of the SMS Test record, and made available to the Client that commissioned the test (Section 9.4). Test messages are typically one-time codes sent by the service under test.

Observed OTP Reports. In an Observed OTP Report you ask the service named on the Task — one from our catalogue — for a one-time code, the way that service asks for it: usually with your own phone number or your account on that service. The service therefore learns what you give it, as in any sign-in. Each report is taken on one of your phone numbers: when you take the Task you pick one of the SIMs in your phone that is on a network the Client chose — on any network we know, when it chose none — and you ask the service for the code on that number; a Task aimed at networks none of your SIMs is on is not offered to you. We record that number and its network with the report from the moment you take the Task (we know your SIMs as Section 3.3 describes), and the Client receives them with the report (Section 9.4). The report you send us carries:

• your answers: the channel the code arrived on — SMS, WhatsApp, Telegram, a voice call, a flash call, a push notification or email — or that it did not arrive; roughly how long it took; the code itself, typed by you exactly as you received it (for a code that arrived by SMS, typing it is optional); and any comment you add;
• the times, stamped by our servers rather than your phone: when you pressed «I requested the code», when you sent the report, and the time between the two;
• your proof: at least one screenshot — always — and a screen recording when the Task asks for one; for a code that did not arrive, a screenshot of the service's screen showing that a code was requested. You make them with your phone's own tools and choose them from your gallery through Android's photo picker; the app never records your screen and needs no storage permission to attach them. We keep each file's technical metadata as we do for any Task media (Section 3.5).

A capture shows everything that was on your screen when you made it — other conversations in a messenger's chat list, names and numbers in a call log, your own phone number typed into the service's form, notifications that arrived meanwhile. We do not crop, blur or edit captures: the automated check (Section 8) and the Client (Section 9.4) see each one exactly as you sent it. So do not send anything personal or confidential in a screenshot or a recording — yours or anyone else's — that you would not want other people to see: the Client who ordered the test receives it. The app tells you this once, before your first report, and reminds you of it where you attach your captures. The app does not read your SMS inbox for an Observed OTP Report: a code that arrived by SMS is reported and proved like any other.

3.5. Task submissions, location and media metadata (GPS/EXIF)

Some Tasks require photos, videos, audio or answers collected or produced by you. We process the content you submit for a Task, and for media files we extract and store their technical metadata (EXIF), including GPS coordinates and capture time, which we use to verify the submission is genuine. Media you submit may also incidentally show other people or places; Section 9.5 covers that. Accepted submissions are delivered to the Client that commissioned the Task and become part of that Client's Task records (Section 13.2 explains what this means for deletion).

3.6. Wallet, balance and payout data

We process your ERN balance and earnings history, and, when you withdraw earnings: your withdrawal amounts, your recipient cryptocurrency wallet address (and address tag/memo where applicable), transaction identifiers, and your withdrawal history. Withdrawals are paid in USDT. On-chain transactions are public: your wallet address and the transferred amount become part of a public blockchain record that we can neither edit nor delete (Section 9.6).

3.7. Chat

Messages you exchange with Clients through Platform chat: message text, machine translations, attachments, and moderation status. Every chat message with text is automatically checked by a moderation system, and translated messages are processed together with up to 30 prior messages of the conversation for context (Section 8).

3.8. Technical and security data

IP address and an approximate location (country, city and approximate coordinates) derived from it — the derivation happens on our own servers using a local database; your IP address is not sent to any geolocation provider. We also keep an event journal: a record of what happens on your account — sign-ins, Task and SMS Test activity, withdrawals, verification actions — with the time of each and, where the action involved them, the IP address and the location derived from it, your email address, the phone number and SIM details, the device and app version, the withdrawal wallet address and, for an SMS Test, the message text. We also keep operational logs, and any correspondence you send to our support mailbox. Section 12 says how long each is kept.

3.9. App permissions

The Android app declares the permissions listed in its Play data-safety form, and asks for each one at the moment a feature first needs it, never at install. As of the date of this draft it asks for: read SMS (only for SMS Tests, Section 3.4); read phone state (when you add a phone number, to recognise your SIM cards — Section 3.3); notifications — once, when you first open the app after signing in, and again only if you later turn a notification setting on without having allowed them; the camera, when you take a photo or a video for a Task with the app's camera button; and your location, together with the camera, only for a Task whose files must carry one — your precise location where the Task names a place to be near, which the app also uses to show you how far from it you are, and your approximate location otherwise. The location goes into the file and from there into the Task's check (Section 3.5). An Observed OTP Report never asks for the camera or your location. Choosing a file from your gallery goes through Android's photo picker or file chooser, which hands the app only the files you pick and needs no permission. Microphone and media-library permissions are declared but not requested by any current feature.

3.10. What the app reports about its own operation

To find and fix faults, the Android app tells us how it is running. Nothing in this section is used to decide anything about you — not whether a submission is accepted, not your pay, your verification level or any restriction on your account.

• With every request. Each request the app makes to our servers states the app's version and build number, your phone's Android version, and a random identifier the app makes for that one request and never uses again. We record them with the request and count them in aggregate — for example, how many requests each app version made and how many of them failed — and the request's identifier goes into our servers' own record of that request, so that a failure the app reports (below) can be matched with what our servers saw.
• Technical events. While you are signed in, the app sends us short technical events about its own operation:
  • when it was opened and closed and how long it ran, when it was updated to a new version, how long it was without a network connection, whether its previous run ended in a crash, and how far the phone's clock is from ours and whether the phone sets its time automatically;
  • which app permissions were granted, whether the app may show notifications, how the phone's power-saving settings treat the app, and whether they stopped it while it was waiting for an SMS Test's message;
  • for an SMS Test: whether and when its message reached the phone, and — each time the app looked for it — how many messages it found, how many of them had arrived after the test started and how many before it by the phone's own clock, how far that clock was from ours, how long after the start the first one came, on which SIM slot, and whether the phone let the app read them at all; never who sent a message or what it said;
  • that a request to our servers, a sign-in, the live connection to our servers, or the sending of an SMS Test's result failed, and why;
  • for each file you send with a job: its kind, format and size, how long the upload took, and — if it failed — how much had been sent and the kind of failure; and each failed attempt the app tried again: which part of the file it was sending, which attempt it was, how much had been sent and the kind of failure;
  • for a job you took: that you opened its screen (from the list, or to continue it); if you left without sending, how far you got — answered, attached, a failed send, a refusal — how long the screen was open, whether anything was answered and how many files were attached; a send that did not arrive, and at which stage; and a file the app refused before sending, with the rule it failed — for a photo taken too far from the place a Task names, how many metres away it was;
  • for identity verification: that you opened one of its steps — your face, your identity document, your address or the questions about you — and for which verification level; that a capture failed, at which stage (for example the consent screen, the camera permission, placing your face, turning your head or blinking, recording, or sending it to us), which attempt it was and, if our servers refused it, the reason they gave; that the app tried a capture again; and, if you left a step unfinished, at which stage and how long you had spent on it — never the pictures or the video themselves, and nothing read from your document;
  • that the app asked you to update it — with a notice you can close or a screen you cannot pass without updating — and whether you opened the app store from it;
  • each push notification the app received: its kind, how late it arrived, whether a notice was shown, and the phone's power-saving state at that moment;
  • when something fails, the last steps before it, up to twenty: the names of the app's screens you passed through (such as "home" or "task card", never what was on them), the app going to the background and back, the network dropping and returning, and the app's own events, each with how long before the failure it happened. If the app crashes, the steps of that run are kept on your phone and sent with the next start.
• What every event carries: your phone's manufacturer and model, its language setting, the type of network (Wi-Fi, mobile or none) and — from the version of the app that adds it — which mobile network your phone's data connection is registered on (its operator code, which also shows the country that network is in) and whether the phone is roaming, the app and Android versions, a random identifier of that one launch of the app, your account's internal identifier and — for an event about a particular Task, job or SMS Test — that item's identifier; an event about a failed request to our servers also carries that request's identifier (above). Until they are sent, events are held in the app's encrypted storage on your phone, up to a fixed size, each beside the identifier of the launch it came from — so that identifier stays on your phone only while an event of that launch waits to be sent. Events recorded while you are signed out are sent after you sign in, and signing out deletes any not yet sent.
• Who reads them. Our engineers, to find and fix faults. And, since 2026-10-12, our support staff — one Agent at a time, beside that Agent's account — when you tell us about a fault, so that a report like «my answer would not send» is answered from what your phone recorded. Support never reads them across Agents, and nothing they read here is used to decide anything about you.
• What we never record, and what we never do with it. We record nothing about what you do outside the EarnHub app. Inside it, we record only what helps us find and fix faults — the job screens, the verification steps and the steps before a failure described above. These events never contain anything you typed, photographed or recorded, the content of any message, your contacts, your location or coordinates — beyond the country of the mobile network your phone is on, which its operator code shows — your IP address, or any identifier of your phone — hardware, advertising or otherwise — that outlives one launch of the app, and we do not record your taps or your scrolling. We do not use them to follow what you like or to build a profile of you, we never use them for advertising, and we never sell them or give them to anyone for their own purposes. The only outside services that handle anything about the app's operation are Google's crash reporting and push delivery, below, and they do so for us.
• Crash reports. From the version of the app that adds crash reporting, when the app crashes it sends a crash report to Google's Firebase Crashlytics service (Section 10): the technical trace of the fault, the state of the app and details of the device at that moment (such as its model and Android version), and identifiers that Crashlytics and Firebase create for the app's installation. We do not attach your account identifier, name, email address or phone number to a crash report.
• Push notifications. From the version of the app that adds them, notices reach your phone through Google's Firebase Cloud Messaging (Section 10). To address your phone, the app gives our servers the identifier Firebase creates for this installation of the app; we keep one per account. Notices reach your phone only while you are signed in. However you are signed out — you sign out in the app, your session expires, or we end it, a block of your account included — no further notice is sent to that phone, and the identifier is deleted: at once when you sign out in the app, and otherwise at the first notice that would have gone to it. It is also deleted when your account is deleted, or when Google reports that it no longer works. A push carries only the kind of event and a reference to the notice in your in-app inbox — never its words; the app then shows the notice from our servers. If you turn on notifications about new SMS Tests, the app also subscribes, through Google, to a topic named after the mobile operator of each of your numbers — the operator code our servers gave the number, such as «KZ_TELE2» — so that news of SMS Tests for that operator reaches you; Google therefore holds which installations of the app follow which operator. A push about new tests carries that operator code and nothing else. The app leaves a topic when you turn the setting off, when you sign out, or when none of your numbers is on that operator any more.

Section 12 says how long each of these is kept.

4. Personal data we process about Clients

4.1. Account, company and billing data

• Account identity: name, email address, phone number, password (stored only as a salted hash), TOTP seed if you enable 2FA, account recovery codes; if you sign in with Google, the Google account identifier; if you verify your phone via Telegram, your Telegram account identifier.
• Company data: company name, billing address, country, phone, website; team invitations and member roles.
• Billing data: your ERN balance and transaction ledger; top-up records including USDT transaction hashes and the originating wallet address, where applicable.

4.2. Company verification (KYB) data

If your company applies for verification, we process: company registration documents and company proof-of-address documents; the extracted registration data (stored encrypted); your company website; a residential address declared by the account owner (entered through an address autocomplete service, Section 10); and, where the verification level requires identification of the company's owner, the owner's KYC data as described in Section 3.2 — including ID documents and face comparison, which involve biometric data.

At the higher (Pro+) company-verification levels we may also write to your company directly to confirm that the person applying is authorised to act for it. That letter goes to an address at your company, not to you; it names you (your name and email address) as the person making the claim; and the reply is read by our system from the verification mailbox named in Section 10, stored with your company's verification record, and assessed automatically (Sections 8.1, 9.8, 10, 12). The letter is always sent by a member of our staff, never automatically.

4.3. Content you upload — you are the controller

Files and datasets you upload to the Platform (for example, data for Agents to process) may contain personal data of third parties. For that data, you are the controller and we act as your processor: we store it, distribute it to Agents per your Task settings, and run automated content-safety checks on it (Section 8). You are responsible for having a lawful basis to upload it and to have it processed as your Task instructs. We process it only to operate your Task and the Platform's safety checks.

4.4. Chat and technical data

The same chat processing (Section 3.7) and technical/log/support-correspondence data (Section 3.8) apply to Client users.

5. Personal data about website visitors

Our public web pages are the Portal at earnhub.space and the domains earnhub.app and earnhub.io. For a visitor who only browses, we process exactly one category of data: the standard web-server access log of each request — your IP address, the requested URL, your browser's user-agent string and connection details — kept for the period stated in Section 12, plus an approximate location derived from the IP address on our own servers. Our pages set no advertising or third-party analytics cookies or trackers; our analytics are first-party and run on our own servers. A public statistics endpoint on earnhub.app publishes only aggregate counters and an anonymous event feed (a country code, an amount, a service name) — it contains no names, account identifiers or IP addresses.

6. Why we process personal data (legal bases)

6.1. We process personal data on the following bases, matched to the purposes in this Policy:

• To perform our contract with you: operating your account, matching and running Tasks, paying Agents, billing Clients, providing chat and support (Sections 3, 4).
• With your consent: Sensitive Personal Data (Section 7), the optional profile fields you choose to fill in, and the app permissions you grant.
• To comply with legal obligations that apply to us: keeping financial and transaction records, responding to lawful requests (Sections 9.7, 12).
• For the Platform's legitimate operational needs, where the PDPL permits processing without consent: security monitoring, fraud and duplicate-account prevention, moderation and content safety, finding and fixing faults in the app (Section 3.10), and establishing or defending legal claims.

7. Sensitive Personal Data, and the consents we ask for

7.1. We process the following Sensitive Personal Data:

We do not process your religion, political views or marital status on our servers as answers to our own questions: if you answer those questions, the answer stays on your phone (Section 7.3). A Client's own Task may ask you about them, only with your agreement (Section 7.4).

7.2. Biometric data and precise location are processed only with your explicit consent, asked for at the moment they are first needed: before a verification capture session opens your camera, and before a Task that requires location/camera data first requests the corresponding permission. You can decline; declining means you cannot complete that verification level or that Task, but the rest of the Platform remains available. You can withdraw consent at any time by deleting your account, in the app or by writing to the support mailbox (Section 13.3); deleting it deletes your face embeddings at once.

7.3. Your religion, political views and marital status never leave your phone. The law treats data that reveals a person's religious beliefs, political opinions or family as sensitive. If you choose to answer such a question, the app keeps the answer on your phone only, encrypted with a key held in your phone's own secure hardware, and does not show it again — you can change or delete it, not read it back. We never receive it. When a Client — and only a fully verified (Pro+) Client — aims a Task at such an attribute, for example a survey of people of one faith, the condition travels to your phone with the Task and your phone decides whether to offer it to you; the Client never sees who matched or how many people did, and we erase the condition from our servers when the Task ends. Such a Task runs only if at least 20 Agents who are asked the question fit its other conditions — an Agent that Client has chosen to ignore is not counted among them — so that an answer cannot point at one person. Its results reach the Client without saying who answered: no Agent label, no profile attributes, no chat with you. The work you do on it moves none of the statistics Clients see about you (completed jobs, reliability, rating, earnings), and you are paid for it as for any Task; and Clients see how recently you were in the app only to the day, never the time of day. What we do learn is that you took such a Task, because we pay you for it; that stays with your Task history (Section 12) like any other Task you do, and while the Task runs our staff can see what it aims at and who took it. The same rule covers any sensitive category the questionnaire may add later, such as membership of a political party. Stated honestly: anyone holding your unlocked phone can see which Tasks it offers you.

7.4. A Task that asks about you. A Client's own Task may ask you about your health (for example your symptoms, a diagnosis or the medicines you take), your faith, your political views, your family (your marital or relationship status, or something sensitive about a relative), your ethnic origin, your sex life or a criminal record — a company developing a medicine asking people about their symptoms, for example. Asking how many people live with you, or whether you have small children, is not such a question. Our automated check of every Task before it runs (Section 8) marks a Task that asks any of these, and then:

a. only a fully verified (Pro+) Client may run it — a Client below that is told which topic its Task asks about and that it may not; b. you are told, before you take it, which of these topics it will ask you about, and you take it only if you agree; you are asked again for every Task, and we record your agreement with each piece of work you take. Not agreeing costs you nothing but that Task; c. its results reach the Client without saying who answered — no Agent label, no profile attributes, no chat with you — under the rules of Section 7.3: it goes to everyone who fits its conditions, never to a list of named people, and runs only when at least 20 Agents fit them, so that an answer cannot point at one person; the work you do on it moves none of the statistics Clients see about you, and you are paid for it as for any Task; d. a Task that has already run with results that say who answered cannot start asking about these topics — the Client has to create a new Task; e. your answers are kept like the results of any Task (Section 12): they belong to the Client's records of the Task, and we hold them for the Client. The automated check of each answer before it is accepted (Section 8) reads them as it reads every answer. We do not copy them into our event records (Section 3.8); our record of your agreement — which Task, which topics, when — is kept there like any other record of your work. While the Task runs, our staff can see who took each piece of it, as for every Task.

The law treats this data as sensitive and allows it to be processed with your explicit consent; the agreement in (b) is that consent, given for one Task at a time. You withdraw it for the rest of a Task by not taking more of it, and for everything you have answered by deleting your account (Section 13.3), which removes the link between you and those answers. Stated honestly: what a Task asks is decided by an automated check of its words, which can mark a Task wrongly in either direction; we measure it on every change of the check and on all the Tasks on the Platform (Section 8).

8. Automated processing, moderation and AI services

8.1. The Platform uses automated systems, including third-party large-language-model (LLM) services, for the following. The named providers and their jurisdictions are in Section 10.

• Chat moderation and translation: every chat message containing text is checked by an automated moderation model before delivery; translation processes the message plus up to 30 prior messages of the conversation.
• Content safety: every file uploaded to the Platform — by a Client, and by an Agent for a Task (images, text, video frames, audio) — is scanned by an automated moderation model. For a video a Client uploads to be shown to Agents (a file for a Task, an example in a Task's description, a chat attachment), the model also listens to its soundtrack, in a check of its own; a soundtrack that is silent is not sent. A video a Client provides for verification is checked for content safety on its frames only. An Agent's video is checked on its frames when it is delivered; if the Client who received it later puts it into a Task to be shown to other Agents, the model also listens to its soundtrack, once, before they receive it (a silent soundtrack is not sent), and a video whose soundtrack does not pass is not given to them — the Client keeps it.
• Submission checking: Agent Task submissions — photos, video frames, audio, together with GPS coordinates and capture time extracted from the files — are checked by an automated model for compliance with the Task. For an Observed OTP Report (Section 3.4) the model receives the Task's title and description with the service's name, your answers — the channel, how long you said the code took, the code you typed and your comment — your screenshots and up to eight frames of each screen recording, and each file's technical metadata (such as its capture time and the software that made it, and — when a file carries them — the camera and GPS coordinates), and judges whether your screenshots show what you reported: that the code you typed is visible on them, that it came from the named service by the channel you chose, and — for a code that did not arrive — that the service's own screen shows a code was requested. It also copies from your screenshots the number the service says it sent the code to, and the SIM or network a message is labelled with, where they show one; our servers — not the model — compare them with the number the report was taken on and its network (Section 3.4). A report whose screenshots plainly show the code going to another number, or arriving on another network's SIM, is refused, and the refusal names the number the report was taken on, partly hidden, and its network; a number the screenshots hide, or a SIM they name only by its slot («SIM 1»), is never a reason to refuse. A screen recording is checked only for showing the Task — the service, its messages or a call — rather than something else; the Client watches it. The check also writes down the code it read off your screenshots and keeps it with the record of that check (Section 12), and — when it refuses a report for its number — the number or the SIM label it read. When that code is one you reported before for the same service, the model is asked one more question — whether the message carrying it arrived after that earlier report — and it is given the code and how long ago that report was; a code that repeats in a message that arrived again is accepted, and one shown again from the earlier message is refused.
• Document and face verification: ID document images, proof-of-address and company documents are read by an automated model (OCR/extraction), and pairs of face images are compared by an automated model. Liveness scoring runs entirely on our own servers; the liveness video itself is stored with our storage provider (Section 10).
• Company (KYB) research: your company name, website and the registration details you claim are used as search queries against a web-search service.
• Company-verification replies: where we write to a Client's company to confirm an applicant's authority (Sections 4.2 and 9.8), the reply we receive — its full text, together with the name and email address of the person who made the claim — is scored by an automated model to decide whether it confirms or denies the claim. The reply of an employee of an outside company is therefore processed by an LLM provider (Section 10).

8.2. Automated decisions with real effects. Whether an Agent's submission is accepted — and therefore paid — is decided by these automated checks at the moment of submission, without a human in the loop. A rejected submission is not paid and uses up an attempt; repeated rejections or timeouts can close that Task unit to you permanently. Verification checks are likewise automated in the first instance. If you believe an automated decision about you was wrong, you may contest it through our support mailbox (Section 18) and a human will review what the record supports.

8.3. We keep records of AI-service usage (token counts, cost, request identifiers) linked to the Client or Agent concerned. These records do not contain the content that was processed.

9. Who receives personal data

Our de-identification commitment (Agents). Agents appear to Clients under an anonymized platform label, never under their name, and we do not give Clients an Agent's email address, phone number, face photo, or any other data that identifies the Agent as a person — we enforce this on our side. There are exactly two exceptions: (1) data an Agent consents to share as part of performing a specific Task — for SMS Tests the receiving phone number is inherently part of the result (Section 9.4), for Observed OTP Reports the code the Agent typed and whatever their screenshots and recordings show (Sections 3.4 and 9.4), and collected media carries the location and capture-time metadata the location consent covers; and (2) anything an Agent chooses to hand to a Client themselves, for example by sending personal documents in chat — that is the Agent's own decision and responsibility. Clients are contractually prohibited from attempting to re-identify Agents or contact them outside the Platform (Client Terms, Section 9.2).

9.1. Our staff

Our team of three, on a need-to-know basis, under the access controls in Section 14.

9.2. Service providers (processors)

The named providers in Section 10, strictly for the purposes listed there.

9.3. Clients receive Agent data — this is a feature, not an accident

When Agents make themselves available for Tasks, Clients can search and filter Agents by their profile attributes through the Portal, and what a Client sees depends on how far its own account is verified. Every Client sees your country, your mobile operator, your joining date and your platform statistics (completed units, likes and dislikes, reliability, and how recently you were in the app — to the day, never the time of day). From the Advanced level a Client also sees, where you have provided or the app has reported them, your spoken languages and native language, age, gender, region, phone model, time zone, total earned ERN, your pets, the transport you use, the devices you have at home and the messengers and social apps you use; from the Pro level, your education, employment, profession, household income range, type of housing, height, weight and clothing size. No Client ever sees your religion, political views or marital status — we do not hold them (Section 7.3) — or any part of your phone number in search or on your profile. A fully verified (Pro+) Client may aim a Task at such an answer without ever seeing it, and the results of such a Task never say who answered (Section 7.3); the same is true of a Task that asks you about your health, faith, views, family, origin, sex life or a criminal record (Section 7.4). A Client may aim a Task only at what its own level lets it see; for a one-time-code (OTP) delivery test it chooses by mobile network, phone model, language, the messengers you use (a code sent through a messenger reaches only its users) and platform statistics, never by the rest of the profile you declare. Clients additionally receive the results Agents submit for their Tasks, and with each result only the attributes listed above that the Client's level shows and the Client chose for that Task — results of Tasks other than OTP delivery tests never carry your phone number or mobile operator; for SMS Tests, the receiving phone number is part of the result, and for Observed OTP Reports, the code the Agent typed and their screenshots and recordings, after a delay (Section 9.4) — and chat messages Agents send them. None of this identifies the Agent as a person (see the de-identification commitment above); Clients must use Agent data only to run their Tasks on the Platform and must not attempt to identify the person behind an Agent label.

9.4. One-time-code results and the services being tested

SMS Tests involve a third-party service sending a message to the Agent's SIM; that service necessarily learns the Agent's phone number in the course of the test flow. The Client that commissioned the test receives the individual result of each test — including the phone number that received the message, the sender identifier, the message text and the timing — as well as aggregate deliverability statistics. An Agent who takes an SMS Test is therefore disclosing their phone number to the commissioning Client and to the service under test. This is the task-consent exception to our de-identification commitment (Section 9, opening): the test cannot exist without the number, and the SMS-test consent states this before the Agent takes the test.

In an Observed OTP Report the Agent requests the code from the service themselves, so the service learns whatever the Agent uses to request it — usually their phone number — as in any sign-in. Each report is taken on one of the Agent's phone numbers, on a network the Client chose, and the Client receives that number with the report — as with an SMS Test, the number is what the measurement is about: how the service's codes reach a number on that network. On a Task whose results never say who answered, the Client receives neither the number nor its network. The Client that commissioned the Task receives each report in two stages:

• at once: the phone number the report was taken on and its network (operator and country); the channel the Agent chose, or that the code did not arrive; how long the Agent said it took; the Agent's platform label; and three times — when the Agent pressed «I requested the code», when they sent the report, and the wait between the two;
• no earlier than 30 minutes after the report was sent: the code the Agent typed, their comment, and their screenshots and screen recordings, with everything those show (Section 3.4). The delay is the same for the whole Platform and is set so that, in the ordinary course, a one-time code has expired before the Client can read it.

The Client may keep the screenshots and recordings of the reports it accepted in its own file storage on the Platform, and may export its results (Section 12). Our staff can see a report in full at any time. An Agent who sends an Observed OTP Report is therefore disclosing to the commissioning Client the phone number the report was taken on, the code they typed and whatever their captures show — the task-consent exception to our de-identification commitment (Section 9, opening). The app says so once, before the Agent's first report.

9.5. People who appear in submitted media

Photos and videos Agents submit may incidentally include bystanders. We instruct Agents to avoid capturing identifiable people where the Task does not require it. Such media is processed as Task-result content (stored, checked, delivered to the Client that commissioned it). The same goes for the screenshots and screen recordings of Observed OTP Reports, which can show other people's names, numbers or messages that were on the Agent's screen (Section 3.4).

9.6. Public blockchains

USDT payouts and top-ups are executed on public blockchains (Section 10): wallet addresses, amounts and transaction identifiers become permanently public. This is inherent to how blockchains work and is not reversible by us or anyone.

9.7. Authorities

We disclose personal data where a law that applies to us requires it, or to establish, exercise or defend legal claims. We have no standing arrangements with any authority.

9.8. Third-party companies we contact to verify a Client's authority (KYB)

This is the one case where we process the personal data of someone who is not a user of the Platform and has given us nothing. Stated plainly, because it is unusual:

• What we send. When a company applies for a higher (Pro+) verification level, a member of our staff may send a letter to an address at that company — one or more recipients, sometimes with others in copy. The addresses are taken from openly available sources (the company's own website and public registers), collected by the automated research described in Section 8.1 and chosen by a human. Sending is never automatic.
• What the letter says. It identifies EarnHub, names the company, and names the person making the claim — our Client's contact, by full name and email address — and asks the recipient to confirm or deny that this person is authorised to act for the company. It carries a one-time reference code in the subject line, which is how we recognise the reply; that code is valid for the reply deadline (72 hours by default).
• What we do with the reply. The reply is read from the verification mailbox named in Section 10 — which must be a mailbox dedicated to this purpose before this policy is published; see the flag on that entry — and we keep the sender address, subject, date and the full text of the reply with the company's verification record. A copy — the reply text, together with the claimant's name and email address and the letter we sent — is stored in our file storage and assessed by an automated model (Sections 8.1, 10).
• The recipient's data. For the person who receives the letter, the personal data we process is: their work email address, whatever they write back, and the fact that they answered.

9.9. What we do not do

We do not sell personal data. We do not share it with advertisers or data brokers. Our web pages set no advertising or third-party analytics cookies or trackers (Section 5). The Android app contains no advertising or analytics library; the only outside services that receive anything about the app itself are the crash-reporting and push-delivery services in Section 3.10.

10. Named recipients and their jurisdictions

The table below lists every third party that personal data actually reaches as of the date of this draft, what reaches it, and where it is subject to jurisdiction. All of them act as our processors or infrastructure providers except where noted.

Notes, stated for accuracy:

• IP geolocation is local. We resolve IP addresses to approximate locations using a database on our own servers (MaxMind database files); IP addresses are not sent to MaxMind or any other geolocation provider.
• Push notifications go through Google. From the version of the app that adds them, notices reach the app through Google's Firebase Cloud Messaging (Section 3.10), and a push carries none of the notice's words. Notifications also reach you in-app, by email, or by Telegram.
• Email is delivered by a processor that stores what it sends. Resend keeps message content and delivery logs for a period we state in Section 12; it is certified under the EU-U.S. Data Privacy Framework, publishes a data-processing addendum that takes effect automatically for every account, and publishes its own list of sub-processors — which includes hosting, database, analytics and AI providers of its own. We do not control that chain beyond choosing the provider.

11. International transfers

11.1. We are a UAE company. Our servers are operated by the hosting provider named in Section 10, and the other providers in Section 10 process data in the United States and other jurisdictions outside the UAE. In particular, verification evidence including biometric-source material (liveness videos, ID images) is stored with Cloudflare (a US company, on its EU storage endpoint), and ID images and face pairs are sent to DeepInfra (US) — and, when it fails, through OpenRouter (US) to Alibaba Cloud — during verification. The screenshots and screen recordings of Observed OTP Reports, like other Task media, go to the US model providers of Section 10 for checking. Every email we send you is also transferred to, and stored in, the United States by our email provider (Section 10), and there is no storage-location setting that would change that — the provider's regional options govern only where a message is sent from. The same is true of the mailbox that receives company-verification replies (Section 9.8).

11.2. The PDPL permits transfers of personal data outside the UAE to jurisdictions with adequate protection, or otherwise subject to safeguards including appropriate contractual arrangements or the data subject's express consent. The PDPL's executive regulations — which are expected to define the adequacy list and detailed transfer mechanisms — have not been issued. Until they are, we rest our transfers on the contractual data-protection commitments in our providers' terms and, for Sensitive Personal Data, on the express consent described in Section 7.

12. Retention — how long we keep personal data

We keep personal data no longer than needed for the purposes above, subject to the specific periods below. This table states our actual current practice, including where automatic deletion does not yet exist; we would rather tell you the true state than a flattering one.

12.2. Honest gaps we are fixing. Parts of our infrastructure do not yet enforce the retention discipline this Policy intends, and we say so plainly:

• Our raw system journal (a low-level copy of operational logs) is limited by size rather than by time, so individual entries can persist longer than the 30-day queryable store. A fixed time bound is being introduced.
• Our web server's error log is kept on disk and not yet limited in time. When a request fails on its way through, the line it writes can hold the visitor's IP address and the address of the page asked for. A fixed time bound is being introduced. (The frozen archive of old access logs this bullet used to describe is gone.)
• Operational log lines can include personal data that appears in the operations they record (for example, an email address in a failed sign-in). A redaction layer that strips personal data and secrets from log output is being introduced; until it lands, log access is restricted to our three-person team and the 30-day expiry of the queryable store applies.

13. Your rights under the PDPL

13.1. Subject to the conditions and exceptions in the PDPL, you have the right to:

• request access to the personal data we process about you, and information about how it is processed and shared;
• request a copy / transfer of your personal data in a structured, machine-readable form;
• request correction of inaccurate or incomplete personal data;
• request erasure of your personal data (for deleting your account, see 13.3);
• request restriction of, or object to, processing in the circumstances the PDPL provides;
• object to decisions based solely on automated processing as described in Section 8.2;
• withdraw consent at any time where processing rests on consent (Section 7.2) — this does not affect processing already carried out;
• complain to the UAE Data Office if you consider that our processing violates the PDPL.

We have listed only the rights the PDPL provides; where you may have heard of rights under other laws (such as the GDPR), they apply only if that law applies to you independently of this Policy.

13.2. How to exercise your rights.

• Agents can delete their account directly in the app; deletion is confirmed with your second factor. Deletion removes your account, profile, phones and chat threads from our primary systems, revokes and deletes your biometric templates, removes you from Client search, deletes your push registration (Section 3.10), and erases your entries in our event journal and the app's technical events — from our database within minutes, from our event log within nine days and from our backups within 21 days (Section 12). It does not remove: your identity-verification records — ID document images and the encrypted identity data extracted from them — which we keep for 5 years after deletion as identity-verification records and then delete (Section 12); your liveness video, which follows its own 90-day clock (Section 12); Task results and SMS Test results you have already delivered to Clients — for an SMS Test, that includes the phone number that received the message, the sender and the message text, and for an Observed OTP Report, the code you typed and your screenshots and recordings (Section 9.4) — which remain part of the commissioning Client's records; the answers of your submissions that were refused, for 12 months after each refusal (Section 12); financial records (Section 12); the record that your account was deleted (its internal identifier, the time, and the IP address the request came from); the archived copies of your event-journal entries and of the app's technical events, from which your email address, IP address, phone number, message texts and wallet addresses were removed before archiving (Section 12); the copies of both still in our event log, which it deletes nine days after receiving them (Section 12); and, only if the account was frozen or blocked when deleted, the restriction record described in 13.3.
• Clients can request account closure and any other right through the support mailbox; there is no self-service closure in the Portal today.
• Everyone can send any rights request to support@mail.earnhub.space. We will need enough information to verify you control the account concerned. We answer every request ourselves — we are a three-person team — and aim to respond within 30 days; if a request is complex we will tell you within that time what is taking longer and why.

13.3. Deleting your account

This section is the account-deletion resource referenced from the EarnHub Android app's Google Play listing. It is reachable directly at https://earnhub.app/privacy#delete-account.

In the app. Open Profile → Delete account in the EarnHub Android app and confirm with your second factor. The account is deleted at once: your account, profile, phone numbers and chat threads leave our primary systems, your biometric templates are revoked and deleted, you are removed from Client search, and your entries in our event journal and the app's technical events are erased from our database within minutes, from our event log within nine days and from our backups within 21 days (13.2).

Without the app — if you have uninstalled it, lost access to it, or are signed out — write to support@mail.earnhub.space from the email address registered on your account, with the subject «Delete my account» and the phone number the account was registered with. We verify that the request comes from the account holder (we may ask you to confirm from that address or number), delete the account within 30 days of the verified request, and confirm by reply when it is done. Nothing else is asked for.

What is deleted and what is kept. Everything listed in 13.2 is deleted. We keep, for the periods stated in Section 12: identity-verification records (ID document images and the encrypted identity data extracted from them) for 5 years after deletion; your liveness video for the remainder of its 90-day clock; financial ledger, withdrawal and payment records indefinitely, as accounting records; Task results and SMS Test results you have already delivered to Clients — for an SMS Test, including the phone number that received the message, the sender and the message text, and for an Observed OTP Report, the code you typed and your screenshots and recordings — which remain part of the commissioning Client's records; the answers of your refused submissions, until 12 months after each refusal; the record that your account was deleted; the archived copies of your event-journal entries and of the app's technical events, which carry no email address, IP address, phone number, message text or wallet address; and the copies of both still in our event log, for at most nine days (Section 12).

If your account was frozen or blocked when you deleted it (you were shown the reason in the app), we keep one more thing: a record that lets us apply the same restriction if the same phone number or email address registers again. It holds a one-way hash of that number and of that address — not the number or the address themselves — together with the restriction, the reason we showed you and the date. It is used once, at a matching sign-up, and then kept as the record of the restriction (Section 12). We keep it for security and fraud prevention: an account under review must not be able to end the review by deleting itself and registering again. It is not created for an account that was in good standing when it was deleted.

14. Security

We protect personal data with measures that include:

• encryption in transit (TLS) on all public endpoints;
• password hashing (passwords are never stored in readable form);
• encryption at rest for extracted identity data (the text extracted from ID and company documents is stored encrypted with a dedicated key); verification evidence is held in a private storage bucket separate from general content;
• two-factor authentication available to all accounts, and required for sensitive Agent actions (account deletion, withdrawals);
• segregated verification processing: the workers that handle biometric and document checks run network-isolated except for the specific services they need; liveness analysis runs entirely on our own servers;
• operational controls: withdrawals above limits require staff approval; manual balance changes require two staff members; staff actions on verification data are logged in an audit trail;
• access limitation: production access is limited to our three-person team.

No system is perfectly secure, and we do not claim ours is. We describe here what we actually run, and we improve it continuously; material weaknesses we identify are tracked and fixed before launch-critical milestones.

15. Data breach notification

If a breach of personal data security occurs that is likely to prejudice your privacy or the confidentiality of your data, we will notify the competent UAE supervisory authority (the UAE Data Office) as the PDPL requires, and we will notify you directly — through the Platform or the email on your account — without undue delay when the breach is likely to put you at real risk, telling you in plain language what happened, what data is affected, and what we and you can do about it. Reports of suspected security issues: support@mail.earnhub.space (the same desk; mark the subject "security"). Because we are a three-person team, our incident process is simple by design: contain, assess, notify, remediate — with the same people doing all four.

16. Children

The Platform is for adults. You must be 18 or older to use EarnHub as an Agent or to act for a Client. We do not knowingly process children's data; identity verification at higher Agent levels involves ID-document checks that confirm age, though basic accounts are created on self-declaration alone. If we learn an account belongs to someone under 18, we will close it and delete its data as described in Section 13.2.

17. Changes to this Policy

We will update this Policy when the Platform or the law changes. The version and date at the top identify the current text. For material changes we will notify registered users through the Platform or by email before the change takes effect, and — where a change concerns processing that rests on your consent — we will ask for that consent again rather than assume it.

18. Contact

[ENTITY LEGAL NAME], a company incorporated in the RAK Digital Assets Oasis free zone, Ras Al Khaimah, United Arab Emirates.

All privacy matters: support@mail.earnhub.space.

This Policy is provided in English only.