RVRPA Privacy Agreement

Scope and version

This agreement covers data RVRPA handles when you browse the site, create or use a member account, contribute content, use PAC or reading eligibility, submit qualification or activity information, or use Email subscription features. Each feature should process only data needed for that feature.

A material new data use that requires separate consent under applicable law or the service design will be disclosed before activation and use the corresponding acceptance flow. Updating this page alone does not create a new versioned acceptance record for existing members.

Account, member, and eligibility data

Supabase Auth handles Email/password sign-in, Google sign-in identity, and sessions. If you use Google sign-in, Google may provide a verified Email, name, and avatar. Formal member records may include Member ID, nickname, status, trading experience, roles or qualifications, and the referrer relationship.

When you use the relevant features, RVRPA also handles exchange UID submission or confirmation data and records needed for eligibility calculations, PAC ledger and Article-purchase records, tasks or achievements, and Affiliate, Partner, or other qualification data. These records support account management, authorization, review, service delivery, ledger integrity, and security.

Sign-in security uses the `rvrpa_login_device` HttpOnly first-party Cookie for a random device ID; the rate-limit store pairs that ID with a hashed Email plus failure count and lock state. The `rvrpa_referrer` Cookie stores a visitor's referrer choice type and Member ID. After you confirm an author's personal invite-code redirect, the signed HttpOnly `rvrpa_article_referral` Cookie stores the Article override and exchange identifiers so a later UID submission for that exchange can determine attribution. Interface features such as onboarding may also use local storage for non-secret state.

Contribution, application, and review data

An Article contributor application stores the motivation, markets, content types, experience, referral-mechanism familiarity, contribution purposes, and rules answer you submit, plus an optional portfolio URL or writing sample. Article drafts, immutable submission snapshots, image references, author attribution, review state, and return reasons are stored separately.

Member changes, UIDs, tasks, Affiliate or Partner workflows, activity proposals, and other review processes store the original or proposed data, submission time, review result, necessary evidence, and audit data required for that workflow. Pending data does not replace approved formal or public data merely because it was submitted.

Application answers, review notes, Auth UUIDs, private images or Storage locators, unpublished drafts, and restricted Article body content remain restricted data and are not part of ordinary public projections.

What becomes public

The public member page shows an active member's Member ID, public nickname, and active public achievements, plus the public introduction and X, Instagram, and Threads accounts and links the member submits and receives approval for, and published works attributed to that Member ID.

Members with an active Affiliate qualification also show their approved name, introduction, and avatar. The referrer picker may show an eligible Affiliate's Member ID, approved localized name, and current approved avatar. Formally published Articles and Activities show only approved publication content, author attribution, and corresponding public media.

Pending or returned content, private trading experience, Email, Auth UUID, exchange UIDs, PAC balance or statement, the actual referrer relationship, review data, private images or Storage locators, unpublished drafts, and restricted Article body content are not public.

Email subscription and unsubscribe

Email subscription is a separate first-party consent flow. It does not require member sign-in and is not tied to Member ID, profile, referrer, UID, Affiliate, or Partner status. A subscription request needs only Email, locale, and the topics you choose. RVRPA separately stores subscription status, current preferences, revision, confirmation intent, immutable audit evidence, and necessary delivery or sync work metadata.

The first-party request and consent state exists, but real confirmation and welcome Email delivery still waits for the E07 sender to be enabled; a subscription becomes active only after successful confirmation. Preference changes and unsubscribe use a current management capability; local unsubscribe immediately removes send eligibility. Raw bearer tokens for confirmation, management, or unsubscribe are not stored in the DB, outbox, or audit. Confirmed preferences and necessary audit history are not rewritten as though they never existed after unsubscribe.

Subscription data is not automatically merged into a member profile if you later become a member, and subscription consent is not inferred from sign-in, UID, or referrer status. The member-account deletion transaction also does not automatically delete this separate subscription record. Current self-service covers viewing or changing preferences and unsubscribe; other erasure or stop-processing requests require separate privacy handling through the contact path below, subject to applicable retention duties.

Service providers and external services

Cloudflare is used for website or edge services and Turnstile human verification. Supabase is used for Auth, database, and Storage. Google identity is used only if you choose Google sign-in. Account OTP and password-recovery Auth Email is currently sent through Brevo under Supabase's protected mail configuration. Newly managed Article and activity-proposal images use private Supabase Storage; older activity images may still be read from existing Google Drive objects during migration or rollback compatibility. Each provider should receive only data needed to perform its service.

The first-party newsletter or recommendation consent model and Kit-projection data structures exist, but the current program does not call the Kit API and real Kit sender or sync is not enabled. This notice therefore does not describe Kit as currently receiving subscriber data. Before activation, provider and account fit, required notice, and retention decisions must be completed before the relevant Email, locale, topic, and subscription state is transmitted.

When an exchange comparison row has a CMC ID, the browser loads its exchange logo directly from CoinMarketCap's image domain, so that third party can receive ordinary HTTP request metadata; rank and fee derivatives are fetched through an RVRPA same-origin API. If you separately open a third-party website, exchange, or video service, that third party may also process browser and connection data under its policy.

Operational evidence and currently disabled non-account-linked measurement

Email subscription request and confirmation audit events are operational evidence for the consent state machine, not cross-site tracking. A separate minimal first-party measurement implementation has been prepared locally for Article views or external clicks, Activity detail views or external clicks, onboarding, and tutorial events. Its payload and store omit member-account identifiers, but requests still pass through RVRPA and infrastructure that process ordinary network metadata. The new measurement collection is currently disabled.

If it is later activated after the required policy work, the design stores only event ID and event type, public content kind and ID, locale, coarse source, client event time and time zone, plus necessary onboarding version or public Activity model. It does not store Email, Member ID, referrer, topic codes, raw capabilities, full or destination URLs, or private or restricted body content.

No retention period or purge rule has been approved for this measurement. Client and server activation gates must remain closed until retention, notice, and formal release authorization are complete. Updating this page does not turn tracking on.

Retention, deletion, and security

RVRPA does not invent one fixed retention period for every data category. Records follow each feature's lifecycle: account and qualification data supports service delivery, while some submission or review snapshots, audit evidence, and PAC transactions are immutable or ledger records that may need to remain after ordinary editing or unsubscribe to preserve history, ledger integrity, security, or dispute evidence.

The existing permanent-deletion data contract distinguishes accounts with UID or PAC history: without that history, the Auth and formal-member account can be hard-deleted; where ledger integrity requires history, identifiable member account data is removed and a random deletion token is used for the minimum tombstone or PAC-ledger identity, while other member, UID, task, qualification, and audit links are removed or controlled-redacted by the deletion transaction. This does not mean all content evidence disappears: an Article contributor's member link may be cleared while fixed author display or source evidence, immutable submission snapshots, and necessary publication evidence can remain. Published activity content is separately reviewed for anonymous retention or purge. Whether this workflow is enabled in the currently deployed environment depends on the deployed version.

RVRPA uses access controls, RLS, protected server credentials, private Storage, and necessary audit controls to limit unauthorized access. Networked and third-party services still cannot guarantee zero risk.

Access, correction, stopping use, and contact

You can change self-editable data in the existing member interface. Member, UID, or qualification changes that require review follow the existing change or review workflows. With a valid Email management capability, you can view the current subscription status and preferences and explicitly update or unsubscribe.

For access, correction, stopping a particular data use, account deletion, or other privacy questions, contact reversalpatterns@gmail.com with only the information needed to identify the request. Do not send passwords, sign-in tokens, or other secrets that directly grant account access. What can be deleted, anonymized, or must remain depends on the data lifecycle, ledger or audit integrity, and applicable law.

This notice does not invent an unconfirmed legal operating entity, data-use region, governing law, or statutory retention period. If those facts are required for a formal notice, they must be added once confirmed rather than filled with placeholder information.