Skip to main content

Key shards and signing

Salt accounts use threshold signing.

A Salt account does not rely on a single private key. Instead, signing authority is distributed across the signing participants that make up the account quorum. Each signing participant has one key shard, and a transaction can only be signed when the account threshold is met.

Salt is not a signer and cannot sign transactions.

For currently supported EVM networks, Salt uses DKLS23 threshold ECDSA over the secp256k1 curve. The resulting signature is a standard ECDSA signature that can be submitted to an EVM chain as if it came from a normal EOA.

Bitcoin and Solana support are planned as Salt expands beyond EVM accounts.

The core model​

A Salt account is created through distributed key generation.

Distributed key generation, or DKG, is a collaborative cryptographic process that lets multiple signing participants create shared signing authority without ever creating the complete private key in one place.

At the end of account creation:

  • each signing participant has one key shard
  • no participant has the complete private key
  • Salt has no key shard
  • the account has a threshold that determines how many key shards are required to sign

For example, an account may have five signing participants and a threshold of three. In that configuration, five key shards are created, and three eligible signing participants are required to produce a valid transaction signature.

The signing participants are proposers and Robo Guardians. The split between proposer key shards and Robo Guardian key shards is set by Salt account configuration. The infrastructure that holds and uses those shards is controlled by the user or organisation, not by Salt.

For more detail on account configuration, see Accounts.

Signing technology​

Salt's threshold signing uses Silence Labs' Silent Shard, a production DKLS23 MPC library built and audited by cryptography specialists.

Silent Shard is embedded in the Salt signer SDK used by signing participants.

For EVM accounts, the signing protocol produces standard chain-compatible ECDSA signatures over secp256k1. This means a Salt account can behave like a normal EOA on supported EVM chains, while signing authority remains distributed across quorum participants.

Key shards never need to meet in one place. Signatures are formed jointly by the required signing participants.

Account creation​

Account creation is the process that creates the distributed signing authority for a Salt account.

It begins when an organisation owner initiates a new account and selects the signing participants that will make up the account quorum.

Before the account creation ceremony can begin, the selected signing participants must be online. In this context, online means:

  • the participant is authenticated with Salt
  • the participant has an active WebSocket session with the Salt Coordination Layer

These WebSocket connections allow the Salt Coordination Layer to route protocol messages between participants during the ceremony.

End-to-end account creation process​

+-----------------------------+
| Account creator             |
+--------------+--------------+
               |
               v
+-----------------------------+
| Select signing participants |
+--------------+--------------+
               |
               v
+-----------------------------+
| Signing participants online |
+--------------+--------------+
               |
               v
+-----------------------------+
| Huddle created              |
| Coordination Layer routes   |
| protocol messages           |
+--------------+--------------+
               |
               v
+-----------------------------+
| Distributed key generation  |
| SDK runs locally in each    |
| signer environment          |
+--------------+--------------+
               |
               v
+-----------------------------+
| Key shards generated        |
| One per signing participant |
+--------------+--------------+
               |
               v
+-----------------------------+
| Signing paths validated     |
| Off-chain test signatures   |
+--------------+--------------+
               |
               v
+-----------------------------+
| Key shards backed up        |
| Encrypted backup data stored|
+--------------+--------------+
               |
               v
+-----------------------------+
| Account ready for signing   |
+-----------------------------+

Huddles​

Salt uses a huddle to coordinate multi-participant cryptographic workflows.

During account creation, the huddle represents the distributed key generation session. It invites the selected signing participants, coordinates communication between them, and routes the protocol messages required for the ceremony.

Salt coordinates the huddle, but it does not generate, receive, or store private key material.

Distributed key generation​

Each signing participant runs the Salt SDK in its own environment, whether directly, via the Salt app, or a fintech application.

The SDK uses Silence Labs' Silent Shard library to perform the distributed key generation protocol. The protocol consists of multiple rounds of message exchange between participants.

During the ceremony:

  • each participant performs cryptographic operations locally
  • protocol messages are exchanged through the huddle
  • no complete private key is assembled
  • each participant independently generates and keeps its own key shard

At the end of the protocol, every signing participant holds one key shard. Together, the key shards represent the account's distributed signing authority.

Validation and backup​

After key shards are generated, Salt validates that the account can be used correctly.

The account creator initiates the signing of an off-chain message. The signing participants then collaboratively produce threshold signatures for the account's required operational signing paths.

This validation checks that the key shards were generated correctly and that the expected signing paths work before the account is used in production.

After successful validation, each key shard is prepared for backup by being encrypted for the corresponding signer and stored in an Arbitrum smart contract.

This means each signer can recover their own key shard, while Salt cannot use the backup data to sign transactions.

Signing a transaction​

After account creation, key shards are used to produce threshold signatures.

A signing flow starts with a transaction proposal created through the Salt App or an application using the Salt SDK. The proposal describes the action the Salt account is being asked to take, such as the target chain, destination address, value, contract address, function call, or calldata.

Before signing is coordinated, the Salt Coordination Layer evaluates the proposal against the account's active policies.

If the proposal satisfies policy, the coordination layer opens a signing session between the required signing participants.

Threshold signing​

During a signing session, participants exchange the protocol messages needed to produce a threshold signature.

Each participant uses its own key shard from its own environment. The full private key is not reconstructed during signing.

Once enough participants contribute to meet the account's threshold, the session produces a valid signature for the transaction.

Broadcast​

After the threshold signature is produced, the signed transaction can be assembled and broadcast by the transaction proposer to the target chain.

The chain receives a standard signed transaction. It does not know that the signature was produced through a Salt signing flow, which policies were checked, or which signing participants took part.

Security properties​

Salt's key shard and signing model has several important properties:

  • a complete private key is never created in one place
  • private key material is distributed across signing participants
  • each signing participant generates and keeps its own key shard
  • Salt coordinates account creation and signing workflows, but does not possess key shards
  • transactions can be signed without reconstructing the private key
  • backup data supports recovery without giving Salt signing authority