Goal is to create the same covenant value onto KRC721 NFTs. With KCC721, NFTs become utxo-native, enable covenant features for added utility, and also atomic batch transfers to include multiple NFTs into one tx. Limit seems to be around 22 NFTs until compute mass limit is reached.
It’s an early draft but functional. The GitHub also contains a link to a test page on mainnet showing KCC721 in action. We hope to encourage further discussion and development as we believe KRC721 needs an enhancement the same as KRC20 does.
I read the repo before writing this. Solid work: validateOutputStateWithTemplate is doing the same job KCC-1 §8 assigns to template-hash imposition, the Merkle one-time issue is clean, and the 50,000,000-sompi minimum cell puts a real number on state cost. The mainnet demo puts this ahead of most drafts on evidence.
One structural suggestion, offered as convergence with the merged drafts rather than critique. The v2-nft transfer path hardwires the owner check to a P2PK. KCC-20 faced the same fork and landed on a scheme-tagged owner field — schnorr-key/v1 (0x02), covenant-template/v1 (0x03), covenant-id/v1 (0x04) — so a state’s owner can be a key or a covenant lineage without changing the transfer entrypoint. Porting that one tagged field to the NFT state makes NFTs covenant-ownable at the cost of a byte of scheme tag plus the owner payload: escrows, pools, and settlement covenants could then hold and release NFTs under the same authority-scheme table the fungible side already standardized. I posted a proof-gated instance of covenant-id/v1 ownership in the KCC20 specification thread today; that entire profile applies to NFT states verbatim the moment an owner scheme exists to name.
On the 22-NFT batch ceiling: block mass is per-dimension post-Toccata — storage and compute at 500,000 g each, transient at 1,000,000 g (params.rs) — so the batch limit is specifically a compute-dimension property of the transfer program. Publishing the per-NFT compute decomposition alongside the demo would turn the ceiling from an observed wall into an engineering number.
Process thought: kccs.dev currently indexes 0, 1, 2, and 20. A PR to kaspanet/kccs would get this a real number and the structured review it deserves. Happy to help with conformance vectors when it goes in.
I’ve been looking at KCC721 for an upcoming NFT project and wanted to raise a potential issue with globally unique tickers.
A creator normally needs to publicly announce and market an NFT collection before minting begins. Under the current first-valid-genesis rule, doesn’t revealing the collection name/ticker create an opportunity for somebody else to deploy that ticker before the creator?
This becomes particularly problematic for artists announcing future collections or a roadmap, because somebody could reserve those tickers simply to squat them.
Since KCC721 collections already have a unique Covenant ID, could the Covenant ID instead be the canonical collection identity, with ticker/name treated as non-unique display metadata?
I noticed the KCC-0021 metadata discussion arrived at this model for covenant assets — Covenant ID as canonical identity and names/tickers as non-unique claims.
For example, two collections could both display as GHOST while wallets and marketplaces distinguish the official collection by Covenant ID, creator and verification.
Is there a technical reason KCC721 requires globally unique tickers rather than following that model?
Im not a technical person, so I don’t know if this is possible or compatible with the standard being developed here, but there a unique implementation which stores images on-dag rather than utilizing centralized ipfs platforms. I think this is in line with the Kaspa ethos and should be considered.