1. Who we are
ZTOR Services Incorporated publishes the iKnow Blockchain website and related educational software, including hosted plugins, MCP-style APIs, and educational materials. We have not published a street address on this site. Contact us at the role addresses listed in Section 10.
2. What this policy covers
| Layer | Covered here? | Notes |
|---|---|---|
| Website (iknowblockchain.com) | Yes | Marketing / educational site |
| Hosted services, plugins, and APIs | Yes | Access may be invitation, preview, or general; practices described by data category |
| OAuth sign-in / accounts | Available to anyone who signs in to selected hosted services | Self-service: no invitation needed. Sign-in runs through our own sign-in service (section 4.5), where you sign in with Google, or with a reviewer account we create, through Auth0. Legacy invitation credentials remain in use for some clients. |
| Third-party sites, AI hosts, public blockchains | Linked / distinguished only | Their terms govern their processing |
3. Website — information practices
3.1 Website forms, advertising and analytics
- The correction form at /corrections/ stores the reports you send, as described in section 3.4. Other website forms and email links open your email application (
mailto:); the website does not store what you send through them. - The website code does not include advertising trackers.
- The website code does not include site-owned analytics. Infrastructure providers may still process request metadata as described below.
3.2 Browser storage
Your light/dark appearance choice may be saved in your browser’s local storage under a key such as ikb-mode. You can clear it via your browser’s site-data settings. We do not treat this as an account profile.
3.3 Fonts and hosting (website stack)
- The website uses fonts already installed on your device; it does not load web fonts from Google Fonts or another font service.
- The website is hosted through Cloudflare Pages. Hosting providers process request information to deliver and secure the site; their privacy policies apply.
- Website hosting (Cloudflare Pages) is separate from hosted-plugin / API infrastructure (Cloudflare Workers / D1) and from our sign-in service (Cloudflare Workers, Workers KV and Durable Objects). Each layer has its own information practices.
- Infrastructure providers may process standard request metadata (for example IP address, user-agent, timestamps) as described in their policies. We do not promise “no logging” at the platform layer.
3.4 Contacting us by email or the correction form
Email links and request forms open your email application. If you send the email, your address, message, and attachments reach our Microsoft 365 mailbox and are used to respond and handle the issue. Please avoid sending sensitive information that is not needed.
We retain correspondence as needed to handle your request, then delete or de-identify it under an internal schedule. Absolute, immediate, or permanent deletion from every backup or archive cannot be guaranteed (for example, Microsoft 365 backups or legal holds may delay or limit erasure). We will review deletion requests for correspondence we control and any applicable record-keeping obligations.
Correction form. When you send a report from /corrections/, it is stored in a Cloudflare key-value store that belongs to the website: the chain or page it concerns, your description, an optional evidence link, an optional email address, the time it was received, a reference, and its review status with our notes. We do not store your IP address, user agent or a browser fingerprint with the report. Your email address is optional and used only to reply about that report; it is never published. Each report is deleted automatically 12 months after we receive it. If a report leads to a correction, the public corrections log keeps the date, the chain, the reference and our own summary of what changed and why; it never includes your description as written, your email address or other contact details. If we reply by email, that correspondence is handled as email correspondence above. To ask us to delete a report sooner, email [email protected] with its reference.
To slow repeated posting, the Cloudflare data centre that handles your request keeps a count of reports in its cache under a one-way hash of your network address and the date, for about 10 minutes after your last report. The count is not stored with your report.
3.5 Blockchain information on the website
The address lookup on this website is a fictional demonstration. It does not query a blockchain. Donations, if shown, are made through your own wallet; on-chain transactions are publicly visible. This website does not request wallet access or connect to a wallet.
(Real public-address or NFT lookups, if any, occur only via hosted services/plugins/APIs described below — not via the website demo.)
3.6 External links
Links to other publishers (news, docs, directories) take you to sites with their own privacy practices.
4. Hosted services, plugins, and APIs — information practices
Access modes: Hosted tools may be offered under invitation, private preview, or broader access. Status changes (for example from invitation to general availability) do not by themselves change the data categories below.
4.1 What the services do
Provide sourced educational answers, ecosystem news/project discovery, blockchain comparisons (as available), and read-only public-network lookups (addresses, coins, tokens/CATs, NFTs, or similar) using third-party blockchain data and metadata providers. Results can be stale, partial, or wrong. One address is not an entire wallet. We do not independently guarantee NFT authenticity.
4.2 What we intentionally do not do
- No custody, wallet signing, transaction submission, trading, seed-phrase or private-key collection.
- Application-level logging / observability for query text and lookup payloads is disabled where engineered. Observability disabled ≠ zero platform logs — Cloudflare and other infrastructure may still process request metadata.
- We do not claim automatic 24-hour deletion of rate-limit counters, Durable Object quota state, or similar operational state.
4.3 Data categories that may still be processed
| Category | Practice | Notes |
|---|---|---|
| Invitation / access credentials | Opaque bearer tokens (or similar) for invitees / preview users | Legacy invitation access is separate from OAuth sign-in. Storage is layer-specific: the host typically stores hashes of credentials (not raw bearer secrets in app logs); client tooling may keep a token in an OS credential helper; protect device and invite files. We do not claim that tokens “never persist” anywhere. |
| OAuth sign-in and access | Our sign-in service connects your AI app and issues its access (section 4.5). You sign in through Auth0 with the selected identity provider, currently Google, or with a reviewer account. Auth0 and Google process sign-in, profile and security information as described in section 4.5. | Our services keep a pseudonymous identifier derived from your sign-in, not your name or email address, and use it for access, limits and revocation. It is made with a secret key we hold, so it is pseudonymous, not anonymous; hashing does not guarantee anonymity. AI hosts store the tokens we issue them under their own practices. |
| Directory reviewer login | An email-and-password sign-in option, run by Auth0, for accounts we create for reviewers at AI app directories | There is no public sign-up: the option can appear on the sign-in page, but only accounts we create can use it. Auth0 stores each such account’s email address, a username, and a hashed password. Members of the public sign in through the identity provider above. |
| AI app details | Apps that identify themselves by a web address publish their own details (name, return addresses, public keys); our sign-in service fetches them from that address | These describe the app, not you, and the request carries no information about you. Cloudflare may cache a copy for up to 7 days. We keep a one-way hash of the address of each app that completed a sign-in or renewed a connection, for about 31 days after the last one. |
| Invitation lifetimes | Default about 1 day; may be issued for up to about 7 days; some older invites may run about 30 days | Lifetimes vary by invite — there is no universal “7-day for all” claim. Expiry ≠ full deletion of all related operational artifacts. |
| Rate limiting / abuse control | Hashed IP (or similar) and Durable Object (or similar) quota state | Hashed-IP rate windows are abuse-control intervals, not personal-data deletion deadlines. Not a promise of anonymity. Our sign-in pages also limit requests per network address (IPv6 addresses by /64) in one-minute windows, using Cloudflare’s rate-limiting feature keyed by a one-way hash of the address. The address is not written to our storage or kept with your account. |
| Content database (D1) | Educational content / backups on the Workers/D1 stack | Approximately 90-day educational content/backup retention: protected active/previous versions, ≥10 content snapshots, 3 newest verified SQL backups. Not personal-data / auth / support retention. Protected versions and retained verified backups can remain beyond 90 days. |
| Hosting / platform logs (Workers / D1) | Separate from the website Cloudflare Pages stack | Platform may retain request metadata per provider policy. Application-level logging settings do not eliminate provider-side processing. Our sign-in service has Workers logging turned off. It outputs only error information, such as error codes and, when an app’s published details cannot be fetched, the web address of those details. It never outputs names, email addresses, network addresses or tokens, and with logging off we do not keep this output. |
| Third-party blockchain data / NFT index or metadata providers | Server-side lookups | Public addresses, puzzle hashes, token ids, and/or NFT ids may be sent to providers to fulfill a request. Identifiers are not necessarily anonymous. The providers the lookup tools use are named, chain by chain, on the Data sources page. |
| AI host | User’s chosen AI product | Prompts and tool results are processed under the AI host’s terms. We do not assume our service receives the full chat, and we do not control host retention or training. |
4.4 Age and children’s privacy
The Service is intended for people aged 13 and up and is not directed at children under 13. If you are under the age of majority where you live, use it only with a parent’s or legal guardian’s permission (see section 1 of the Terms of Use); where local law sets a higher age for using a service like this one, that age applies to you. We do not operate age verification and do not claim verified age. We do not knowingly collect personal information from children under 13, and we do not direct marketing to children. If you believe a child under 13 has provided personal information to us (for example by email or by signing in), contact [email protected]. COPPA may apply if the service is directed to children under 13 or we have actual knowledge we are collecting personal information from a child under 13. Signing in needs a Google account or a reviewer account we create, and Google sets its own minimum age for its accounts. If we learn that a child under 13 has signed in, we will end that account’s connections, delete the records our services hold for it, and delete its Auth0 profile.
4.5 Our sign-in service
When an AI app connects to iKnow Blockchain, it sends you to our sign-in service at auth.iknowblockchain.com. The service runs on Cloudflare Workers. First it shows the name of the app that is asking, whether that name is verified, and where access will be sent. An app that uses our shared app ID is shown only as an app using that ID, marked unverified. Then it passes you to Auth0 to sign in with Google, or with a reviewer account. After you sign in, it gives the app read-only access (ikb:read).
What our sign-in service keeps.
| Record | What it contains | How long |
|---|---|---|
| Pseudonymous identifier | Made from Auth0’s address and your Auth0 account identifier with a keyed one-way function (HMAC-SHA256) and a secret key we hold. We do not store your Auth0 account identifier, email address, name or network address. | Stored only as part of the records below |
| Connections | For each AI app you connect: the app’s identifier, the address access is sent to, the access granted (ikb:read), when you connected, and one-way hashes of its refresh tokens | Removed automatically after 30 days without use and at most 90 days after you signed in. Removed earlier if the app ends the connection or we revoke it. Signing in again from the same app usually replaces its earlier connection. When it does not, for example when an app on your computer signs in on a new port, the earlier connection is removed by the rules above. Apps that use our shared app ID keep separate connections, except apps that use the same return address (for example Gemini CLI, Qwen Code and Kiro, or Cline, Kilo Code and OpenCode), where signing in from one ends the other’s connection within 15 minutes |
| Access tokens | Signed tokens given to the AI app. They contain the pseudonymous identifier and the identifiers of the app and the connection. We keep a record of each one, under a one-way hash, while it is valid | 15 minutes |
| Sign-in in progress | The app’s request (app identifier, return address, requested access and security values) and the values that tie Auth0’s answer to it, stored encrypted | Up to 10 minutes; deleted when used |
| Daily counts | Sign-ins per person and refreshes per connection, each keyed by a one-way hash; shared totals; and limits on apps not seen before, keyed by one-way hashes of their addresses | Reset at 00:00 UTC; the previous day’s counts are deleted the next time the service uses its counts |
| Block record | Only if we block an account for abuse or security: a marker under the pseudonymous identifier | Until the block is lifted or erased; no automatic expiry |
Cookies during sign-in. While you sign in, our sign-in service sets two cookies on auth.iknowblockchain.com, named __Host-oauth-consent-… and __Host-oauth-upstream-…. Each holds a one-way hash that ties the sign-in to your browser, so another browser cannot finish it. They are secure and HTTP-only. Each lasts at most 10 minutes and is cleared when its step finishes. They are strictly necessary for signing in. We set no advertising, analytics or “remember me” cookies. Auth0 and Google set their own cookies on their own sites while you sign in, under their own policies.
What Auth0 keeps. Auth0 (part of Okta) runs the sign-in step for us. Our sign-in service asks Auth0 only to confirm your account: it receives your Auth0 account identifier and the sign-in option you used, and stores neither. Auth0 keeps its own profile for each person who signs in:
- for a Google sign-in, your Google account identifier and the profile information Google shares: your email address and whether Google has verified it, your name and first name, a nickname, and the web address of your profile picture;
- for a reviewer account, the email address, a username, and a hashed password.
Auth0 also keeps records of sign-ins, including the time, and keeps with your profile the network (IP) address and browser of your latest sign-in, how many times you have signed in and when. On our current Auth0 plan, the sign-in records are kept for about one day; the profile fields are kept until the profile is deleted. Our Auth0 account is hosted in the United States. We delete your Auth0 profile on request (section 9).
What Google keeps. Google verifies your Google sign-in under Google’s privacy policy. Our Google sign-in is registered to iKnow Blockchain, so Google records that your Google account signed in to iKnow Blockchain, and you can see and remove that link in your Google Account (under third-party connections). Removing it does not end your connections or delete records Auth0 or we hold.
What the AI app keeps. The app keeps the tokens we issue it, and your conversation, under its own terms (section 4.3, “AI host”).
What our hosted services keep. Our hosted services check each access token. They keep usage counts, request records that last 60 seconds, and any revocation state under a one-way hash of the token’s issuer and pseudonymous identifier (section 9). We keep daily totals of tool calls, counted by tool, blockchain and whether the call succeeded, for up to 120 days; they contain no account identifier, address, search text or IP address.
5. How we use information
We use information to:
- Operate, secure, and improve the website and hosted services;
- Respond to email, correction reports, and partnership/support requests;
- Enforce access limits and prevent abuse;
- Comply with law and protect rights and safety.
We do not use hosted plugins/APIs to custody assets or execute trades.
6. Sharing
We share information with:
- Infrastructure and processors needed to run the site and services (for example Cloudflare, Microsoft 365);
- Authentication providers: Auth0, which runs the sign-in step, and the selected identity provider (currently Google), to support OAuth sign-in and security. Our sign-in service sends Auth0 a sign-in request and receives your Auth0 account identifier and the sign-in option you used back. Auth0 and Google receive what you enter, and your browser’s information, directly from your browser;
- The AI app you connect: our sign-in service gives it a signed access token containing your pseudonymous identifier (section 4.5). When an app identifies itself by a web address, we fetch the app’s published details from that address; nothing about you is sent in that request;
- Third-party blockchain data / NFT index or metadata providers when you (or your AI host on your behalf) request a hosted lookup (listed on the Data sources page);
- Authorities when required by law or to protect rights/safety;
- Successors in a merger or asset transfer, with notice where required.
Where information is processed. We are based in Kansas, in the United States. Our providers, including Cloudflare, Auth0, Google and Microsoft, process information in the United States and in other countries where they operate. If you use the Service from outside the United States, your information is processed in those places.
7. Retention
| Category | Retention posture |
|---|---|
| Website localStorage theme | Until you clear browser data |
| Correction reports (website form) | Deleted automatically 12 months after we receive them. Entries in the public corrections log remain published; they contain no reporter description as written, email address or other contact details. The hashed count used to slow repeated posting lasts about 10 minutes after the last report. |
| Email correspondence (M365) | Retained as needed to handle the request, then deleted or de-identified under an internal schedule. Absolute erasure from every backup or legal hold is not promised. |
| Invitation credentials / hashed rate-limit state | For invite validity and abuse control. Invite TTLs vary (≈1 day default; up to ≈7 days; some older ≈30 days). Expiry is not a promise that every related artifact is deleted immediately. Hashed-IP windows are not deletion SLAs. |
| D1 educational content & SQL content backups | Approximately 90-day educational content/backup policy (active/previous protected versions; ≥10 snapshots; 3 newest verified SQL backups). Not a personal-data deletion SLA. |
| Rate-limit / Durable Object operational state | Retained for abuse control; inactive quota state can remain until updated. There is no automatic 24-hour deletion guarantee. |
| Sign-in service: connections and hashed refresh tokens | Removed automatically after 30 days without use, and at most 90 days after sign-in; earlier if the app ends the connection or we revoke it |
| Sign-in service: access tokens | 15 minutes |
| Sign-in service: sign-ins in progress and sign-in cookies | Up to 10 minutes |
| Sign-in service: daily counts | Reset at 00:00 UTC; the previous day’s counts are deleted the next time the service uses its counts |
| Sign-in service: block records | Until lifted or erased |
| Hosted services: usage counts tied to your sign-in | Cleared at 00:00 UTC; request records 60 seconds; revocation state while it applies |
| Hosted services: daily totals of tool calls, by tool, blockchain and whether the call succeeded | Up to 120 days. They contain no account identifier, address, search text or IP address |
| Auth0 profiles and logs; Google records | Under each provider’s own retention. We delete your Auth0 profile on request (section 9); provider retention and applicable holds can limit erasure |
| Provider-side logs | Governed by each provider’s policies — outside our sole control |
| AI-host records | Outside our control |
| Public blockchain data | Public and not erasable by us |
8. Security
We aim for reasonable administrative and technical measures appropriate to a small educational service (including disabling app-level query logging where engineered, hashing invitation secrets on the host, and using client credential helpers). Our sign-in service stores refresh tokens and authorization codes only as one-way hashes, requires every app to use PKCE, and signs the access tokens it issues. Before you sign in, it shows you the app’s name, whether that name is verified, and where access goes, and it fetches app details only over HTTPS from the app’s own site, without following redirects. No method of transmission or storage is 100% secure. Report suspected vulnerabilities to [email protected].
9. Your choices and requests
Email [email protected] about your information, access revocation, or deletion of account data or correspondence we control. Deleting your iKnow Blockchain sign-in profile at Auth0 does not delete your Google account or records controlled solely by your AI host or authentication provider. We will review the request and applicable record-keeping needs. Absolute, immediate deletion from every backup or archive cannot be guaranteed.
Records tied to your sign-in. When you connect an AI app, our sign-in service and hosted services keep records under a pseudonymous identifier derived from your sign-in, not under your name or email address. These are your connections and hashed tokens, daily counts for limits, and access and revocation state (sections 4.5 and 7). Daily counts are reset at 00:00 UTC.
To have these records deleted, email [email protected] or [email protected] from the address you sign in with. We will end all your connections, delete the records our services hold for you, and delete your iKnow Blockchain sign-in profile at Auth0. An access token your app already holds can keep working for up to 15 minutes, and usage counts made in that time clear at the next 00:00 UTC. A later sign-in creates a new profile; deletion is not a ban. Hashed network-address counters used against abuse are not stored with your sign-in, so a request cannot locate them.
Disconnecting. To stop your AI app from using the service, remove the iKnow Blockchain connector in that app: in Claude, open Customize > Connectors and choose Remove; in ChatGPT, open Settings > Apps & Connectors, select iKnow Blockchain and disconnect or delete it. Menu names change between app versions; Connect your AI has the current steps. Removing the connector stops your app’s requests. If the app tells our sign-in service when you remove it, that connection ends at once. Otherwise it lapses after 30 days without use, and every connection ends at most 90 days after you signed in. Disconnecting does not delete your Auth0 profile or records our hosted services already hold. Ask us as above if you want them deleted.
We cannot erase: public chain data; copies held solely by your AI host; or provider logs we do not control.
Your applicable privacy rights are not limited by this policy. Contact us with requests concerning information we control.
10. Contacts
| Role | Address |
|---|---|
| Privacy | [email protected] |
| Security | [email protected] |
| Legal | [email protected] |
| Support / feedback | [email protected] / [email protected] |
| Partnerships | [email protected] |
| General | [email protected] |
No response-time service-level agreement is offered.
11. Changes
If we materially change practices, we will update this policy and set a new effective date when the revised policy is published. For material expansions of use (for example, starting to sell data or enabling public accounts), we will provide clearer notice — and where required, consent — rather than silent retroactive switches.