FROST in OAS / AEGIS follows IETF RFC 9591 (Ed25519 ciphersuite). Ceremony coordination and key-share provisioning guides continue to expand; the migration note below is required reading before any 2.x → 3.x upgrade.
FROST enables MHR entities: identities governed by M-of-N humans where no individual holds the full key. Any threshold quorum of M can sign on behalf of the MHR. Final signatures are standard 64-byte Ed25519 encodings — verifiers cannot distinguish single-signer from threshold. AEGIS provides generateShares, signWithThreshold, verifyThresholdSignature, and a distributed FrostCeremony orchestrator for multi-process signing. The Rust OAS crypto stack uses the frost-ed25519 crate (with the frost feature on oas-crypto).

​
frost-ed25519 3.x share regeneration

frost-ed25519 3.x key packages and secret shares are not compatible with 2.x serialized shares. Upgrading without regenerating shares fails closed at deserialize time — it does not silently accept old share bytes.

​
Operator upgrade procedure

  1. Coordinate a simultaneous key-share regeneration with all participants.
  2. Re-run dealer (or DKG) key generation for the same threshold (t, n).
  3. Distribute new KeyPackage bytes over the existing secure channel.
  4. Discard all 2.x share material — it will not load under 3.x.
  5. No action is required for stored final signatures (64-byte Ed25519 format is stable).
Do not roll a 3.x binary into a live signing group that still holds 2.x shares. Plan the regeneration window first; fail-closed deserialization is intentional.

​
Scope

FROST here covers threshold signing for multi-human roots. Broader claims about personhood, uniqueness, or Sybil resistance are outside the FROST primitive and require separate assurance credentials and verifier policy.