Privacy policy.

• Loup is a marketplace for AI skill packs. The personal data we hold is the minimum the marketplace needs: your email and display name, your purchase records, install and usage events, community posts, and any encrypted secrets your installed packs require.
• We never receive your card number. Payment details go from your browser directly to Stripe and are handled under Stripe’s privacy policy. We see transaction metadata and the last four digits, nothing more.
• Buyer secrets are encrypted with AES-256-GCM and used for one purpose only: running your installs. Staff do not read them, with a single narrow exception for abuse investigations.
• Telegram bridging is visible by design. If a creator binds a Telegram group to their Loup community, messages posted in that group appear in the community feed on Loup. This is disclosed in detail in section 2.4.
• You can export everything we hold about you and delete your account yourself at /dashboard/privacy. We do not sell personal information and we do not run advertising trackers.

This policy is issued by Selr Group Pty Ltd (ABN 41 662 328 056), a company registered in Queensland, Australia. We operate Loup, a marketplace where creators sell AI skill packs, buyers install those packs as files into their own AI agents, and affiliates earn commissions for referrals. In this policy, "Loup", "we", "us", and "our" all refer to Selr Group Pty Ltd.

The policy covers personal data we handle through the Loup website, the buyer and creator dashboards, the community features (including Telegram bridging), the affiliate program, and the emails we send. It is organised around four personas, because what we collect and why depends heavily on how you interact with the platform: buyers, creators, visitors, and pass-through individuals (people whose data reaches us through someone else, such as members of a bridged Telegram group). Read the section that matches you, then the cross-cutting sections that apply to everyone.

Three boundary notes. First, payment processing happens on Stripe’s infrastructure under Stripe’s own privacy policy; this document does not govern what Stripe does with the card details you enter at checkout. Second, creators are independent businesses. Where a creator collects data from you outside Loup, or uploads data about their own members for us to host, the creator is responsible for that data as its controller, and we process it on the creator’s behalf under our Data Processing Agreement. Section 2.4 explains what that means in practice. Third, the skill packs themselves run inside your AI agent, on your machines or your accounts; what a pack does with data inside your agent is governed by the pack’s own documentation and your configuration, not by this policy, because that data never reaches us.

For most of what this policy describes, Selr Group Pty Ltd is the data controller: we decide what to collect and why. For creator-hosted member data, we act as a processor. The Data Processing Agreement sets out that split precisely.

A word on vocabulary. "Personal data" (in Australia, "personal information") means any information relating to an identified or identifiable person: an email address, an IP address, a Telegram user ID, a purchase tied to an account. Aggregated or de-identified data that can no longer reasonably be linked to you falls outside this policy, and where we produce such data we do not attempt to re-identify it. This document is written in plain English on purpose; if a sentence here ever conflicts with a marketing page, this document wins.

What we collect. When you create an account and buy or install skill packs, we collect:

• Account data: your email address and display name, plus account timestamps (created, last sign-in, deletion requested if applicable).
• Purchase records: transaction metadata for each order: the pack, the price, the currency, the date, Stripe transaction identifiers, and the last four digits of your card as reported back by Stripe for receipts. Never the full card number, never the CVC. Those go from your browser straight to Stripe.
• Installs and usage events: which packs you have installed, when each install runs (invocation events), and token counts per run. We use these to meter usage and to show you your own consumption.
• Buyer secrets: if an installed pack needs a credential of yours (an API key, a token), we store it encrypted with AES-256-GCM. A secret is used solely to run your own installs. No staff member reads buyer secrets in the ordinary course of business; the only exception is an abuse investigation, where access is restricted to the people running the investigation and is logged.
• Community activity: posts and comments you publish in Loup community spaces, with your display name attached. Community spaces are visible to other users and may be publicly visible.
• Telegram identity, if you link it: your Telegram user ID and display name. If you participate in a Telegram group that a creator has bound to their Loup community, your messages in that group are bridged into the community feed on Loup. This is the single most surprising data flow on the platform, so it gets its own treatment in section 2.4; it applies to you as a buyer too.
• Email engagement: delivery, open, and click events on the emails we send you, recorded through our email provider.
• Logs and IP address: request logs, including IP address and user-agent, kept for security monitoring and rate limiting.
• Support correspondence: if you email support@selrgroup.com.au, we keep the thread so we can answer you and fix recurring problems at the source.

What we never hold for buyers: full card numbers, CVCs, or bank credentials (those go directly to Stripe and stay there); and the content of your conversations with your own AI agent. Packs are delivered as files into an agent you run; what we record about execution is that an install ran and how many tokens it used, not what you said to your agent.

How we use it. Purpose by purpose:

• Delivering the service: account data and install records let us authenticate you, deliver pack files, and run your installs. Buyer secrets exist for exactly that last job and nothing else.
• Billing and receipts: purchase records and usage events (invocations, token counts) drive metering, receipts, and the consumption view in your dashboard.
• Keeping your account safe: logs and IP addresses feed sign-in protection, rate limiting, and fraud screening on purchases.
• Talking to you: transactional email (receipts, security notices, changes to terms) goes to every account holder, because the service cannot run without it. Product and marketing email is separate: consent-based where your law requires it, opt-out everywhere, and the unsubscribe link in the footer works either way. Engagement events tell us whether mail is being delivered and read; we use them for deliverability, not for profiling you.
• Improving the product: usage patterns, mostly in aggregate, show us which packs and features earn their keep and where flows break.

Who receives it. Three kinds of recipients:

• Infrastructure providers, listed with their roles and locations in section 4. Each sees only the slice its function requires.
• Stripe, for payment. Your card details travel from your browser to Stripe without touching us; what comes back to us is transaction metadata and the last four digits.
• The creator whose pack you bought, who can see order details for their own sales (your display name, the pack, the date, the amounts) so they can support you and reconcile their income. Creators never receive your payment details or your buyer secrets.

One forward-looking note deserves its own paragraph. A hosted runtime option exists in the platform’s design that would send prompts to Anthropic for execution. It is currently switched off: today, no buyer prompts leave the platform. If we ever enable it, we will update this policy and the sub-processor list first, and the feature will be visibly optional rather than silently defaulted on.

What we collect. Everything in the buyer section can apply to you as well (creators hold accounts, buy packs, post in communities). On top of that:

• Seller profile: the display name, listing copy, and imagery you publish with your packs. Listings are public; that is their point.
• Payout and identity data, held by Stripe: to pay you, Stripe collects and verifies your payout details and identity under its own terms and privacy policy. We receive status metadata (for example, "payouts enabled") and the identifiers needed to route your share. We do not hold your bank account details.
• Sales records: per-sale transaction metadata, commission calculations, and payout history. We keep these as long as tax and financial-reporting law requires (see section 8).
• GitHub connection: skill packs are delivered as files, and pack source lives in GitHub repositories. When you connect GitHub we store the identifiers needed to fetch and deliver your pack source (account and repository references).
• Community configuration: the communities you run on Loup, including any Telegram groups you bind for bridging.
• Affiliate participation: if you also act as an affiliate, we record your referral code, the referrals attributed to it, and the commissions you have earned, so they can be calculated and paid.

Listings deserve one extra sentence: a seller profile is public by design, visible to people without accounts and to search engines. Publish in it only what you are comfortable having public.

A role change you should understand. When you upload or connect data about your own members, for example a CSV import of your member list, course enrollments, or a community roster, you are the controller of that data and we process it on your instructions as your processor. The Data Processing Agreement governs that processing automatically. Practical consequence: you must have the right to upload that data, and your members’ privacy questions about it go to you first. We will forward to you any request we receive that concerns data we hold on your behalf.

How we use it. To list and deliver your packs, calculate and route your earnings, host the communities you configure, meet our tax and record-keeping obligations, and keep the marketplace safe (including fraud screening on sales).

Who receives it. The providers in section 4; Stripe for payouts; GitHub for pack source delivery; and buyers, who see your public seller profile and listings.

If you browse Loup without an account, the data we handle is thin:

• Logs and IP address: standard request logs (IP, user-agent, pages requested, timestamps) used for security monitoring, abuse prevention, and rate limiting. Logs exist to answer one question, "is this traffic legitimate?", and they age out on the short rolling window described in section 8.
• Analytics, where permitted: we use PostHog (US cloud) for product analytics: pages viewed, the referring site, coarse browser and device information, and where people drop out of flows. In jurisdictions that require prior consent (the EEA and UK), PostHog does not run until you accept it on the cookie banner. Elsewhere, it runs on a notice-and-opt-out basis. The Cookie policy has the details and the off switch.
• Affiliate attribution: if you arrive through a link containing a ?ref= parameter, we store the referral code in a first-party cookie and in your browser’s localStorage. Nothing about you personally is captured at that moment; the stored code simply means that if you later sign up or buy, the referring affiliate is credited with the sale and earns a commission. This is disclosed in full in the Cookie policy.
• Anything you choose to send us: if you email support@selrgroup.com.au, we keep the correspondence so we can answer you.

We do not build advertising profiles of visitors, we do not run third-party ad trackers, and we do not attempt to identify you from your IP address except where necessary to investigate abuse or a security incident.

Some people never sign up for Loup, yet their personal data reaches us because of someone else’s actions. We want this to be the clearest section of the policy, not the most buried. Three situations:

(a) Members of bridged Telegram groups. A creator can bind a Telegram group to their Loup community. Once a group is bound, messages posted in that Telegram group are bridged into the community feed on Loup, where they can be seen by the community’s audience, including publicly. For each bridged message we receive the Telegram user ID, display name, and message content of the person who posted, whether or not that person has a Loup account. If you are in a Telegram group and you are unsure whether it is bridged, ask the group’s admin. If you do not want your messages bridged, stop posting in the bound group or leave it, and contact us at support@selrgroup.com.au to have your bridged messages removed from the Loup feed. Creators who bind groups are required by our terms to tell their group members that bridging is on; a creator who binds a group without telling its members is in breach of those terms, and we act on reports of it. Bridging is also one-directional in scope: we receive what is posted in the bound group, we do not read your private Telegram chats, your contact list, or your activity in groups that are not bound.

(b) People referred by an affiliate. If someone shares a Loup link with you that carries a ?ref= code and you click it, the referral code is stored in your browser as described in section 2.3. The affiliate who referred you can see aggregate statistics about their referrals and the commissions they earned; they are not shown your identity by the attribution system. The stored code sits in your own browser until it expires or you clear it, and clearing your cookies and localStorage removes the attribution with it.

(c) People whose data a creator uploads. Creators can import member lists (for example a CSV of names and email addresses), enrol people in courses, or maintain community rosters on Loup. For that data, the creator is the controller and Loup is a processor: we host and process it only to provide the creator’s community and course features, under the Data Processing Agreement. We do not use creator-imported member data for our own marketing, we do not sell it, and we do not combine it with our marketplace data for our own purposes. If your data was uploaded by a creator and you want it corrected or deleted, contact that creator first, since they control it; if you cannot reach them, contact us and we will forward your request and assist within our role as processor.

Whichever persona fits you, we use personal data for a short list of platform-wide purposes:

• Security and fraud prevention. We analyse logs, IP addresses, usage patterns, and transaction signals to detect account takeover, payment fraud, scraping, and abuse of the runtime. Rate limiting runs on IP and account identifiers.
• Service operation. Authentication, session management, delivering pack files, executing installs, metering usage, calculating commissions, and producing receipts.
• Product improvement. We study how the platform is used, mostly in aggregate (which features get used, where flows break), to decide what to fix and build. Analytics collection is consent-gated where the law requires it.
• Communications. Transactional messages (receipts, security alerts, changes to legal terms) are sent to everyone with an account, since the service cannot run without them. Marketing email is separate: consent or opt-out based depending on your jurisdiction, and every marketing email carries an unsubscribe link.
• Legal compliance and protection. Tax and financial-reporting obligations, responding to lawful requests from authorities, enforcing our terms, and establishing or defending legal claims.

What we do not do, for anyone: sell personal information, share it with data brokers, or use buyer secrets or creator-imported member data for advertising.

Automated decision-making. Automated systems may flag suspicious activity or apply rate limits in real time, but we do not make decisions that produce legal or similarly significant effects on you based solely on automated processing.

Aggregated and de-identified data. We produce counts, rates, and trends across many accounts for capacity planning and platform metrics. Once data can no longer reasonably be linked to a person it sits outside this policy, and we do not try to reverse that.

We run Loup on a small set of infrastructure providers. Before a provider joins this list we require three things: a contract with data protection terms (including transfer safeguards where needed), a security posture consistent with section 7, and a function we cannot reasonably perform in-house. Each receives only what its function requires:

• Supabase (United States and Australia regions): our database and authentication layer. Holds account data, purchase metadata, usage events, community content, and encrypted buyer secrets.
• Vercel (United States): application hosting and CDN. Request data, including IP addresses, passes through Vercel’s edge.
• Stripe: payment processing and creator payouts. Card and bank details go directly to Stripe and never touch our servers; see Stripe’s privacy policy.
• GitHub: hosts and delivers skill pack source files. Receives the repository and account references involved in pack delivery.
• Telegram: when you link a Telegram identity or participate in a bound group, message and identity data flows between Telegram and Loup as described in section 2.4.
• Resend: transactional email delivery, including the engagement events (delivered, opened, clicked) that come back from your mailbox provider.
• Sentry: error monitoring. When something breaks, the error report can include request context such as IP address and account identifiers.
• PostHog (US cloud): product analytics, gated by consent where required. See the Cookie policy.
• Anthropic: conditional and currently inactive. Anthropic would process buyer prompts only if our hosted runtime option were enabled. It is currently off, and no buyer prompts leave the platform today. If that changes, this policy and the sub-processor list will be updated first.

Providers acting as our processors handle personal data only on our documented instructions, under contracts that forbid using it for their own advertising or selling it. Stripe stands slightly apart: it processes the payment data you give it under its own policy, as disclosed above, because payment processing is its regulated business rather than a service performed on our instructions.

Beyond providers, three further recipient categories: creators receive order data for their own sales, as described in section 2.1; authorities receive data where the law compels disclosure or where disclosure is necessary to protect people from serious harm; and in the event of a merger, acquisition, or asset sale, personal data may transfer to the successor entity, which remains bound by this policy until it publishes a replacement. We do not sell personal information to anyone.

Where the GDPR or UK GDPR applies, every processing activity in this policy rests on one of four legal bases under Article 6:

• Contract (Article 6(1)(b)): running your account, delivering and executing packs, metering usage, processing purchases and payouts, and sending transactional messages. Without this processing the service you signed up for cannot exist.
• Legitimate interests (Article 6(1)(f)): fraud prevention, platform security, rate limiting, abuse investigation, and product improvement based on usage patterns. For each of these we have weighed our interest against your rights and freedoms; none involves decisions with legal effect on you, and you can object as described in section 12.2.
• Consent (Article 6(1)(a)): marketing email and non-essential cookies, including analytics in the EEA and UK. Consent can be withdrawn at any time without affecting the service.
• Legal obligation (Article 6(1)(c)): retaining tax and financial records, responding to binding requests from authorities, and complying with sanctions and anti-fraud law.

A worked mapping of the common cases:

• Account management, pack delivery, install execution, buyer secret storage: contract.
• Purchase processing, payouts, commission calculation: contract.
• Fraud screening, rate limiting, security logging, abuse investigation: legitimate interests.
• Product analytics: consent in the EEA and UK; legitimate interests with opt-out elsewhere.
• Marketing email: consent, or opt-out-based where your law permits it, with an unsubscribe link in every message.
• Tax and financial record retention: legal obligation.
• Affiliate attribution: contract with the affiliate, legitimate interests with respect to the referred buyer.

Where we act as a processor for creators (section 2.4(c)), the creator is responsible for establishing the legal basis; our processing rests on the creator’s documented instructions under the Data Processing Agreement.

The fastest path for most requests is self-serve, no email required:

• Export your data. /dashboard/privacy lets you download a machine-readable copy of the personal data we hold about your account: profile, purchases, installs, usage events, community activity, and attribution records. Encrypted secret values are excluded from the export by design; you re-enter credentials wherever you migrate to.
• Delete your account. The same page lets you delete your account. Deletion removes your personal data except the records we are legally required to keep (see section 8), and deleted data ages out of backups on the backup cycle.
• Correct your data. Profile details are editable in the dashboard. Anything you cannot edit yourself, email us and we will correct it.
• Marketing opt-out. Every marketing email contains an unsubscribe link. Unsubscribing never affects transactional messages like receipts and security notices.
• Cookie choices. The cookie banner’s manage link lets you change your consent state at any time; see the Cookie policy.

Depending on where you live, you also hold statutory rights: access, correction, deletion, portability, restriction, objection, and the right to complain to a regulator. The jurisdiction annexes in section 12 spell out the exact set for Australia, the EEA and UK, and the United States. To exercise any right that the dashboard does not cover, email support@selrgroup.com.au. We may ask you to verify your identity before acting on a request, because handing your data to an impersonator would itself be a breach, and we respond within the timeframes the applicable law sets. If your request concerns data we process on a creator’s behalf, we will forward it to that creator and assist, as section 2.4(c) describes.

If we refuse a request, for example deletion of a transaction record that tax law makes us keep, we will say so, name the ground, and point you to the complaint path in section 12 that applies to you. Exercising a privacy right is free and never degrades your service.

Security measures we maintain, in plain terms:

• Encryption in transit: TLS 1.2 or higher on every connection.
• Encryption at rest for secrets: buyer credentials are stored under AES-256-GCM, with key rotation capability.
• Multi-factor authentication on the infrastructure accounts that run the platform.
• Least-privilege access for staff, with row-level security policies in the database so queries are scoped to the tenant they belong to.
• Rate limiting and abuse detection on the public surfaces.
• Audit logging of sensitive operations, including secret access, and a no-plaintext rule for credentials: decrypted secret values are not written to logs.
• Backups taken on a schedule, with deleted data purged on cycle.

No security program eliminates risk entirely, and we will not pretend otherwise. If a breach occurs that affects your personal data, we will notify you and the relevant regulators as the applicable law requires, including the notifiable data breaches scheme of the Australian Privacy Act and Articles 33 and 34 of the GDPR where they apply.

Your side of the bargain matters too. Use a strong, unique password, protect the email account that controls your password resets, and treat the credentials you store as buyer secrets with the care you would give any production key: rotate them if you suspect exposure, and remove them when an install no longer needs them. If you believe your account has been compromised, contact support@selrgroup.com.au immediately.

We keep personal data only as long as a stated purpose requires:

• Account data: for as long as your account is active. On deletion, personal data is removed except as listed below.
• Transaction, tax, and financial records: up to seven years after the transaction, as Australian tax and corporations law requires. Where a record must survive account deletion, we keep the minimum needed for the legal purpose.
• Usage events (invocations, token counts): for as long as they are needed for billing, metering, and dispute resolution.
• Community posts and comments: removed or de-identified as part of account deletion, subject to the same backup-cycle lag as everything else.
• Security logs: on a short rolling window sufficient for incident investigation.
• Backups: deleted data persists in backups until the backup cycle purges it, after which it is gone from backups too.

For data we process on a creator’s behalf, retention follows the creator’s instructions and the delete-or-return commitment in the Data Processing Agreement.

The criteria behind these periods, if you want the reasoning rather than the numbers: whether the data is needed to operate an active account, whether a law names a minimum retention period, whether a dispute or investigation is open, and whether the purpose could be met with aggregated data instead. When the last applicable reason expires, the data is deleted or de-identified rather than kept on the off chance it becomes useful.

We are an Australian company, and several of our providers run on United States infrastructure: Vercel, PostHog, GitHub, and Stripe, with Supabase operating in both US and Australian regions. Using Loup therefore involves transferring personal data across borders.

Where the GDPR or UK GDPR applies to a transfer, we rely on the European Commission’s Standard Contractual Clauses (and the UK addendum or international data transfer agreement, as applicable) with the receiving provider, alongside the provider’s own technical safeguards. For disclosures from Australia, we take the steps Australian Privacy Principle 8 requires before disclosing personal information overseas, which in practice means contractual commitments from each provider that its handling is consistent with the APPs. The current list of providers and their locations is in section 4.

In plain English: Standard Contractual Clauses are a contract template published by the European Commission that binds the receiving company to European-grade protections wherever in the world it operates, and APP 8 is the Australian analogue duty, under which we must take reasonable steps before an overseas disclosure and remain accountable for what happens to the data afterwards. If a transfer mechanism we rely on is struck down or replaced, we will move to a lawful successor mechanism rather than carry on regardless.

Loup is not directed at anyone under 18, and we do not knowingly collect personal data from children. If you believe a person under 18 has created an account or that we otherwise hold a child’s data, tell us at support@selrgroup.com.au and we will delete it. We do not run age-verification checks; we rely on the age representation every account holder makes in our terms, and we act on credible reports.

We update this policy when the platform or the law changes. The date at the top reflects the latest revision. For material changes, for example a new sub-processor that handles buyer prompts, or a change to what creators can see about buyers, we will give notice by email or by a prominent notice in the product before the change takes effect. Continued use after the effective date constitutes acceptance, but for changes that require consent under applicable law, we will ask for it rather than assume it. A change notice will name what changed in concrete terms; "we updated our privacy policy" with no detail does not count as notice in our book.

We are bound by the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). This policy is our APP 1 privacy policy. Under the APPs you may request access to the personal information we hold about you (APP 12) and request correction of it (APP 13); the self-serve tools in section 6 satisfy most such requests immediately, and we handle the rest by email.

Our overseas disclosure practices are described in section 9; the likely recipient locations are the United States (Vercel, PostHog, GitHub, Stripe, and the US Supabase region).

If you believe we have breached the APPs, complain to us first at support@selrgroup.com.au so we can investigate. If you are not satisfied with our response, you may complain to the Office of the Australian Information Commissioner (OAIC) at www.oaic.gov.au. The OAIC accepts complaints online and its service is free.

Access and correction under the APPs are free of charge. In the limited cases where the Act permits us to refuse (for example, where access would prejudice an active fraud investigation), we will give you written reasons and the complaint mechanisms available to you.

If you are in the European Economic Area or the United Kingdom, the GDPR or UK GDPR gives you the following rights over personal data for which we are the controller:

• Access (Article 15) and portability (Article 20): the export at /dashboard/privacy delivers both in one machine-readable file.
• Rectification (Article 16) and erasure (Article 17): dashboard editing and self-serve deletion, with the legal retention carve-outs in section 8.
• Restriction (Article 18) and objection (Article 21): you may object to processing based on legitimate interests, including analytics, and we will stop unless compelling legitimate grounds override. Objection to direct marketing is absolute: one unsubscribe click ends it.
• Withdrawal of consent (Article 7(3)): via the cookie banner for cookies and the unsubscribe link for marketing, at any time, without affecting prior processing.

We have not yet appointed a representative in the EU or the UK under Article 27. Until we do, please direct any GDPR inquiry to us at support@selrgroup.com.au; if we appoint a representative, their details will appear in this annex. You also have the right to lodge a complaint with the supervisory authority of your place of residence or work, or, for the UK, with the Information Commissioner’s Office. Transfers out of the EEA and UK are covered in section 9.

When objecting to legitimate-interest processing, tell us which processing you mean so we can act precisely. For analytics, the fastest objection is the cookie banner’s manage link, which switches PostHog off without any correspondence. For anything else, email us and we will either stop the processing or explain the compelling grounds we believe override, in which case the complaint routes above remain open to you. On Article 22: as stated in section 3, we do not make solely automated decisions with legal or similarly significant effects, so no separate Article 22 mechanism is needed today.

Several US states (including California, Colorado, Connecticut, Virginia, and others) grant residents privacy rights. For the state laws that ask for disclosure by category: we collect identifiers (email address, display name, IP address), commercial information (purchases, installs, subscription state), and internet activity (usage events, pages viewed, email engagement). We collect no biometric data, no health data, and no precise geolocation. Sources are you, your devices, Stripe, and creators (where a creator imports data about you, we act as their service provider). Disclosures go only to the providers and recipients in section 4, for the business purposes this policy describes. Where the state laws apply to you, we honour:

• The right to know and access the personal information we hold: covered by the export at /dashboard/privacy.
• The right to correct inaccurate personal information.
• The right to delete, subject to the legal retention carve-outs in section 8.
• The right to opt out of sale or sharing. We do not sell personal information, and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of. If that ever changed, we would provide the required opt-out mechanism before doing it.
• Non-discrimination: exercising a privacy right never degrades your service.

To exercise a right that the dashboard does not cover, email support@selrgroup.com.au. We will verify your identity, accept requests from authorised agents where state law provides for them, and respond within the statutory window. If we decline a request, we will explain why and how to appeal where state law gives you an appeal right. Because we do not sell or share personal information, we do not process opt-out preference signals for sale or sharing; should our practices ever change, the required signal handling would ship with the change.

Privacy questions, rights requests, and complaints all go to support@selrgroup.com.au. Put "Privacy" in the subject line so it routes correctly, and tell us which right you are exercising, the email address on the account concerned, and, if you are writing about a creator’s community or a bridged Telegram group, which community or group you mean. The controller is Selr Group Pty Ltd (ABN 41 662 328 056), Queensland, Australia; postal address available on request. Remember that the fastest route for exports, deletion, and cookie choices is self-serve: /dashboard/privacy and the cookie banner’s manage link.