1. Who is responsible
Hashcade is an independent experimental project in beta testing. This notice describes the personal data handled by this deployment. The person who decides why and how that data is used is responsible for it (the “data controller” under data-protection law). Beta status does not remove privacy rights or the need to identify that person and provide contact details.
- Person responsible for this beta
- Not yet supplied.
- Contact address
- Not yet supplied.
- Privacy contact
- Not yet supplied.
- Relevant supervisory authority
- Not yet supplied.
2. Information the service handles
| Information | Purpose and source |
|---|---|
| Account and profile | Your unique sign-in username (also your initial public player name), any later public-name changes, optional contact email, appearance preferences, optional profile photo and internal account identifiers, supplied by you or created by the service. |
| Registration choices | The Terms version, document fingerprint and acceptance time, plus your separate initial analytics choice and notice version. A copy of the presented Terms, Privacy notice and analytics wording is kept to evidence these choices; the initial analytics choice does not override a later withdrawal or browser privacy preference. |
| Authentication | Salted password hashes, hashed recovery credentials, hashed device tokens, session and security timestamps. The service stores password verification data rather than a readable password. A valid recovery credential grants account access. |
| Gameplay | Game inputs and validation records, saved game states, point changes, activity history, rankings, era results and online participation, generated while you play. |
| Mining | Linked worker identifiers, pool events, accepted and rejected shares, assigned share difficulty, share evidence, best difficulty and activity times, received from the configured mining integration. |
| Rewards | Allocations, claims, saved receiving address and network, destination scripts, block and transaction identifiers and reconciliation records. These are needed to verify and administer rewards. |
| Technical information | Network addresses used for connection handling and rate limiting, request and error information available to the server, and browser storage described below. Additional access logging depends on the deployment’s proxy and hosting configuration. |
Email and profile photos are optional. Email is not currently verified or used for email account recovery. The normal photo-upload flow crops and re-encodes a small profile image in the browser; the saved image is used for your account presentation. Do not provide sensitive information in public names, photos or worker identifiers. Hashcade never needs your wallet’s private key or seed phrase.
3. Purposes and legal bases
The proposed basis for account access, saving games and administering requested eligible rewards is providing the service and taking steps at your request. Security, abuse prevention, reconciliation, service diagnostics and proportionate public competition features may rely on legitimate interests where applicable law permits and a documented balancing assessment supports that use. Records may also be necessary to meet a specific legal obligation; any such obligation must be identified rather than assuming one applies everywhere.
Optional profile content is used for the feature you request. Each optional use needs an appropriate legal basis and separate valid consent where required; registration is not blanket consent for marketing or unrelated tracking. The core application contains no advertising or third-party analytics integration. The completed notice must also cover any additional integrations used.
4. What other players can see
Player names, game points, ranks and participation indicators are visible in the arcade. The worker list displays other users’ live workers with masked aliases, estimated hashrate and best-share difficulty. Your own offline workers are also visible to you. Masking is pseudonymization, not a promise that a worker can never be linked to someone. Public competition data can be copied by viewers.
Your sign-in credentials, recovery code, optional email, private reward ledger and saved receiving address are not exposed through the public worker list or leaderboard. The current profile photo is used in your account interface, not added to public standings. Authorized maintainers can access stored information when needed to run, secure or support the service.
5. Providers, disclosures and Bitcoin
This deployment may use hosting and infrastructure providers, mining pool and node integrations, and transaction processing infrastructure to provide the service. Access should be limited to the relevant purpose and governed by appropriate contractual or legal safeguards. Information may be disclosed where required by law, to respond to a lawful request, or to establish or defend a legal claim, subject to applicable safeguards.
- Actual providers and their roles
- Not yet supplied.
- Processing countries / locations
- Not yet supplied.
- International transfer arrangements, where needed
- Not yet supplied.
A Bitcoin payment publishes transaction information on the relevant network. Addresses, amounts and transaction relationships may be viewed and analyzed by others and linked to an identity using other information. The current server uses Bitcoin mainnet. Blockchain records are replicated independently; Hashcade cannot erase them from the network. This does not remove your rights regarding personal data held off-chain by this project.
6. Cookies and browser storage
The essential hc_device authentication cookie identifies your signed-in device and has a maximum age of 30 days. It is HttpOnly and SameSite=Strict; the application marks it Secure when the configured public origin uses HTTPS. Sign-out revokes the current device credential. Session storage holds an account reference; local storage holds presentation preferences and, where applicable, local game history, pending demo requests or data from older preview accounts.
These built-in storage mechanisms support sign-in and requested functionality, not advertising. Clearing browser storage may sign you out or remove local preferences; it does not erase server-side records. Keep your recovery code separately. Your optional usage-analytics choice and dismissal of the analytics reminder are stored in local storage. You can change your analytics choice in Settings.
Optional usage analytics
From version 0.82, Hashcade offers optional first-party website analytics. Collection starts only after you check the optional analytics box when registering, choose Allow analytics, or enable it in Settings; you can decline and continue playing. The browser sends named page visits, a fixed list of interface actions (for example opening a game or using Fullscreen), and foreground practice play time. It sends no form contents, passwords, recovery codes, receiving addresses, full URLs, screen recordings or gameplay key presses. The analytics tables do not store IP addresses. No third-party analytics service receives these events.
A random visit identifier lives in memory until reload, an account change or approximately one day. When you are signed in, the server links optional events to your account so authorized admins can review your usage. Guests remain unlinked to an account; no cross-device identity is created. Browser Global Privacy Control or Do Not Track preferences disable optional collection. Turn analytics off in Settings to stop future collection and discard queued events; past records follow the retention schedule below. Clearing browser storage resets your choice.
Separately, verified game progress supplies server-side run counts, active play time, last scores and run states for service administration. These exclude pauses, bots and offline time and do not depend on optional click tracking. Usage analytics never award points, establish payment eligibility or override the sealed reward allocation. Admin access is protected by a separate expiring session; player and public APIs do not expose these dashboards.
Daily usage summaries are retained for 400 days. Completed run details, visits and website events are retained for up to 90 days, with a further cap of one million website events and one million visits, so busy deployments may have less detailed history. Cleanup runs approximately hourly while the server is active and on the next collection after downtime. Counters attached to still-saved games stay with those games to prevent double-counting on resume. These limits do not delete financial ledgers, saved games or backups. Administrative analytics must be included in the stated purposes, balancing assessment and access/deletion procedures.
7. Retention and deletion
The current software keeps account records, saved progress, point and accepted-work ledgers, era settlements and payment evidence in the server database. The historical ledgers do not currently have automatic time-based deletion. Worker hashrate uses a rolling five-minute calculation, but this is not a five-minute deletion policy for underlying mining records. Best-share statistics can persist across eras. The private account audit stream is capped at the latest 10,000 entries; this is not a cap on every ledger or log.
Device credentials expire after 30 days. Expiry prevents their use but should not be read as a promise that all historic security records are immediately erased. Backup, infrastructure log and account-retention periods need a defined schedule, together with deletion or anonymization procedures and any necessary exceptions for disputes or legal duties.
- Deployment retention schedule and request procedure
- Not yet supplied.
Personal data must be retained only as long as justified by its purpose and applicable law. This draft discloses the current implementation; it does not justify indefinite retention or claim that a complete deletion workflow already exists.
8. Security and automated processing
Controls include password hashing, hashed authentication credentials, scoped account access, input validation and verified game and mining records. Production security also depends on HTTPS, administrator access controls, secure infrastructure and protected backups. No system is immune to compromise. Contact the support or privacy contact promptly if you suspect unauthorized account access; never send your password, recovery code or private keys in a support request.
Software validates game scores and accepted mining work, applies resting decay, calculates rankings and allocations and checks claim eligibility. These operations can affect your access or reward amount. Funding discrepancies can trigger a hold. Request an explanation and human review through the contact above if you believe the underlying data or outcome is wrong. The person responsible for this beta must assess any additional safeguards required for automated decisions with legal or similarly significant effects.
9. Your choices and rights
You can update your player name, email, appearance and saved payout address through Profile and change your password or recovery code through Security. Existing confirmed claims retain their locked destination. Sign out on a shared device and keep your recovery backup safe.
Depending on the laws that apply, you may request access, correction, erasure, restriction, portability, or object to certain processing. Where processing relies on consent, you may withdraw that consent without affecting prior lawful processing. Rights can have lawful limits, including protecting other people, resolving claims or meeting a specific retention obligation. Account closure does not automatically delete all reward or blockchain records.
Send a request to the privacy contact above. Proportionate identity verification may be requested, but you should never be asked for your wallet keys or password. Where the GDPR applies, responses are normally due within one month; permitted extensions require explanation and notice. You can complain to the competent data protection authority, including where applicable the authority in your habitual residence, workplace or the place of the alleged infringement.
10. Children and changes
The beta is intended for adults aged 18 or older, subject to stricter local requirements. Registration currently does not verify age. If a child has supplied personal data contrary to the applicable eligibility rules, the person responsible should assess and take appropriate protective action. Do not treat this paragraph as an implemented age-verification system.
Material changes should be published with a new effective date and additional notice where appropriate. Changes to a privacy notice do not by themselves create a new lawful basis for collecting or repurposing data. The final notice must reflect the deployed service, its real providers and its actual retention practices.
This draft describes the beta. The responsible person, contact details and deployment facts still need confirmation and review before publication. New accounts must actively accept the version shown at registration. Acceptance does not replace the remaining publication review.