# Rust SDK

> DFNS releases its first Rust SDK. Typed access to the full API, request signing built in, and a design that never asks for your key material.

- Author: Pierre Beugnet (Lead Blockchain Engineer)
- Published: 2026-09-08
- Category: Product
- Canonical: https://dfns.co/article/rust-sdk/
- All DFNS articles: https://dfns.co/llms-full.txt

---

DFNS now has a Rust SDK. It is server-side, fully typed, async on Tokio, and it handles the part of integrating DFNS that developers actually spend time on: cryptographic request signing. It is live on crates.io, documented on docs.rs, and open source on GitHub with the repository open for issues and contributions.

Getting started is one line:

```rust
cargo add dfns-sdk-rust
```

## Why Rust

The systems our clients build in Rust are exactly the systems DFNS sits under: exchange matching engines, payment processors, settlement services, node infrastructure, the software where performance is a requirement and memory safety is a security control. Those teams have been integrating DFNS over raw HTTP, implementing user action signing by hand. They asked for a first-class SDK. This is it.

And Rust is not new at DFNS. It is the language our cryptographic core already speaks: the official FROST implementation our researchers contribute to is Rust, and so is the signing infrastructure it runs in. The SDK closes the loop, the language of our signing core is now the language you integrate it in.

## What's in the box

A typed client for the DFNS API, with helpers for the operations backends do most: wallets, transfers, and signatures. Read-only operations need nothing but an auth token, list wallets, fetch balances, and read history in a dozen lines. The SDK is async end to end on the Tokio runtime, with a minimum supported Rust version of 1.75.

The interesting engineering is in how state-changing operations work. Every mutating call on DFNS requires user action signing, a cryptographic signature over a per-request challenge, which is what makes DFNS requests phishing-resistant and replay-proof. The SDK owns that entire challenge flow: fetching the challenge, formatting the assertion, completing the request. You provide exactly one thing: the signature.

## Two signing models, one deliberate omission

The SDK supports both places a signing credential can live.

* Direct signing, when your backend holds the credential key: you implement one trait, UserActionSigner, with the cryptography library of your choice, and the client calls your sign method at the right moment. Notice what the SDK does not do: it ships no key signer of its own. That is a design decision, not a gap. Your private key material never enters the SDK's dependency tree, never crosses an abstraction you didn't choose, and is never touched by code you didn't pick. The SDK owns the protocol; you own the key. For the security-conscious teams Rust attracts, we think that is the right division, and it keeps the trust surface exactly as small as you make it.  
* Delegated signing, when the key is not on your backend at all: user passkeys signing on their own devices, or an external KMS like AWS KMS or HashiCorp Vault. The DfnsDelegatedClient splits every signed operation into an init and complete pair, your server starts the action and receives the challenge, the user's device or your KMS signs it out of band, and your server completes it. Passkey-controlled wallets, with the end user holding the credential, become a straightforward server flow rather than a protocol you reverse-engineer.

## Get started

* Install: `cargo add dfns-sdk-rust`  
* Read the docs: [docs.dfns.co/sdks/backend/rust](https://docs.dfns.co/sdks/backend/rust)  
* Explore the code: [github.com/dfns/dfns-sdk-rust](https://github.com/dfns/dfns-sdk-rust)  
* Talk to our team: [sales@dfns.co](mailto:sales@dfns.co)