SIP-XXX: Standard Trait Definition for Commitment-Based Private Metadata (Encrypted NFTs) #250
Conversation
There was a problem hiding this comment.
@proofofgame Thank you for sending this PR, I think this would be an excellent addition. It is well written and already close to ready for the next step.
Overall I believe:
- The SIP meets the minimum bar for a standards-track proposal.
- Technical content is coherent, minimal, and well justified.
- With minor editorial tightening and one or two clarifying statements, it would be appropriate for formal consideration and community review under the SIP process.
Minimum additions or clarifications recommended before editor sign-off:
- Explicit relationship to SIP-009
- Add one short paragraph explicitly stating that this trait is designed to be implemented alongside SIP-009-compliant NFTs, not as a replacement.
- This avoids ambiguity for reviewers and implementers.
- Trait optionality clarification
- Explicitly state that get-owner-envelope is optional and that contracts may implement only the commitment interface.
- This is implied but should be stated normatively.
- Algorithm registry guidance
- While flexibility is good, SIP reviewers may request a short table or registry suggestion for algo values (even if non-binding).
- This can remain informative, not normative.
- Failure mode clarity
- Clarify expected behavior when no private layer exists for a token-id (e.g., return error vs. empty optional).
- You already recommend an error code; explicitly tie this to trait behavior.
Some global editorial notes:
- Capitalization is mostly consistent; keep section headers capitalized, but avoid unnecessary capitalization in prose.
- Reduce parenthetical overload where possible; move clarifications into short sentences.
- Prefer declarative, shorter sentences for readability.
- Replace passive constructions where clarity improves.
I did my best to mark specific ways on how to improve the SIP further, as much as possible with examples so hopefully you don't have to guess what I mean. Feel free to make adjustments if there is anything I misunderstood.
Overall quality is high. The proposal is clear, technically sound, and already close to SIP-ready. Issues are mostly consistency, minor grammar, and opportunities to simplify language without losing rigor.
sip-enft-private-layer.md
Outdated
| - **Status**: Draft | ||
| - **Consideration**: Technical | ||
| - **Type**: Standard | ||
| - **Layer**: Traits |
There was a problem hiding this comment.
I am not sure we need this "Layer" line. I see it in recent SIPs (31, 33, 34), but not in the older ones, and it looks like it is repeating "type". in all of these, including this one.
Example from SIP033
Type: Consensus
Layer: Consensus (hard fork)
This is not a question for the author more for the other editors/CAB's. Perhaps I am misunderstanding the purpose this "Layer" categorization. @wileyj what do you think?
When I see "Layer", I am thinking more along the lines of "Stacks (Bitcoin L2)", or "Stacks subnet (Bitcoin L3)", it would make it a future-oriented categorization field.
There was a problem hiding this comment.
Good point. I removed the “Layer:” field for now to match older SIP formatting; happy to re-add if editors prefer keeping it.
| Cryptographic commitments (hash commitments) and commit–reveal mechanics are widely used across blockchains and in on-chain games to prevent equivocation. Separately, some NFT ecosystems support “encrypted metadata” or off-chain private content patterns, but these are typically application-specific and lack a shared interface for wallets/indexers. | ||
| To the best of our knowledge, Stacks currently has no minimal, interoperable trait + event convention that standardizes a commitment-anchored private layer for SIP-009 NFTs. This SIP fills that gap by defining a composable trait and predictable indexer events, while remaining non-consensus and implementation-agnostic. | ||
|
|
||
| ## Activation |
There was a problem hiding this comment.
With SIP009 and SIP010 we had criteria for minimal adoption by a certain bitcoin block. So that we have some signal for adoption before activating the SIP. I suggest something similar here.
This SIP is activated when three contracts are deployed on mainnet that adopt the trait specified in this standard before Bitcoin block 1,000,000.
A trait that follows this specification is available on mainnet as...
From SIP009
This SIP is activated if 5 contracts are deployed that use the same trait that follows this specification. This must happen before Bitcoin tip #700,000.
A trait that follows this specification is available on mainnet as SP2PABAF9FTAJYNFZH93XENAJ8FVY99RRM50D2JG9.nft-trait.nft-trait.
There was a problem hiding this comment.
Thanks for the feedback on activation criteria.
I've thought about this carefully. SIP-009 required 5 contracts because it's foundational infrastructure - every NFT project needs it. This SIP is a specialized trait for a specific use case (private metadata), so adoption will naturally be more limited.
Proposed approach:
- Reference trait deployed (we can do this)
- At least one production/mainnet NFT contract uses the trait(s) exactly as specified in this SIP (we can upgrade/deploy a production contract for our eNFT games to match the final interface + events)
- At least one ecosystem integration - indexer, wallet, or marketplace demonstrating they can consume the interface
Criteria (3) is key: it proves interoperability without requiring us to convince other projects to implement a Draft SIP. An indexer parsing our events is independent validation that the interface works.
There was a problem hiding this comment.
That sounds reasonable to me. I like the approach. I would still like to see a time component. "...before Bitcoin block x."
proofofgame
changed the title
2 participants
Adds a draft SIP proposing an eNFT trait for commitment-based private layers (non-consensus). Discussion: https://forum.stacks.org/t/encrypted-nfts-on-stacks-a-standard-trait-for-commitment-based-private-layers-enft/18560