1. Executive summary

Chatalystar is a verified-creator adult companion platform. From launch we treated trust & safety as a product surface rather than a compliance afterthought. This white paper documents scoped creator upload controls: available identity and session binding, moderation and response controls, and a transparent operations posture that publishes quarterly data when a report is available. Historical and delegated upload paths differ. These controls do not prove every depicted person's age or consent, or that every surface has identical coverage. The AB 1705 development controls described at /trust#ab-1705 await counsel approval and verified production rollout.

Our thesis is that the median operator in this category does almost nothing, the leader was forced into compliance by a near-death event, and the regulatory environment is converging on the EU DSA / UK OSA model. A platform built compliance-first is durable; one retrofitted under enforcement pressure is not. This document is meant to be readable by regulators, journalists, payment processors, banking partners, and creators evaluating where to host.

2. Problem framing

Three risks define modern adult-content hosting: child sexual abuse material (CSAM), non-consensual intimate imagery (NCII), and identity fraud (uploaders posing as someone else). The first two are criminal harms with mandatory reporting obligations; the third is the upstream risk that enables both. A platform that cannot prove who uploaded what cannot meaningfully respond to either.

Checking identity once at signup does not settle later attribution: stolen sessions and compromised accounts remain risks. Available session and upload bindings support investigation, but fresh creator wallet attestations are not universal across historical, grandfathered, and delegated paths. A Crew Mode declaration must identify the actual declaring person, not automatically the creator account owner.

3. Phase 1 — Identity binding chain

3.1 Veriff verification

Every Star completes third-party government-ID verification with biometric liveness through Veriff before publishing. Members are 18+; Stars are 21+. The verification record is retained per /privacy and made available under valid legal process.

3.2 Wallet binding

Where present, the Star's EIP-712 wallet attestation binds wallet address, Veriff session hash, and accepted Creator Agreement version and content hash. Historical accepted versions remain authoritative; a current template is not evidence that every creator accepted it. Available signatures support attribution, not independent proof of every depicted person's age or consent.

3.3 Vault PIN

An additional out-of-band second factor, separate from wallet keys, is required to enter the upload vault. This protects against device theft and key compromise scenarios where a wallet is unlocked but the human is not present.

3.4 Per-session attestation

The signed-session path binds wallet → identity → agreement → session ID → timestamp. Grandfathered paths can lack a fresh per-unlock creator signature, and delegated actors have distinct attribution. Session authorization expiry is not evidence expiry: retained declarations have a separate seven-calendar-year minimum from submission in the AB 1705 development design.

3.5 Per-upload binding

Governed creator-upload records link assets to available session, hash, and chain-of-custody evidence; some historical fields can be absent. The separate AB 1705 development design uses explicit typed-name assent for an identified per-file slot, reusable server-verified email, and server-bound immutable storage versions or verified derivatives. This is not a generic future-content batch promise or proof of every depicted person's age or consent. Supported admissions and publication require the new evidence only after approved cutover; ambiguous ingress is paused then. Declaration enforcement defaults off pending approval, and production coverage is unverified.

AB 1705 (Chapter 890, approved September 30, 2026; ordinary effective date January 1, 2027) requires before-upload certifications under penalty of perjury of each depicted person's adulthood at creation, consent to depiction, and consent to this website upload, plus contact information and verified email. The development archive preserves exact accepted text, version, signature, submission time, contact/email evidence and content linkage independently of ordinary account deletion or session revocation. Founder-only retrieval is access-checked and audited. The statutory retention minimum is seven years after submission; longer-availability, legal-hold and other obligation guards need approved criteria. This does not require retaining all media or personal data forever. Historical inventory statuses are evidence findings, not legal verdicts; a current review or statement cannot prove receipt before a past upload. Sources and related claims reviewed October 7, 2026, not counsel-reviewed. See /trust#ab-1705 for official sources, /privacy#upload-evidence-retention for the staged notice, /2257 for related records, and /trust/report for removal concerns. Exact execution, applicability, historical treatment, retention, backups, deployed schema and rollout require further approval or verification. These statements complement ordinary care, moderation, reporting and removal; they provide no immunity.

3.6 HMAC chain of custody

Each upload row is HMAC-linked to the previous row. Tamper with any earlier row — selectively delete an embarrassing upload, alter a timestamp, swap the asset reference — and the chain breaks. An external auditor can verify the chain end-to-end without trusting the platform.

4. Phase 2 — Responsive infrastructure

4.1 Public reporting routes

Public reporting starts with the in-content report control when one is available because it preserves the exact content URL and surrounding context. When direct reporting is unavailable, the structured report form at /trust/report captures the URL, screenshots, reporter relationship, and reason for the appropriate triage lane. The Trust contact surface can also start an inquiry. Public contact routes for policy, legal process, copyright, and records requests have documented SLAs and submission guidance.

4.2 Triage queue & SLA

Reports route to a moderation queue with severity-based prioritization. Severity-1 reports (suspected CSAM, NCII, imminent harm) target acknowledgement within 4 hours and action within 24 hours. Other categories target acknowledgement within 24 hours.

4.3 NCMEC / IWF / Stop NCII integrations

Sightengine performs upload-time minor screening. Confirmed matches are reported to NCMEC under 18 USC § 2258A. The Stop NCII hash list is checked at upload to block re-circulation of consensually-removed intimate imagery. The IWF hash list is integrated for known-CSAM blocking.

4.4 Quarterly transparency reports

The pipeline can expose anonymized aggregates, published quarterly snapshots, or a cached published snapshot. The public /trust page displays the returned provenance label; when no report has been published, it displays no metrics rather than a synthetic fallback. Counts may include reports received per category, action rates, response times, appeal outcomes, NCMEC reports filed, and hash-match counts where the underlying data supports them.

4.5 Law enforcement liaison

legal@chatalystar.com is monitored by trained personnel for valid legal process. Subpoenas, preservation requests, and emergency disclosure requests have documented response times. Preservation requests are honored before any contested deletion proceeds.

5. Threat model & abuse cases

5.1 Adversary profiles

Opportunistic uploader: tries to upload prohibited material, expects loose moderation. Defeated by Sightengine + minor screening + manual review.
Identity-fraud actor: poses as someone else or uses a stolen account. Vault PIN and available session evidence reduce some risks; grandfathered or delegated paths are not uniformly freshly wallet-signed.
Coercion actor: pressures a verified creator to upload non-consensual material of a third party. Upload attribution supports investigation; performer consent review, reporting and removal remain necessary. Provenance alone cannot establish consent.
Repeat-offender: attempts to re-upload removed material. Defeated by hash-list integrations (IWF, Stop NCII).
Plausible-deniability actor: claims another person used the account. Available signed-session evidence supports attribution on that path, not universal proof of the human uploader or depicted persons' consent.

5.2 Out-of-scope adversaries

Nation-state-level cryptographic attacks against EIP-712 signature validity, the wallet provider, or NIST-approved HMAC primitives are out of scope for this document. So is platform-internal insider attack against logging substrate; we mitigate with read-only metrics views, audit trails, and least-privilege access but do not claim cryptographic immunity from a fully-rooted operator.

6. Standards mapping

The /trust page hosts a scope-limited product mapping to relevant duties; it is not a claim that every operative legal requirement is implemented or deployed. AB 1705 development safeguards are separately labeled review / rollout pending. The current posture supports selected EU DSA notice-and-action and systemic-risk work, 18 USC § 2257 / § 2257A and § 2258A workflows, UK age-assurance work for relevant adult-content surfaces, and applicable U.S. age-verification controls. Jurisdiction, product surface, and legal applicability still require review.

7. Verification approach

Independent verification of these claims is supported by three mechanisms:

Where independently verifiable attestation records are available, they support existence and timing checks. Do not infer a fresh creator signature on every historical or delegated upload, or age/consent certification from a provenance record alone.
The HMAC chain-of-custody can be reconstructed from any creator's upload history; an auditor with read access to a creator's metadata rows can verify integrity end-to-end.
Quarterly transparency reports are reproducible from the responsive-infrastructure pipeline; the methodology is documented in Annex D and category definitions are stable across reports.

Outside-counsel legal review of public claims on /trust is recommended before each major content update; we treat that as operational rather than architectural and budget for it separately.

8. Roadmap

A future phase may evaluate hardware-rooted provenance standards. The deployed generated-image path currently uses a visible Chatalystar synthetic-media label and a Chatalystar XMP provenance extension; we do not call that metadata C2PA or claim certification. Creator/member uploads follow their existing upload path and are not automatically relabeled as synthetic.

Other tracks under active design but not yet shipped include cross-platform takedown coordination through industry working groups, formal Tech Coalition membership, and localized white-paper translations.

Annex A — Cryptographic primitives

Wallet signatures: EIP-712 typed-data v4 (secp256k1).
Per-row HMAC: HMAC-SHA-256 with rotated platform key; key rotation at 90-day intervals; previous keys retained for verification.
Asset hashing: SHA-256 over the canonical bytes of the uploaded asset.
On-chain anchoring: per-session attestation merkle-root anchored on a public EVM-compatible chain at session close.

Annex B — Hash-list integrations

IWF (Internet Watch Foundation) hash list — known CSAM. Hard-block at upload + NCMEC report on confirmed match.
NCMEC hash sharing — known CSAM. Hard-block at upload + automated CyberTipline submission.
Stop NCII — non-consensual intimate imagery hashes contributed by the public. Hard-block at upload + flagged-creator review.

Annex C — Article 34 risk register

EU DSA Article 34 requires VLOPs to conduct annual systemic-risk assessments. We voluntarily maintain an equivalent register. The current register identifies five systemic risks (CSAM, NCII, identity fraud, coordinated inauthentic behavior, deceptive AI persona use) and tracks each to specific deployed mitigations. The register is reviewed quarterly and re-published with the transparency report.

Annex D — Comparison methodology

Composite scores in the /trust comparison chart are derived from five factors weighted equally: identity binding (does the platform bind uploads to a real person?), per-upload accountability (can the platform attribute an individual asset to an uploader?), response SLA (median time from report to action), NCMEC integration (is reporting automated and mandatory?), and transparency (does the platform publish quantitative moderation data?). Each factor scores 0-20; the composite is the sum.

Scores for non-Chatalystar platforms are derived from those platforms' own published policies and from observable behavior at content-upload, takedown, and reporting moments. Where a platform's posture has changed materially (e.g. Pornhub's December 2020 reset), the post-change posture is scored and labeled.