Use KMS to Store Private Keys and Sign Transactions on Solana
Generate wallets, private keys, blockchain addresses, and sign transactions locally
In this guide, you will learn how to generate wallets, private keys, blockchain addresses, and sign transactions locally using Tatum Key Management System (KMS).
This guide shows how to start using KMS on Solana and similar blockchains.
Before you start, we recommend that your review the following sections:
- Private Keys and Mnemonic Phrases for general information about risks of using private keys and mnemonics in transactions.
With KMS installed, you will go through the following steps:
- 1.Generate a managed wallet.
- 2.Send some test SOL to your new address.
- 3.Enable KMS daemon mode.
- 4.Initiate a transaction and let KMS sign it.
- 5.Get transaction details.
To generate a wallet that is managed by KMS, use the
generatemanagedwallet command in CLI mode.Request
1
tatum-kms --path=wallet.dat --testnet generatemanagedwallet SOL
2
3
Enter password to access wallet storage:*****
When you first use KMS, you will be prompted to enter a password to encrypt your data. This password is created the first time you enter it, and you should store it in a safe place.
The wallet storage is encrypted with an AEC cipher and is stored on your local server. The password you provide is used to encrypt the mnemonics and private keys inside. If you lose your password, you will lose access to your mnemonics.
Response
The response contains your wallet mnemonic's signature ID as the first parameter:
1
{
2
"xxx-59be-4792-81c5-yyy": {
3
"mnemonic": "urge pulp usage sister evidence arrest palm math please chief egg abuse",
4
"xpub": "tpubBCDEF"
5
}
6
}
Use a Solana testnet faucet to send some test SOL to the Solana address that you generated in Step 1. You can use any faucet (example).
Daemon mode is essentially KMS running in the background and listening for pending transactions to sign and broadcast them.
- Transactions are identified by your API key.
- You can filter transactions by blockchain.
To enable daemon mode, enter the following code on your local server:
1
tatum-kms daemon --path=wallet.dat --testnet --chain=SOL --api-key=your-testnet-api-key --period=10
You must enter the password to unlock the wallet storage. The password is required whenever you start the daemon or restart the daemon after it stopped.
By default, Tatum KMS checks for the pending transactions every 5 seconds using this API call. One API call consumes 1 credit from your monthly credit allowance.
Instead of a privateKey (left), **** the call uses a signatureId field (right) that contains your signature ID:
As you can see, there is no private key or mnemonic anywhere in the KMS request, nor was any other sensitive information required.
KMS now detects a new pending transaction, signs it locally and sends the transaction to the blockchain. KMS must also mark the transaction as processed so that it will not be sent to the blockchain again.
When KMS picks up the pending transaction, it will output something like the following sample:
1
{
2
"withdrawalId": null,
3
"chain": "SOL",
4
"serializedTransaction": "{escaped-json-transaction-payload}",
5
"hashes": [
6
"b8eb99cd-ba04-4031-a65f-11d6420ebdd1"
7
],
8
"index": null,
9
"withdrawalResponses": null,
10
"id": "61fe7c68cf2fbc595cbb89dd"
11
}
Using the KMS transaction ID from the
id field of the response to the previous request (61fe7c68cf2fbc595cbb89dd in the example above), you can now use the Get transaction details endpoint to acquire the details of the transaction you have just performed.Request
1
curl --request GET
2
--url https://api.tatum.io/v3/kms/61fe7c68cf2fbc595cbb89dd
3
--header 'x-api-key: your-testnet-api-key-from-tatum'
Response
The response will contain the details of your transaction:
1
{
2
"withdrawalId": null,
3
"chain": "SOL",
4
"serializedTransaction": "{escaped-json-transaction-payload}",
5
"hashes": [
6
"b8eb99cd-ba04-4031-a65f-11d6420ebdd1"
7
],
8
"index": null,
9
"withdrawalResponses": null,
10
"txId": "f7572ef070d381612b7594940cc73ec008e796b37a73ff031f3855d2a23c9ade",
11
"id": "61fe7c68cf2fbc595cbb89dd"
The response contains a Solana transaction ID in the
txId field (f7572ef070d381612b7594940cc73ec008e796b37a73ff031f3855d2a23c9ade in the example above), which you can use to view the blockchain transaction in any Solana blockchain explorer.