NFT Interface Proposal (erc-721)

[trail cedar]

@lone orbit and @heavy wedge are proposing an interface for NFTs on Soroban, similar to ERC-721, to standardize the way applications interact with NFTs.

Calling everyone to discuss the interface. Leave your comments in this thread or directly on the pull request.

https://github.com/stellar/stellar-protocol/blob/d977961f61e0545287591c296bf5392d225a5be7/contract/sep-nft.md

[heavy wedge]

@wet rampart @sour crypt

[wet rampart]

I am not technical enough to contribute at that level, however I really do think as a community we will be much stronger if we agree and set standards to work on, and from that popint of view this makes a lot of sense. My shortcomings are not understanding the issues (if any) of erc-721 and whether/how to improve on them if required...

[heavy wedge]

Something dymtro said today got me thinking. I wonder if its feasbile i can find a way that my collection interface can act sort of like a sac proxy for the original erc721 implementation from @lone orbit the thing is i am wondering how i could identify the address correctly for calls like balance or transfer there isnt like a metadata field or any data field

If this concept makes sense. Itd be easy to make a extension to the first erc721 that would be a single proxy though. Only collections would need metadata. Imagine then we could have the minimalist implementation and then a user could choose if they wanted sac interop or not

[wet rampart]

Hey - just adding an update as per request from @regal shard - for us, the importance of creating a classic asset and then wrapping it is really important for a number of reasons - but primarily my biggest concern is that if we use Soroban assets we are dependent on all the wallets out there updating to show Soroban assets inc. dealing with specific use cases in order to show (example) our TBM NFTs.

This IMO will be a nightmare and just end up with a more fratured community with different providers assets living in silos - and so because of this our current approach is we must start with a classic and wrap - it means all assets we create are instantly visible in existing wallets (perhaps not with the image displayed correctly but thats window dressing), they will not be able to trade the assets from inside the wallets (unless they do Soroban integration work) but overall this is a massive boon for me in terms of easy compatibility in the community

[visual meadow]

I also have a hunch that interop for NFTs should live on Stellar, whereas additional functionality can be enabled on Soroban. I'll work on informing myself better over the coming weeks, because I'm not in a great position to contribute to this discussion as it stands.

I guess my first question would be: what's the advantage of having an ERC-721 inspired interface over the interoperability that Stellar assets already offer? Aren't the Soroban-native NFTs that we've seen so far been highly project-specific?

[lone orbit]

It's interesting to question this need, as @smoky kelp said yesterday, where is the requirement?
If we check eip 721 we can see

Motivation
A standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum. We provide for simple ERC-721 smart contracts as well as contracts that track an arbitrarily large number of NFTs. Additional applications are discussed below.

This standard is inspired by the ERC-20 token standard and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).

Differences between this standard and EIP-20 are examined below.

Now we can wonder if stellar will face the same issue on the NFT tracking.

One point on adopting this kind of standard already in place is that most users know about it. At least this is a starting point.

[heavy wedge]

was researching that last night about difference between erc20 and 721 and rather why 721 was created.

appreciate the perspectives!

[sour crypt]

As I mentioned yesterday on Stellar Global, I am not in favor of an ERC721-like standard on Soroban/Stellar and here are some important reasons:

Inappropriate Paradigm: Ethereum employs an account-based model which necessitates the creation of contract interface standards like ERC20, ERC721 for modelling third party asset issuance. This is due to assets on Ethereum not being first-class citizens and requiring tracking ownership via smart contract data, i.e. an unsophisticated mapping system which also poses all sorts of challenges (e.g. state expiry, royalties...).

Stellar, in contrast, provides a practical and robust asset issuance layer hence importing the flawed Ethereum model for standardizing NFT issuance on Stellar seems inappropriate in most cases.

While I don't rule out some use-cases for Soroban-based NFTs, I think a standard, more so an Ethereum-based one, is counter-intuitive for builders and may lead them to produce many improper and limiting implementations.

**Loss of Interoperability: ** Stellar treats third-party assets as first-class citizens, resulting in de facto global interoperability.

For example, hardware wallets like Ledger currently allow Stellar users to bid, offer, sell, auction and generally interact with any NFT issued on Stellar without necessitating our apps/contracts to be greenlit/whitelisted/integrated by the Ledger ecosystem, or worse, requiring our users to engage in risky blind-signing transactions.

NFTs on Stellar are fundamentally Stellar assets and inherently integrate with these services. The need for a standard to issue NFTs has been unnecessary on Stellar to achieve such global interoperability on the ecosystem.

By contrast, Soroban-based assets are isolated from any service by default, unless the service explicitly supports a specific interface.

**Isolation from SDEX: ** Soroban unfortunately does not support SDEX operations. I think this is unfortunate because this could turn the SDEX into the first and biggest L1 price Oracle in the industry.

Importantly, Soroban-based assets being isolated from the SDEX means they cannot benefit from L1 discovery mechanisms across markets (paths) nor can they benefit from SDEX interoperability for market execution and overall trade operations.

This can drastically limit sales funnel and end-user options, important points to consider before deciding the issuance method for NFT assets. For example, Opensea, talking about their infamous struggles with on-chain royalty payment enforcement, explained on their blog that lack of interoperability is what “limits their [creators and collectors] sense of control over where their collections are sold."

Issues with Royalties Payment Enforcement: As mentioned above, major marketplaces like Opensea attempted and failed to standardize NFT payment enforcements because their solution (on-chain operator filter) required the whole Ethereum ecosystem to adopt a specific interface for NFT issuance, which did not happen. They are reverting to optional royalties.

Stellar, however, does not inherit these issues and it is my belief that we should leverage Stellar's tried-and-true method for issuing NFTs (classic) and utilize Soroban smart contracts for tasks other than modeling these assets. It feels like coercing Stellar technology.

This being said, it may be important to precise that if a consensus is reached on a Soroban-based NFT standard with widespread adoption potential, I would be okay to support it across the Litemint platform. However, my preference is clearly to encourage builders to design solutions that align with Stellar's inherent paradigm, which offers better futureproofing, security, interoperability and leverages Stellar strengths appropriately.

[lone orbit]

Supporting already existing NFTs on stellar within soroban would be very nice.

However, it seems to me that some features are missing for soroban to fully interact with the current NFTs.
The fact that when you wrap a stellar asset to soroban, you have one contract instance for each asset which makes
it more difficult to manage a collection for example. We cannot mint a stellar asset from soroban.
Maybe an approach where we could wrap an account would be easier to handle, possibly this account would not be usable
in classic, only its effects could be visible. (i.e. once wrapped, the signers are changed to be the wrapped contract).

We could then create assets that are both soroban assets and classic.

(Just putting it here as it comes to my mind, didn't think it through all implications)

[heavy wedge]

A big concern is soroban nft discoverability it seems. Just to point out i've proposed SEP0042 to help deal with this https://discord.com/channels/897514728459468821/1162558946867953704

We are still reviewing and working on the proposed interface standard and it's on github

also want to point out that this proposal in no way aims to discourage the use of "classic NFTs" It is rather our hope that by providing some blueprints it will help developers make their contracts have easier interop with other dapps like marketplaces and wallets

[heavy wedge]

One thing i'm trying to find a solution to with The Blue Marble is making classic assets be governed by soroban contracts; for the purpose of enforcing royalties. Right now my initial thought is to use set_admin to set the admin (on a SAC, after wrapping) to a proxy contract that handles transfer auth, but i'm still researching the matter.

[heavy wedge]

@lone orbit @sour crypt @trail cedar @wet rampart @analog pollen @karmic gust

I'm circling back on this, I've been asked if we developed an nft standard for soroban a couple times, and I remembered we had started talking about it here; but I don't think anything ever became of it. Since a number of months have passed and i know some of you have built nft projects in soroban, i am wondering if you can provide some guidance about what you did, and if you think we could develop a standard off the things you've built.

I also found this https://github.com/taskdotio/soroban-nft-royalties from The Blue Marble, which could be helpful

[wet rampart]

I’d need @analog pollen to advise really, I’m not technically expert enough

[heavy wedge]

Thank you steve. Ive had a few people asking me. I was thinking maybe i could check out the work u guys did and maybe design around that. Is that royalties repository the one youre using in the video u showed me

[wet rampart]

Yes, its all here https://github.com/taskdotio/soroban-nft-royalties

Just note that currently we dont have a Testnet option, its is all running on mainnet as we wnated to move fast and I wnated to avoid more infrastructure costs for the bridging api's

You have access to the bridging api's in that doc too

[karmic gust]

I'm inclined with this perspective because Stellar's technology is highly versatile, making it challenging to establish a universal NFT standard. However, there's significant work to be done with Soroban to simplify interactions with the Stellar Decentralized Exchange (SDEX), where many of us have already made considerable investments. I believe we should focus on the following foundational principles:

1. Treating NFTs as First-Class Citizens

Emphasizing NFTs as first-class citizens will take advantage of the dedicated support and features within the Stellar ecosystem. It would be cool if Soroban expands support for things like offers on SACs.

2. Enforcing Royalties with Multi-Sig

This mechanism could be further explored with Soroban smart contracts, leveraging their capabilities to create more sophisticated and flexible royalty enforcement methods.

3. Improving the Wrapping Process

The wrapping process for NFTs, which allows assets from other chains to be represented and traded on Stellar, is crucial for interoperability and market growth. Enhancements here could involve simplifying the wrapping and unwrapping processes, reducing costs of development, and ensuring security.

4. Indexing and Cross-Platform Availability

An efficient indexer for Stellar’s NFTs is fundamental for discoverability and cross-platform trading. Such a tool would not only increase the visibility of Stellar NFTs but also enhance liquidity and market participation.

[shell dawn]

Hello @heavy wedge I did a bit a research on NFT implementations in Soroban: Here are my results: #🔹｜developer-chat message

[heavy wedge]

thanks!

[shell dawn]

Hello @trail cedar . I was just talking with @heavy wedge and wanted to paste here the NFT contract that I wroted for the Gladius Team. It's based on the work done by @lone orbit who fist implemented a ERC721Enumerable for Soroban

https://github.com/GladiusClub/gladius-contracts/tree/main/contracts%2Fgladius-nft

[heavy wedge]

Thank you!

[blazing loom]

I don't know the use case for this contract, so I don't know if that's an issue, but I'm pretty sure after a certain number of NFTs (I think around 1600, if I remember correctly), you won't be able to mint more NFTs due to the CPU instructions limit. Also, the mint cost will increase with each NFT minted.

[shell dawn]

Yes, this is correct. But it will be much more than 1600. For the Gladius sport club use case it did make sense to use instance storage, with this you could manage all NFTs at once.
You can see more of instance v/s persistent data here
https://github.com/paltalabs/instance-persistent-dos-soroban

For a NFT standard I aggree that should be persistent storage as the balances of a SAC

[blazing loom]

Just fyi Balance and TokenOwner use persistent storage, but it says instance in the comments. However, the limitation isn't because of the instance storage limit but due to CPU instructions when working with large vectors and maps. I did testing a while ago, but I think the limit was 200M instructions then, so it might be even less than 1600 NFTs now. Have you tried to mint 1600 NFTs?

[blazing loom]

To be clear, I'm not saying it's an issue right now, but when I did testing for an NFT contract I was writing (I think 4 months ago), reading and setting a large map/vector consumed a lot of CPU instructions. So, if you haven't tested it, I would encourage you to test it. It's better to be safe than sorry.

[shell dawn]

Can you share this script? I'm interested in experienting this 😇

[blazing loom]

Unfortunately, I don't have it anymore. But here's what I ended up with https://github.com/eugene3141/soroban-nft. It's heavily inspired by cw721.

[heavy wedge]

Awesome the more implementations I see the easier it'll be to write a spec 🙂

Thanks guys

[heavy wedge]

I will post a tldr of the things we discussed in a little bit here 🙂

Thanks for coming today

[heavy wedge]

@opaque thunder here is the discussion

[trail cedar]

@opal snow also proposed a 1155 standard recently. It doesn't compete with 721 since both serve a different purpose.

What does everyone think? https://github.com/stellar/stellar-protocol/blob/d45afcb68b635b954fe5085e89f00ab9d000401f/ecosystem/sep-1155.md