Guardian, FROST, DKG, and custody
Understand what Guardians can sign, refuse, coordinate, and never learn.
Follow these 10 lessons in order, or choose the topic you need. Each lesson combines an explanation, a worked example and practice inside the Guild.
Guardian responsibilities
Guardians receive signed requests, validate protocol rules and transaction structure, reserve issuance accounts, and contribute authorization when policy permits.
Open lessonFROST signing rounds
Guardians exchange nonce commitments and signature shares so a threshold subset produces one BIP340-compatible group signature.
Open lessonDistributed key generation
Participant-local DKG creates shares without any coordinator learning the group secret or plaintext participant shares.
Open lessonThresholds and quorum
A t-of-n topology trades availability against compromise resistance; current tests and planned deployments must not be confused with one permanent quorum.
Open lessonCoordinator trust boundary
Signature aggregation is public; safety depends on each honest Guardian independently rejecting invalid signing requests.
Open lessonTEE custody
Attested enclaves bind code measurements and short-lived sealing keys so shares are finalized, stored, and used inside confidential workloads.
Open lessonSigning policy binding
Request IDs, action types, transaction hashes, signing inputs, group keys, and policy digests prevent replay and cross-round substitution.
Open lessonGuardian passphrases
Wallet passphrases protect encrypted local wallet files; production Guardian key packages have separate enclave and operator custody controls.
Open lessonFailure, rotation, and migration
The v1 custody design treats lost Guardians and rotations as a new DKG plus funds migration rather than reconstructing shares centrally.
Open lessonProduction-readiness boundaries
Implemented policy gates, test proofs, live cloud rehearsals, external audits, and real-funds enablement are separate milestones.
Open lesson