Workspace email log in

In this blogpost we announced Workspace, and email login. Here we will explain how it works.

Your email lives on our server, and it is never seen by your browser's storage, by analytics, or by anyone outside your team. It is never written to a log. This post explains exactly where it sits, what protects it, and what could be exposed in the event of an attack.

Safe is a smart account. Most users sign in by signing a challenge with their wallet, and no email is involved that path. For everyone else, there are two doors: log in using email with a one-time code, or withGoogle. Both create the same question: where does the email live?

How your email is stored

You never type your email into our app to sign in. The browser hands off to our backend, which hands off to Auth0, a dedicated identity provider. The provider receives the address, sends the code or talks to Google, and verifies you. Our web app never posts, logs, or holds the email during sign-in.

The server stores the verified address. Our client-side user state contains five things: session expiry, last Workspace, a loading flag, a sync flag, and a sign-in-in-progress flag. No email field. There is no email or wallet address field. Only the expiry timestamp and Workspace ID survive a page reload.

When the app needs to display your email, it asks the server. The reply lives in an in-memory cache that is never written to disk. Refresh the page and it's gone. Sign out and every cached piece of user and Workspace data is actively evicted.

Your session lives in a cookie the page cannot read. The session between our server and the browser is secured by a JWT: set by the server, invisible to JavaScript, sent only over encrypted connections, and sent only to our backend.

What we do to protect it

The cookie travels on a need-to-know basis. Balances, transactions, and chain data are fetched without credentials. The session cookie rides along only on routes that require identity: auth, your user record, Workspaces, and notifications.

Sessions are short and fail closed. They last 24 hours. A local timer signs you out at expiry regardless of network conditions. Only an explicit server "no," or the clock, ends a session early. Sign-out also walks back through the identity provider and clears its session there, then confirms with our server that the cookie is dead.

Invites, the one place an email crosses our UI, are a controlled crossing. Workspace admins can invite teammates by email. The address is validated, normalized, sent to the server once, and the form state dies with the dialog. From the server's response onward, the member is an opaque numeric ID. Analytics, renewal, and removal all key off the number, never the address. The invite link itself grants nothing: the invitee must sign in with the invited inbox through the same delegated flow. Invites expire on their own.

Disclosure is scoped to your team. Workspace members can see each other's emails on the members page. That's deliberate: a treasury team should know who is in the room. The rule isn't "no human sees an email." It's "the server discloses it only to the team it belongs to," and your browser still never stores it.

Analytics never learn it. We collect no IP addresses, we turn that off at the source. Tracking is opt-in and off by default. Events go to EU servers. Identity is pseudonymous:wallet address or Workspace ID.

What happens in the worst case

• Attacker reads browser storage. They cannot read the email or your sessiontoken, just onchain data: a timestamp, a Workspace ID, consent flags.

• Malicious script on the page. A script running on our page can do anything your session can: read your account and Workspace data, including the members page of whichever Workspace is open. The browser still attaches your session cookie to its requests, regardless of whether the script can read the cookie's value. It still can't exfiltrate that cookie, and it can't harvest a stored list of emails, because none exists. It also can't move assets: execution requires a signature from your wallet, and a script on our page has no path to that. The exposure lasts for the life of the session, not indefinitely.

• Analytics database leaks. Pseudonymous events, no IPs, no emails.

• Intercepted invite email. The invite carries no authentication information or tokens. It's an invitation to authenticate, not a ticket in: whoever receives it still has to sign in through the same flow as everyone else.

The cost

Showing "signed in as you@example.com" costs a round-trip on every fresh load. No client feature can key off an email. One-email-one-method generates support tickets from people who just wanted to switch buttons. We take all three.

The cheapest data to protect is the data you don't have. The second cheapest is the data that never leaves the server. Ours never does, even the copies handed to us.

Safe Labs

15 June 2026

Copy link