> For the complete documentation index, see [llms.txt](https://docs.skullco.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skullco.in/encrypted-nfts/implementation-architectures.md).

# Implementation Architectures

#### **A)** Hybrid: Off-chain Secrets + On-chain Commitments

*Current implementation on Stacks blockhain*

**Storage:**

* **Off-chain:** encrypted payload (or encrypted “envelope”) stored on a controlled service (DB/object storage).
* **On-chain:** commitment = `H(payload_bytes)` (or `H(ciphertext)`), plus optional metadata (algo/version/mime/size).

**Access / Reveal**

* Client signs a request (wallet signature).
* Gateway verifies **current NFT ownership on-chain**, rate-limits, then returns the encrypted bytes (or a short-lived URL).
* Client verifies: `H(received_payload) == on-chain commitment`.

**Answer verification (example: Seed Phrase Hunt)**

* Canonical answer stored encrypted (or as `H(answer||salt)`).
* User submits answer → server checks correctness without publicly revealing plaintext (e.g., compare hashes/HMACs; or compare deterministic transforms).

**Pros**

* Fast UX, low cost, chain-agnostic.
* Strong integrity guarantee: server can’t “swap the secret” after mint without being caught.

**Trade-offs**

* Availability and access control depend on the service (not fully trustless).
* Privacy is off-chain (keys + delivery must be protected).

***

#### B) On-chain Commitments + On-chain “Claim” + Off-chain Key Release 

**Idea:** keep payload encrypted off-chain (or even on-chain), but move *the “right to reveal”* and *the audit trail* **on-chain**. The secret is only unlocked when an on-chain condition is met (ownership + event + optional payment/proof).

**Storage**

* **Option 1:** ciphertext stored off-chain; commitment on-chain.
* **Option 2:** ciphertext stored on-chain (if small enough); commitment still on-chain.

**Unlock flow**

1. Owner calls an on-chain function: `claim-reveal(token-id)` (or `start-reveal`), emitting an event.
2. Backend watches chain events and releases the decryption key (or envelope) to the owner **only after** seeing the on-chain claim.
3. Client decrypts locally and verifies commitment.

**Pros**

* More “protocol-like”: reveal attempts are publicly auditable.
* Stronger fairness for games: unlocks can be conditioned on on-chain actions (fees, deadlines, proofs-of-participation).
* Still much simpler than ZK reencryption proofs.

**Trade-offs**

* Still relies on a key release service (or MPC network) for confidentiality.
* Requires indexer/event listener reliability.

#### **C) Fully On-Chain (ciphertext + proofs on-chain)**

**Storage:**

* Ciphertext stored directly in contract storage
* Master encryption key encrypted under owner's pubkey
* All data verifiable on-chain

**Transfer flow:**

1. Seller re-encrypts master key under buyer's pubkey
2. Seller generates **ElGamal re-encryption consistency proof** (ZK proof)
3. Seller submits new ciphertext + proof on-chain
4. **Contract verifies proof:** "new ciphertext contains same master key"
5. If proof valid → transfer proceeds, payment released
6. Buyer decrypts master key with private key → decrypts secret

**Proof verification:**\
`verify_reencryption_proof( old_ciphertext, new_ciphertext, old_pubkey, new_pubkey, zk_proof ) -> bool`\
\
**Pros:**

* Trustless (cryptographic guarantees, no escrow needed)
* Maximum auditability (everything on-chain)
* Prevents seller cheating (can't provide fake secret)

**Cons:**

* Higher gas (proof verification + storage)
* Requires chains with EC operations + ZK precompiles 
* More complex implementation


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.skullco.in/encrypted-nfts/implementation-architectures.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.