Signers
Signer implementations beyond keypairs — cloud KMS, Ledger, Web Crypto, passkeys, and multisig
In addition to the in-process keypairs built into @mysten/sui, the
SDK ecosystem ships more implementations of the Signer interface. Some keep
the private key outside your application — in a cloud key-management service (KMS), on a hardware
wallet, or as a non-extractable browser key — while others, like
multisig, combine several signers together. Because each one
extends the same Signer base class, it works anywhere a keypair does.
External signers
These signers hold the key material outside your process. Each is published as its own package, so you install only the one you need:
| Signer | Package | Scheme | Key lives in |
|---|---|---|---|
AwsKmsSigner | @mysten/aws-kms-signer | Secp256k1 or Secp256r1 | AWS KMS |
GcpKmsSigner | @mysten/gcp-kms-signer | Secp256k1 or Secp256r1 | GCP KMS |
LedgerSigner | @mysten/ledger-signer | Ed25519 | Ledger hardware wallet |
WebCryptoSigner | @mysten/webcrypto-signer | Secp256r1 | Browser Web Crypto store |
For the AWS and GCP signers, the curve of the underlying KMS key determines the signature scheme
(ECC_NIST_P256 → Secp256r1, ECC_SECG_P256K1 → Secp256k1).
Each signer above is its own npm package — import directly from @mysten/aws-kms-signer,
@mysten/ledger-signer, and so on, and depend only on the ones you use. The @mysten/signers
package is a convenience umbrella that re-exports all four under subpaths (@mysten/signers/aws,
@mysten/signers/gcp, @mysten/signers/ledger, @mysten/signers/webcrypto) if you would rather
depend on a single package. The individual pages below use the standalone packages.
Other Signer implementations
Two more Signer implementations live in @mysten/sui itself rather than in a standalone package:
- Passkey: sign with a WebAuthn passkey (biometric or
platform authenticator) through
PasskeyKeypair. - Multi-signature: combine signatures from several public
keys under a configurable threshold with
MultiSigPublicKey. ItsgetSignermethod returns aMultiSigSigneryou can use anywhere a keypair works. The underlying keys can be keypairs, KMS signers, passkeys, or zkLogin identifiers.
Shared interface
Because every signer extends Signer, the signing API is identical regardless of where the key is
held; only the way you construct the signer differs:
// Derive the address
const address = signer.getPublicKey().toSuiAddress();
// Sign a personal message
const message = new TextEncoder().encode('hello world');
const { signature } = await signer.signPersonalMessage(message);
// Sign and execute a transaction (resolves to a discriminated union)
const result = await client.signAndExecuteTransaction({ transaction, signer });
if (result.FailedTransaction) {
throw new Error('Transaction failed to execute');
}
console.log(result.Transaction.digest);See Cryptography for the full signing and verification API that all signers share.
Construction
Each external signer exposes a static factory rather than a public constructor, because preparing the signer requires an async round-trip to fetch the public key from the KMS or device:
AwsKmsSigner.fromKeyId(keyId, options). See AWS KMS Signer.GcpKmsSigner.fromOptions(options). See GCP KMS Signer.LedgerSigner.fromDerivationPath(path, ledgerClient, suiClient). See Ledger Signer.WebCryptoSigner.generate()andWebCryptoSigner.import(exported). See Web Crypto Signer.