# Key Management

#### **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.<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.skullco.in/encrypted-nfts/key-management.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.