← All legal documents

Data Processing Addendum

Last Updated: August 27, 2026

This Data Processing Addendum (“DPA”) forms part of the agreement between Know Reply Inc. (“Know Reply”, “we”, “us”), a Delaware corporation, and the customer identified in that agreement (“you”, “the APP”) for use of Earnesty (the “Service”). It describes how personal data is handled when an APP runs an earned tier on Earnesty. It applies from the moment you accept the Terms of Service, and it applies to both halves of what we do — the part where we process data on your instructions, and the part where we process data for our own purposes. Section 4 draws that line explicitly, because getting it wrong would be worse than the paperwork of getting it right.

1. Scope and Incorporation

This DPA is incorporated into the Terms of Service by reference and takes effect without a separate signature. It applies to all processing of personal data carried out in connection with the Service, including through the Earnesty application at https://go.earnesty.app, the Earnesty API and webhooks, and the USER-facing status pages at https://earnesty.page.

Where you require a countersigned copy for your own records, contact us at privacy@earnesty.app.

2. Definitions

Terms defined in the Terms of Service carry the same meaning here. In addition:

• Personal data, processing, controller, processor, data subject, personal data breach, and supervisory authority have the meanings given in Article 4 of the GDPR. Equivalent terms under other Data Protection Laws are read to have the closest corresponding meaning.
• Data Protection Laws means all laws applicable to a party’s processing under this DPA, including the EU General Data Protection Regulation (Regulation (EU) 2016/679) (“GDPR”), the UK GDPR and the Data Protection Act 2018 (“UK GDPR”), the Swiss Federal Act on Data Protection (“FADP”), and the California Consumer Privacy Act as amended by the California Privacy Rights Act (“CCPA/CPRA”).
• APP means the software product that runs an earned tier using Earnesty, and the organization that operates it — our customer.
• APP Personnel means the individuals at the APP who hold Earnesty accounts: organization members, administrators, and billing contacts.
• USER means an end user of the APP who is enrolled in the APP’s earned tier and earns a Reward by posting.
• Reward means whatever an APP grants its USER for a Qualifying Post, in the APP’s own product. Rewards take whatever form the APP chooses — usage credits, model tokens, seats or licences, entry to a Drop, a bonus month — and an APP may offer more than one form. Earnesty never issues, holds, or transfers a Reward; we verify the post and relay the instruction.
• Credits means the most common form of Reward, and the one most of our examples use: an APP’s own in-product usage currency. “Credits” is an example of a Reward, never a limit on what a Reward may be.
• Claim, Claim Code, Partner Tag, Qualifying Post, Verification, and Drop have the meanings given in the Terms of Service.
• Supported Platform means a social platform Earnesty supports for posting and Verification, as listed in Annex III, with its current status stated at Supported Platforms.
• Platform-Derived Data means data we obtain from a Supported Platform’s public APIs, including post identifiers, public post content and URLs, post timestamps, public author identifiers and handles, public engagement counts, and platform disclosure labels.
• APP Data means personal data we process on your behalf as a processor, as scoped by Section 4.1.
• Sub-processor means a third party engaged by us to process APP Data.
• Standard Contractual Clauses or SCCs means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914.
• UK Addendum means the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018, version B1.0.

3. Order of Precedence

Where documents conflict on a data protection question, the following order applies, highest first:

1. The Standard Contractual Clauses, the UK Addendum, and the Swiss terms in Section 15, to the extent they apply to a given transfer.
2. This DPA.
3. The Terms of Service and any order form or plan documentation.

Nothing in this DPA is intended to reduce the protection the SCCs give to data subjects. If a term of this DPA would have that effect, the SCCs prevail for that term only, and the rest of this DPA stands.

4. Roles of the Parties

Earnesty sits between an APP and the public internet, and it does two structurally different things. We describe both honestly rather than declaring ourselves a processor for everything and hoping the description holds.

The rule that decides the role is purpose, not field. The same identifier can appear on both sides of the line if it is being used for two different purposes. Where we act on your instructions to run your earned tier, we are a processor and you are the controller. Where we decide for ourselves what to collect and why — querying public platform APIs, keeping evidence that a rewarded post was disclosed, and detecting fraud and abuse across the Service — we are an independent controller.

4.1 Where we are a processor and you are the controller

We are a processor and you are the controller for the personal data we handle in order to operate your earned tier on your instructions. This includes:

• The productUserId — the opaque identifier for a USER in your own system, which you supply to us. We never resolve it to a name, an email address, or any other identifier unless you send us one.
• Enrollment and seat state — that a USER is enrolled or waitlisted, and when.
• Claim records — issuance, the Claim Code, the economics you configured, the terms snapshot, state, and redemption.
• Reward delivery — computing the granted value against the terms snapshot and transmitting the grant instruction to your endpoint or webhook, including delivery status, retries, and the Reward-grant ledger.
• Signup attribution records you have configured, where a new USER arrives via a Claim Code or self-report.
• Your dashboard, reports, and insight runs — analysis you request over your own corpus.
• Support and configuration work we perform at your direction.

For all of this, you are the controller. You decide who is enrolled, what a Claim is worth, and what happens to the Reward at your end.

4.2 Where we are an independent controller

We are an independent controller, with our own legitimate interests as the lawful basis under Article 6(1)(f) of the GDPR, for the following. This is not processing we do on your instructions, and you cannot instruct us to stop doing it while continuing to use the Service, because the Service does not function without it.

• Querying Supported Platform public APIs to discover and retrieve candidate posts, and receiving whatever the platform returns.
• Binding a platform account to a USER — the platform name, platform author identifier, public handle, and the post that created the binding. This is the hijack guard: one platform handle binds to at most one USER per APP.
• Verification and disclosure-compliance evidence — the platform post identifier, public URL, post timestamp, verification timestamp, the terms snapshot, the granted value, whether the Partner Tag was present and where in the post it appeared, whether the APP’s @mention was present, and whether the platform’s own paid-partnership label was observed. We keep this because a rewarded post is a paid endorsement under 16 CFR Part 255, and both of us may need to show that it was disclosed.
• The reply-bonus settlement read. Five days after a post’s own timestamp, we read the post once to settle its reply bonus: whether it is still public, whether it still carries the Partner Tag, and how much conversation it drew. There is one such read per post, and the conversation is measured in distinct accounts that replied — ten replies from one account count as one — paid along a curve up to a maximum the APP sets.
• Distinct accounts are counted, never listed. Counting distinct accounts means reading which accounts replied, and those accounts belong to people who never enrolled with you or with us. So we count in the moment and keep only the number. The distinct count is computed transiently during the settlement read; the resulting figure is stored against the verified post record; the identifiers and handles of the replying accounts are discarded when that read completes and are never stored, indexed, profiled, matched against a USER, or disclosed to you. Replying accounts are therefore not a retained category of data subject, and they do not appear in Annex I.
• Fraud and abuse detection — one platform post identifier credits exactly once, ever; one handle binds to one USER; velocity, duplication, and coordination signals; and abuse investigations across the Service. Our legitimate interest here is the integrity of the Service and the protection of every APP on it, not only yours. Fraud and abuse detection is entirely mechanical. It never reads sentiment, and it never changes what a Qualifying Post earns.
• Our own direct relationship with the USER — the Participation Agreement a USER accepts, the status page we show them, and the notices we send them about their own Claims.
• Service security, audit logging, legal compliance, and defence of legal claims.

We give USERs their own notice for this. The processing described in this Section 4.2 is set out for USERs in the USER Privacy Notice, which we publish and maintain ourselves. USERs are not left to discover our processing through your privacy policy alone, and you are not asked to describe our processing on our behalf.

4.3 The boundary, with examples

The platform binding record sits closest to the line, and we will not pretend otherwise: we use it to deliver your rewards to the right USER, which is processor work, and we use it to stop account hijacking and cross-APP abuse, which is our own controller work. Both purposes attach to the same row. Where you exercise a right against APP Data — deletion on termination, for example — we honour it for the processor purpose and tell you plainly what we retain as an independent controller and why.

4.4 Mutual obligations for the independent-controller portion

For the processing described in Section 4.2, and for any personal data one party discloses to the other where each acts as its own controller, both parties agree:

• Independence. Each party determines the purposes and means of its own processing separately. Nothing in this DPA creates joint controllership under Article 26 of the GDPR, and neither party processes that data on the other’s instructions.
• Own lawful basis and own notice. Each party is responsible for having a lawful basis for its own processing and for giving data subjects the information required by Articles 13 and 14. We do this through the USER Privacy Notice; you do it through your own.
• Own compliance. Each party complies with Data Protection Laws applicable to it and maintains appropriate technical and organizational measures for the data it holds.
• Data subject requests. Each party handles the requests it receives that relate to its own processing. If a party receives a request that plainly belongs to the other, it forwards it without undue delay and does not answer on the other’s behalf. We will tell a USER which parts of a request we can answer ourselves and which they must take to the APP.
• Breach notification. Each party notifies the other without undue delay of a personal data breach affecting personal data the other party disclosed to it or is likely to be materially affected by, with enough detail for the other party to meet its own Article 33 and 34 obligations.
• Regulators and complaints. Each party notifies the other without undue delay of a supervisory authority inquiry, enforcement action, or data subject complaint that materially concerns the other party’s processing, and cooperates reasonably in responding, unless prohibited from doing so by law.
• Onward transfers. Each party ensures a valid transfer mechanism is in place for its own international transfers.
• Responsibility. Each party is responsible for its own processing, including under Article 82 of the GDPR, and neither party’s compliance is contingent on an instruction from the other.

5. Details of Processing

The subject matter, duration, nature and purpose of the processing, the categories of data subjects, and the categories of personal data are set out in Annex I. Annex I also populates Annex I of the Standard Contractual Clauses where those apply.

6. Our Obligations as Processor

For the processing described in Section 4.1, we will:

• Process only on your documented instructions, including on international transfers, unless required otherwise by a law we are subject to — in which case we will tell you before processing, unless that law forbids it on important grounds of public interest. Your instructions consist of this DPA, the Terms of Service, the configuration you set in the Earnesty application, and your documented use of the Earnesty API. Any other instruction must be agreed in writing, and we may charge for instructions that require engineering work.
• Tell you if an instruction infringes. If we consider an instruction to breach Data Protection Laws, we will tell you promptly and may suspend that instruction until it is resolved.
• Bind our people to confidentiality. Every person we authorize to process APP Data is under a written confidentiality obligation that survives the end of their engagement, and access is granted on a need-to-know basis only.
• Keep the data secure. We implement and maintain the technical and organizational measures in Annex II, appropriate to the risk under Article 32.
• Help you answer data subjects. Taking into account the nature of the processing, we will assist you by appropriate technical and organizational measures — including the export, correction, and deletion functions in the application and the API — in fulfilling your obligation to respond to requests to exercise rights under Chapter III of the GDPR. Where a request reaches us directly and plainly concerns APP Data, we will not answer it ourselves; we will refer the data subject to you and tell you without undue delay. We aim to provide assistance within 10 business days of your request, so that you can meet a 30-day statutory deadline.
• Help you with assessments and consultations. We will provide reasonable assistance with your obligations under Articles 32 to 36 — security of processing, breach notification and communication, data protection impact assessments, and prior consultation with a supervisory authority — taking into account the nature of the processing and the information available to us.
• Notify you of a breach without undue delay. See Section 9.
• Delete or return the data on termination. See Section 10.
• Make available the information you need to demonstrate compliance with Article 28, and allow for and contribute to audits, as described in Section 13.
• Not use APP Data for our own purposes beyond what Section 4.2 describes. In particular, where you request an insight run, post content and metadata from your own corpus are sent to Google, on Vertex AI, to produce that analysis, and neither APP Data nor USER post content is used to train AI models — by us or by Google. We do not sell or share it either.

7. Your Obligations as Controller

You confirm that:

• You have a lawful basis for the processing you instruct, and for disclosing productUserId values and any other APP Data to us.
• You have given your USERs the information required by Articles 13 and 14 about your own processing, and about the fact that a third-party service verifies their public posts and instructs the grant of a Reward — Credits, or whatever form your product gives. We publish the USER Privacy Notice to cover our own side; your notice still has to cover yours.
• Your own terms of service permit you to operate an earned tier with your users.
• Your instructions to us will not put us in breach of Data Protection Laws.
• You will not send us personal data we do not need. In particular, do not put names, email addresses, or other directly identifying information into the productUserId field. It is designed to be opaque to us, and keeping it opaque is the single cheapest privacy control in the system.
• You will not send us special categories of personal data under Article 9, personal data relating to criminal convictions and offences under Article 10, or personal data of children below the age at which your jurisdiction permits them to consent to online services.

8. Sub-processors

General written authorization. You give us general written authorization to engage Sub-processors for the processing described in Section 4.1. The Sub-processors engaged as of the Last Updated date are listed in Annex III.

• Diligence and flow-down. Before engaging a Sub-processor we carry out reasonable diligence on its security and privacy practices, and we impose data protection obligations on it that are no less protective than those in this DPA.
• Our responsibility. We remain fully liable to you for a Sub-processor’s performance of its data protection obligations.
• Notice of change. We will notify you at least 30 days before a new Sub-processor begins processing APP Data, or before an existing one takes on a materially different role. Notice is given by email to your billing and administrative contacts and by updating Annex III. You may subscribe to change notices at privacy@earnesty.app.
• Objection. You may object on reasonable data protection grounds within 30 days of the notice. We will work with you in good faith to find an alternative. If we cannot reasonably accommodate the objection, either party may terminate the affected portion of the Service on written notice, and we will refund prepaid fees covering the terminated portion for the period after termination.
• Emergency replacement. If a Sub-processor must be replaced urgently — for outage, security, or the loss of a platform’s developer access — we may do so before the notice period expires, and will notify you as soon as we reasonably can.

Supported Platforms are listed in Annex III for transparency. As explained in Section 14, a Supported Platform is a controller in its own right over the data on its own service; it is not processing on your behalf when it answers a public API query.

9. Personal Data Breach

We will notify you without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting APP Data. The notification will describe, to the extent known at the time:

• the nature of the breach, including the categories and approximate number of data subjects and records concerned;
• the likely consequences;
• the measures we have taken or propose to take, including to mitigate possible adverse effects; and
• a contact point for further information.

Where we cannot provide all of this at once, we will provide it in phases without further undue delay. We will cooperate fully with you in investigating and remediating the breach, and will not make a public statement identifying you without your prior agreement unless required by law. Our notification is not, by itself, an acknowledgement of fault or liability.

You are responsible for any notification to supervisory authorities and data subjects required of you as controller.

10. Deletion and Return

On termination or expiry of the Terms of Service, and at your election notified to us within 30 days of that date, we will delete or return APP Data and delete existing copies. If you make no election, we delete.

• Timing. Deletion is completed within 30 days of the later of the termination date and your election, subject to the wind-down in the next bullet. We will confirm deletion in writing on request.
• Wind-down first. As set out in the Terms of Service, issuance of new Claims stops immediately on cancellation, but evaluation and settlement continue for already-issued Claims, open Drop windows, and reply-bonus settlements still due on posts already made. We retain the APP Data needed to finish those settlements until they complete, and no longer. The outstanding obligation is always finite and computable.
• Export. You can export APP Data through the application and the API at any time during the term. We recommend doing so before termination.
• Permitted retention. We may retain APP Data where required by a law we are subject to, and only for as long and to the extent that law requires, and we will keep it protected and processed only for the purpose of that requirement.
• Our controller records are separate. Deletion under this Section applies to APP Data. It does not delete the Verification and disclosure-compliance evidence we hold as an independent controller under Section 4.2, whose retention is governed by Section 14 and the USER Privacy Notice. We will tell you what remains and why.
• Backups. Data in encrypted backups is overwritten on our ordinary backup cycle — seven retained daily backups, plus point-in-time recovery across that window — and is not restored into production except to recover from an incident. Deleted data therefore ages out of backups within seven days of deletion.

11. Data Subject Requests

Requests from APP Personnel about their own Earnesty accounts come to us; we handle them as controller of that data and respond within 30 days.

Requests from USERs are split along the Section 4 line. A USER can ask us directly about the Verification evidence, platform binding, and status-page data we hold as an independent controller, at privacy@earnesty.app. For their productUserId, the Rewards they hold, and everything inside your product, the request belongs to you, and we will say so and route it to you. Neither party answers for the other, and neither party stalls a data subject by pointing at the other without also forwarding the request.

12. Records of Processing

Each party maintains a record of processing activities as required by Article 30. On reasonable request, we will provide the information about our processing that you need to complete your own record.

13. Audits and Information Rights

We will make available all information reasonably necessary to demonstrate compliance with Article 28 and this DPA, and will allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.

• Documentation first. We may satisfy an audit request by providing our current security documentation, penetration test summaries, and third-party audit reports or certifications, including our SOC 2 report once available. In most cases this is enough, and it is the fastest route for both of us.
• On-site or on-system audits. Where documentation genuinely does not answer your question, you may conduct an audit on at least 30 days’ written notice, no more than once in any 12-month period, during regular business hours, scoped to the systems and records used to process APP Data, and subject to confidentiality obligations. An additional audit may be conducted where required by a supervisory authority or following a personal data breach affecting APP Data.
• Auditor. An auditor you mandate must not be a competitor of ours, and must sign a confidentiality agreement with us.
• Limits. Audits must not unreasonably disrupt our business or compromise the security or confidentiality of other customers’ data. You bear your own audit costs; we bear ours, except that we may charge our reasonable costs for audits beyond the first in any 12-month period.

14. Platform-Derived Data

This section exists because a meaningful part of what Earnesty holds is not governed only by this DPA. It is also governed by the developer agreements of the Supported Platforms, and those agreements sometimes set the retention rules for both of us.

• We are bound by platform developer terms. We access Supported Platform data under each platform’s developer agreement and policy — today the X Developer Agreement and Policy, and the equivalents for platforms added later. Those terms bind us in addition to this DPA, and we will comply with them.
• Deletion on the platform propagates to us. Where a post is deleted, made private, or otherwise ceases to be publicly available on a Supported Platform, we delete the stored post content and engagement metrics we derived from it on our next refresh of that record. This is a platform requirement, not a discretionary policy, and it applies whether or not you or the USER asks for it.
• What survives, and why. We retain the minimal settlement record needed to evidence a completed and disclosed transaction: the platform post identifier, the post timestamp, the granted value, the terms snapshot, and whether the Partner Tag was observed. We do not retain the post’s text or public engagement counts once the source post is gone.
• Some retention periods are not ours to set. Neither you nor we can lengthen a retention period that a platform’s terms cut short, and a platform may require deletion sooner than either of us would choose. Equally, an instruction from you cannot require us to keep Platform-Derived Data in breach of a platform’s terms. If a platform changes its requirements, we may have to change our retention accordingly, and we will update Annex I when we do.
• Deletion does not unwind settlement. Deleting a post on the platform removes the platform-derived record. It does not claw back a Reward already granted for it. A Claim is evaluated at the post’s timestamp against the terms snapshot in force when it was issued, and settled promises stay settled.
• Availability. Platform APIs impose rate limits and change without our involvement. We are not responsible for a platform’s own processing of personal data on its service, nor for its availability.

15. International Transfers

We are established in the United States and process personal data there. Where personal data is transferred out of the European Economic Area, the United Kingdom, or Switzerland to a country without an adequacy decision, the following apply.

• EU Standard Contractual Clauses. The SCCs are incorporated into this DPA by reference and are deemed executed by the parties. Module Two (controller to processor) applies to transfers of APP Data under Section 4.1. Module One (controller to controller) applies to transfers of personal data under Sections 4.2 and 4.4. Where you are yourself a processor for your own customer, Module Three applies in place of Module Two.
• How the SCCs are completed. The optional docking clause in Clause 7 applies. For Clause 9, Option 2 (general written authorization) applies, with the notice period in Section 8 of this DPA. In Clause 11, the optional independent dispute resolution language does not apply. Clause 17 is governed by the law of Ireland and Clause 18(b) designates the courts of Ireland, notwithstanding the governing law of the Terms of Service. The Annexes to this DPA populate the corresponding SCC Annexes: Annex I here completes SCC Annex I, Annex II here completes SCC Annex II, and Annex III here completes SCC Annex III.
• UK transfers. The UK Addendum is incorporated by reference and applies to transfers subject to the UK GDPR. For Table 1, the parties and their details are as set out in Annex I. For Tables 2 and 3, the SCCs as completed above apply, with the Annex information in Annexes I to III. For Table 4, the Importer may end the Addendum as set out in Section 19 of the Mandatory Clauses.
• Swiss transfers. For transfers subject to the FADP, the SCCs apply with these changes: references to the GDPR are read as references to the FADP; the competent supervisory authority is the Swiss Federal Data Protection and Information Commissioner for Swiss transfers; references to a “Member State” do not prevent a data subject in Switzerland from bringing proceedings in Switzerland; and the SCCs protect the personal data of natural persons.
• Transfer safeguards. In addition, we maintain the supplementary measures described in Annex II, including encryption in transit and at rest, access controls, and a policy of challenging overbroad government access requests and of notifying you where we are legally permitted to do so.

16. CCPA/CPRA Terms

These terms apply to personal information subject to the CCPA/CPRA. Capitalized terms in this section have the meanings given in that statute.

For the processing described in Section 4.1, we act as a service provider and you act as a business. We:

• process personal information only to perform the business purposes set out in this DPA and the Terms of Service, and as otherwise permitted by the CCPA/CPRA;
• do not sell personal information and do not share it for cross-context behavioral advertising, in either case as those terms are defined by the CCPA/CPRA, and receive no monetary or other valuable consideration for it;
• do not retain, use, or disclose personal information for any purpose other than the business purposes specified, including for a commercial purpose other than providing the Service;
• do not retain, use, or disclose personal information outside our direct business relationship with you;
• do not combine personal information received from you with personal information received from another source, except where permitted by the CCPA/CPRA and its regulations — for example, to detect security incidents or to protect against fraudulent or illegal activity;
• comply with the obligations the CCPA/CPRA places on service providers and provide the same level of privacy protection it requires;
• notify you if we determine we can no longer meet these obligations, and on notice from you will stop and remediate unauthorized use;
• grant you the right, on reasonable notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of personal information; and
• engage subcontractors only under a written contract imposing these same obligations, consistent with Section 8.

We certify that we understand the restrictions in this section and will comply with them.

For the processing described in Section 4.2, we act as a business with respect to that personal information, and our own USER Privacy Notice governs it, including the consumer rights we honor and how to exercise them. We do not sell or share that information either.

Where we deidentify or aggregate personal information, we maintain it in deidentified form, publicly commit not to attempt reidentification, and contractually obligate recipients to the same.

17. Liability and Precedence

Each party’s liability under this DPA is subject to the limitations and exclusions in the Terms of Service, including the aggregate cap of the amounts you paid us in the twelve months preceding the claim. Nothing in this DPA:

• limits either party’s liability to a data subject under Article 82 of the GDPR or under the SCCs;
• limits liability that cannot be limited under applicable law; or
• alters the allocation of liability between the parties in the SCCs, which stands on its own terms.

Where the same loss is claimed under both this DPA and the Terms of Service, it is recovered once, not twice.

18. Term, Changes, and General

This DPA takes effect when you accept the Terms of Service and continues for as long as we process personal data in connection with the Service, plus the wind-down and deletion periods described above.

We may update this DPA to reflect a change in the Service, in Data Protection Laws, or in our Sub-processors. We will post the updated version, update the Last Updated date, and — for material changes affecting your rights or our obligations — give at least 30 days’ notice by email to your administrative contacts. Changes to Annex III follow the notice and objection process in Section 8. If a change materially reduces your protections and you object in writing within 30 days, we will discuss it in good faith, and you may terminate the affected portion of the Service if we cannot resolve it.

If any provision of this DPA is held invalid or unenforceable, the rest remains in force.

Annex I — Details of Processing

A. Parties

Data exporter (controller): the APP, as identified in the Terms of Service and in your Earnesty organization record. Contact: the administrative and billing contacts on your account. Activities relevant to the transfer: operating an earned tier for the APP’s end users.

Data importer (processor, and independent controller as described in Section 4.2): Know Reply Inc., a Delaware corporation. Contact: privacy@earnesty.app. Activities relevant to the transfer: providing Earnesty — Claim issuance, post Verification against Supported Platform public APIs, reward instruction and delivery, fraud and abuse detection, and reporting. Know Reply Inc., 8 The Green, Suite B, Dover, Delaware 19901, USA.

B. Description of the Transfer

Subject matter. Provision of the Earnesty service to the APP, and the Verification of public posts made by the APP’s USERs.

Duration. The term of the Terms of Service, plus the wind-down described in Section 10 and, for Platform-Derived Data and compliance evidence, the periods described in Section 14.

Nature and purpose of the processing.

• Creating and administering Earnesty accounts for APP Personnel, and authenticating them.
• Enrolling USERs supplied by the APP, and maintaining seat and enrollment state.
• Issuing Claims and Claim Codes, and valuing a Claim against the terms snapshot as of the post’s timestamp.
• Querying Supported Platform public APIs to discover candidate posts, on a USER-initiated check, a paste-the-URL submission, or a daily sweep.
• Verifying posts against mechanical checks: public, author bound to the USER or Claim Code present, @mention present, Partner Tag present, post not previously credited, terms snapshot recorded, platform disclosure label observed.
• Valuing a Qualifying Post as of its post timestamp and transmitting a Reward-grant instruction to the APP, with retries.
• Settling the reply bonus in a single grant five days after a post’s own timestamp, from a count of the distinct accounts that replied, along a curve bounded by the maximum the APP has set.
• Retaining Verification and disclosure-compliance evidence.
• Detecting and preventing fraud and abuse, and securing the Service.
• Showing a USER their own status at their APP’s status page.
• Billing the APP through Stripe for its subscription.
• Providing dashboards, reports, and — where the APP requests them — insight runs over the APP’s own corpus. Insight runs never affect Verification, eligibility, or what a post earns.
• Sending transactional email to APP Personnel about the account, billing, and Claim activity.

Categories of data subjects.

• APP Personnel — organization members, administrators, and billing contacts at the APP.
• USERs — end users of the APP enrolled in its earned tier.

Categories of personal data.

About APP Personnel:

• Name, email address, email verification state, and profile image where supplied.
• Authentication records: hashed password and/or federated account identifiers, tokens, and verification records.
• Session records: session token, creation and expiry, IP address, and user agent.
• Organization membership, role, and active organization.
• API key metadata (label, prefix, creation and last-used timestamps — never the raw key).
• Billing contact details, Stripe customer identifier, and payment-method identifier. Full payment card numbers are handled by Stripe and are never stored by us.
• Audit log entries recording administrative actions.

About USERs:

• productUserId — the USER’s opaque identifier in the APP’s own system, supplied by the APP.
• Enrollment and seat state (enrolled or waitlisted) and enrollment timestamp.
• Claim records: Claim Code, base value, cooldown days, state, issued and redeemed timestamps, the platform post identifier that redeemed the Claim, granted value, the terms snapshot, and the timestamp of the last on-demand check.
• Platform binding: platform name, platform author identifier, public handle, the post identifier that created the binding, and the binding timestamp.
• Verified post records: platform post identifier, public URL, post timestamp, verification timestamp, granted value, terms snapshot, the observed state of the platform’s paid-partnership label, observed public repost counts, and the number of distinct accounts that replied as counted at the reply-bonus settlement. We hold that number, never a list of who replied.
• Reward-grant records: amount or other granted value, grant type (claim or bonus), delivery status, delivery attempts, and delivery timestamps.
• Signup attribution records: the Claim Code entered at signup or a self-report, and the attribution timestamp.
• Audit log entries referencing the USER, the APP, and the platform post identifier.

Sensitive data. None is requested, required, or intentionally processed. We do not process special categories of personal data under Article 9 of the GDPR or data relating to criminal convictions under Article 10, and the APP is instructed in Section 7 not to send any. A USER writes their own post in their own words on a public platform, and we cannot control what a person chooses to publish about themselves; we do not solicit, index, or use post content for any purpose other than the mechanical Verification checks listed above.

Frequency of the transfer. Continuous, for the duration of the Terms of Service.

Retention. APP account and USER enrollment data for the life of the account, then deleted under Section 10. Platform-derived post content and engagement metrics only while the source post remains public, under Section 14. The minimal settlement record for the period stated in Section 10. Aggregated and anonymized analytics for up to 24 months.

Sub-processors. As listed in Annex III, for the processing and retention periods described there.

Competent supervisory authority. Determined under Clause 13 of the SCCs by reference to your establishment or your Article 27 representative.

Annex II — Technical and Organizational Measures

These are the measures we implement and maintain under Article 32 and Clause 8.6 of the SCCs. They apply to APP Data and to the data we hold as an independent controller alike.

• Encryption in transit. All data transmitted between clients and our servers, and between our services and Sub-processors, is encrypted using TLS 1.2 or higher.
• Encryption at rest. All stored data, including database contents, object storage, and backups, is encrypted using AES-256.
• Secrets and credentials. Credentials the APP supplies for reward delivery are stored encrypted. Webhook payloads are signed with a per-APP signing secret so you can verify their origin. API keys are stored hashed; the raw key is shown once, at creation.
• Access controls. Role-based access control, multi-factor authentication for all administrative access, least privilege by default, and access reviews on joining, role change, and departure. Production access is limited to personnel who need it to operate or support the Service.
• Pseudonymization and data minimization. USERs are identified to us by an opaque productUserId supplied by the APP. We do not request or store USER names or email addresses, and the design keeps identity resolution on the APP’s side.
• Infrastructure security. Network segmentation, firewalls, managed infrastructure with vendor-maintained patching, intrusion detection, and regular vulnerability scanning.
• Integrity controls. One platform post identifier credits exactly once, ever, enforced by a database uniqueness constraint; one platform handle binds to at most one USER per APP, likewise enforced structurally; a Claim’s economics are frozen in a terms snapshot at issuance so settlement is always reconstructable.
• Logging and monitoring. Audit logging of administrative and reward-affecting events, application and infrastructure monitoring, and alerting on anomalous activity.
• Backup and recovery. Encrypted managed backups taken daily, with seven retained and point-in-time recovery enabled across that window, so the recovery point objective within the window is measured in minutes rather than to the last nightly backup. Restoration is used only for incident recovery.
• Secure development. Code review, dependency scanning, separation of development and production environments, and no use of production personal data in development or test environments.
• Personnel security. Background checks for personnel with access to personal data, signed confidentiality agreements, and regular security and privacy training.
• Incident response. A documented incident response process with defined severity levels, an on-call rotation, and the notification commitments in Section 9.
• Sub-processor management. Security diligence before engagement, contractual flow-down of these obligations, and periodic review.
• Deletion. Documented procedures for deletion on termination, for platform-triggered deletion under Section 14, and for confirming deletion in writing.
• Business continuity. Managed, redundant cloud infrastructure. Verification speed is a floor on every plan, and a Claim’s base value is fixed at the post’s timestamp, so a service interruption never changes a Claim’s base value. The reply bonus settles five days after the post’s own timestamp rather than five days after Verification, so a delay in Verification does not shorten the conversation counted toward it either. A post’s earnings do not depend on when we get around to looking.
• Certification. We implement controls aligned to the AICPA Trust Services Criteria for security, availability, and confidentiality, and are pursuing SOC 2 Type II certification. We do not publish a target completion date, and will say so plainly if asked rather than name one we are not certain of.

Annex III — Sub-processors

Current as of the Last Updated date. Changes are notified under Section 8.

Sub-processor paperwork on file. Resend’s Data Processing Addendum (updated 31 December 2025) is incorporated automatically on use of the service — no separate signature is required — and incorporates the Standard Contractual Clauses under Modules One, Two and Three, with UK and Swiss modifications. Resend maintains its own sub-processor list at https://resend.com/legal/subprocessors and gives 14 days’ notice before adding or replacing one.

Supported Platforms. Earnesty queries the public APIs of the following platforms. They are listed here for transparency; each is a controller in its own right over the data on its own service, operating under its own terms with its own users, and is not processing APP Data on your behalf when it answers a public query. Our use of their data is governed by their developer agreements, as described in Section 14.

Which of these is live today and which is anticipated is stated in one place only: Supported Platforms. Adding a Supported Platform is a change to this Annex and is notified under Section 8.

Contact Us

For questions about this DPA, to request a countersigned copy, to subscribe to Sub-processor change notices, or to raise a data protection matter, contact us at privacy@earnesty.app. For contract notices generally, see the notice provisions of the Terms of Service.