How the SCYNEXUS applications handle personal data.
This policy explains the current MVP data-handling behavior of the Public Portal and Auth Service, the choices available to users, and the production details that still require approval.
The Public Portal—including this Privacy Policy page—does not collect or store personal data, accept form submissions, set its own cookies or browser-storage values, or run analytics. This is an implementation-aligned MVP notice, not a final production policy for services reached after the public handoff.
1. Public Portal: no data storage
The Public Portal, including this page, only serves localized public information. It does not require an account; collect or store names, email addresses, credentials, form entries, or other personal data; set its own cookies or browser-storage values; or run analytics and advertising trackers.
Selecting an authentication action leaves the Public Portal and opens the separate Auth Service. The remaining sections explain that service boundary so users know what changes after the handoff; they do not mean the Public Portal stores that data.
2. Data handled in the current MVP
Depending on the authentication method, the Auth Service may handle an email address, email-verification state, display name, account and user-chain identifiers, progression intent, provider name, a cryptographic commitment derived from the provider subject, credential-link metadata, session identifiers and token hashes, login-code records, timestamps, registry and MFA state, and security-event details.
The local chain folder path and selected main-chain action are handled in browser storage according to the Cookie Policy. A chain path may also be associated with an authenticated account when the dedicated chain-storage endpoint is used. The Public Portal does not currently collect form submissions, analytics identifiers, advertising profiles, or credentials.
3. Why data is handled
Current purposes are to create or match an account, verify access, issue and validate sessions, link configured identity providers, associate an accountable user chain, remember user-requested browser choices, detect and investigate security activity, operate requested application functions, and preserve the technical audit state needed for those functions.
SCYNEXUS does not currently use the covered applications to sell personal data, deliver behavioral advertising, or build advertising profiles. Final production lawful bases must be documented for each purpose and jurisdiction before launch.
4. Sources and sharing
Data may come directly from the user, from the user's browser and device during application use, or from a configured identity provider after the user requests that sign-in method. The Auth Service stores only a cryptographic commitment of the provider's stable subject in its current local data record rather than the raw provider subject.
Data may be processed by configured identity providers and the hosting, storage, security, or infrastructure providers required to operate the applications. A named production processor list and contractual safeguards have not yet been approved. SCYNEXUS may also disclose data when legally required or necessary to protect users, the service, or legal rights, subject to applicable law.
5. Storage, retention, and deletion
The current local Auth Service uses application data storage for accounts, credential links, sessions, email codes, and security events. Browser cookies and local or session storage follow the durations and controls described in the Cookie Policy. Users are responsible for protecting folders and artifacts stored on their own devices.
Short-lived authentication state and login records expire according to their implemented controls, but the MVP does not yet define an approved production retention and deletion schedule for account and security records. Production deployment must define periods by data category, deletion or anonymization rules, backup handling, legal preservation exceptions, and account-closure behavior.
6. Security and verifiable records
Current safeguards include hashed session tokens, cryptographic provider-subject commitments, short-lived authentication state, scoped cookies, authenticated endpoints, and security-event records. No internet service or local device can be guaranteed completely secure, and users remain responsible for their devices, credentials, recovery methods, and local chain storage.
SCYNEXUS is designed to keep raw personal data off public or broadly visible records where possible and to use commitments or evidence references instead. A hash or commitment may still relate to a person in context and must not be treated as automatically anonymous.
7. User choices and data-protection rights
Users can control optional browser persistence, clear browser storage and cookies, choose among available authentication methods, and revoke active sessions where the application provides that control. Depending on applicable law, individuals may also have rights to information, confirmation of processing, access, correction, deletion or anonymization, restriction or objection, portability, information about sharing, withdrawal of consent, and review of qualifying automated decisions.
Rights are not absolute and may depend on identity verification, jurisdiction, legal preservation duties, security needs, and whether SCYNEXUS acts as controller or processor for the relevant data. A production rights-request channel and response procedure must be published before launch.
8. International use and children
Identity, hosting, or infrastructure providers may process data in more than one country. Production regions, transfer destinations, safeguards, and user notices have not yet been finalized. Do not use the MVP for regulated or sensitive personal data unless an approved workflow and agreement explicitly permits it.
The current applications are not directed to children. Production eligibility rules, age thresholds, and any parental-authorization process must be determined for each launch jurisdiction before child data is knowingly processed.
9. Changes and contact
This policy must be reviewed whenever application data flows, providers, purposes, legal roles, or user controls change. Material production changes should be communicated through an appropriate notice and, where required, renewed consent.
The formal privacy contact, controller identity, registered address, and data-protection officer or representative details are pending approval. Until those details are published, this page should not be presented as a complete production privacy notice.
Last reviewed against the current repository implementation: July 29, 2026. The structure follows transparency topics reflected in official ANPD privacy-notice guidance; legal approval remains required.