Arbiter

Arbiter is an open-source permissioned signing service for cryptocurrency wallets. It runs as a background daemon with an optional desktop client for vault management. It is the reference implementation of the signing and custody work we do for clients, and it is public so you can audit the reasoning before you hire us to apply it to your system.

Core guarantee. The vault never exposes private key material under any circumstances. It produces a signature only when the request satisfies the policies configured by the owner. Automation tools and SDK clients get exactly the access they were granted, nothing more.

Authentication. Every peer, whether a management client or an automation tool, authenticates via public-key challenge and response. The server issues a nonce-based challenge, the peer signs it, and the server verifies before allowing any operation. On first run a one-time bootstrap token registers the first management client. Every SDK client after that must be explicitly approved by an already-registered owner.

Key hierarchy. Keys are arranged in three layers. A user password derives the root key, and the root key encrypts individual wallet keys. Password rotation therefore re-encrypts only the root key rather than every wallet, and root key rotation is independent of the password. Everything at rest is encrypted with versioned symmetric AEAD, and the vault migrates older entries to the current scheme automatically on unseal.

Vault lifecycle. On startup Arbiter boots sealed and cannot produce any signature at all. To unseal, the management client encrypts the password with a server-generated one-time key and sends the ciphertext, so the plaintext password never travels over the wire. Once unsealed, the root key is held in a hardened memory cell protected against dumps, page swaps, and hibernation files.

Permission engine. SDK clients have zero access by default. Grants are issued explicitly by the vault owner and scoped to a specific wallet and chain. For EVM chains, Arbiter decodes known contract calls and presents them with human-readable meaning, such as “transfer 500 USDT to 0x…”, then enforces configurable volume limits, rate limits, and time-window restrictions per grant. Unknown contracts can be permitted too, with transaction count and rate caps. Nonce management is handled automatically to prevent replay.