Skip to main content

How Templ keeps chats safe

  • Templ never asks for a private key or seed phrase.
  • Chats can't send transactions or move money.
  • Only the person who asked, your team and the you add can read a chat.

Wallet sign-in​

Wallet connection supplies an address. (SIWE) proves control of it by checking a signed message. Templ checks the domain, URI, chain, one-time nonce and expiry. A signature for another site cannot be reused as a Templ sign-in.

Signing in sends no transaction and grants no token approval. The widget calls four wallet methods: eth_requestAccounts, eth_accounts, eth_chainId and personal_sign. Wallet sign-in happens in the authentication flow; a support message cannot create a wallet-signing request.

Accounts and sessions​

Accounts need no real name, phone number or identity document. One account can hold up to five Ethereum wallets and five Solana wallets, and any of them signs in. Each extra wallet needs its own proof. Templ refuses a wallet that already belongs to another account and never merges two opaque accounts. An email address saved for alerts cannot sign in.

Browser sessions use HttpOnly cookies and expire no later than 30 days after signing. Removing a wallet signs out the sessions it opened. The last wallet cannot be removed.

The embedded widget currently accepts externally owned EVM accounts. Contract-wallet signatures fail closed. Its session stays in memory and expires within an hour; it cannot reuse the app's cookie session. Switching wallets clears the widget's authorization. The widget guide covers the supported sign-in flow and local draft storage.

A can let people ask before signing in. Those guest sessions have the same site and workspace limits. A wallet address the protocol's app reports for a guest is shown to staff as unverified and proves nothing. Staff can ask the user to verify; only the user can start that sign-in. When a guest signs in, their thread moves to the proved wallet. If the wallet already has a thread there, both stay and staff see them linked. Accounts are never merged.

Private support​

A thread is readable by its user, the workspace manager, and the staff and AI agents the manager has given support access. Assignment grants no permission. Removing support access ends access to history, notes, screenshots, search, exports and new events on an open connection.

are excluded from user responses, notifications and exports. Screenshots are stored privately, and each view checks current thread access. Private support files have no public media URL.

Users can stop team messages. That prevents staff writes, initiation and reopening, including the manager and API clients. Only the user can ask again and lift the stop.

Private means access-controlled, not end-to-end encrypted. Templ and its service providers process stored support data. If a team uses an AI agent, the chats it reads may go to the company that runs its AI model. Templ's own support chat uses Anthropic's Claude. Saved screenshots and exports can be shared outside Templ.

Trust lists each service provider and whether it's on, how long each kind of data stays, what the activity log records and how to ask about your data. The Privacy Policy covers retention and lawful disclosure.

Protocol identity​

A workspace name, staff badge or paid plan is not an authenticity check. Reach support through your protocol's official site. Staff badges show granted permissions, not a guarantee that advice is safe.

Share only the network, transaction hash and issue details needed for the request. Review context before sending it. A transaction hash does not prove that the sender owns the transaction's wallet, and proving a wallet does not grant permission to move its assets.

Feature availability and app status show the current release state. Safety explains legal intake and appeals.