Loyal Hearts Club — Safety Ledger Policy

Loyal Hearts Club, LLC ("we," "us," "our," or the "Company") operates the Loyal Hearts Club platform (the "Platform," "App," or "Service"). This Safety Ledger Policy ("Policy") explains how we retain limited, non-reconstructive identity data after account deletion or ban to protect the safety of our user community. This Policy is supplemental to our Privacy Policy, Terms of Service, and Biometric Data Policy.

We believe that a safe community is a prerequisite for honest relationships. The Safety Ledger is a critical component of our commitment to user safety.

Purpose of the Safety Ledger
What Data Is Retained
What Data Is NOT Retained
When Safety Ledger Entries Are Created
How Retained Data Is Used
Legal Basis for Retention
Non-Reconstructive Nature of Retained Data
Data Security
Data Retention Period
Your Rights and Limitations
Consent and Disclosure
Changes to This Policy
Contact Information

1. Purpose of the Safety Ledger

1.1. Community Safety. The Safety Ledger exists to protect the Loyal Hearts Club community from individuals who have been removed from the Platform for violating our Terms of Service, engaging in harmful behavior, or otherwise posing a safety risk.

1.2. Fraud Prevention. The primary purpose is to prevent banned or removed users from circumventing enforcement actions by creating new accounts.

1.3. Ban Evasion Detection. When a new user registers or undergoes photo verification, their identity markers are compared against the Safety Ledger to detect potential ban evasion.

1.4. Specific Threats Addressed. The Safety Ledger protects against:

Banned users creating new accounts to continue harmful behavior;
Users who were removed for harassment, scamming, or threatening behavior returning under new identities;
Users creating duplicate accounts to circumvent platform limits or policies; and
Identity theft and impersonation attempts.

2. What Data Is Retained

The Safety Ledger retains only the following data points, all of which are non-reconstructive:

2.1. Hashed Phone Number

Your phone number is hashed using SHA-256 with an application-specific salt before storage.
The hash is a one-way function: your actual phone number cannot be recovered from the hash.
Purpose: Detect if a new registration uses the same phone number as a previously removed account.

2.2. Hashed Email Address

Your email address is hashed using SHA-256 with an application-specific salt before storage.
The hash is a one-way function: your actual email address cannot be recovered from the hash.
Purpose: Detect if a new registration uses the same email address as a previously removed account.

2.3. Face Embedding

A 128-dimensional floating-point vector representing the geometric relationships between facial features.
This encoding is non-reconstructive: it is impossible to reconstruct, regenerate, or approximate a facial image from this vector.
The face embedding is only present if you completed photo verification before account removal.
Purpose: Detect if a new user's face matches a previously removed account, even if they use a different phone number and email.

2.4. Ban Record IDs

References to the specific ban records associated with your account.
Purpose: Provide context about why the Safety Ledger entry exists and what enforcement actions were taken.

2.5. Hashed Device Fingerprints

Device fingerprints are hashed using SHA-256 with an application-specific salt before storage.
The hash is a one-way function: your actual device information cannot be recovered from the hash.
Purpose: Detect if a new registration originates from the same device as a previously removed account.

3. What Data Is NOT Retained

The Safety Ledger explicitly does not retain the following personal information:

| Data Type | Retained? | |---|---| | First name or last name | No | | Profile photos or images | No | | Bio or profile description | No | | Faith preference | No | | Children status | No | | Sexual orientation | No | | Gender | No | | Discovery preferences | No | | City or state | No | | Date of birth | No | | Messages or conversation content | No | | Conversation history or metadata | No | | Admirer requests or connections | No | | Couple profile information | No | | Topic posts or replies | No | | Support ticket content | No | | Payment details | No | | Notification preferences | No |

In summary: The Safety Ledger contains only cryptographic hashes and a mathematical vector. It does not contain any information that would allow someone to learn your name, see your face, read your messages, or reconstruct your profile.

4. When Safety Ledger Entries Are Created

Safety Ledger entries are created only under the following circumstances:

4.1. Account Deleted (Clean)

When an account is deleted through the standard administrative process. The entry is created with source type account_deleted to provide a baseline fraud prevention record.

4.2. Account Banned

When an account is banned due to violations of the Terms of Service or other enforcement actions. The entry is created with source type account_banned to prevent the banned user from re-registering.

4.3. Account Deleted After Ban

When a banned account is subsequently deleted. The entry is created with source type account_deleted_post_ban to maintain the ban enforcement record even after the account data is anonymized.

4.4. No Other Triggers. Safety Ledger entries are never created for:

Account deactivation (which is user-initiated and reversible);
Routine profile updates;
Voluntary feature changes; or
Any reason other than the three triggers described above.

5. How Retained Data Is Used

5.1. New Registration Screening

When a new user attempts to register, the following checks are performed against the Safety Ledger:

(a) Phone hash comparison: The SHA-256 hash of the new user's phone number is compared against hashed phone numbers in the Safety Ledger.

(b) Email hash comparison: The SHA-256 hash of the new user's email address is compared against hashed email addresses in the Safety Ledger.

(c) Face embedding comparison: If the new user undergoes photo verification, their face encoding is compared against face embeddings in the Safety Ledger using Euclidean distance measurement.

5.2. Match Responses

When a match is detected between a new registration and a Safety Ledger entry, the system may take one or more of the following actions:

(a) Quarantine: The new account may be placed into a quarantine state pending administrator review.

(b) Administrator Alert: An alert is generated for the moderation team to investigate the potential match.

5.3. Human Review. Matches are subject to human review by our moderation team. No user is permanently denied access solely based on an automated Safety Ledger match without the opportunity for administrator review.

5.4. No Other Uses

Safety Ledger data is used exclusively for the purposes described in this Section. It is never used for:

Marketing or advertising;
Profiling or behavioral analysis;
Sale to third parties;
Research or analytics (except aggregated, de-identified statistics about system effectiveness);
Any purpose unrelated to fraud prevention and community safety.

6. Legal Basis for Retention

6.1. California Consumer Privacy Act (CCPA)

The CCPA provides consumers with the right to request deletion of their personal information (§ 1798.105). However, § 1798.105(d)(2) provides an exception permitting businesses to retain personal information necessary to:

"Detect security incidents, protect against malicious, deceptive, fraudulent, or illegal activity, or prosecute those responsible for that activity."

The Safety Ledger is maintained under this exception. Retaining non-reconstructive identity markers is necessary to detect banned users attempting to re-register (a deceptive activity) and to protect the community from individuals previously removed for fraudulent or harmful behavior.

6.2. Texas Data Privacy and Security Act (TDPSA)

The TDPSA, effective July 1, 2024, provides consumers with data privacy rights, including the right to deletion. However, § 541.107 provides exceptions permitting data retention to:

"Prevent, detect, protect against, or respond to security incidents, identity theft, fraud, harassment, malicious or deceptive activities."

The Safety Ledger is maintained under this exception. The retention of non-reconstructive identity data is necessary to prevent banned individuals from evading enforcement through new account creation, and to detect identity theft and harassment.

6.3. Proportionality

We believe the Safety Ledger represents a proportional approach to fraud prevention:

(a) Minimal data: Only five data points are retained, all in non-reconstructive form.

(b) No readable PII: No names, photos, messages, or other human-readable personal information is kept.

(d) Non-reconstructive embedding: The face embedding cannot be used to generate a facial image.

(e) Purpose-limited: The data is used exclusively for new registration screening.

(f) Human oversight: Matches trigger review by human moderators, not automated denials.

7. Non-Reconstructive Nature of Retained Data

7.1. Hashed Data (Phone, Email, Device Fingerprint). SHA-256 hashing is a one-way cryptographic function. Given a hash value, there is no computationally feasible way to determine the original input. The addition of an application-specific salt further protects against precomputation attacks (rainbow tables).

7.2. Face Embedding. The 128-dimensional face encoding is a mathematical abstraction of facial geometry. It is fundamentally different from a photograph:

(a) It contains no pixel data, color information, or visual information of any kind.

(b) There is no known technology or algorithm that can reconstruct a face from a 128-dimensional encoding.

(c) The encoding captures relative geometric relationships (e.g., ratios of distances between facial landmarks) in a compressed form that discards the vast majority of visual information.

(d) Multiple different faces could theoretically produce similar (though not identical) encodings, further demonstrating that the mapping is not reversible.

7.3. Practical Implications. If the Safety Ledger database were compromised:

(a) An attacker could not determine anyone's name, phone number, email address, or what they look like.

(b) An attacker could not reconstruct any user profiles or personal information.

(c) The hashes could potentially be compared against known values (e.g., if an attacker already had a specific phone number, they could hash it and check for a match), but they could not extract the original values from the hashes alone.

8. Data Security

8.1. Access Controls

Safety Ledger data is stored in a secured database with access restricted to authorized system processes.
Administrative access requires authenticated administrator credentials and is logged in the immutable audit trail.
The Safety Ledger cannot be browsed or searched by regular users or moderators outside of the automated screening process.

8.2. Infrastructure Security

Safety Ledger data is protected by the same comprehensive security infrastructure as all other Platform data, including:

Encrypted connections (HTTPS/TLS) for all data in transit
Role-based access control (RBAC) with principle of least privilege
Immutable audit logs for all access and modifications
Security headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy)
CORS protection
Rate limiting on all sensitive endpoints

8.3. Audit Trail

All interactions with Safety Ledger data are logged, including:

Creation of new entries (who, when, why, source type)
Matches detected during new registration screening
Administrative access or review
Any modifications (which should not occur under normal operations, as entries are designed to be immutable)

8.4. Separation of Concerns

Safety Ledger data is logically separated from active user data. After a Safety Ledger entry is created and the associated account is anonymized, there is no technical link between the Safety Ledger entry and any active user profile.

9. Data Retention Period

9.1. Retention Duration

Safety Ledger entries are retained for as long as reasonably necessary to fulfill the fraud prevention and community safety purposes described in this Policy. Factors considered in determining retention duration include:

(a) The severity of the conduct that led to the account's removal;

(b) Whether the entry is associated with a ban (versus a clean deletion);

(d) Applicable legal requirements and retention exceptions; and

(e) Industry standards for fraud prevention data retention.

9.2. Review

We periodically review Safety Ledger entries to assess whether continued retention remains necessary and proportionate.

9.3. Destruction

When a Safety Ledger entry is no longer needed for its stated purpose, the data is permanently destroyed in accordance with applicable data destruction standards.

10. Your Rights and Limitations

10.1. Right to Know

You have the right to know whether a Safety Ledger entry exists for you. Contact us at legal@loyalheartsclub.com to make this inquiry. We will verify your identity before responding.

10.2. Right to Access

You have the right to request information about the data contained in your Safety Ledger entry. Due to the non-reconstructive nature of the data, we can confirm:

Whether an entry exists;
When it was created;
The source type (account_deleted, account_banned, or account_deleted_post_ban); and
The categories of data retained (hashed phone, hashed email, face embedding, ban records, hashed device fingerprints).

We will not provide the raw hash values or embedding vectors, as they are not meaningful in human-readable form. We will provide them in machine-readable format upon request.

10.3. Right to Request Deletion

You have the right to request deletion of your Safety Ledger entry. However, please understand that:

(a) Under CCPA § 1798.105(d)(2), we may retain the data if it is necessary to detect security incidents and protect against fraudulent or illegal activity.

(b) Under TDPSA § 541.107, we may retain the data to prevent, detect, protect against, or respond to fraud, identity theft, and harassment.

(c) We will evaluate each deletion request on its individual merits, considering the original reason for the entry, the time elapsed, and the ongoing risk assessment.

(d) If we deny a deletion request, we will provide you with a written explanation of the legal basis for continued retention and information about how to appeal the decision.

10.4. Right to Appeal

If your request for deletion is denied, you may appeal by contacting legal@loyalheartsclub.com with additional information supporting your request. We will review appeals within a reasonable timeframe and provide a written response.

10.5. Right to Non-Discrimination

We will not discriminate against you for exercising your rights under this Policy.

10.6. Limitations

The following limitations apply to Safety Ledger rights:

(a) Verification of identity is required before we process any request. Because Safety Ledger data is non-reconstructive, we may need to verify your identity through alternative means.

(b) We cannot "correct" hashed data. Hashes are mathematical outputs of specific inputs. If your phone number or email has changed, the old hashes would not match your new information, and the new information was never added to the Safety Ledger.

(c) Response times are governed by applicable law (generally 45 days under CCPA and TDPSA, with extensions as permitted).

11. Consent and Disclosure

11.1. Registration Consent

At registration, you are required to consent to the Safety Ledger Policy. This consent is separate from the Terms of Service and Privacy Policy consents, and is recorded with your user ID, document version, timestamp, and IP address.

11.2. Informed Consent

By consenting to this Policy, you acknowledge and agree that:

(a) If your account is deleted or banned, a Safety Ledger entry will be created containing the non-reconstructive data described in Section 2;

(b) This data will be used for new registration screening as described in Section 5;

(d) The retained data is non-reconstructive and does not contain your name, photos, bio, messages, or other human-readable personal information; and

(e) You have the rights described in Section 10, subject to the limitations described therein.

11.3. Withdrawal of Consent

You may withdraw your consent to this Safety Ledger Policy. However, withdrawing consent will result in account deactivation, as this Policy is a required consent for use of the Service. Additionally, withdrawal of consent does not retroactively require deletion of an existing Safety Ledger entry that was created under a separate legal basis (fraud prevention exceptions under CCPA and TDPSA).

11.4. Re-Consent

If we update this Policy to a new version, you will be prompted to review and accept the updated Policy before continuing to use the Service.

12. Changes to This Policy

12.1. We may update this Safety Ledger Policy from time to time. When we make changes, we will:

(a) Update the "Last Updated" date at the top of this document;

(b) Increment the version number;

(d) Present a re-consent interstitial requiring your acceptance of the updated Policy before you may continue using the Service.

12.2. Changes to this Policy do not retroactively affect Safety Ledger entries created under a prior version.

13. Contact Information

If you have questions, concerns, or requests regarding this Safety Ledger Policy or your Safety Ledger data, please contact us:

Privacy and Legal Inquiries: legal@loyalheartsclub.com
User Support: support@loyalheartsclub.com
Mailing Address: Loyal Hearts Club, LLC, Austin, TX

Loyal Hearts Club — Relationships, built on honesty.