• FROSTR evaluation for tenex-eventd
  • Objective
  • What FROST solves
  • Why this fits Signet
  • Hard constraint on the current v3 key
  • Same-npub share rotation caveat
  • Integration options
    • Option A: stabilize the current bunker first
    • Option B: move to a fresh threshold-generated identity
    • Option C: same-npub threshold retrofit with share refresh
  • Go ecosystem read
  • Effort estimate
  • Recommendation
  • Decision needed

§FROSTR evaluation for tenex-eventd

§Objective

Evaluate whether Signet should move from a single-key bunker to threshold signing so one leaked machine or one leaked process does not immediately burn the Nostr identity.

§What FROST solves

Fact: RFC 9591 standardizes FROST, a threshold Schnorr signing protocol.

Fact: the Go library github.com/bytemare/frost advertises RFC 9591 support and explicitly supports Secp256k1.

Fact: FROSTR-adjacent tooling already exists in the Nostr ecosystem (FROSTR-ORG/igloo-desktop, igloo-server), which makes this direction ecosystem-aligned rather than custom crypto.

§Why this fits Signet

• tenex-eventd already acts like a signing control plane.
• NIP-46 gives us the remote-signing protocol boundary.
• FROST is the right primitive if we want to remove single-process custody of the signing key.

§Hard constraint on the current v3 key

Fact: the current v3 identity already exists today as a single local secret.

Inference: turning an already-created single secret into “2-of-3 shares” is not the same trust model as a threshold key generated through DKG from the start.

Important consequence:

• Even if the v3 secret is now split for operational use, the historical single-key exposure already happened.
• That means threshold retrofitting improves future custody but does not erase past exposure history.

§Same-npub share rotation caveat

Fact: RFC 9591 covers threshold signing, not a whole operational system for proactive share refresh / in-place share rotation.

Inference: keeping the same npub while rotating one compromised share requires an additional refresh / resharing story, not just baseline FROST signing.

So there are two separate questions:

1. Can we threshold-sign for this identity?
   • Yes, in principle.
2. Can we rotate a single share in place without changing the public identity?
   • Not from RFC 9591 alone; that needs refresh-capable protocol support and careful ops design.

§Integration options

§Option A: stabilize the current bunker first

• Keep v3 as a single-key NIP-46 bunker.
• Harden ACLs, audit logging, and client permissions.
• Lowest immediate implementation risk.

§Option B: move to a fresh threshold-generated identity

• Create a new Nostr identity through DKG / threshold setup from day one.
• Expose it through a NIP-46-compatible coordinator.
• Best clean-slate security posture.
• Tradeoff: new npub.

§Option C: same-npub threshold retrofit with share refresh

• Keep the current public identity.
• Add threshold custody plus future share refresh semantics.
• Highest complexity.
• Not something go-nostr or the current tenex daemon gives us out of the box.

§Go ecosystem read

Fact: bytemare/frost is a serious Go implementation with secp256k1 support.

Fact: current Nostr-native FROSTR product work appears concentrated in dedicated projects like Igloo, not in go-nostr itself.

Inference: we can likely build a Go threshold signer around existing FROST libraries, but we should not expect a drop-in “NIP-46 bunker backed by refreshable FROST custody” package today.

§Effort estimate

• NIP-46 bunker: low-to-moderate, already live locally.
• FROST-backed coordinator prototype: moderate-to-high.
• Production-ready threshold ops (DKG, recovery, resharing, revocation, auditability): high.

§Recommendation

Do not build custom threshold crypto.

Recommended sequence:

1. Keep the current v3 identity behind the new NIP-46 bunker immediately.
2. Decide whether same-npub custody is a hard requirement.
3. If no, plan a fresh threshold-generated v4 identity with DKG.
4. If yes, treat “share refresh without npub change” as a separate research/architecture track, not as a quick follow-on to the bunker work.

§Decision needed

The founder decision is not “whether FROST is good.” It is:

• Is a new threshold-generated identity acceptable once the bunker path is stable?
• Or is preserving the existing npub across future share rotation a hard non-negotiable?

That answer changes the architecture materially.