For District Partners

Overview

Classroom Token Hub (CTH) is a teacher-developed classroom management application with a simulated economy. Teachers configure classroom activities, attendance, payroll, checking and savings, rent, insurance, and store purchases.

This page explains account setup, classroom access, and data handling for schools and districts. See the Privacy & Data Handling policy for more details.

1. Data Collection, Processing, and Storage

Teacher setup

• A username and authenticator setup; optional registered passkeys.
• A two-part teacher display name, class name, optional section label, and class time zone.
• Class settings, classroom content, and any submitted support reports.

Student setup

• The teacher supplies first and last name fields as they should be entered during claiming. These may be full or partial names; the last field is not restricted to one initial.

  privacy_tipChoose classroom names with privacy in mind

  While these fields are labeled as first name and last name, teachers can use agreed classroom names or nicknames. Students enter the values the teacher supplied. A roster built entirely from classroom nicknames leaves no real-name identifier in the platform.
• The roster supports optional encrypted teacher notes. Keep unnecessary personal or sensitive information out of notes and other free-text fields.
• The student enters the class join code, matching name fields, and, if another unclaimed roster entry shares the name, the distinguishing code the system generated for their entry and the teacher shares, then creates a username, PIN, and passphrase.

Stored records

Display names and roster notes use application-level Fernet encryption. Username and roster-name matching use keyed HMAC-SHA256 digests. PINs and passphrases use salted scrypt hashes. These protections apply to specific fields; they do not mean every database field is encrypted.

The application also stores classroom activity, support content, and technical diagnostic records. Names directly identify people. Activity stored under an opaque student reference is pseudonymous: the application can link it to a student, but an amount or timestamp is not itself a name. These linked records are not anonymous.

2. Class Boundaries and Shared Accounts

Classroom economy records belong to a particular class and student participation record. Teachers work in the selected class they own, and students access the classes they have joined.

A single sign-in account can participate in multiple classes. A signed-in student can add another class after matching that class’s roster. This shares account credentials across those memberships; it does not combine their balances, attendance, purchases, or classroom economy history. Matching names alone do not merge accounts.

System administrators handle support reports and operational information. Teachers can also share a hall-pass verification link with school staff, as described below.

3. Student Account Claiming

Claim-matching hashes and distinguishing codes are cleared after a successful claim. Display names remain encrypted for classroom use. Importing a roster creates new entries; matching an already-claimed student’s name does not merge or update their entry. When unclaimed entries share a name, the system assigns each a distinct distinguishing code, including an existing unclaimed entry that did not have one.

1. The teacher provisions a roster entry and shares the class join code.
2. The student enters the join code and first and last name fields matching that entry.
3. If several entries match, the student enters their entry’s system-generated distinguishing code, which the teacher shares from the roster.
4. The student creates a username, a 4–6 digit PIN, and a passphrase to finish setup.

4. Information Not Required for Accounts

Teacher and student account forms do not require email addresses, phone numbers, home addresses, dates of birth, parent contact details, government identifiers, or district student ID numbers. CTH does not provide an academic gradebook or connect to a district student information system.

This does not mean the application cannot contain sensitive information. Attendance, hall-pass destinations, classroom bonuses and fines, insurance claims, roster notes, and support explanations can describe student activity. Free-text fields are not a suitable place for medical details, disciplinary case records, contact information, or other unnecessary personal data.

If someone emails support, their email provider and the support mailbox necessarily process the message and sender address; email is separate from account registration.

5. Data Lifecycle and Deletion

Delete a student: permanently removes that class participation record and its related application data. Other class memberships remain. Deleting the last student in a class also deletes the class; if it was the teacher’s last class, the teacher account is deleted too. The deletion dialog warns about these consequences.

Unclaim a student: disconnects the sign-in account while preserving the class participation record, balance, activity, and items for the next claimant. The teacher re-enters the names to use for claiming. Use this when the wrong account claimed a roster entry or a student needs to consolidate accounts. A detached student account is deleted if it has no other class memberships.

Delete a class or teacher account: deleting a class removes its related application records; deleting a teacher account deletes all of its classes. These actions have no archive or undelete option.

Inactive teacher accounts: accounts are automatically deleted after 180 days without a successful sign-in, or after 30 days from creation if they have never signed in. Their classes are deleted through the same account-deletion process. Class activity does not reset this sign-in clock.

Downloaded exports remain under the school’s control and are not removed by application deletion. Contact support about retention of infrastructure backups or logs.

6. Authentication and Security Controls

• Teachers: username plus a time-based one-time password (TOTP) from an authenticator, or an enrolled passkey. The application does not use teacher email/password login.
• Students: username and passphrase for sign-in. The PIN is used for attendance, transfers between checking and savings, and hall passes. Purchases, rent, insurance payments and cancellation, and other entitlement use require the passphrase.
• Stored credentials: PINs and passphrases use salted scrypt hashes. Authenticator secrets are encrypted. Passkey registration stores a public key and credential metadata.
• Recovery: a teacher can issue a student an eight-character code that expires after ten minutes. The recovery form asks for that code, then directs the student to create new credentials. Teacher recovery requires at least three students with claimed accounts in every class the teacher owns, and one valid student confirmation per class. CTH randomly selects two students in each class and keeps their identities hidden from the teacher; recipients stay fixed for the five-day attempt, and each code lasts 30 minutes. See the account recovery details.
• Sessions: signed, HTTP-only, SameSite=Lax cookies; the Secure flag is enabled in production configuration. Student sessions have a ten-minute limit from login; teacher sessions expire after ten minutes of inactivity.
• Request protection: the application includes CSRF protection and rate limits. Selected forms use Cloudflare Turnstile when configured.

7. Application Access and Support Review

Teachers can see classroom rosters and activity, manage student participation, and download class roster or student exports. Students see their own display name and classroom information made available to them.

Support staff can review submitted teacher reports and escalated student issues. Reports include technical diagnostics such as the page URL, route and request correlation information, IP address, and browser details. Teachers choose separately whether to include balances, the reported transaction, recent transactions, student report text, and the class label. These options are not selected by default. The submitted snapshot is fixed: support does not refresh it from live classroom records. Every ticket belongs to a class participation record, including a teacher’s own ticket, and deletion of that record removes the associated ticket. Free-text submissions contain what the author types; omit unnecessary personal details.

Shared hall-pass verification

A person with a teacher’s verification link can select one of that teacher’s classes and submit a student’s first and last name. Because the class and the name are both supplied by the person asking, a match confirms what they already hold rather than disclosing a student; it adds the pass itself — destination, status, and the current day’s departure or return time. The page returns no roster, no multi-day history, and no internal identifiers. The page does not require a teacher or student login. Share the link only with intended school staff.

8. Hosting, Service Providers, and Encryption Limits

The application needs access to its encryption key to display protected fields. A person or process with both the database and that key can decrypt those fields. Field encryption does not make data inaccessible to every infrastructure administrator.

The public site is published through GitHub Pages and loads fonts from Google Fonts and styling from jsDelivr. The application integrates Cloudflare Turnstile when configured and supports operational monitoring. These services receive technical request information; Turnstile verification can include the visitor’s IP address.

See technical data and service providers for information about these requests. Contact support with questions about hosting and data handling.

9. Single Sign-On and District Integration

The current application cannot integrate with district SSO through SAML or OpenID Connect, district roster synchronization, or external student-ID matching. Classroom Token Hub respects district governance and policies so long it does not conflict with internal invariants. Requests for feature changes in exchange for district adoption are categorically refused shall they contradict internal documentation. Districts may fork and self-host a modified version of the application, but that deployment is not reviewed or supported by the original developer. The source repository is available under the PolyForm Noncommercial 1.0.0 license. Review its conditions before self-hosting or modifying the application. A modified deployment needs its own review and privacy disclosures.

10. School Adoption and Accessibility

Schools and districts should review the intended educational use, authority to provide student information, required notices or consent, access, retention, and service providers before adoption.

Review the U.S. Department of Education’s FERPA guidance for service providers and the FTC’s COPPA guidance. The FTC limits school-authorized consent to the educational context; it does not remove the operator’s applicable obligations.

For help with keyboard navigation, screen readers, contrast, or another access need, contact support@classroomtokenhub.com.

11. Simulated Financial and Activity Records

While using the dollars ($), the currency within Classroom Token Hub has no real monetary value. The application does not connect to banks or real payment processing.

It records classroom payroll, bonuses and fines, transfers, rent and other obligations, insurance, store purchases, and entitlement use. Balances are derived from ledger records; pending transactions can affect the amount available to spend. Corrections use recorded reversal or void workflows.

These records use class and student participation identifiers, and are resolved back to a named student only in the provisioning teacher’s own class views. Amounts, timestamps, and ordinary activity fields are not all encrypted with the display-name encryption facility. Class-level economic summaries are available to teachers.

12. Use of Information

• CTH does not display advertisements or sell user data.
• Public pages request fonts and styling from the providers listed above.
• Classroom summaries, operational monitoring, and support diagnostics are part of the application.
• The application does not provide district SSO, a gradebook, or real banking services.

Contact Information

Current users of Classroom Token Hub should utilize the in-app ticket system for help and support. If the in-app ticket system is unavailable to you or if you are not currently a user, please contact support@classroomtokenhub.com.

Due to the design constraint of Classroom Token Hub, we are unable to respond to district queries regarding a specific teacher or student. Classroom Token Hub does not ask or store school or district information during sign up. District personnel are advised to reach out to the teacher who is using Classroom Token Hub.

For security questions, inquire about our privacy practices, or incident reports, contact security@classroomtokenhub.com. For security vulnerabilities, please privately report them to GitHub Security Advisories.

Students and families should reach out to the classroom teacher or school. Classroom Token Hub has very limited visibility and authority over student issues.