Skip to main content

Salt Coordination Layer

The Salt Coordination Layer is the off-chain coordination and policy layer used by Salt accounts.

It authenticates users, manages organisation-level access, evaluates policies, and coordinates real-time workflows between the participants in an account quorum.

It does not hold signing authority and cannot sign transactions.

Responsibilities​

The coordination layer is responsible for the application and workflow logic around Salt accounts.

It handles:

  • authentication
  • organisation and collaborator management
  • access-level checks
  • policy configuration and evaluation
  • transaction proposal routing
  • API access for the Salt SDK and Salt App
  • WebSocket coordination for account creation and signing workflows
  • communication with Robo Guardians

The coordination layer is not the cryptographic signing layer. Signing operations are performed by quorum participants from their own environments.

Authentication​

Salt authentication uses signed messages based on the Sign in with Ethereum (SIWE) standard.

When a user signs in, the application requests a wallet signature from the browser wallet or EOA used for authentication. This signed message proves control of the EOA without requiring Salt to custody a credential or private key.

After authentication, the browser receives a JWT that is attached to API requests from the domain in use. For users of the Salt App, that domain is at salt.space. For embedded applications using the Salt SDK, the domain may be the fintech or third-party application’s own domain.

Salt App as a privileged domain​

The Salt App is Salt’s privileged application domain.

A user can create a Salt organisation directly through the Salt App, or be onboarded into one through a third-party application using the Salt SDK.

In both cases, the organisation remains a Salt organisation. Depending on the user’s access level, the Salt App can provide a direct interface for viewing the organisation, its accounts, and its policies.

Third-party SDK applications are scoped differently. If a user creates a Salt organisation through one fintech application, that organisation is not automatically visible inside another fintech application.

This lets fintechs embed Salt without giving other third-party applications access to their users’ Salt organisations, while still preserving a direct Salt interface via Salt app.

Access levels​

After authentication, the coordination layer checks the user’s access level inside the organisation.

Access levels determine what a user can see or do in the application layer. They are separate from signing authority.

For example, an organisation owner can add collaborators, create accounts, and edit policies. Other access levels have more limited permissions.

For a full breakdown, see Access levels.

Policy evaluation​

The coordination layer evaluates policies before coordinating signing workflows.

Policies may restrict proposed actions based on rules such as destination address, asset, transaction size, contract function, timing window, or required participant role.

If a proposed transaction does not satisfy the relevant policy, the coordination layer does not coordinate Robo Guardian participation.

For a deeper explanation, see policies.

Communication model​

Salt uses APIs and persistent WebSocket connections.

APIs are used for standard application actions, such as authentication, organisation management, policy management, and transaction proposal creation.

WebSockets are used for real-time coordination during workflows that require multiple participants, such as account creation or transaction signing.

At a high level:

  • the Salt SDK communicates with the coordination layer through APIs and WebSockets
  • the Salt App uses the same coordination layer through the SDK and application interface
  • Robo Guardians maintain outbound WebSocket connections to the coordination layer
  • the coordination layer routes workflow messages between the required participants

This allows Salt to coordinate multi-participant workflows without performing the cryptographic signing operations itself.