Authentication

Salt uses wallet-based authentication.

Users authenticate by signing a message with their externally owned account, or EOA. Salt uses that signature to prove control of the EOA, issue a session token, and determine what the user can access inside the tenant they authenticated against.

Authentication is tenant-aware. A user can use the same EOA across multiple applications built on Salt, but each authenticated session is scoped to the domain used to sign in.

There are also privileged Salt domains. A privileged Salt domain can provide users with a direct Salt interface for organisations they have created directly on Salt or via third-party applications using the Salt SDK.

The exact privileged Salt domains may vary by environment, including testnet and production.

At a glance

Salt's authentication and authorisation model is designed around several security properties:

• authentication uses Sign-In with Ethereum (SIWE)
• authentication is bound to the domain being used
• authenticated sessions are represented by JSON Web Tokens (JWTs)
• third-party application sessions are scoped to their own tenant
• the same EOA can participate in multiple tenants without exposing data across them
• privileged Salt domains provide continuity and recovery paths
• Robo Guardian configuration is only available to sessions authenticated against a privileged Salt domain
• sensitive operations can require an additional signed authorisation

Tenants

A tenant is an app domain using Salt infrastructure.

For example:

• a Salt-operated domain may act as a privileged Salt domain
• a fintech using the Salt SDK may operate from its own domain
• a testnet deployment may use a separate Salt-operated testnet domain

Tenants may share Salt infrastructure, but their users, organisations, accounts, and application data remain logically separated.

Most authenticated API responses are scoped by two things:

• the authenticated EOA
• the tenant encoded in the session token

This means the same EOA can authenticate to multiple apps without automatically exposing data from one app inside another.

SIWE authentication

Salt authenticates users using Sign-In with Ethereum (SIWE).

When a user signs in, the Salt Coordination Layer creates a SIWE challenge message for the relevant domain. The user signs that message using their EOA.

After the signature is verified, Salt issues a JWT representing the authenticated session.

The JWT is attached to authenticated API requests from the application domain in use.

Domain binding

SIWE includes domain binding.

When a browser wallet processes a SIWE request, it compares the website currently displayed in the browser with the domain declared inside the SIWE message.

If the domains do not match, the wallet may warn the user that the signature request could be part of a phishing attempt.

For example:

Browser URL	SIWE message domain	Result
Salt-operated domain	Matching Salt domain	Authentication proceeds normally
Third-party application domain	Matching third-party domain	Authentication proceeds normally
Unknown or malicious domain	Salt-operated domain	Wallet may display a domain mismatch warning

The Salt authentication endpoint only issues authentication challenges for registered tenant domains.

This combination of registered tenant domains and wallet-level domain validation helps protect users from signing authentication messages for the wrong application.

JWT sessions

After successful authentication, Salt issues a JWT.

The JWT includes information such as:

• the authenticated EOA
• the tenant domain
• session metadata

Every authenticated API endpoint requires a valid JWT.

When handling a request, Salt authorises access using both the authenticated EOA and the tenant encoded in the JWT.

This means API responses are scoped to the authenticated identity and the tenant session.

Tenant-scoped data access

Tenant-scoped access prevents data from one application being exposed inside another.

For example, if the same EOA authenticates to one fintech application and then another fintech application, each authenticated session receives a separate tenant-scoped JWT.

An organisation created through one fintech application is not automatically visible inside another fintech application.

This allows fintechs to build embedded Salt experiences without giving other third-party applications access to their users' Salt organisations.

Privileged Salt domains

Privileged Salt domains have a special role.

When a user authenticates against a privileged Salt domain, Salt can return organisations the authenticated EOA has access to across Salt tenants, rather than only organisations created directly through that domain.

This does not bypass authentication or ownership checks. A user can only access organisations associated with EOAs they control and permissions they have been granted.

Privileged Salt domains exist so users can retain a direct Salt interface for organisations and accounts created through third-party applications.

For example, if a fintech application built on Salt became unavailable, a user could authenticate through a privileged Salt domain using the same EOA and access the Salt organisations available to that EOA.

The exact privileged Salt domains are environment-specific and may differ between testnet and production.

Robo Guardian configuration access

Robo Guardian setup requires sensitive operational information. This may include downloadable software, API credentials, and configuration values needed to connect a Robo Guardian container to the Salt Coordination Layer.

Robo Guardian configuration endpoints are only available to sessions authenticated against a privileged Salt domain.

Requests from other tenant domains cannot retrieve this information.

This prevents third-party fintech web interfaces from exposing Robo Guardian deployment and management details inside their own application environment.

A bot or service that needs to retrieve Robo Guardian configuration must use a valid JWT from a privileged Salt domain.

Session management

Salt uses short-lived JWTs.

Current session behaviour is:

• JWT lifetime of approximately 15 minutes
• automatic refresh using a token refresh mechanism
• sessions remain active until explicitly revoked or terminated

Additional authorisation for sensitive actions

Some actions require an additional signed authorisation beyond the normal authenticated session.

This is used for sensitive operations, such as changes that affect how assets can move from an account.

Examples may include:

• increasing transaction limits
• modifying allowlists
• changing account policies
• changing organisation security settings

Authentication answers:

• Who is the user?
• Which tenant are they accessing?

Additional signed authorisation answers:

• Did this authenticated user approve this exact action at this moment?

How additional authorisation works

When a sensitive operation is requested, Salt creates a message describing the operation.

The user is prompted to sign that message using their EOA.

Once the signature is verified, Salt can confirm that the authenticated user explicitly approved that specific action.

Because the signed message contains the details of the requested operation, the authorisation cannot be reused for a different action.

Tenant-aware cryptographic services

Some Salt cryptographic services are also tenant-aware.

For example, Salt's VOPRF (verifiable oblivious pseudorandom function) service can produce tenant-specific entropy to be used in cryptographic workflows.

Requests from different tenants receive tenant-specific outputs, helping keep cryptographic operations isolated between tenant contexts.

Recovery and continuity

Privileged Salt domains provide the simplest continuity path if a third-party application becomes unavailable.

A user can authenticate through a privileged Salt domain using the same EOA and access the organisations available to that EOA.

Salt will also provide recovery tooling that can recover account information directly from on-chain data where applicable.

Recovery options may include:

• authenticating through a privileged Salt domain
• using recovery tooling independently

This gives users a direct Salt continuity path while preserving tenant isolation for third-party applications.

Multi-tenant authentication and data isolation map