# Key types overview

The vault holds two categories of key: **imported secrets** and **generated keys**. Both are stored as MPC shares across the key store nodes so the raw secret never exists in a single location.

## Imported secrets (HMAC)

HMAC keys authenticate API requests to exchanges that use a shared-secret signing scheme. You paste the secret into the browser during import; the browser shards it using Sodot's client-side library and sends each share directly to the corresponding key store node. The secret never passes through the Orchestrator.

Three HMAC variants are supported: HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512. The vault selects the correct variant based on the venue's configured signing scheme.

## Generated keys (Ed25519 and RSA)

For exchanges that authenticate with asymmetric signatures, the vault generates the key for you using a distributed key-generation ceremony. The secret material is created and held in shares across the key store nodes; it is never assembled in one place.

After generation you retrieve the public key from the vault, paste it into the exchange's key-registration screen, and record the API key identifier the exchange assigns. You then save that identifier back to the key record in the vault.

The vault supports Ed25519 keys (widely used by modern exchanges) and RSA 4096 keys (for exchanges that require a certificate-signing request).

## Key metadata

Every key record carries the following fields:

| Field | Description |
|---|---|
| Key name | A label you assign for identification |
| Venue | The exchange or counterparty this key authenticates to |
| Environment | Logical tag (for example, production or staging) |
| API key identifier | The identifier returned by the exchange after registration |
| Expiration date | Optional date after which signing can be blocked |
| Frozen | Whether the key is currently frozen |

You can update the environment, expiration date, and API key identifier at any time after creation.

## Backup-key requirement

Key creation is blocked until a backup public key is configured for the system at deployment time. This requirement ensures no key can be created before disaster recovery is set up. The pre-deployment steps are covered in the [Deployment guide](/deploy/operations/backup-dr).

## Listing and filtering keys

The **Offchain Keys** page shows a table of all keys. Use the search field to filter by name, or use the venue and environment dropdowns to narrow the list. Each row shows the key name, venue, signing scheme, environment, security groups, expiration date, freeze status, and creation date.

![Offchain Keys inventory with populated rows across venues and environments, one key frozen](/img/guide/keys/overview.png)
*The Offchain Keys inventory. The dimmed row with the snowflake icon is a frozen key, blocked from signing until it is unfrozen.*