sync-keychain

name	sync-keychain
description	Sync the solana-keychain dependency and scaffold adapters for signer backends Kora does not support yet. Use when the user says 'sync keychain', 'bump solana-keychain', 'check for new signers', or 'add support for the <X> signer'.

Sync solana-keychain

Bump the solana-keychain pin, then reconcile Kora's SignerTypeConfig against the backends upstream actually ships.

Bump the pin

Compare the crates.io max_stable_version against the pin in crates/lib/Cargo.toml, edit if they differ, then cargo update -p solana-keychain.

Keep default-features = false and the features = ["all", "sdk-v4"] list intact. sdk-v4 exact-pins solana-sdk for the entire workspace, so a major keychain bump cascades into every crate — expect that to be the bulk of the work on a major.

Find the gap

Upstream backends, from a shallow clone of solana-foundation/solana-keychain:

grep -rhoE "pub struct [A-Za-z]+SignerConfig" --include="*.rs" "$tmp/kc" \
  | sed 's/pub struct //;s/SignerConfig//' | sort -u

Enumerate by *SignerConfig struct, not by from_* method. from_* also matches key-format helpers (from_bytes, from_pem, from_u8_array_string, …) which are not backends and would be scaffolded as phantom signers.

Kora's side — derive it, never hardcode:

awk '/pub enum SignerTypeConfig/,/^}/' crates/lib/src/signer/config.rs \
  | grep -E "^    [A-Z][A-Za-z]* \{" | tr -d ' {'

Variant names are the upstream struct prefix: AwsKmsSignerConfig → AwsKms → from_aws_kms. Also record whether each from_<name> is async; the build function must match.

The difference between the two lists is the work. If it's empty, report and stop.

Scaffold what's missing

Six edits per signer, five of them in crates/lib/src/signer/config.rs: config struct, enum variant, build function, validation function, two match arms — plus an arm in crates/lib/src/validator/signer_validator.rs. That last match is exhaustive, so omitting it is a compile error rather than a silent gap.

Copy the shape of the nearest existing analogue (Fireblocks for an async HTTP backend, AwsKms for a cloud-KMS one). references/scaffolding.md has the templates and the reasoning behind each piece.

Two rules that are not obvious from the surrounding code:

• Secrets are referenced by env var name in signers.toml, never inlined. Any new config field holding a credential must be named *_env.
• Never interpolate an upstream error directly. sanitize_error! strips secrets out of error strings from remote signer SDKs.

Verify with cargo check -p kora-lib, just fmt, cargo test -p kora-lib --lib signer.

Report

Version before/after, upstream backend count, signers scaffolded, files touched. Say plainly that scaffolding is a starting point: a new signer lands with no integration test and no signers.toml documentation entry.