Skip to main content
A Walley party is controlled by a single Ed25519 key. This page covers how the SDK loads it, how the party id relates to it, and how authentication works under the hood.

Loading the key

The recommended way is a key file — key material stays out of source code:
The file’s format is detected automatically: a PKCS#8 PEM, a 24-word BIP-39 recovery phrase, or a hex/base64 raw key. Inline forms are also supported:
The recovery phrase is the key: its 256 bits of entropy are used directly as the Ed25519 private key — no derivation path, no passphrase — exactly as the Walley app encodes it at registration. See Recovery Phrase.

Keys, fingerprints, and party ids

The Signer class converts between representations:
A Canton party id is <hint>::<fingerprint>, so the key and the party are cryptographically bound. Identify the party either way:
A party_id whose namespace doesn’t match the key’s fingerprint is rejected up front.

Signing arbitrary messages

w.sign(...) produces a signature bundle any verifier can check against the party id — useful for login proofs and off-ledger attestations:
This is the headless equivalent of the dApp SDK’s signMessage.

Configuration reference

audience must match the target deployment’s auth configuration, you can override it together with api_base when pointing at a non-production environment.