Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.vaulkyrie.xyz/llms.txt

Use this file to discover all available pages before exploring further.

FROST stands for Flexible Round-Optimized Schnorr Threshold signatures. RFC 9591 specifies a two-round threshold signing protocol for Schnorr signatures and defines how participants generate nonces, commitments, signature shares, and an aggregate signature. Vaulkyrie uses the Rust frost-ed25519 implementation through:
  • crates/vaulkyrie-frost/src/lib.rs
  • crates/vaulkyrie-frost-wasm/src/lib.rs
  • src/services/frost/frostService.ts

Why FROST fits Solana

Solana accounts use Ed25519 signatures. FROST can produce a standard Ed25519-compatible signature from threshold shares. That means downstream Solana transaction validation sees a normal signature even though no single participant held the full private key.

Vaulkyrie DKG mapping

The WASM module exports DKG round functions:
WASM exportBrowser wrapperOutput
dkg_round1dkgRound1Secret package and broadcast package.
dkg_round2dkgRound2Updated secret package and peer-addressed packages.
dkg_round3dkgRound3Key package, public key package, group public key.
The browser wrapper serializes FROST structures as JSON-compatible byte arrays so they can be passed between WASM and browser relay transports.

Vaulkyrie signing mapping

WASM exportBrowser wrapperPurpose
signing_round1signingRound1Generate nonces and commitments.
signing_round2signingRound2Produce one participant signature share.
aggregate_signatureaggregateSignatureCombine shares into final signature.
verify_signatureverifySignatureVerify the aggregate signature against the group key.

Signing sequence

Local vs multi-device signing

signLocal in src/services/frost/frostService.ts is a convenience path for signing with enough key packages on one device. It is useful for testing and for accounts whose threshold packages are locally present. Multi-device signing uses SigningOrchestrator in src/services/frost/signingOrchestrator.ts. It waits for commitments and signature shares from the relay before aggregating.

Server cosigner integration

The server cosigner path uses the same FROST rounds, but one participant is automated by relay-server/src/cosigner.ts. The cosigner:
  1. Loads its stored key package.
  2. Joins a relay session from an invite.
  3. Emits signing commitments when it receives a sign request.
  4. Waits for enough commitments.
  5. Sends its signature share.
It never needs all shares.

Primary reference