Privacy Policy

1. The Controller

• Controller: Remény Farm Kft. ("Remény Farm", "we", "us", "our")
• Form: Hungarian limited-liability company
• Tax number: 26667089-2-10
• Company registry number: 10-09-037306
• Managing director: Goldmann Dávid
• General contact email: info@remenyfarm.hu
• Data-protection contact: info@remenyfarm.hu

Remény Farm Kft. is a Hungarian limited-liability company with its registered seat in Hungary. Our full corporate identification — including the registered seat, the name of the company-registry court, and the statutory accounting identifier — is available in our Hungarian-language Impressum, which is the authoritative public record.

2. Scope of this Policy

This Privacy Policy describes how Remény Farm Kft. processes personal data in connection with the unified Chirp Coop and Remény Farm services, including:

• the public web surface at chirpcoop.com;
• the capability-equivalent web surface at tyutyu.hu, including RealChirp checkout and authenticated Patron features;
• the Chirp Coop mobile applications for iOS and Android (current and future);
• supporting infrastructure used by the game (push notifications, analytics, AI generation, in-app purchases).

The two web hosts run one capability-symmetric application: the host selects language and brand, while authentication selects access to Patron features. The Hungarian-language privacy notice describes the same processing for Hungarian readers and includes local service detail. Neither host selection nor this language split changes the privacy boundary.

This Policy is based on Regulation (EU) 2016/679 (the General Data Protection Regulation, "GDPR") and Act CXII of 2011 of Hungary on the right of informational self-determination and freedom of information ("Infotv.").

3. Principles of Processing

We process personal data in accordance with Article 5 of the GDPR. Specifically, we commit to:

• lawfulness, fairness, and transparency — processing only with a clear legal basis and in a manner explained to you in plain language;
• purpose limitation — using personal data only for the purposes described in this Policy;
• data minimisation — limiting collection to what is necessary;
• accuracy — correcting inaccurate data on request without undue delay;
• storage limitation — retaining personal data only as long as needed for the stated purpose or required by law;
• integrity and confidentiality — applying appropriate technical and organisational security measures;
• accountability — being able to demonstrate compliance with the above.

We do not sell personal data. We do not use personal data for behavioural advertising. We do not engage in automated decision-making that produces legal or similarly significant effects on you within the meaning of Article 22 of the GDPR.

4. Categories of Personal Data We Process

The following sub-sections list, for each category, the data processed, the purpose, the legal basis under Article 6 GDPR, and the retention period.

4.1 Account registration data

• Data: a Supabase-generated opaque user identifier and the literal account classification (anonymous or permanent). Chirp Coop may create an anonymous account after a successful security challenge without asking for an email address. If you later link the same account to email, we process that email address and preserve the same user identifier. An optional display name is processed only if you provide one.
• Purpose: to identify the account, secure it, preserve game progress during an optional email upgrade, and deliver the game.
• Legal basis: GDPR Article 6(1)(b) — performance of the contract you enter into when you create a Chirp Coop account.
• Retention: for the lifetime of your active account. Account deletion removes the authentication account and private game identity as described in § 7; that section separately explains mandatory accounting records and limited rights-handling evidence.

4.2 Game-state data

• Data: the name you give to your virtual queen; her current mood and progression state; gameplay events (logins, taps, ritual completions); egg draws and their outcomes; clan membership and inter-player relationships within the game.
• Purpose: to run the game, persist your progress between sessions, and enable the game features you use. A virtual queen and her game state are private account data by default.
• Legal basis: GDPR Article 6(1)(b) — performance of the contract.
• Retention: for the lifetime of the account, then deleted with the account unless a specific legal retention duty applies.

4.3 AI prompt and output data

This category is summarised here and described in full in § 6.

• Data sent to the model: the animal's chosen name and selected story context. Real-hen diaries can include farm and flock facts, weather, patronage activity, farm-journal and visit notes, a patron-provided hen introduction, breakfast-photo captions and analysis summaries, and previous diary entries. Free text can contain personal information.
• Data received from the model: generated Chronicle text and related story-continuity information in the requested language.
• Purpose: to generate the requested Chronicle feature.
• Legal basis: GDPR Article 6(1)(b) — performance of the contract.
• Retention: private Chronicle entries are deleted with the Account as described in § 7; identifying content in a real hen's history is assessed under that section. We have no individually agreed Anthropic retention arrangement. Anthropic normally deletes API inputs and outputs within 30 days of receipt or generation. Flagged Usage Policy violations can extend retention to 2 years for content and 7 years for classification scores; legal requirements may require longer retention. Commercial retention policy.
• Batch processing: daily diaries also use asynchronous batches. Results remain downloadable for 29 days after batch creation; that download limit does not establish erasure of all batch metadata. Deleting our stored Chronicle does not itself delete the provider's copy. Batch processing.

4.4 Mobile in-app purchase metadata

• First-cohort status: the first international soft-launch cohort has no ads and no in-app purchases. RevenueCat is not initialised for that cohort, and no purchase or entitlement metadata is collected from those players. Patron or real-farm status has no gameplay effect in that cohort.
• Data if a later accepted release activates IAP: mobile Game purchase and entitlement state as reported by RevenueCat (active, in grace period, expired, refunded); the product identifier; transaction timestamps; and platform. Card numbers and platform-account credentials are processed exclusively by Apple Inc. or Google LLC; Remény Farm Kft. does not have access to them.
• Purpose: to deliver mobile in-app purchases, manage entitlements (virtual gifts, cosmetics, paid egg draws, noncompetitive convenience boosts, optional mobile-game subscriptions), and comply with Hungarian accounting and tax law.
• Legal basis: GDPR Article 6(1)(b) — performance of the contract; and GDPR Article 6(1)(c) — compliance with a legal obligation, specifically the accounting-record retention duty under Hungarian law.
• Retention: necessary accounting documents and supporting records are retained for at least 8 years under section 169 of Act C of 2000 on Accounting. Separate entitlement and operational metadata does not automatically acquire that duration; it is retained only for its stated service or justified legal purpose, as described in § 7.

4.5 Diagnostic and security data

• Sentry data: scrubbed crash and error reports. Allowed diagnostic context is limited to release/build, environment, platform, operating-system and device model, app state, error type/stack, opaque route or state-machine identifiers, and the opaque Supabase user identifier where a valid session exists. The application disables default PII collection and sends no IP field; the first international cohort is blocked until provider-side IP scrubbing is enabled and evidenced in the hosted Sentry project.
• Capgo release-health data: the mobile updater assigns a random identifier scoped to one app and may report the app id, platform, native/build/bundle/plugin and operating-system versions, release channel and install source, production/emulator flags, and allowlisted update, launch-readiness, WebView timing, crash, ANR, memory, and other native-health actions. A stateless Cloudflare privacy relay reconstructs each event before Capgo receives it.
• Excluded data: the Capgo release-health path never receives an account UUID, Capgo custom_id, advertising identifier, cross-app identifier, request body, email, display name, queen name, Patron data, auth or challenge token, raw error message, stack, source/navigation URL, user agent, session identifier, process name/description, or unknown free-text metadata. The relay stores nothing and does not log request bodies, device identifiers, IP addresses, or user agents. Sentry separately excludes replay, screenshots, attachments, user feedback, profiling, performance traces, headers, cookies, query strings, form values, and local or session storage.
• Purpose: to keep the game stable, diagnose bugs, detect abuse, and protect against fraud.
• Legal basis: GDPR Article 6(1)(f) — legitimate interest in operating a safe and reliable service, subject to data minimisation and your right to object.
• Sentry retention: crash and error events have a standard 90-day retention under our paid subscription; we have no custom retention agreement. This period concerns error events, not every provider record or backup, and does not postpone handling of an erasure request under § 7. Sentry retention periods.
• Capgo retention: operational release-health records are retained for 90 days, separately from account deletion and the rights-correspondence periods in § 7. The Cloudflare relay does not store these records.

4.6 Indirect contextual data

• Data from OpenWeatherMap: non-personal weather data for the geographic region of the simulated farm. This is not personal data about you and is not linkable to your account, but it is included here because it forms part of the prompt context described in § 4.3 and § 6.

4.7 Cloudflare Turnstile security challenge

• Data: Cloudflare may receive the IP address, browser and device signals, and challenge-interaction data needed to determine whether a request is automated. Chirp Coop receives a short-lived challenge token.
• Purpose: to prevent automated anonymous-account creation and abusive email-code requests.
• Handling: the token stays in process memory, is never placed in a URL, browser storage, logs, analytics, or rendered HTML, and is passed unchanged to Supabase Auth. Supabase Auth is the only service that verifies it. Each attempt uses fresh cryptographic state and a fresh challenge.
• Legal basis: GDPR Article 6(1)(f), our legitimate interest in preventing abuse and protecting account infrastructure.
• Retention: Chirp Coop does not retain the challenge token. Cloudflare applies its own security-service retention under its DPA and privacy terms.

4.8 First-cohort product analytics

• Data: after a valid Supabase session exists, the mobile app may send an allowlisted product event under the opaque Supabase user identifier. Common fields are limited to platform, launch market when available without IP or GPS inference, app version, build number, the literal cohort key, and anonymous/permanent account type. The only event-specific fields are an opaque upgrade-catalog identifier on the first soft-currency upgrade event and, on each shared AR anchor attempt, its duration in milliseconds and its outcome (resolved, timed out, failed or cancelled), without coordinates or anchor identifiers.
• Excluded data: email, display name, queen name, Patron identity, advertising identifier, device fingerprint, payment value, free text, precise location, URL, referrer, user agent, screen dimensions, timezone, feature flags, and automatic client metadata.
• Operation: PostHog receives raw, single-event HTTPS requests only. No PostHog client SDK, autocapture, cookie, local storage, durable queue, or automatic retry is used. Each event disables GeoIP. PostHog may create a minimal person record keyed only by the opaque Supabase identifier so that person, event, and recording erasure can be requested and verified; we send no person properties.
• Purpose and legal basis: to measure first-cohort retention, product milestones and the reliability of shared AR anchors under GDPR Article 6(1)(f). Analytics failures never affect sign-in or gameplay.

4.9 Public-web measurement, attribution, and functional referral fulfillment

• Scope: browser measurement is disabled on authenticated, admin, account, redemption, game-bootstrap, auth-secret URL fragments, and other sensitive destinations. On eligible public pages it remains disabled until granular prior consent. Missing, invalid, blocked, or unwritable consent storage fails closed.
• Analytics data: Vercel Analytics and Speed Insights receive the public-page use and performance context required by those services. Profileless PostHog sales events use an ephemeral in-memory random ID and a closed field list: event name; host, path, locale, surface, placement, target, section/FAQ/ calculator values; checkout attempt, quantity, duration, provider, status or error; order ID, currency and value; picker counts; referral handle and UTM values; and share moment/channel. GeoIP and person profiles are disabled.
• Marketing measurement and conversion data: with marketing consent, a referral handle and utm_source, utm_medium, and utm_campaign may be kept for 30 days and attached to checkout for attribution. Referral/UTM values and checkout-event referral properties are sent to PostHog only when marketing consent also exists. A first-party sales-visit counter is incremented at most once per tab, and checkout/session markers prevent duplicate reporting. Google Tag Manager requires both analytics and marketing consent. The RealChirp begin_checkout event contains total value, currency, quantity, and stable item ID, name, category, and unit price. It contains no email, order ID, payment-session token, or referral value. The post-payment redemption route remains browser-telemetry-free.
• Functional invitation, discount and reward data: independently of marketing consent, the member invite slug from an invitation link (/m/<slug>, or an older ?w= or ?ref= link) may be stored by itself for up to 30 days in chirp-referral-discount and sent with a waitlist signup or a gift or RealChirp checkout. The slug is the inviting member's public handle or a short invite code and identifies the inviter, not the visitor. The server validates it and ignores it when it belongs to the visitor's own email address. On a waitlist signup it records the inviting member on the new entry (the inviter's waitlist entry and invite slug), so that the promised first-month discount survives the wait for a coop opening; at checkout it finds that recorded inviter through the buyer's email address and applies the discount to card payments. After successful payment, the server records the referral conversion and fulfills the inviter's bonus-month reward when the inviter holds an open patronage, subject to the monthly anti-abuse cap; an inviter on the waitlist moves up the queue instead (§ 4.14). The invitation page shows only the inviter's public handle display name or club card name, never an email address, legal name or private handle, and runs no browser measurement. This functional path carries no UTM or browser measurement data and sends no referral property to PostHog without marketing consent.
• Measurement purpose and legal basis: consented public-funnel, performance, referral, and conversion measurement under GDPR Article 6(1)(a). We do not use these tools for behavioural advertising.
• Functional invitation purpose and legal basis: applying the invited friend's discount, crediting the inviter's queue places and fulfilling the capped bonus-month reward under GDPR Article 6(1)(b), performance of the invitation offer.
• Retention and withdrawal: first-party retention is itemised in the Cookie Policy: both browser referral records last at most 30 days, tab markers last for the tab session, and durable conversion-deduplication markers last until withdrawal or browser deletion. Provider-side data follows each configured project retention and contract. Cookie settings in the footer allow withdrawal at any time; withdrawal blocks future sinks, deletes owned marketing storage, denies Google consent, and reloads after an active runtime is revoked. It does not delete chirp-referral-discount, because that record remains necessary to honor the requested discount until its own expiry. The inviter recorded on a waitlist entry follows that entry's retention (§ 4.14). It does not automatically erase data already received by a processor; the rights in § 8 remain available.

4.10 MailerLite contact lists and Coop TV campaign processing

• Patron contact projection: MailerLite receives the confirmed account email, an opaque account/contact identifier where available, current RealChirp Patron status and counts, payment-summary fields, Coop TV eligibility, and the preferred communication language. The language is taken from the saved account preference, then signup language metadata, and otherwise defaults to Hungarian. We use this projection to maintain the Patron contact list and its eligible-member language segments. A cancellation updates the Patron fields; the sync never overrides an existing provider unsubscribe or bounce state and never uses a forced resubscribe operation.
• Registered-account contact list: a registered account that is not a Patron is projected into a separate MailerLite contact list, kept apart from the Patron list. That projection is limited to the confirmed account email, the opaque account identifier, the account creation date, the preferred communication language, and a marker naming which of the two lists the contact belongs to. An account with no confirmed email address, including an anonymous game account, is not projected at all. We use this list to keep in touch with people who created an account, for service and onboarding messages about that account. It is not a marketing-consent list: we do not send promotional direct marketing to it, which under Section 6 of Hungarian Act XLVIII of 2008 would require your prior express consent. If the account later becomes a Patron, the contact moves to the Patron list and is removed from this one. Every message carries an unsubscribe control, and you may object to this processing at any time under § 8.
• Leaving the lists on account deletion: recording your request queues your contact's departure from the lists we manage and excludes the account from further eligible-account synchronisation. Provider unsubscribe and list removal are processed asynchronously, before the separate verified contact erasure described in § 7. A queued operation is not confirmation that the provider has completed it.
• Account-email marker: after an account-email change, the browser may retain a versioned MailerLite synchronisation marker containing the opaque account ID, SHA-256 digests of the old and target normalized addresses, and expiry. It contains no plaintext email and is used only to detect confirmation and queue the current Patron contact for server-side MailerLite synchronisation.
• Coop TV recording campaign: when a new Coop TV recording is published, a localized campaign may be sent only to eligible Coop TV members who remain subscribed in the matching MailerLite segment. Eligibility includes current coop members and the final Patron of a hen in the Ancestor Hall. MailerLite applies its unsubscribe and bounce suppression, includes an unsubscribe control, and records delivery, bounce, and unsubscribe state. Where campaign tracking is enabled, it may also record opens and link clicks. We use these signals for delivery and aggregate campaign operations, not behavioural advertising or significant automated decisions. Live-start events are not emailed.
• Legal basis: GDPR Article 6(1)(b), performance of the Patron service, for maintaining the Patron contact and delivering the requested member content; and Article 6(1)(f), our legitimate interest in secure delivery, suppression, and aggregate campaign operation. The separate registered-account contact list rests on Article 6(1)(f) alone, our legitimate interest in keeping in touch with people who created an account about that account; you may object under Article 21 at any time. You may stop future Coop TV campaign email at any time through the unsubscribe control without ending Patron access.
• Retention: the browser marker lasts no more than 24 hours and is cleared on invalid data, account/address mismatch, sign-out, or successful queueing. MailerLite contact, suppression, and campaign-event records follow the configured provider retention and remain only as long as needed for the purposes above, to honor unsubscribe/bounce state, or to handle a rights request under § 8. MailerLite receives confirmed contact data through the server-side workflow, not from the browser marker itself.

4.11 Uploaded profile images

• Data and purpose: a profile image deliberately selected on web or through the native camera/library prompt is processed to display the account avatar. The client prepares image pixels, but the server is authoritative: it checks the declared JPEG/PNG type against the bytes, rejects unsafe dimensions, decodes the image, limits its longest edge to 512 pixels, and stores a newly encoded canonical PNG. The stored avatar therefore carries pixels, not the source file's EXIF, GPS, or other embedded metadata.
• Legal basis and retention: GDPR Article 6(1)(b), performance of the requested profile feature. The avatar is retained until replacement or account deletion, subject to the deletion rules in § 7.

4.12 Walk-up egg-sale receipts

• Data: when you buy eggs in person at the farm (a "walk-up" sale), the seller may enter an email address at the handoff kiosk so the receipt can be delivered to you. The buyer has no account; the kiosk stores the email address only against the issued receipt in a server-only ledger, together with the sale's quantity, price, and receipt number.
• Purpose: to issue the statutory receipt and send its copy to the email address you provide, with limited delivery and reconciliation records.
• Legal basis: GDPR Article 6(1)(c) — compliance with Hungarian accounting and invoicing law; the email delivery itself is the requested fulfilment of the sale under Article 6(1)(b).
• Retention: the receipt and necessary accounting data are retained for at least 8 years under section 169 of Act C of 2000 on Accounting. The separate delivery email has a 30-day retention and retry window from the first recorded delivery result after issue, whether sent, skipped, failed or uncertain. The same window applies to technical provider responses and error details. A retry does not restart it. An active sending operation or specific legal hold can defer erasure of the data it still needs. An unresolved case is reviewed rather than treated as a reason for indefinite retention. A specific legal hold may preserve only the data needed for that matter. Because a walk-up buyer has no account, access and erasure requests are handled through § 1 without requiring account creation. The accounting duty does not by itself require retention of the separate delivery email.

4.13 In-person patronage gifts and continuation

• Data: for the one-hen, one-month patronage gift bought in person, we record the required buyer email, payment method (cash or card, without card details), receipt identifier, amount, gift code, and the code's status, expiry, and delivery state. At redemption, the code is linked to the Recipient's authenticated account and chosen hen. If the Recipient requests monthly continuation, Stripe customer, checkout, and subscription identifiers and the planned first billing date may also be recorded; we do not receive the card number.
• Purpose: server-side capacity and payment confirmation, issuing and emailing the gift code and a copy of the receipt containing 27% VAT, redemption and fixed-term patronage fulfilment, and, only when requested by the Recipient, setting up and managing later monthly continuation. The buyer email supplied for this transaction is not itself marketing consent.
• Legal basis: GDPR Article 6(1)(b) for the purchase, delivery, redemption, fixed term, and requested continuation; GDPR Article 6(1)(c) for receipt and accounting obligations.
• Retention: the receipt and necessary accounting records are kept for at least eight years. Separate receipt-delivery email and raw receipt responses follow the short periods in § 4.12. Gift-source buyer and recipient contacts and optional messages expire thirty days after the original unredeemed code deadline or, after redemption, the purchased term's end. A live or extended entitlement, unresolved required receipt, active operation or specific legal hold can defer the affected erasure. Legacy purchases and observed refunds require case review; review failures do not justify indefinite retention. Requests concerning these data are handled through § 1. Erasing the buyer's unnecessary personal data does not cancel another recipient's entitlement. The limited rights-handling evidence and specific holds in § 7 apply separately.

4.14 Patronage waitlist

Hen-patronage spots open one coop at a time. When the current coop is full, the sales page offers a waitlist signup.

• Data processed: email address, chosen language, planned number of hens, the time and surface of the signup, the text version and timestamp of the consent, a digest derived from the connection's network identifier (abuse limiting), and any campaign or referral markers attached to the signup (utm parameters, and the invite slug and waitlist reference of the member whose invitation link the signup followed).
• Purpose and legal basis: email notification about the next coop opening and hen-patronage offers; consent under Article 6(1)(a) GDPR, which also serves as the express consent required by Section 6 of Hungarian Act XLVIII of 2008 on business advertising. Consent is voluntary and can be withdrawn at any time through the contacts in § 1 or as indicated in the notification emails; withdrawal does not affect the lawfulness of prior processing.
• Retention: a waitlist entry is kept until consent is withdrawn, and at most for 12 months after the relevant coop-opening round closes; after withdrawal the entry is closed in a de-identified form that prevents any further contact.

Optional friend invitations

When the two-stage invitation policy is enabled, a waitlist member may submit up to three friends' email addresses per send. Alternatively, they can share a public signup link without giving us friends' addresses.

• Source, data and purpose: the inviting member supplies the address. We process it with language, sender reference, a hashed mailbox identifier, an email-only invitation credential, an encrypted mail body, sending and delivery outcomes, activation timestamps and suppression records to deliver the invitation, record queue rewards once, prevent duplicates and abuse, and honor declines. Supabase stores these records; Resend receives the address and invitation content for email delivery.
• Choice and legal review: invitations do not enroll the recipient in the waitlist or establish marketing consent, including account-level consent. Opening a page does not activate an invitation. Activation or decline requires an explicit action, and any waitlist signup requires the recipient's separate voluntary consent. Invitation sending is off by default and may only be enabled after the operator documents the applicable legal basis and reviews advertising-law requirements, including Section 6 of Hungarian Act XLVIII of 2008. A friend's request is not the recipient's consent.
• Retention and controls: the address, invitation credential hash and encrypted mail body are scrubbed on suppression (including a decline, bounce or complaint), or by recurring cleanup after the 30-day invitation expiry. Hashed mailbox deduplication/suppression identifiers and minimal sending and reward audit records are retained to prevent repeat contact and duplicate rewards; they are not a marketing mailing list. Contact § 1 to object or request erasure. Private invitation links are excluded from analytics and are not passed to other pages as referrers.

Overtake moment

When a member moves up because of their invitations, the app shows them a sample of at most ten members they passed. For each one it shows only the first letter of the email address, the number of hens they plan to adopt and the month they joined (for example "K. · waiting for 3 hens · since Sep"). We never show the full email address, a name or an exact date. The server does the masking, so the full address never leaves the database. Legal basis: our legitimate interest in letting members see how the queue moves (GDPR Article 6(1)(f)). You can object at the contact in section 1; we then leave you out of these samples.

4.15 Optional community encounters, places and shared AR

• Data and purpose: when you choose these features, we process your account identifier, mutually confirmed encounters and timestamps, hen-card snapshots, friendship and blocking choices, sharing approvals, venue visits, egg captures, rewards and real-egg gift ledger entries. These records provide the community features you request and prevent duplicate rewards or transfers. A meeting does not create a friendship automatically; a shared memory requires both participants' approval.
• Location: QR encounters, venue scans and AR egg actions send your current precise coordinates, accuracy and capture time to our server for proximity checks. Foreground Nearby exchanges use an explicitly confirmed nearby connection. We do not collect an all-day route or show a live map of members. An egg you deliberately place publishes its map position while available; the private creator link and placement receipt are kept for operation and dispute handling.
• Camera and providers: shared AR uses Google ARCore Cloud Anchors. Google processes camera data and spatial anchor data to align the same object across phones, and collects installation identifiers, SDK usage and diagnostic data as described in its ARCore disclosure. Hosting temporarily uploads camera data; resolving processes camera data in memory. Stored anchors expire under their configured lifetime. Google's Privacy Policy also applies. The map provider shown in the attribution (currently MapTiler AG, Switzerland) receives ordinary network requests, including IP address and the requested map area. We do not send account identifiers to the map provider.
• Legal basis and choice: performance of the optional service you request, GDPR Article 6(1)(b). Access to device sensors follows the operating system's permissions. You can decline or revoke those permissions and stop using the affected feature. Camera and location are used for these actions while the app is open.
• Retention and controls: short-lived meeting tokens and unfinished meeting proposals expire and are removed by a recurring cleanup. Meeting memories, venue history, rewards and placement records remain for the lifetime of the account. Relationships and sharing choices can be changed separately. Expired placement attempts are unavailable for use but may remain in your private operation history until deletion. Account-deletion preparation removes private community history and creator associations; detached published-egg records may remain to preserve other participants' earned rewards. Real-egg transfers retain their conserving ledger history with deleted participants detached. Google's anchor expiry and SDK retention are separate from deletion of our account records. Sharing withdrawal prevents future in-app sharing; it cannot recall a picture already saved by a recipient.

4.16 Server-side analysis of business events

• Data: while the service runs, our servers record a fixed, closed set of business events. We send no other event and no other field:
  • start of a hen patronage: the acquisition code and the coop identifier;
  • end of a patronage: the end-reason code, the patronage length in days and the coop identifier;
  • the cancellation reason code chosen in the Stripe customer portal (never the free-text comment);
  • the daily Golden Grain claim;
  • an egg handover: the number of eggs;
  • an egg collection booking: pickup or delivery, and the number of eggs;
  • a farm event registration: the party size;
  • a hen photo or video upload: the media type and the coop identifier;
  • a patronage renewal (a successful Stripe payment for the next period): the patronage length in days;
  • a waitlist signup: the signup surface code, the number of hens wanted and whether a referral brought it;
  • a waitlist entry turning into a purchase.
• Identification: account events carry the account's random internal identifier (UUID); waitlist events carry the waitlist entry's random identifier. We send no email address, name, phone number, postal address, payment amount, free text or precise or IP-derived location. PostHog's GeoIP lookup is disabled on every event and no person property is set. For account events PostHog keeps a minimal person record without properties so that deletion can be requested and verified; waitlist events create no person record.
• Purpose: to understand how patrons use the service, why they cancel and what keeps them, as the basis for product and business decisions.
• Legal basis: our legitimate interest, GDPR Article 6(1)(f). The data set is narrow, fixed and pseudonymous, carries no contact data, free text or location, and is not used for profiling, advertising or automated decisions. In-app behaviour (screens, taps) is not part of this; in the Tyutyu app it is measured only with consent, see § 4.17.
• Objection: you may object at any time under Article 21 at the contact in § 1. On objection we delete the person record and events tied to your account in PostHog and stop sending events about your account.
• Recipient and transfer: PostHog Inc. (USA) as processor under a signed data processing agreement. Transfers rely on the EU-US Data Privacy Framework and Module 2 of the Standard Contractual Clauses.
• Retention: at most 24 months, then deletion. Account deletion also deletes the person record and its events in PostHog (§ 7). Waitlist events can no longer be linked to anyone once the entry is erased.
• Operation: events are first written to a durable queue in our database and sent to PostHog in batches at most every five minutes. Queued events of an account that was deleted or has a pending deletion request, or of an erased waitlist entry, are not sent.
• Cancellation feedback: if you cancel a patronage in the Stripe customer portal, the portal may ask for a reason (a fixed choice) and an optional comment. We receive both from Stripe and store them with your account to understand why patrons cancel. Only authorised administrators see the comment; it never goes to PostHog, logs or error tracking. It is deleted with your account. Legal basis: GDPR Article 6(1)(f), our legitimate interest in improving the service.

4.17 Tyutyu app usage statistics (with consent)

• Data: if you consent, the Tyutyu app sends usage events from a closed list: an app open (from the icon, a notification or a link), an app page opened, by its fixed page identifier and without content, and a notification tap, by the notification's fixed type. Every event carries the platform (iOS or Android), the release channel (beta or production), the app version and the update-bundle version. From the consent version of 23 October 2026, and only with that updated consent, the app also sends one event when you open your club card: which card view was shown, whether the app lowered it for smoother motion, your phone's graphics chip family from a short fixed list (for example Adreno or Mali, never the exact model), a coarse band of how long the card was open and whether you closed it before it settled.
• Identification: events carry your account's random internal identifier (UUID), so they can be joined with the events of § 4.16. We send no name, email address, phone number, hen or coop identifier, free text, precise or IP-derived location, advertising identifier or device fingerprint. There is no PostHog client SDK, autocapture, session replay or cookie. PostHog's GeoIP lookup is disabled on every event; PostHog keeps a minimal person record without properties so that deletion can be requested and verified.
• Purpose: to understand which features patrons use and which they skip, so we can improve the app.
• Legal basis: your consent, GDPR Article 6(1)(a). Consent is voluntary; without it the app works the same. You can give it with a separate, unticked checkbox when you order a patronage, or once when the updated app first asks.
• Withdrawal: you can turn it off at any time with the "Usage statistics" switch in the app's Settings. Withdrawal takes effect immediately; from then on no event is sent. Withdrawal does not affect the lawfulness of earlier processing; you can ask for the deletion of earlier events at the contact in § 1.
• Record of your decision: we record your decision (yes or no), the text version, where you decided (order, first launch or Settings) and the time with your account, so we can prove the consent. The record is deleted with your account.
• Recipient and transfer: PostHog Inc. (USA) as processor under a signed data processing agreement; transfers rely on the EU-US Data Privacy Framework and Module 2 of the Standard Contractual Clauses.
• Retention: at most 24 months, then deletion. Account deletion also deletes the person record and its events in PostHog (§ 7).

Online consumer withdrawal declarations

The online withdrawal function collects your name, contract identifier, chosen language and downloadable-receipt choice, and records the declaration version, a random receipt identifier and server receipt time. No account, additional email address or identity-document upload is required. If you submit while signed in, we also record your account identifier; when it is the account that placed the order, no separate email confirmation is needed. We match the declaration to the identified order. The confirmation link and the letter about the outcome go to the email address stored with the order or its linked account (never an address typed on the form), and any cancellation, refund and receipts use the existing order records. We process the declaration to comply with consumer-law duties (GDPR Article 6(1)(c)) and assess the identified contract and any refund (Article 6(1)(b)). Supabase stores the case; only authorized case administrators may review it. Name, contract reference, account identifier and the order, payment and hen identifiers linked to the case are removed 30 days after case closure; the outcome, dates and minimal receipt, review and closure evidence are retained for one year after closure for accountability and legal-claim handling (Article 6(1)(f)). An actual legal dispute may justify a documented, time-limited hold. Unresolved cases remain available for review. The receipt is delivered as a text file through your selected browser download and is not sent by email.

5. Recipients and Processors

The following service providers receive data for the activities listed. Providers processing personal data on our instructions require an Article 28 data-processing agreement (DPA). Payment, banking and platform providers may also act as independent controllers for their own services and legal duties; their privacy notices apply to those activities. The references below identify provider terms, and do not mean that every provider has the same role.

We share personal data only to the extent needed for the listed activity. Our production Supabase database is hosted in the United States. Transfers outside the EEA require an applicable adequacy decision or appropriate safeguards, such as Standard Contractual Clauses. EU–US Data Privacy Framework coverage depends on the receiving entity and covered processing. Contact § 1 for information about the safeguards applicable to your data and how to obtain a copy. A provider's published DPA does not itself establish our account's region, retention settings or the transfer route used.

Capgo currently uses its global service for this processing. If we move to the provider's EU region, the updater's update, channel, and statistics endpoints will move together; we do not mix regions within one mobile identity.

Beyond processors, we may also disclose personal data to:

• competent public authorities (courts, regulators, tax authorities, law-enforcement bodies) where we are legally required to do so;
• professional advisors (accountants, auditors, lawyers) bound by professional confidentiality obligations;
• a successor entity in the event of a corporate restructuring, merger, or acquisition, subject to the same protections set out in this Policy.

6. AI Processing — Specific Notice

Chronicles use configurable Claude models operated by Anthropic to generate animal stories. Daily real-hen diaries use selected farm and patronage context; previews and corrections can involve additional requests. The following describes the Chronicle data flow.

6.1 What we send

The prompt includes the animal's chosen name and relevant story facts. For real-hen diaries, the available inputs include the categories listed in § 4.3, selected according to the feature's configuration. Farm notes, hen introductions, captions and earlier stories may identify people; cleaning text for safe prompt handling does not anonymize it.

The Chronicle integration does not deliberately add your account email, Supabase user identifier, client IP address, billing details or payment data as prompt fields. Such information may nevertheless appear if someone includes it in free text.

6.2 What we receive

Generated diary text and story-continuity information, stored for the relevant animal and language. The treatment of private account content and identifying real-hen history is described in § 7.

6.3 Training opt-out

Anthropic's commercial policy excludes API inputs and outputs from model training by default. We have not granted permission to use application data for model training. Express permission or submitted feedback can change the provider's treatment of the affected data. Commercial training policy. The applicable retention periods are described in § 4.3.

6.4 Nature of the output

The Chronicle output is creative writing, not factual reporting. It is generated by a language model and may contain hallucinations, mistakes, or stylistic embellishments. It is not a record of anything that physically happened, and it is not medical, veterinary, or any other form of professional advice. The corresponding limitation of liability appears in our Terms of Service.

6.5 Your right to know

You have the right, at any time, to ask us what the model has generated about your queen, to receive a copy of the prompt and output for any specific Chronicle entry, and to ask us to delete a specific Chronicle entry if you find it inappropriate. Contact us using the addresses in § 1.

7. Account Deletion and Real-Chicken Record Permanence

Anonymous and permanent users can initiate account deletion in the mobile app and at the directly reachable web resource /account/delete. The web resource requires authentication so the request is applied only to the current account.

• Anonymous accounts: deletion immediately removes the Supabase Auth account and associated private queen, brood, and wallet/ledger data that is not legally retained unless the account identity changed before the request. Erasure of the opaque telemetry and push identity and matching records at PostHog, Sentry, and OneSignal is durably queued and tracked separately. The rights-response deadline in § 8 applies.
• Capgo release-health records: Capgo's random app-scoped device identifier is deliberately not mapped to an account UUID, so account deletion cannot target it by account. We do not create that identity link merely for deletion. The records expire under the retention above; a rights request may be handled through the § 1 contact and provider support where the requester can supply sufficient device-specific evidence.
• Permanent accounts: the standard account-deletion flow has a seven-day cancellation window, followed by automatic processing. To withdraw a request during that window, contact support using § 1 before processing starts; withdrawal is handled through support. The deletion resource reports the expected timing. Additional identity information is requested only where necessary to resolve reasonable doubts about the requester. Contact § 1 if you need an erasure request considered sooner; the cancellation window does not replace your statutory rights or extend the response deadline. Withdrawing deletion does not automatically renew a subscription or resubscribe you to email lists.
• Email-linked game data: the private virtual queen, private chronicles, game state, and account profile are deleted with the playable account. A virtual queen is not published by default and is not retained as a public profile after deletion.
• Required accounting records: documents and necessary payment relationships remain for the applicable statutory period, restricted to accounting, tax and related legal purposes. Separate delivery email, raw provider responses and optional personal notes do not automatically inherit that period. Erasure removes unnecessary copies without cancelling mandatory receipt issuance or another person's gift entitlement.
• Real chickens: non-identifying animal facts, portraits and life history can remain public. We remove former Patrons' identifying references, including identifying names, links and personal text. Where a remaining record can still identify you, it remains personal data and requires its own lawful basis and retention limit. A reversible alias is not erasure; accepting these terms does not waive your rights.

7.1 Requests, responses and limited evidence

Where a correspondence address is available, we queue an acknowledgement and updates about local erasure and verified processor completion. Local account erasure and full processor completion are different stages. A message accepted by our email provider is not proof that it reached your inbox. If a provider operation remains unresolved, we report that honestly and review the case.

We process a temporary correspondence address, language, request reference, timestamps and status to handle your rights request under Article 6(1)(c). The address is used only while necessary for the open case, with periodic review. It is cleared after the email provider accepts the terminal response, or at a fixed 30-day expiry after the terminal decision if sending cannot be confirmed; retrying does not extend this period.

We retain minimal closed-case evidence for one year from terminal completion: the request reference, necessary opaque identifiers, processing dates, outcome, any optional selected deletion-reason category, processor confirmation references and correspondence status. This is our limited retention policy for an annual review and recent rights-handling disputes, under Article 6(1)(f), not a statutory one-year requirement. It does not include your account profile, free-text feedback or routine identity-document copies. You may object under § 8. A specific legal obligation or claim can justify a documented, restricted hold with a review date and finite end date.

We communicate relevant erasure to recipients of your data, subject to the statutory exceptions, and identify those recipients on request. A retained accounting document or independently operated platform account is explained separately; it is not silently marked as erased.

7.2 Backup copies

Restricted backup copies may remain until the applicable backup expires. Our production database's point-in-time recovery window is seven days (verified 6 September 2026); this does not describe every provider's backups. They are not used to reactivate your account or for marketing. Before a restored system resumes service, completed erasures must be reapplied and checked using a separately retained erasure record. That record must outlast the verified recovery window; a longer backup window requires a specific retention review. Contact § 1 for the backup periods applicable to your request.

8. Your Rights

You have the following rights under the GDPR and the Infotv., subject to the conditions and exceptions in the applicable law:

• Right of access (GDPR Article 15) — to obtain confirmation of whether we process personal data about you, and a copy of that data.
• Right to rectification (GDPR Article 16) — to have inaccurate personal data corrected.
• Right to erasure (GDPR Article 17) — to have your personal data erased where the legal conditions apply. Public animal history creates no blanket exception for your personal data.
• Right to restriction of processing (GDPR Article 18).
• Right to data portability (GDPR Article 20) — to receive a machine-readable copy of the personal data you provided to us.
• Right to object (GDPR Article 21) — to processing based on legitimate interest, on grounds relating to your particular situation.
• Right to withdraw consent (where processing is based on consent) — withdrawal does not affect the lawfulness of processing already carried out before the withdrawal.

To exercise any of these rights, contact us at the addresses in § 1; an account is not required. We provide information about action taken without undue delay and within one calendar month of receiving your request. Where necessary because of complexity or the number of requests, we may extend by up to two further months, but must explain the extension and its reasons within the first month. An acknowledgement or progress email does not itself extend the deadline. If we do not act, we explain why and tell you about your right to complain to the supervisory authority or seek a judicial remedy.

We will not charge you a fee for exercising your rights unless your request is manifestly unfounded or excessive (Article 12(5) GDPR).

9. Security Measures

We apply the following technical and organisational security measures, designed in line with Article 32 GDPR:

• HTTPS everywhere — all traffic between you and our services is encrypted in transit using TLS;
• Supabase Row Level Security (RLS) as the authoritative permission boundary on database tables; application code defers to RLS rather than reimplementing access rules;
• passwordless authentication — we sign you in with email "magic-link" tokens rather than storing passwords;
• secrets in Supabase Vault — service-role credentials, API keys, and webhook secrets are stored encrypted at rest and never embedded in client code;
• regular backups of the production database;
• PII-scrubbed error capture — Sentry stack traces are filtered to remove email addresses, display names, and other identifying values before they are stored;
• minimised release-health capture — a stateless Cloudflare relay reconstructs Capgo events from an allowlist, strips free text and identity joins, and logs no body, device identifier, IP address, or user agent;
• fresh Turnstile challenges for anonymous bootstrap and configured email-code requests, with tokens kept out of URLs, storage, logs, analytics, and HTML;
• least-privilege access controls internally — only the people who need access to a category of data have access to it;
• subprocessor management — we review the security posture of each processor before engaging them and re-review on changes that affect our risk profile.

No system is perfectly secure. If we discover a personal-data breach that is likely to result in a risk to your rights and freedoms, we will notify you and the competent supervisory authority in accordance with Articles 33 and 34 GDPR.

10. Cookies and Similar Technologies

Our Cookie Policy lists the current necessary and consented browser storage, processors, retention, and the footer control for withdrawing optional measurement consent.

11. Children's Data

Chirp Coop is intended for users aged 13 and over. The real-chicken patron service at tyutyu.hu is a separate product with its own age threshold of 18+ under its own Terms.

11.1 Age of digital consent

Where you are a resident of the European Union or the European Economic Area, we rely on Article 8 GDPR. The default age of digital consent under the GDPR is 16, with Member States able to set a lower threshold no lower than 13. Where you are aged 13–15 and resident in a Member State whose national age threshold is higher than your age, we require verifiable parental consent before we may rely on consent as the legal basis for any processing that depends on consent. Hungary's age threshold for digital consent is 16; users aged 13–15 resident in Hungary therefore need verified parental consent.

We do not knowingly create accounts for users under 13. If we become aware that a user is under 13, we will close the account and delete the associated personal and private game data, subject only to legally required retention and the separately redacted public record of any real farm animal.

11.2 No targeted advertising to minors

We do not show targeted advertising to any user, and in particular we never profile users for marketing purposes. We do not use minors' personal data for marketing purposes of any kind.

11.3 Parental enquiries

A parent or legal guardian who believes their child has created an account without consent can contact us using the addresses in § 1. We will act on a substantiated parental request without undue delay.

12. International Data Transfers

Several of our processors are established in the United States (see § 5). Personal data transferred to those processors is transferred under:

• the European Commission adequacy decision for the EU–US Data Privacy Framework (where the processor is certified under the Framework); and/or
• Standard Contractual Clauses adopted by the European Commission under Article 46(2)(c) GDPR, supplemented by appropriate additional safeguards where required by the transfer-impact assessment.

We review the legal basis of each international transfer on an ongoing basis. If the European Court of Justice or the supervisory authorities determine that a transfer mechanism is no longer valid, we will update this Policy and, where necessary, change processors.

13. Right to Complain

If you believe our processing of your personal data violates the GDPR or the Infotv., you have the right to lodge a complaint:

• with the Hungarian supervisory authority — the National Authority for Data Protection and Freedom of Information (NAIH):
  • website: naih.hu
  • email: ugyfelszolgalat@naih.hu
• with the supervisory authority of the EU or EEA Member State of your habitual residence or place of work, if you are resident in another Member State; the European Data Protection Board maintains a list of national authorities at edpb.europa.eu;
• with a competent court, in addition to or instead of lodging an administrative complaint, where you believe your rights have been infringed (Article 79 GDPR).

You also have the right to seek a judicial remedy against a supervisory authority's decision under Article 78 GDPR.

14. Amendments to this Policy

We may amend this Privacy Policy from time to time — in particular when laws change, when we add or change processors, or when we introduce a new feature that affects how we process personal data.

When we make a material change, we will:

1. publish the updated Policy at chirpcoop.com/privacy;
2. send a notification to the email address on your account at least 30 days before the changes take effect;
3. give you the opportunity to cancel your account before the new terms apply if you do not agree with them.

Non-material changes (typo fixes, structural edits, clarifications that do not change the underlying processing) take effect immediately when we publish them. We update the Last updated date at the top of the page every time the Policy is republished.

15. Effective Date

This update, published on 23 October 2026, adds the club card open event to the consent-based usage statistics in the Tyutyu app (§ 4.17); the app sends it only with the updated consent. The update of 19 October 2026 added consent-based usage statistics in the Tyutyu app (§ 4.17) and the patronage renewal event (§ 4.16). Neither update retrospectively restricts your rights or establishes acceptance of a change to an earlier contract.