NFT SEP (via OpenZeppelin)

[naive agate]

Discussion and PR created for NFT SEP 🌟
https://github.com/stellar/stellar-protocol/discussions/1674
https://github.com/stellar/stellar-protocol/pull/1675
PTAL and comment on GH

NFT SEP (via OpenZepplin)

NFT SEP (via OpenZeppelin)

[frigid robin]

Super excited for this one!

[slow dagger]

@frigid robin Do you have strong opinions about NFT Metadata?

Like for instance, Opensea has a set of standards:
https://docs.opensea.io/docs/metadata-standards

Also, in terms of storing images on-chain, it looks like the SEP is currently leaning towards IPFS?

[frigid robin]

I really don’t, honestly. I’m just happy that this will bring more flexibility for developers, and ultimately, a better experience for end users. This is a great question for @finite igloo -- I’d love to hear his thoughts since he’s one of the top Stellar veterans on NFTs and the mind behind Litemint

[torn comet]

I know @raven tide and @worthy bolt had a couple draft NFT seps a little while ago. Would love for their feedback and thoughts, too

[raven tide]

My proposal was not original since I used the open zeppeling ERC721 interface for my implementation. I think @worthy bolt wanted to add compatibility with metadata of sep 39, the classic NFT standard, plus enforcing royalties in the interface.
At the time I remember that there was some objections about mimicking the ethereum standard while we had something with sep 39 already.
For example, I find it strange the way set_approval_for_all is working because, I suppose, this is how nft marketplace on ethereum was working (?). You approve the control of all assets owned by an address.

[worthy bolt]

Yeah im writing a reply and referencing the one u and me worked on vinamo i had it ready to post and my laptop died lol

But ill post shortly

[torn comet]

Yeah, I was confused by set_approval_for_all, too. I wasn't very familiar with ERC721 before a couple weeks ago, though. I'm trying to think if there's another use-case, besides NFT marketplaces, where the approval concept is necessary. Would that be something that's better left as an "implementation detail" or something?

I suppose the marketplace-ing of NFTs has become somewhat "essential" to the user experience, though? or, maybe that's more true for the image NFTs that are often just speculative assets?

[arctic rapids]

We can think about the "approval_for_all" as a convinient way to assign a manager to all your NFTs instead of doing that one-by-one. A parallel with fungible tokens could be setting a MAX (infinite) approval. So besides marketplaces, I suppose there many other valid cases for it.

[raven tide]

I see how this could make sense in a game for example where you delegate your collection, the game manager can then sign the TX for you, not sure if such a thing exists though.
Or more generally you can delegate your collection when using WebApp to manage your collections, if most actions would require an approval this would be a bad user experience

[slow dagger]

Has Fred from litemint been looped into this discussion?

Any thoughts @finite igloo

[finite igloo]

Yes, I did not jump in earlier because I realize from past discussions (e.g. Phoenix was working on a similar standard) that my take on this topic differs from everyone here 😁 But always happy to articulate my opinion again, I believe an NFT standard is inadequate for Stellar.

I came across this proposed vision for ledger programmability a couple weeks ago (apologies for the XRPL ref) but that summarizes where I am coming from:

Anti-objectives :

• Being exactly the same as some existing design (at the expense of what is best for the XRPL)
• Replacing XRPL’s existing building blocks with smart contracts (its primitives are a key selling point)

Basically, we should not be copying Ethereum when it is done at the expense of what is best for [Stellar], and that would typically be the case here. Ethereum and Stellar designs are strongly contrasting when it comes to asset issuance because of the Stellar first class asset model.

To be specific, on the key points from this NFT SEP motivations:

• making it difficult to ensure interoperability between different NFT contracts and applications.

This initial statement is incorrect. Every asset issued on Stellar is de facto interoperable (first-class citizen) with all services and wallets i.e. transferable, tradable everywhere—unlike contract-based issuance.

• SAC is mainly designed for Fungible tokens

Likely incorrect too. Stellar assets non-fungibility is modeled via the properties (unique, locked supply) of a unique class so unlike on Ethereum with ERC20 vs ERC721, Stellar design is fully agnostic to asset fungibility—again, all assets on Stellar enjoy the same primitives.

• Metadata handling, Permission controls, Customizability

These features can also be achieved by decoupling asset issuance from the contract, unlike Ethereum forced into coupling by-design, specifically:

• Metadata handling: The best for [Stellar] is to standardize Soroban data storage, not to import the ERC721 issuance model. Standardizing on-chain storage would preserve the ability for decoupled issuance and keep the ability for Stellar to treat assets as first-class abstractions.

• Permission controls: I reckon it is not perfect (especially in regards to intuitiveness) but here is an example of decoupling for royalties avoiding the limitation and pitfalls that come with adopting the Ethereum model (points also discussed in my blog).

So I agree that we're missing some crucial tools but these shortcomings require ad hoc solutions and/or adequate protocol updates making it more intuitive for developers on our use cases—not juxtaposing an ERC721-based standard.

• Transfers & ownership

As said earlier, Stellar assets already enjoy full interoperability along with strong security guarantees—this quality is fully reusable with decoupling. NFT standardization efforts should be aiming at that imho.

On a positive note, I am always glad to see more NFT related efforts on Stellar, but not at the cost undermining its core design and importing serious long-term issues which Ethereum as yet to solve.

[raven tide]

I remember some talk about being more stellar oriented but never been able to get it right.

I wonder if we could build the following contracts:

• The NFT token is a SAC that cannot mint() more than one unit, (maybe it could burn)
• The token is emitted by a parent contract that would represent the collection.
  The mint() function would deploy the NFT Token contract. This parent contract could
  be the admin of the NFT Token contract.

The benefits I see with this model is that the NFT Token could have its features/functions
for itself, avoiding the burden of resource management at the collection level.
Also, it allows the NFT to be fully identified on the ledger rather than being an id within
another contract.

[naive agate]

I hear you @finite igloo. What about NFT use cases that require full programmability? for example subscriptions (think SorobanDomains registrations as NFTs) or AMM positions (Uniswap V3, for example represents positions as NFTs)?

(BTW, I don't think it's the end of the world if both types of NFTs to co-exist in the Stellar ecosystem)

[torn comet]

I'd also be curious about @finite violet input on this. Skyhitz is music NFTs, but NFTs nonetheless

Anybody know who's behind 8888zone (i think it used to be stellar skulls, or maybe they're just related projects)? seems like they're the first NFT marketplace that's been on soroban, so they might have some insights worth sharing

[finite violet]

Thanks for the ping, @torn comet. From our perspective, we didn’t follow any standard because the technical constraints outweighed the benefits. Seeing Open Zeppelin work on this SEP confirms we took the right approach! We just store the metadata hashes in our contract, which has worked really well so far. By the way, I love the idea that NFTs could represent positions in the market (like a 2x leverage long on XLM) it makes it super interesting.

[finite igloo]

If this was a quick design decision for a specific project, I might agree—but this is a standard. An NFT standard for Stellar should prioritize building on Stellar strengths, before defaulting to a misfitted Ethereum-imported design.

On a side note, I believe uniswap V3 is in fact embracing a more decoupled model i.e. their pool/pair contract is no longer an ERC token. Luckily, Stellar could do that by default, that's unless it decides to standardize/promote an import of ERC-721 as best practice 😉

To draw a better analogy, it’s like having a modern promise-based system (Stellar) only to direct developers into callback hell, when the right approach would be to implement and standardize syntactic helpers like async/await—easing the use of a more abstracted (harder to grasp) yet future-proof, and fitted system.

To be clear, I’m not saying that mingling contract-based issuance is never necessary. But unlike on Ethereum where there is no choice, an NFT SEP for Stellar should be prioritizing a design that first leverages its core—then fallback to an ERC-721 model if needed. Right now the NFT SEP is not just doing the opposite, it is also dismissive to the best fitted approach for Stellar, and fails to make sure devs understand problems with such juxtaposed issuance in regards to interoperability, fragmentation and ownership on the network.

[echo jackal]

To draw a better analogy, it’s like having a modern promise-based system (Stellar) only to direct developers into callback hell, when the right approach would be to implement and standardize syntactic helpers like async/await—easing the use of a more abstracted (harder to grasp) yet future-proof, and fitted system.

I would use another analogy from the JS world: the failed Deno/Tauri way.

I really like using Deno, specially because of their focus on security and native TS support... But the Deno team failed at something important from the start: thinking that a small project can tell others what to do once they are already used to it, and that was their npm approach because they said it was not the best for Deno. Not being able to support what everybody in the ecosystem is used to meant that Deno was almost dead from the start, that's why with 2.0 they now support more stuff everybody is used to (The Tauri team made a similar mistake with their "we are not shipping chromium with our apps").

Stellar is not in a position to tell the rest of the ecosystem: "we think we have a better approach for our network", because Stellar is a tiny portion of the ecosystem and the truth is that after more than a decade, the Ethereum approach won and they set the standards, if we want to import devs from there, then we need to support as much as possible the "way" they do it (even if we think is not the best approach on Stellar). Once we have a big enough market base is when we will be able to start setting different approaches, until then we need to support the way they do if we want to attract their devs (which is what Deno is doing now)

I agree the async/await case is valid... but we are nowhere like their position because that approach was designed for the whole javascript ecosystem by the "rulers" of the ecosystem while Stellar doesn't set the standard for the whole blockchain ecosystem since we don't have enough market power.

Regarding the SEP, I like it but I would also love if it defines the ledger keys the contract could use (not all of them but at lest the important ones like the owner). The reason is because if everybody is free to se their own keys for the storage, then we will end up at a similar position than TOML files for keys that are not standard: consuming them without the "API" is going to be a nightmare similar to how already is a nightmare to consume both SAC and Soroban assets for accounts using the RPC.

Using the balance method (which what I call the API since the contract returns that data) thru the simulation might be ok for one account (one call to the RPC)... but there are many cases where that's just not efficient (a wallet that has many accounts, a server that consumes balances from multiple accounts, a aggregation service, etc) and it's better to get the ledger keys directly. But we already have the issue that for accounts' balances we need to decide if we need to get the trustline ledger data or the "Balance" data from the contract based on the type of user AND the type of asset which it adds complexity because each option has "ifs" on them (smart wallets for example)

I would like to avoid that type of burden because something I have heard multiple times from devs that are coming from other chains is the phrase "stellar has too many nuances" and if they already have issues with understanding the differences between using horizon and the rpc to get balances or even understanding what the source account is, now imagine if on top of that we also add the differences in the ledger keys

[finite igloo]

DeepSeek—and many others—would disagree. But more importantly, what I am discussing here isn't about "setting the example for everyone else", as per my initial quote, it's about doing what's "best for [Stellar]". Whether Stellar fails to lead in our use case is a whole other debate entirely which poor design choices will only be self-fulfilling.

Now to illustrate with another crucial point from the Uniswap V3 whitepaper:

In Uniswap v1 and v2, the pool contract is also an ERC-20 token contract, whose tokens represent liquidity held in the pool. While this is convenient, it actually sits uneasily with the Uniswap v2 philosophy that anything that does not need to be in the core contracts should be in the periphery.

Stellar has a unique opportunity to avoid the industry past mistakes with its fully interoperable, decoupled, first-class citizen assets model—instead it would choose to prioritize and standardize a coupled issuance model that even leading Ethereum protocols are trying to move away from. At the very least, it should not be set as the priority model in a Stellar(!) standard. I strongly remain unconvinced that this approach isn't shortsighted 🙏

[echo jackal]

That's my point, that Tauri and Deno failed at the start because they focused on what's "best for [Stellar]"([Deno/Tauri]) instead of supporting what the rest of the ecosystem is used to, which they finally accepted.

Uniswap v3 literally ditched ERC20 to adopt ERC721 (which is what this SEP is using as a base) and Deepseek is on an industry that's basically brand new so I think is not a valid example because ERC721 is ~7 years old while deepseek got popular by a model they launched months ago

[finite igloo]

I believe you misunderstood what Uniswap is talking about. Their comment is about moving from the V2 inheritance model (their pair contract is-a ERC20 specialization) to their V3 contract being an aggregation i.e. tokens can now exist without the aggregate (pool). What they highlight is not the type being aggregated—it is the decoupling.

Unfortunately, besides importing a concrete type over a Stellar abstraction, this SEP promotes the V2 model (e.g. the onchain storage use case mentioned in the SEP should be aggregate instead of being an ERC721 itself, leading to many issues I mentioned above). Hope this clarifies.

[lost onyx]

I understand @echo jackal's position from a pragmatic point of view (and dev acquisition) but I really have to support what @finite igloo is saying. We (meaning Stellar) have a rather different (some might say way better) tech stack than EVM. I do not think we need to align with how EVM/ETH does things. We should analyze, consider improvements and then enhance based on Stellar's unique features and capabilities. Unless we want to spend 5years for "research", feature upgrade and implementations 🤣 . You can check sentiment on devs (core and others) from EVM/ETH ecosystem ... not that great.

Would this create friction for Eth devs? Yes. But even at its core, you can't compare using Rust with using Solidity.

As for Deno... well, I don't think anyone better than the creator of Node to have an opinion on how things could have been better. Was it the right call? I don't think he loses much sleep over that question 🙂

[echo jackal]

2.0 is he and his team accepting that they failed and they needed to embrace what others are used to if they want to have at least a really small market share.

[lost onyx]

If you are talking about supporting npm packages... well, they also run a business, that doesn't make it a great tech decision anyway 🙂

[echo jackal]

relying only on having the best tech decision was the reason they failed... Sometimes you need to accept that you need to support something that you might think is bad tech if you want to have market share. I really hate commonjs and I want it to disapear because is a cancer for the javascript ecosystem and it's been abandoned for more than a decade... But I still support it because not supporting it is shooting myself for no gain

[lost onyx]

I agree on that, but that's a business decision. And I think this thread is more on the tech/impl side for the NFT spec?

[echo jackal]

The point is: having a soroban standard for NFTs that is similar to what the rest of the blockchain ecosystem is used to

basically accepting the "bad tech" in pro of bringing more devs that are used to that standard

[lost onyx]

Ford would agree with you, but I'd rather have a Lambo 😉

[echo jackal]

Do you have the lambo? No, just like we don't have devs

that's the point

[lost onyx]

KALE would disagree with you 🤣 2 devs? Tyler and Fred maybe? How many "users" deriving in over 200k transactions? (if we are talking network as a whole I mean)

Jokes aside, I guess things will progress into how you see things. This is the way that happens with standards so I wouldn't be too stressed about it.

But, having said that.. I would really love to have all Stellar standards leveraging Stellar's unique capabilities.

[echo jackal]

What "unique" capability is not being used in a dead simple NFT standard?

[lost onyx]

👆 -- I defer to the guy who really knows his NFTs 🙂

[finite igloo]

I would actually say that standardizing the use of (quoting) "bad tech" to [hypothetically] bring more devs is the opposite of pragmatism. Standardization should be based on solid frameworks, not on ifs and buts. Unless discussing a marketing paper (I hope not), focus should be on real matters like long-term robustness, security, backward compatibility, adequation and strong interoperability for our use cases.

[lost onyx]

I actually used "pragmatic" in that sense more like "marketing", but I just did not want to use that word 😉

[lost onyx]

Ah... sometimes "standards" are really put out just because of this "...a marketing paper", but I don't believe that's how Stellar does things! (Thankfully!)

[carmine elm]

LFG

[arctic rapids]

Hey @finite igloo
You bring up some great points, so we’d love to clarify some aspects and hear more from you about that:

1. Interoperability
   While Stellar’s first-class asset model ensures interoperability at the asset layer, there’s still a gap for interacting with NFTs in a standardized way on a contract level. Without a common contract interface, different projects may implement their own custom solutions. Another point is that it becomes harder to build general-purpose NFT tooling.

2. Asset issuance vs. contract-based models
   We completely agree that SAC isn’t inherently restricted to fungible tokens, but today, using it for NFTs requires additional off-chain work or custom contract logic. The SEP aims to provide a more structured way to manage metadata, permissions, and interactions without forcing everyone to reinvent the wheel. It isn’t necessarily about coupling asset issuance and contract logic but rather to provide a standard way for contracts to interact with NFTs. Btw would you see value in some sort of an extension that leverages the classic assets' issuance model while making contracts easier to compose?

[finite igloo]

Thanks for the response.

Even at face value, I think this SEP is failing to highlight that builders have to forgo key features of Stellar, besides new complexity and interoperability challenges:

• NFTs lose access to native primitives (e.g. cross-currency payments, liquidity...). Builders will not be able to tap into these layers without building and/or relying on non-native services.

• Using non-native asset identifiers breaks uniformity with current native ids ISSUER:CODE/SAC-ADDR, bringing more complexity for builders and confusion for end users.

• No backward compatibility with the current Stellar ecosystem and marketplaces. Bridging the gap requires major development efforts for stakeholders.

• No support for SEP1 likely means non-trivial discovery and indexing (event based?).

Key limitations that should be highlighted in the SEP.

But as I mentioned, this SEP also overrides the native Stellar asset abstraction with a non-native concrete type, and you touch an important point with this question:

Btw would you see value in some sort of an extension that leverages the classic assets' issuance model while making contracts easier to compose?

This is what the SAC (maybe it lacks anything crucial?) does:

• enables classic assets in Soroban while preserving their nature (a syntactic tool).
• avoids all issues listed above.
• provides native aggregate capabilities to smart contracts.

The Uniswap V3 pool contract would be a typical example of customizability and transfer control, not having the aggregate as the token itself that would leverage the SAC. I think we should rather encourage blueprints like this on Stellar as this model is more flexible for more use cases than ERC-721 e.g. custom NFT collections...

And for metadata handling, a dedicated Standard, not mingling issuance, could serve all token as well, incl. SEP-41 and classic, many metadata-dependent assets are still expected to be issued via classic/SAC.

[torn comet]

As always, really helpful insights @finite igloo! I've got some questions about how I'm conceptualizing things:

I'm curious how this would play out (on Stellar) for the kinds of NFTs that became so popular back in 2021-2022. I'm thinking of the kinds like Bored Apes, CryptoPunks, etc. If I understand them correctly, each Ape can be thought of as a unique "version" of the same underlying token (that might not be an exactly precise characterization of it). It's one contract, but each one has a different background color, mouth shape, accessories, etc. Then, the token itself that is owned by a user essentially corresponds to the ID of the "version" they own.

• How does that kind of model work currently in Stellar? I think Litemint (which is probably fairly representative of how the rest of the ecosystem does things) creates a brand new asset/issuer pair for each of the "versions": BoredApe01:GA..., BoredApe02:GB..., etc. With the correct trustline limits and/or amounts minted, those truly are non-fungible and indivisible. Each of the "versions" of the NFT then would have its own corresponding SAC that can be used to transfer, approve, burn, etc. the token. (Is that maybe cost-prohibitive? Having a single-purpose SAC for just a single stroop of a locked asset?)
• How could this work now that we've got smart contracts? As you've pointed out pulling all the issuance out of the "classic" realm and putting it exclusively in the contract will give up some really beneficial ecosystem compatibility. Representing smart-contract-only tokens isn't yet thoroughly present in the ecosystem and will likely require some pretty major changes/work across a wide variety of teams and projects. In a "perfect" world, do you think an NFT contract would/could act more as a "collection manager" or something (maybe more like ERC1155) that kinda "wraps" the relevant SAC functions for each of the issued assets? Does that "collection" NFT contract then become the Admin address for the respective SAC contracts so it can control mint, clawback, set_authorized, etc.? In the example of bored apes, could this also be somewhat costly? At least 1.5 XLM for each issuer, right? (2 base reserves for the account + 1 for an ipfs manageData entry) If you wanted to save some by issuing the NFTs from a single account, then you might hit the account sub-entries list (max 1000), depending on how many NFTs you're trying to create.

Sorry if that doesn't make sense. Trying to wrap my head around ERC721 and refresh my Stellar NFT memory at the same time! Concepts are getting mixed in my head perhaps 🤣

I know bored apes, cryptopunks, etc. are far from the only kinds of NFTs. They've just been top-of-mind for me as of late, and so that's been framing a lot of my thinking

[finite igloo]

Yes concretely, a typical setup would involve deploying SAC for NFT assets and, depending on specific requirements, configure admin, lock asset issuer.

Basically, in this model the aggregate contract implements customizability, permission control, transfer, ownership just like in the SEP but not being a concrete asset contract itself makes a huge difference with issued NFTs staying compatible with all services and implementing SEP-1 (stellar.toml). Similar to Uniswap V3 model with a key difference, soroban supports this natively! Standardization across the ecosystem (still ideal) does not have to become sine qua non for assets.

Important also, we are not breaking the abstraction—if creators require fungible assets, this design works seamlessly, whether issuing dao tokens, in-game coins, event tickets, a limited edition of 100 comic books, or 1/1 art piece.

In my view, an NFT standard on Stellar should rather focus, not on the issuance (contracts don't need to be an asset to address NFT use cases), but on surrounding utility, like royalty payments, collection management etc. For example, we could standardize a dedicated hook-system à la Uniswap V4, Soroban has the most robust cross-contract call system out there allowing a transfer to delegate royalty payments to a marketplace contract or execute an auction, essentially adopt a modular approach rather than the rigid ones Ethereum is already evolving from.

On the cost, back in 2021 we helped a creator deploy 10,000 NFTs see this tweet , distributed them across several issuer accounts to comply with TOML size and sub-entry limits. The overall cost was 5,000 XLM (which included distribution accounts and trustlines).

[torn comet]

Thanks for the response! Are you able to share which project that was with 10,000 NFTs? I'd love to poke around the assets and see how it all works together

[finite igloo]

Looks like their website/toml is down now, that was one of their accounts address