Skip to content
mera
Get startedGetting started →

Signing sessions

A signing session holds a private key and signs with it until end is called.

Two constructors exist, one per signature scheme:

Independent of passkeys

Section titled “Independent of passkeys”

A session’s input is a raw private key, derived from PRF output, decrypted from a vault, or imported from elsewhere.

A session uses an in-memory private key and doesn’t contact an authenticator.

The lifecycle

Section titled “The lifecycle”

Construction copies the key into a session-owned snapshot. Ending the session zeroes that copy and is permanent. An ended session throws on signing, and new signatures require a new session.

Sessions also support using declarations: disposal calls end() when the scope exits, so a session can be bound to a block instead of a manual call.

The signing session lifecycle. A private key, derived, decrypted, or imported, is consumed when the session is created. The live session holds the only copy of the key and signs on request. Calling end() zeroes the session's key copy; the ended state is permanent, and a new signature needs a new session. Private key create the session Live signs on request end() Ended

How long to keep a session

Section titled “How long to keep a session”

After end(), the next signature needs fresh key material, and both sources (reproducing a derived key, decrypting a vault) start with a ceremony and its prompt. Session lifetime is a trade-off between that prompt and the open window.

An app that signs frequently may keep the session for a burst of work and end it when the burst finishes. Apps that sign occasionally are better served by holding no session at all: create one just to read the public key, end it, zero the private key, and identify the account by its address. The next signature then starts with a fresh ceremony.

See also

Section titled “See also”