Privacy

1. Who operates Templ

templ.fun Ltd operates Templ. This policy explains how Templ uses personal data.

templ.fun Ltd is a BVI Limited Company. Its company number is 2191511. It registered on 28 October 2025.

Its registered and mailing address is Quijano Chambers, P.O. Box 3159, Road Town, British Virgin Islands.

This policy covers Templ's app, support widget, API, docs and blog. Customer websites and wallets have their own notices.

“Customer” means the organization that runs a workspace. “User” means a person who asks that Customer for support. “Team” means the Customer's manager, staff and authorized AI agents. Personal data means information that identifies someone or can reasonably link to them.

Features can be enabled separately for each workspace. A description here does not activate a feature. Check your workspace's settings and Feature availability.

2. Who controls your data

Your Customer controls its support data. Templ processes that data for the Customer.

The Customer is the controller of user support data. Templ is its processor. We store, deliver and process that data under documented instructions. The Data Processing Addendum sets those duties.

This includes authorized AI answers, drafts and agreed done-for-you support. Templ staff answer for the Customer under its instructions. Its manager must explicitly grant each person's staff access. Buying a service grants no inbox access.

Templ controls its own account administration, billing, business measurement and direct support data. It also controls necessary platform security and verified legal-intake records. This role does not authorize other uses of private Customer cases.

When lawfully enabled, Templ controls the separate improvement purpose described in section 7. That role starts with its separate de-identification step. Accepting the DPA alone supplies no lawful basis for that purpose.

If the Customer acts for another controller, Templ acts as its subprocessor. The Customer must have authority to give instructions.

3. What data we receive

We receive what you share and the records needed to run support.

An account does not normally require your real name, phone number or identity document. A wallet address can still be personal data. We may need limited identity proof for a legal or privacy request.

Share only what the case needs. Never share private keys, recovery phrases, passwords or access codes. Free text and screenshots may contain sensitive data. Share sensitive data only where needed and lawfully permitted.

Public blockchain data comes from networks and RPC providers. Sharing a wallet or transaction may link that public data to your case.

4. Why we use data

Each use needs a lawful basis. Optional permissions cover only their stated purpose.

The Customer chooses lawful grounds for its support data. It must provide the notices and choices its users' laws require.

Where the EU GDPR or UK GDPR applies to Templ as controller, these bases apply:

We must assess necessity and the effect on your rights before relying on legitimate interests. You can object to those uses.

The BVI Data Protection Act, 2021 has been in force since 9 July 2021. Its consent rules and exceptions apply separately. A GDPR legitimate-interest basis does not replace BVI requirements.

You can withdraw consent through the relevant control or a privacy request. Withdrawal does not undo earlier lawful processing. Missing required data may prevent us from providing the relevant feature.

Improvement copying needs its own lawful grounds, notices and transfer safeguards. We must keep it off where those requirements are unmet. California restrictions in section 17 also apply.

5. Who can read your case

Users see their own cases. Staff and agents need current permission to read private data.

A user can read their own case history. The manager and authorized staff can read retained cases their permissions cover. Newly authorized staff can read retained messages. Billing access, token ownership, names and ordinary case assignments grant no case access.

Specialists have access only through a qualifying follow-up or recent team mention. Their access covers that case alone. It ends when the condition or role ends. Specialists cannot reply to users, resolve, assign, export or search cases.

Every private read, write, search result, export, attachment and event checks current access. Internal notes, AI drafts and team case facts stay with the team. Member exports exclude internal notes and other team-only records.

Templ staff need the Customer manager's explicit staff grant to enter its inbox. This includes done-for-you support. Narrow infrastructure, security or legal processing follows the DPA or applicable law. It grants no ordinary support role.

Recipients can copy data they may read. Removing access cannot erase copies they already made. Customers remain responsible for those copies and their own providers.

6. How AI uses cases

Enabled AI can read case content. A draft stays with the team until a person sends it.

The Customer can authorize its own agent or an agreed Templ-managed agent. Each case has an enforced mode: AI answers, AI drafts only or AI off. The team controls that mode. Agents cannot change it themselves.

An authorized agent may receive permitted messages, knowledge and relevant shared transaction checks. It may also receive permitted team case facts. Customer-run agents may send this data to the Customer's model providers. The Customer must explain its own recipients and uses.

Templ-managed agents use Anthropic when that service is ordered and enabled. Anthropic receives permitted inputs and generated output. Inputs can include messages and approved knowledge. Secret filters can miss content.

Templ's own support workspace and Templ Demo use OpenAI when their AI agent is enabled. Free pilot workspaces use this setup when their managers turn on AI. OpenAI receives selected case messages, checked transaction facts and approved knowledge. Paid Customer workspaces do not use this OpenAI setup. Improvement copies never go to OpenAI.

AI answers may be wrong, incomplete or out of date. Check answers before relying on them. A person decides whether to send a draft. You can ask the team for a person in your own case. That request adds no charge.

Chat and AI cannot sign transactions or transfer funds. Legal and privacy requests need a person. Customers must not use support AI for unlawful automated decisions.

The Customer may save de-identified evaluation cases inside its workspace. A person checks each copy before saving it. These copies can still contain personal data. They stay up to 730 days after saving and may outlive the source case. A linked privacy request or workspace deletion removes them sooner. Legal holds never extend their retention.

Evaluation copies leave through authorized exports or agents the manager allows. Templ does not read them for its own improvement purpose. Templ trains no model on these copies or Customer support data.

Provider retention depends on the applicable agreement and settings. We do not promise zero provider retention. Managed model processing needs terms that prohibit training on Customer data. Customer-run model providers follow the Customer's separate arrangements.

7. How improvement copies work

An eligible finished case may produce a de-identified copy. That copy remains personal data.

Templ does not make improvement copies yet. Feature availability shows public features.

Improvement copying has a separate release gate. Workspace feature flags do not enable it. The widget must show the notice before the opening message is sent. The notice links here, and its version stays with the case.

A case becomes eligible after resolution and its reopen window. Cases without a message for 30 days may also become eligible. Tests, spam and cases under legal hold are excluded.

The workspace cleans text before sending it to the separate improvement store. The rules replace wallet addresses, transaction hashes and signatures, emails, ENS and SNS names, handles, phone numbers and IP addresses. They replace external links, exact dates, times, block numbers, long identifiers and the names they find. Amounts are rounded.

Writers receive stable pseudonyms within their workspace, such as member-3f9a2c1b, staff-7d10e4aa and ai-agent. The copy holds no direct mapping back to those writers. It may hold cleaned messages, week, networks, sign-in level, resolution, handoff, labels and time ranges.

The copy excludes internal notes, screenshots, other files, account identifiers, wallets, website data and IP data. Cases with detected keys or recovery phrases keep no text. Messages with detected leftover identifiers are dropped.

The rules can miss an unusual name. Public blockchain facts can sometimes identify someone. De-identified copies can still identify people. Templ treats every copy as personal data.

Copies help Templ improve AI answers, rules and setup. They also help check resolution rules and review disputed charges. Copies never create or change a charge. Templ never uses them to profile or contact users. Templ never sells them or tries to identify people from them.

Copies go to no model provider. Templ trains and fine-tunes no model on them. Customer-authorized AI processing in section 6 is a separate use.

At most 3 named Templ readers may read copies. Each needs a wallet sign-in less than 15 minutes old and a stated purpose. Every read is logged. The workspace sees a monthly read count. Reader access cannot open raw private cases.

Copies stay at most 730 days after creation. Ordinary source-case deletion does not shorten that separate period. A legal hold never keeps a copy.

You can object for free at any time. Ask the team in your chat or Ask about data. A manager or support lead records the request. It removes every improvement copy of your cases in that workspace. This includes copies whose source cases are gone. It also stops new copies of your cases there. Workspace deletion removes all its copies.

No product setting excludes a workspace. Only a signed custom contract does. That rule does not remove legal rights or required consent choices. Want a contract without this? Talk to us.

We do not assume these copies meet California's statutory definition of deidentified data. A controller label cannot bypass service-provider restrictions. Copying must remain off where its use would breach those restrictions.

8. Which providers receive data

Providers receive data needed for their task. Optional providers receive data only when their feature runs.

The subprocessor register sets the permitted purposes. Provider contracts, locations and transfer safeguards must cover the affected processing.

Enabled contract checks can query Sourcify, Blockscout or Etherscan. Those services receive public contract addresses and chain identifiers.

Customers can connect agents, alerts and signed webhooks. Their settings and access checks limit what reaches those destinations. Channel alerts contain fixed events, counts or waiting time and an authenticated link. They exclude message text, notes, tags, names, emails, wallets, transactions and amounts. A signed webhook may include wallets and shared transactions only when the manager turns that on.

We may disclose necessary records to professional advisers under confidentiality duties. Verified authorities receive data only on a lawful basis. A business transfer must preserve privacy duties and applicable user choices.

9. What stays on your device

Cookies and browser storage keep sessions and drafts. Clearing them may remove your route back to a guest case.

The app uses a secure, HttpOnly session cookie. App sessions last at most 30 days. The server stores a digest of the random session credential.

A guest widget saves a random support credential and case identifier on the Customer website. Its server record lasts 90 days. The browser copy stays until cleared or replaced, but stops working after 90 days.

A widget wallet session lasts at most 1 hour. Its token stays in that tab's session storage until the tab closes. Enabled remembered sign-in can renew sessions for up to 30 days after the wallet proof. Origin, workspace, expiry and revocation checks still apply. The widget uses no third-party sign-in cookie.

A wallet the app reports remains unverified. A guest shares that claim only by choosing it before sending. A separate wallet proof binds a case to a wallet.

The app saves unsent replies, internal-note drafts, retries and inbox preferences on your device. They remain separate by account, workspace and case. Current access is checked before restoring case drafts. Sign-out, an account change or revoked access clears those saved drafts. The app keeps at most 50 entries. Entries older than 7 days are discarded when storage is checked.

The widget can save drafts and unfinished sends on the Customer website. The Customer can disable draft storage. Closing the widget or signing out can leave drafts saved. A confirmed send, Discard or clearing the text box removes them. Drafts older than 7 days are discarded when restored. Other scripts on that website can read its local storage.

Each IP address can open 3 guest cases a day in a workspace. Templ counts them with a keyed one-way hash. Its key stays secret on Templ's servers. A hash counts for 24 hours. The workspace's next guest case removes older hashes.

A user can choose Talk to a person in their chat. Templ saves the time, reason code, user and case. The team's activity list shows the user's account and the time. The case keeps the time and reason code. Only the team sees its AI mode. The AI agent's latest check-in stays in server memory. A restart clears it. The widget uses it to show “AI agent is typing”.

The widget does not offer reply emails yet. Users check replies by opening their case.

Reply-check timing can stay in browser storage for 1 day, without message text. A stored “still need help” choice stays until cleared. Sent case history stays in page memory. Lines after a send and AI presence stay in memory rather than saved records.

10. How we count service use

First-party counts use fixed events. Optional Google measurement must pass its privacy checks before collection starts.

Server counts use daily totals and fixed step or failure codes. They carry no accounts, wallets, workspaces, message text, emails, addresses or URLs. These daily counts stay for 400 days. Their Cloudflare log lines stay up to 7 days.

The widget loads no browser analytics code on the Customer website. That website may run its own analytics under its own notice.

Optional Google measurement uses an isolated frame and a random tab identifier. It receives only approved fixed events. Google still receives browser and network metadata. Consent must come first where law requires it.

Our measurement controls check Do Not Track and Global Privacy Control. We use no advertising signals or personalized advertising. Templ does not sell personal data or share it for cross-context behavioral advertising.

11. How payments use data

Stablecoin transfers are public. We keep billing records but cannot erase blockchain history.

Payments use the stablecoins and networks shown in the app. Supported tokens include USDC and USDT where official on configured EVM networks and Solana. Payments are direct stablecoin transfers. Each method stays closed until its release checks and verification pass. The app lists the enabled network, recipient and payer.

We record payer wallets, tokens, amounts, transaction references, workspace and verification status. Verified matching transfers credit the balance once. A redirect or wallet signature never credits it. Custom deals use payment requests tied to signed order forms. The same scanners verify their transfers.

Blockchain addresses, amounts and transaction history are generally public. A case may link them to you. Deleting a Templ record cannot erase the underlying chain record.

Templ does not control your wallet or request its private key. Chat cannot sign or send transactions. Wallet sign-in uses a separate authentication message. Templ provides support software and agreed services. It gives no financial, investment or tax advice.

12. How long data stays

Different records have different time limits. Ending service does not automatically erase every record.

Refused-request counts hold no names, wallets, IP addresses or websites. Managers, billing staff and support leads can see them. Later relevant activity removes expired counts and retry identifiers.

Archiving hides a case from the default inbox. It changes neither billing nor retention. Resolving a case does not immediately delete it. Deleted content cannot be recovered through an export.

Some cleanup runs on later activity or in batches. A record may remain beyond its nominal age until cleanup runs. These cycles do not remove lawful storage limits or deletion duties. Provider logs and backups have separate technical cycles. We must restrict retained copies and honor valid deletion instructions after restoration.

The Customer can choose return or deletion of processor data under the DPA. Enabled workspace deletion closes access first. The manager has 7 days to cancel before batched deletion starts. A valid hold can preserve covered data. Where deletion is unavailable in the app, Ask about data.

13. How legal holds work

A report alone grants no access. We check authority and limit any disclosure or hold.

Safety explains legal notices, urgent reports and appeals. Legal records may include names, organizations, emails, jurisdiction, legal grounds and evidence references. Signed-in reports may include an account identifier. A reported message copy contains only content the reporter could access.

Authorized Templ operators review the central queue. Workspace managers cannot read it. We independently verify official contacts, authority, legal instruments and scope. An intake receipt proves only receipt.

We preserve or disclose relevant data only on a valid legal basis. We limit its scope and notify the Customer where permitted and required. We do not automatically forward every report or all case history.

A documented hold can pause deletion of its covered case or workspace. It preserves only data that remains. It cannot recreate deleted data. Normal retention resumes when the hold ends. If holds cannot be checked, case deletion pauses until they can.

A hold does not extend the 90-day message-evidence clock. It never keeps improvement or evaluation copies beyond their rules. Active enforcement cases have a 30-day operator review date. That date promises no final closure or deletion.

14. How access stays private

We check identity and current access. Private support is not end-to-end encrypted.

We use scoped sessions, origin and workspace checks, rate limits and private file permissions. Authorized service operations and approved providers can process content. No system can promise perfect security.

Wallet sign-in binds domain, URI, chain, nonce and expiry. Widget proofs also bind the intended workspace. Replay and revocation checks apply. A connected or app-reported address alone proves no ownership.

User sessions never grant staff authority. An email verifies an alert destination. It never signs in, merges accounts or grants inbox access.

Staff and agent replies are screened for signing, approval and transaction requests. Recognized private keys and recovery phrases are refused before storage. Ambiguous values can still appear in the user's case and staff inbox. They are hidden from models, bots, webhooks, exports and copies unless shared as a typed transaction. Filters do not make sharing secrets safe.

We investigate personal-data breaches and notify affected Customers under the DPA. We notify regulators and people where law requires it. We claim no security certification or breach-free service.

15. Where data is processed

Providers and authorized operations may process data in several countries. Restricted transfers need lawful safeguards first.

Templ is a BVI company. Approved providers may process data outside your country and the BVI. A signed order form must state any agreed residency commitment.

Restricted EEA transfers need an applicable lawful mechanism. This may be the EU Standard Contractual Clauses under Decision (EU) 2021/914. Restricted UK transfers may use the UK Addendum or International Data Transfer Agreement. Required terms, annexes and risk assessments must be completed before the affected transfer.

BVI transfer rules apply separately. Accepting the Terms is not blanket transfer consent. A provider policy alone does not establish lawful safeguards.

Ask about data to request relevant safeguards and applicable terms. We protect confidential information while providing what the law requires.

16. How to ask about data

Ask your Customer about its support data. Ask Templ about data it controls.

For a case, start with the Customer team in your chat. We help that team respond under the DPA. You can also Ask about data. We route processor requests to the Customer unless law requires another response.

For Templ-controlled data, you may ask for access, correction or deletion. Applicable law may also give portability, restriction, objection and consent-withdrawal rights. Improvement objections are free and need no special reason.

We may ask for limited proof to protect other people's data. We never ask for private keys, recovery phrases, payment or transaction signatures. We do not require a new account for a privacy request.

We answer within applicable legal deadlines. GDPR and UK GDPR requests generally require a response within 1 month. BVI access requests generally require a decision within 30 days, subject to lawful extensions. We explain lawful extensions, refusals or exceptions.

Required legal or billing records may have deletion exceptions. We explain those limits. We cannot erase blockchain history or copies others independently hold.

You may complain to your relevant data protection authority without contacting us first. UK users can contact the Information Commissioner's Office. EEA users can contact their local supervisory authority. BVI rights follow its applicable regulator and complaint procedures.

The privacy request email is privacy@usetempl.com. Our registered address in section 1 also accepts written requests.

17. California privacy rights

California rights apply where the CCPA covers the processing. Templ's service-provider duties can apply below business thresholds.

The CCPA, as amended by the CPRA, can give access, correction, deletion and information rights. You may use an authorized agent, subject to reasonable checks. We do not discriminate against people who exercise those rights.

We do not sell personal information or share it for cross-context behavioral advertising. We do not use sensitive information to infer personal characteristics. Private messages may still contain sensitive personal information.

Collected categories include identifiers, customer records, commercial information, internet activity and information users share in cases. Case content may include other statutory categories, including sensitive personal information. Section 3 lists sources and purposes. Section 8 lists recipients. Section 12 lists retention periods and criteria.

Customer support information follows the DPA's service-provider or contractor restrictions. Those terms prohibit unauthorized combining, sale, sharing and uses outside the direct Customer relationship. Improvement copying cannot override them.

Use Ask about data or the privacy request email in section 16. Covered access, correction and deletion requests generally receive acknowledgment within 10 business days. A substantive response is generally due within 45 calendar days. We explain any lawful extension.

We honor applicable opt-out preference signals for covered sale or sharing. Where relevant activity occurs, applicable law also gives sale, sharing and sensitive-use choices.

18. Children and policy changes

Customers must meet their users' privacy rules. We give notice of material changes to our own practices.

Templ provides business support software. Customers must meet applicable age, notice and parental-consent rules. We do not seek children's data for advertising or profiling. Ask about data if a child may have shared data unlawfully. We work with the Customer to investigate and take lawful action.

We publish changes here and update the date. We notify Customers of material changes through the service or an available verified contact. New purposes need required notices and lawful grounds before they start. Continued use alone does not provide separately required privacy consent.