search

Key Management

hashtag
Our Approach:

Phase 1 (Current): Launch with Hybrid model

  • Optimized for Stacks/Clarity

  • Fast iteration, proven UX

  • Escrow contracts mitigate delivery/dispute risk

Phase 2 (Planned): Add Fully On-Chain options

  • Fully on-chain re-encryption proofs on networks that support them

  • Backwards-compatible at the asset level: existing NFTs can keep their identifiers within a given chain/contract, while adding a new verification/reveal layer.

  • Optional: users choose Hybrid (cheaper) or Fully On-Chain (trustless)

Design principle: Build modular from day one so migration doesn't break existing assets.

Key Management:

Wallet-derived keys (recommended):

  • Encryption key derived from wallet seed via BIP-32 path

  • No extra seed phrases to manage

  • Import wallet → encryption key auto-restored

  • Path example: m/44'/5757'/0'/0'/1' (Stacks coin type 5757)

Key server (convenience mode):

  • Third-party holds encryption keys

  • Authenticated via wallet signature

  • User signs challenge → server decrypts → returns plaintext

  • Trust trade-off for convenience

Client-side (maximum security):

  • Generate encryption keypair locally

  • Store in browser secure storage or hardware wallet

  • Full control, but key loss = cannot decrypt

Security Model:

Threats:

  • Server compromise (Hybrid model)

  • Front-running (transfer races)

  • Seller withholding re-encryption / key transfer (fully on-chain variants): mitigated via atomic transfer + proof-verified key switch, or escrow with deadlines/refunds.

  • Buyer claiming "secret was wrong" post-purchase

Mitigations:

  • Hybrid: Escrow smart contract (seller must provide valid ciphertext or payment refunded)

  • Fully On-Chain: ZK proofs eliminate trust (contract verifies consistency)

  • Front-running: Time-locked commits (commit txn, reveal after block confirmation)

  • Disputes: Hash(secret) published at mint, verifiable post-decrypt

Disclosure by choice: Players can share secrets voluntarily. This is intentional:

  • Teams can pool information

  • Markets emerge for "leaked" secrets

  • Social dynamics (who do you trust?) become part of gameplay

Not a bug, a feature: Information markets require voluntary disclosure.

Why This Matters:

eNFTs are the first practical way to run honest incomplete-information games on-chain. Prior attempts:

  • Dark Forest (zk-SNARKs) → bot wars, too complex

  • Traditional NFTs with "hidden traits" → revealed on-chain, not truly hidden

  • Off-chain game servers → not verifiable, requires trust

Confidentiality boundary: commitments guarantee integrity; confidentiality depends on encryption + key delivery. Treat all URIs and off-chain payloads as untrusted inputs; wallets should sandbox previews and warn on external links.

PreviousImplementation ArchitecturesNextUse Cases

Last updated