Cashu Development Kit (CDK)

The cdk-nostr crate provides Nostr support for the Cashu Development Kit. It is organized into several functional modules:

• keys: Handles secret key generation, parsing, and x-only public key derivation.
• nip44: Implements NIP-44 v2 authenticated encryption between Nostr keys.
• inbox: A standing NIP-17 inbox listener. It subscribes to relays for gift wraps addressed to a specific identity, unwraps them, and delivers the resulting rumors to a NostrInboxListener callback.
• nwc (requires nwc feature): Implements the NIP-47 Nostr Wallet Connect wallet service.
• npubcash (requires npubcash feature): An npub.cash API client for handling quotes, settings, and NIP-98/JWT authentication.

CDK Mintd is a Cashu mint daemon implementation for the Cashu Development Kit (CDK). It provides a complete Cashu mint server implementation that supports multiple database backends and pluggable payment backends.

Warning: This project is in early development. While it works with real sats, always use amounts you are willing to lose.

The cdk-fake-wallet is a fake Lightning wallet implementation designed specifically for testing within the Cashu Development Kit (CDK) ecosystem.

Key Behavior:

• It simulates Lightning Network interactions.
• Quotes are automatically filled without any actual Lightning Network communication.

⚠️ WARNING: This library is intended for testing purposes only. Do not use this implementation in production environments.

The cdk-redb crate provides a storage backend implementation using Redb for CDK wallet functionality. It is designed to handle the following core wallet responsibilities:

• Wallet storage: Persistent storage for wallet state.
• Proof tracking: Managing and tracking Cashu proofs.
• Transaction history: Maintaining a record of transactions.

The management API is composed of several per-domain gRPC services served on the same port. Every request must include the x-cdk-protocol-version header set to cdk_common::MINT_RPC_PROTOCOL_VERSION (the CLI handles this automatically).

The wallet seed is automatically generated and stored in <work-dir>/seed during the first run. This seed is used to derive all keys and is essential for restoring your wallet.

Warning: Back up your seed file securely. Anyone with access to the seed can spend your tokens.

To restore proofs from a specific mint using your seed, use the restore command.

cdk-cli restore <MINT_URL>

The sync loop applies blocks in chunks (default 16 blocks per wallet-lock) to prevent blocking user operations like address reveals.

Key Sync Behaviors:

• Esplora: Requests have a 10-second timeout. parallel_requests must be greater than zero.
• Bitcoin Core Checkpoints: Fresh wallets checkpoint at the current tip. To restore a wallet from a mnemonic, use BitcoinRpcConfig::wallet_rescan_from_height to specify the known birthday height. This only affects creation and does not rewind existing state.
• Reorgs: On reorgs, Bitcoin Core sync follows the orphaned branch to find the common ancestor and replays replacement blocks. This includes blocks below the original birthday height.
• Errors: Missing headers or block data cause a sync tick failure and retry. A rollback with no replacement block is retried rather than reported as completed.

Secret fields (mnemonics, passwords, URLs) must contain a reference rather than a literal value in the TOML file. Supported reference types are:

• env:VARIABLE: Reads the named environment variable.
• file:/absolute/path: Reads the content of the specified absolute file path.

Example Configuration:

[info]
mnemonic = "file:/run/secrets/mint-mnemonic"

[database.postgres]
url = "env:CDK_MINTD_POSTGRES_URL"

[bdk]
bitcoind_rpc_password = "env:CDK_MINTD_BDK_BITCOIND_RPC_PASSWORD"
mnemonic = "file:/run/secrets/bdk-mnemonic"

cdk-mintd persists only the references in the configuration store; resolved secret contents are never written to the database.

The mint supports rotating keysets to newer versions (e.g., V1 to V2). You can control this via policy configuration in your initialization or apply document:

• use_keyset_v2 = true: Forces V2. If the current active keyset is V1, it will be rotated to V2 on startup.
• use_keyset_v2 = false: Forces V1. If the current active keyset is V2, it will be rotated to V1 on startup.
• Unset (Default): Preserves the current keyset version. If no keyset exists, V2 is created.

Manual Rotation: You can manually trigger a rotation using the cdk-mint-cli:

cdk-mint-cli rotate-next-keyset --use-keyset-v2 true  # Rotate to V2
cdk-mint-cli rotate-next-keyset --use-keyset-v2 false # Rotate to V1

🔒 CRITICAL SECURITY CONSIDERATIONS:

The LDK management interface has NO AUTHENTICATION and allows sending funds and managing channels. To prevent unauthorized access:

1. NEVER bind the webserver to 0.0.0.0 or expose it publicly.
2. ONLY use 127.0.0.1 (localhost) for the webserver_host.
3. For remote access, use a VPN, SSH tunneling, or a reverse proxy with authentication.

While CSRF protection and non-permissive browser CORS are implemented to reduce browser-based attack paths, they do not replace the need for proper access control and authentication.