> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Offline signer key store
> Which networks a DFNS offline signer wallet can use, and the per-chain timing considerations for signing transactions out-of-band.
export const SupportLink = ({children}) => {
const url = "https://support.dfns.co";
return {children || url};
};
The offline signer is a DFNS key store in which signing happens **out-of-band**, on infrastructure that is not continuously connected to the DFNS API. DFNS builds the unsigned transaction, the signature is produced offline, and the signed transaction is broadcast later. Because that round trip is operator-driven, the delay between building a transaction and broadcasting it is effectively **unbounded** — which is the main thing to design around (see [Transaction timing](#transaction-timing-considerations)).
It is one of three key stores, alongside [MPC](/advanced/deployment-models/mpc) and [HSM](/advanced/deployment-models/hsm). Setting up an offline signer is coordinated with DFNS — contact our Support Team.
## Supported networks
An offline signer key can sign for a network as long as the network's signing scheme is one the offline signer produces. It supports:
| Signature scheme | Curve | Covers |
| ---------------- | --------- | --------------------------------------------------------------------------- |
| ECDSA | secp256k1 | EVM networks, Bitcoin (legacy and SegWit), Tron, and other secp256k1 chains |
| EdDSA | ed25519 | Solana, Stellar, TON, Aptos, Sui, Cardano, and other ed25519 chains |
It does **not** support:
* **Schnorr signatures** — so Bitcoin **Taproot** addresses are not available (legacy and SegWit ECDSA address types are).
* **The Stark curve** — so **Starknet** is not available.
* **Hierarchical (HD) master keys** — offline signer keys are provisioned individually, not derived from a master key.
There is no separate per-network allow list for the offline signer: any network whose signing scheme and curve are ECDSA/secp256k1 or EdDSA/ed25519 is eligible. Creating a wallet on a network whose scheme the key can't produce is rejected at wallet creation.
## Transaction timing considerations
For most networks a signed transaction has no expiry, so an unbounded offline delay is not a problem. But several networks stamp a **validity window** into the transaction when DFNS builds it: if you don't broadcast the signed transaction within that window, it is rejected on-chain and you have to rebuild and re-sign it. These windows apply to every wallet, but they matter most for offline signing, where the delay before broadcast is largest.
| Network | Validity window after the transaction is built | Notes |
| ---------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Solana | \~90 seconds (recent blockhash) | Use a [durable nonce](#solana-durable-nonces) to remove the expiry — this is the recommended approach for offline signing. |
| Hedera | \~180 seconds | The tightest window; there is no durable-nonce equivalent, so broadcast promptly or rebuild. |
| Stellar | up to 24 hours (time bounds) | |
| XRP Ledger | \~24 hours (`LastLedgerSequence`) | |
| TON | up to 24 hours (`valid_until`) | |
| Aptos | up to 24 hours (`expireTimestamp`) | |
| Cardano | up to 24 hours (TTL) | |
| Concordium | up to 24 hours (expiry) | |
| Canton | up to 24 hours (expiry) | |
| EVM | none (nonce-based) | Broadcast whenever; make sure the account nonce you built with is still the next one when you broadcast. |
| Bitcoin | none (UTXO-based) | Broadcast whenever; make sure the inputs you signed are still unspent. |
For networks that order transactions by an account nonce or sequence number (EVM, and account-based chains generally), a transaction you signed earlier becomes invalid if a later transaction consumes that nonce or sequence first. When signing offline, broadcast in order and don't build a new transaction on the same account until the previous one has confirmed.
### Solana durable nonces
Solana's \~90-second blockhash window is too short for offline signing, so Solana transactions from an offline signer wallet use a **durable nonce** instead of a recent blockhash. The nonce doesn't expire, so the transaction stays valid until it is broadcast. When you sign from the dashboard, this is applied for you; over the API you set `useDurableNonce` (and pre-provision a nonce account pool). See [Use Solana durable nonces](/guides/solana-durable-nonces) and [Recent blockhash and transaction timing](/networks/solana#recent-blockhash-and-transaction-timing).
## Related
Default multi-party-computation signing
Hardware security module signing
Remove the \~90s Solana expiry for offline signing
Back up and recover keys