Neue Signer hinzufügen

Dieser Leitfaden richtet sich an Wallet-Dienstanbieter und Entwickler, die neue Schlüsselverwaltungslösungen in die solana-keychain-Bibliothek integrieren möchten. Durch das Hinzufügen Ihrer Signer-Implementierung ermöglichen Sie Entwicklern, Ihren Dienst für die sichere Signierung von Solana-Transaktionen über eine einheitliche Schnittstelle zu nutzen.

Verwenden Sie ein LLM? Schauen Sie sich die Skill zum Hinzufügen von Signern an.

Architekturübersicht

Die Bibliothek verwendet eine Trait-basierte Architektur, bei der alle Signer das in src/traits.rs definierte SolanaSigner-Trait implementieren. Die Bibliothek bietet außerdem ein einheitliches Signer-Enum, das alle Implementierungen umschließt und eine Laufzeitauswahl der Signatur-Backends ermöglicht, während eine konsistente API beibehalten wird.

Schnelle Integrationscheckliste

  • Erstellen Sie Ihr Signer-Modul mit Implementierung
  • Implementieren Sie das SolanaSigner-Trait (3 asynchrone Methoden + pubkey())
  • Fügen Sie ein Feature-Flag in Cargo.toml hinzu
  • Aktualisieren Sie das Signer-Enum in src/lib.rs (4 match-Zweige)
  • Aktualisieren Sie src/error.rs reqwest From impl cfg gate (falls Ihr Signer reqwest verwendet)
  • Erzwingen Sie HTTPS und konfigurieren Sie Timeouts für HTTP-Clients
  • Fügen Sie umfassende Tests hinzu
  • Aktualisieren Sie die Dokumentation
  • Reichen Sie einen PR ein

Schritt 1: Erstellen Sie Ihr Signer-Modul

Erstellen Sie ein neues Verzeichnis unter src/ für Ihre Implementierung:

src/
├── your_service/
│ ├── mod.rs # Main implementation with SolanaSigner trait
│ └── types.rs # API request/response types (if needed)

Schritt 2: Definieren Sie Ihre Signer-Struktur

Definieren Sie in src/your_service/mod.rs Ihre Signer-Struktur:

//! YourService API signer integration
use crate::{error::SignerError, traits::SolanaSigner};
use solana_sdk::{pubkey::Pubkey, signature::Signature, transaction::Transaction};
use std::str::FromStr;
/// YourService-based signer using YourService's API
#[derive(Clone)]
pub struct YourServiceSigner {
api_key: String,
api_secret: String,
wallet_id: String,
api_base_url: String,
client: reqwest::Client,
public_key: Pubkey,
}
impl std::fmt::Debug for YourServiceSigner {
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
f.debug_struct("YourServiceSigner")
.field("public_key", &self.public_key)
.finish_non_exhaustive()
}
}

Schritt 3: Implementieren Sie Konstruktor- und Hilfsmethoden

Remote-Signer müssen HTTPS erzwingen und HTTP-Timeouts konfigurieren. Verwenden Sie die gemeinsame HttpClientConfig-Struktur für Timeout-Einstellungen.

use crate::http_client_config::HttpClientConfig;
impl YourServiceSigner {
pub fn new(
api_key: String,
api_secret: String,
wallet_id: String,
public_key: String,
http_config: Option<HttpClientConfig>,
) -> Result<Self, SignerError> {
let pubkey = Pubkey::from_str(&public_key)
.map_err(|e| SignerError::InvalidPublicKey(format!("Invalid public key: {e}")))?;
let http = http_config.unwrap_or_default();
let builder = reqwest::Client::builder()
.timeout(http.resolved_request_timeout())
.connect_timeout(http.resolved_connect_timeout());
// Enforce HTTPS in production; wiremock uses HTTP in tests
#[cfg(not(test))]
let builder = builder.https_only(true);
let client = builder.build().map_err(|e| {
SignerError::ConfigError(format!("Failed to build HTTP client: {e}"))
})?;
Ok(Self {
api_key,
api_secret,
wallet_id,
api_base_url: "https://api.yourservice.com/v1".to_string(),
client,
public_key: pubkey,
})
}
/// Sign raw bytes using your service's API
async fn sign(&self, message: &[u8]) -> Result<Signature, SignerError> {
let encoded_message = base64::engine::general_purpose::STANDARD.encode(message);
let url = format!("{}/sign", self.api_base_url);
let response = self
.client
.post(&url)
.header("Authorization", format!("Bearer {}", self.api_key))
.json(&serde_json::json!({
"wallet_id": self.wallet_id,
"message": encoded_message,
}))
.send()
.await?;
// Use generic error messages — never expose raw API response text
if !response.status().is_success() {
let status = response.status().as_u16();
return Err(SignerError::RemoteApiError(format!(
"YourService API returned status {status}"
)));
}
// Parse response — always use map_err, never .expect() or .unwrap()
let response_data: SignResponse = response
.json()
.await
.map_err(|e| SignerError::SerializationError(format!("Failed to parse response: {e}")))?;
let sig_bytes = base64::engine::general_purpose::STANDARD
.decode(&response_data.signature)
.map_err(|e| SignerError::SerializationError(format!("Failed to decode signature: {e}")))?;
let sig_array: [u8; 64] = sig_bytes
.try_into()
.map_err(|_| SignerError::SigningFailed("Invalid signature length".to_string()))?;
Ok(Signature::from(sig_array))
}
}

Schritt 4: Implementieren Sie das SolanaSigner-Trait

Das Trait hat 3 asynchrone Methoden (sign_transaction, sign_message, is_available) plus pubkey(). Beachten Sie, dass sign_transaction SignTransactionResult zurückgibt – ein getaggtes Enum, das angibt, ob die Transaktion vollständig oder teilweise signiert ist.

Verwenden Sie die gemeinsamen TransactionUtil-Hilfsfunktionen zum Signieren und Serialisieren.

use crate::transaction_util::TransactionUtil;
use crate::traits::SignTransactionResult;
#[async_trait::async_trait]
impl SolanaSigner for YourServiceSigner {
fn pubkey(&self) -> Pubkey {
self.public_key
}
async fn sign_transaction(
&self,
tx: &mut Transaction,
) -> Result<SignTransactionResult, SignerError> {
let tx_bytes = bincode::serialize(tx)
.map_err(|e| SignerError::SerializationError(format!("Failed to serialize: {e}")))?;
let signature = self.sign(&tx_bytes).await?;
// Add the signature at the correct position
TransactionUtil::add_signature_to_transaction(tx, &self.public_key, signature)?;
// Serialize and classify as Complete or Partial
let serialized = TransactionUtil::serialize_transaction(tx)?;
Ok(TransactionUtil::classify_signed_transaction(
tx,
(serialized, signature),
))
}
async fn sign_message(&self, message: &[u8]) -> Result<Signature, SignerError> {
self.sign(message).await
}
async fn is_available(&self) -> bool {
let url = format!("{}/health", self.api_base_url);
self.client
.get(&url)
.send()
.await
.map(|r| r.status().is_success())
.unwrap_or(false)
}
}

Schritt 5: API-Typen hinzufügen (Optional)

Wenn Ihre API benutzerdefinierte Typen benötigt, erstellen Sie src/your_service/types.rs:

use serde::{Deserialize, Serialize};
#[derive(Serialize)]
pub struct SignRequest {
pub wallet_id: String,
pub message: String,
}
#[derive(Deserialize)]
pub struct SignResponse {
pub signature: String,
}

Schritt 6: Feature-Flag hinzufügen

Aktualisieren Sie Cargo.toml, um Ihren Signer als optionales Feature hinzuzufügen:

[features]
default = ["memory"]
memory = []
vault = ["dep:reqwest", "dep:vaultrs", "dep:base64"]
privy = ["dep:reqwest", "dep:base64"]
turnkey = ["dep:reqwest", "dep:base64", "dep:p256", "dep:hex", "dep:chrono"]
your_service = ["dep:reqwest", "dep:base64"] # Add your feature
all = ["memory", "vault", "privy", "turnkey", "your_service"] # Update all

Schritt 7: Signer-Enum aktualisieren

Fügen Sie Ihren Signer zu src/lib.rs hinzu. Sie benötigen 4 Match-Arme in der SolanaSigner-Implementierung: pubkey, sign_transaction, sign_message und is_available.

// Add feature-gated module
#[cfg(feature = "your_service")]
pub mod your_service;
// Re-export your signer type
#[cfg(feature = "your_service")]
pub use your_service::YourServiceSigner;
// Add to Signer enum
#[derive(Debug)]
pub enum Signer {
#[cfg(feature = "memory")]
Memory(MemorySigner),
// ... existing variants
#[cfg(feature = "your_service")]
YourService(YourServiceSigner), // Add your variant
}
// Add constructor method
impl Signer {
#[cfg(feature = "your_service")]
pub fn from_your_service(
api_key: String,
api_secret: String,
wallet_id: String,
public_key: String,
) -> Result<Self, SignerError> {
Ok(Self::YourService(YourServiceSigner::new(
api_key,
api_secret,
wallet_id,
public_key,
None, // uses default HttpClientConfig
)?))
}
}
// Update trait implementation — 4 match arms
#[async_trait::async_trait]
impl SolanaSigner for Signer {
fn pubkey(&self) -> sdk_adapter::Pubkey {
match self {
// ... existing variants
#[cfg(feature = "your_service")]
Signer::YourService(s) => s.pubkey(),
}
}
async fn sign_transaction(
&self,
tx: &mut sdk_adapter::Transaction,
) -> Result<SignTransactionResult, SignerError> {
match self {
// ... existing variants
#[cfg(feature = "your_service")]
Signer::YourService(s) => s.sign_transaction(tx).await,
}
}
async fn sign_message(
&self,
message: &[u8],
) -> Result<sdk_adapter::Signature, SignerError> {
match self {
// ... existing variants
#[cfg(feature = "your_service")]
Signer::YourService(s) => s.sign_message(message).await,
}
}
async fn is_available(&self) -> bool {
match self {
// ... existing variants
#[cfg(feature = "your_service")]
Signer::YourService(s) => s.is_available().await,
}
}
}

Wenn Ihr Signer reqwest verwendet, fügen Sie Ihr Feature dem #[cfg(any(...))]-Gate bei der From<reqwest::Error>-Implementierung in src/error.rs hinzu.

Schritt 8: Umfassende Tests hinzufügen

Fügen Sie Tests zu Ihrem Modul hinzu (am Ende von src/your_service/mod.rs):

#[cfg(test)]
mod tests {
use super::*;
use solana_sdk::{signature::Keypair, signer::Signer};
use wiremock::{
matchers::{header, method, path},
Mock, MockServer, ResponseTemplate,
};
#[tokio::test]
async fn test_new() {
let keypair = Keypair::new();
let signer = YourServiceSigner::new(
"test-key".to_string(),
"test-secret".to_string(),
"test-wallet".to_string(),
keypair.pubkey().to_string(),
None,
);
assert!(signer.is_ok());
}
#[tokio::test]
async fn test_sign_message() {
let mock_server = MockServer::start().await;
let keypair = Keypair::new();
let message = b"test message";
let signature = keypair.sign_message(message);
Mock::given(method("POST"))
.and(path("/sign"))
.respond_with(ResponseTemplate::new(200).set_body_json(serde_json::json!({
"signature": base64::engine::general_purpose::STANDARD.encode(signature.as_ref())
})))
.expect(1)
.mount(&mock_server)
.await;
let mut signer = YourServiceSigner::new(
"test-key".to_string(),
"test-secret".to_string(),
"test-wallet".to_string(),
keypair.pubkey().to_string(),
None,
).unwrap();
signer.api_base_url = mock_server.uri();
let result = signer.sign_message(message).await;
assert!(result.is_ok());
}
#[tokio::test]
async fn test_sign_unauthorized() {
let mock_server = MockServer::start().await;
let keypair = Keypair::new();
Mock::given(method("POST"))
.and(path("/sign"))
.respond_with(ResponseTemplate::new(401))
.expect(1)
.mount(&mock_server)
.await;
let mut signer = YourServiceSigner::new(
"bad-key".to_string(),
"bad-secret".to_string(),
"test-wallet".to_string(),
keypair.pubkey().to_string(),
None,
).unwrap();
signer.api_base_url = mock_server.uri();
let result = signer.sign_message(b"test").await;
assert!(result.is_err());
}
}

Schritt 9: Dokumentation aktualisieren

Fügen Sie Ihren Signer zur Tabelle der unterstützten Backends in der README.md hinzu:

BackendAnwendungsfallFeature-Flag
MemoryLokale Schlüsselpaare, Entwicklung, Testingmemory
VaultEnterprise-Schlüsselverwaltung mit HashiCorp Vaultvault
PrivyEingebettete Wallets mit Privy-Infrastrukturprivy
TurnkeyNicht-verwaltete Schlüsselverwaltung über Turnkeyturnkey
IhrServiceKurze Beschreibung Ihres Dienstesyour_service

Fügen Sie ein Verwendungsbeispiel hinzu:

use solana_keychain::{Signer, SolanaSigner};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let signer = Signer::from_your_service(
"your-api-key".to_string(),
"your-api-secret".to_string(),
"your-wallet-id".to_string(),
"your-public-key".to_string(),
)?;
let pubkey = signer.pubkey();
println!("Public key: {}", pubkey);
Ok(())
}

Testen Ihrer Integration

Führen Sie Tests für Ihr Feature aus:

# Test only your signer
cargo test --features your_service
# Test with all features
cargo test --all-features

TypeScript-Signer

Wenn Sie auch ein TypeScript-Signer-Paket hinzufügen, erstellen Sie es unter typescript/packages/your-signer/. Wichtige Muster:

  • Factory-Funktion createYourSigner() gibt SolanaSigner<TAddress> zurück
  • Config-Interface exportieren (YourSignerConfig)
  • HTTPS auf apiBaseUrl Config-Feldern erzwingen
  • Fehlertext der Remote-API mit sanitizeRemoteErrorResponse() aus @solana/keychain-core bereinigen
  • Gegen fehlerhaftes JSON mit Optional Chaining und try/catch absichern
  • throwSignerError(SignerErrorCode.*, { cause, message }) aus @solana/keychain-core verwenden
  • @throws JSDoc zu Factory-Funktionen hinzufügen, die Fehlercodes auflisten

Umbrella-Paket aktualisieren

typescript/packages/keychain/ aktualisieren — 6 zu modifizierende Dateien:

  1. src/types.tsYourSignerConfig zur KeychainSignerConfig diskriminierten Union hinzufügen
  2. src/create-keychain-signer.ts — Factory importieren, Switch-Case hinzufügen
  3. src/resolve-address.ts — Zum Fast-Path- oder Fetch-Path-Switch-Case hinzufügen
  4. src/index.ts — Config-Typ, Namespace, Factory-Funktion und Klassen-Exporte hinzufügen
  5. package.json@solana/keychain-your-signer: "workspace:*" Abhängigkeit hinzufügen
  6. tsconfig.json{ "path": "../your-signer" } Referenz hinzufügen

Die Switch-Anweisungen haben vollständige never Prüfungen — TypeScript wirft einen Fehler, wenn Sie zur Union hinzufügen, aber einen Case verpassen.

Checkliste für die Einreichung

Vor dem Einreichen Ihres PRs:

  • Code kompiliert ohne Warnungen (just build)
  • Alle Tests bestehen (just test)
  • Code ist formatiert/Linting besteht (just fmt)
  • Keine hartcodierten Werte oder Secrets im Code
  • Fehlermeldungen sind generisch (kein roher API-Antworttext)
  • HTTPS auf Remote-HTTP-Clients erzwungen
  • HTTP-Timeouts über HttpClientConfig konfiguriert
  • Folgt Rust-Namenskonventionen (snake_case)
  • Zur README.md Tabelle unterstützter Backends hinzugefügt

Implementierungstipps

Fehlerbehandlung

Verwenden Sie immer die vorhandenen SignerError Varianten. Verwenden Sie niemals .expect() oder .unwrap() bei nicht vertrauenswürdigen API-Antworten:

// Good — uses existing error types with generic messages
return Err(SignerError::RemoteApiError(
format!("YourService API returned status {}", status)
));
// Good — converts from standard errors
let bytes = base64::decode(data)
.map_err(|e| SignerError::SerializationError(format!("Failed to decode: {e}")))?;

Best Practices für Sicherheit

  • Niemals sensible Daten loggen (private Keys, API-Secrets)
  • Debug Implementierung verwenden, die sensible Felder verbirgt
  • Alle Eingaben validieren (öffentliche Keys, Signaturen)
  • HTTPS für alle Remote-API-Aufrufe verwenden (erzwungen über https_only(true))
  • Request- und Connect-Timeouts über HttpClientConfig konfigurieren
  • Niemals rohen Remote-API-Fehlertext in Fehlermeldungen offenlegen
  • Option<Pubkey> (nicht Pubkey::default()) für das Public-Key-Feld vor init() verwenden

Testen mit Mocks

Verwenden Sie wiremock zum Mocken von HTTP-APIs. Prüfen Sie nur den Fehlertyp, nicht den Fehlermeldungstext:

#[cfg(test)]
mod tests {
use wiremock::{MockServer, Mock, ResponseTemplate};
#[tokio::test]
async fn test_api_call() {
let mock_server = MockServer::start().await;
Mock::given(method("POST"))
.respond_with(ResponseTemplate::new(200))
.mount(&mock_server)
.await;
// Use mock_server.uri() as your api_base_url
}
}

Hilfe erhalten

  • Überprüfen Sie vorhandene Signer-Implementierungen auf Muster:
    • src/memory/mod.rs — Einfach, synchron
    • src/para/mod.rs — Erfordert Initialisierung (als Vorlage für neue Signer verwenden)
    • src/turnkey/mod.rs — Komplexe Signaturverarbeitung
    • src/vault/mod.rs — Externe Client-Bibliothek
  • Wichtige Dateien: src/traits.rs (Trait-Definition), src/transaction_util.rs (gemeinsame Hilfsfunktionen), src/http_client_config.rs (Timeout-Konfiguration)
  • Eröffnen Sie ein Issue für Design-Diskussionen, bevor Sie mit der Arbeit beginnen

Beispiel für eine PR-Struktur

feat(signer): add YourService signer integration
Adds support for YourService as a signing backend.
- [X] Code compiles without warnings (`just build`)
- [X] Code is formatted/linting passes (`just fmt`)
- [X] Add comprehensive tests with wiremock - All tests pass (`just test`)
- [X] Implemented SolanaSigner trait for YourServiceSigner
- [X] Added feature flag 'your_service'
- [X] HTTPS enforced, HTTP timeouts configured
- [X] Added to README.md supported backends table
Closes #1337

Is this page helpful?

Verwaltet von

© 2026 Solana Foundation.
Alle Rechte vorbehalten.
Verbinden Sie sich