NFT Support on Stellar

[Michael Feldstein]

Hi Friends,

There's been a lot of action on NFTs in the crypto sphere lately, and I believe that Stellar is actually the perfect place for NFTs to be built.  People are looking for a cheaper, more eco-friendly alternative to mint their artwork on, but there is one stumbling point to making this possible.  Since we don't have a concept of indivisible assets, most of the stellar based NFT solutions use single stroops to represent the token.  Since this is such a tiny amount, there are precision issues in the dex meaning you can't place a buy order for more than 214.7483647 of the counter asset, so NFT sales would be limited to 214 dollars/lumens.  There are schemes to get around this, such as intermediate tokens issued to allow path payments but this muddies the story quite a bit.

To make Stellar the best place for NFTs we'd need one of two solutions, either:

Allow for indivisible assets or Increase the precision on the dex. Indivisible assets would be a great improvement in ergonomics, but the precision fix seems like it would be faster to fix.

Allow for indivisible assets:

If we allowed for indivisible assets, it would mean we could sell one logical token, rather than one stroop, and we wouldn't run into the precision issues on the dex so we could support it like any other trade on the network.  Jed brought this up and Johan wrote an early CAP proposal years ago, but I think now the market has shown that this is a really important concept.  This would be the ideal solution because people looking at explorers, or wallets that don't understand NFTs would still show a "1" balance, and people looking to implement NFTs wouldn't need to figure out why we're using .00000001 instead of 1.

Increase the precision on the dex

If the indivisible assets approach isn't something we can do any time soon, we would need to make it so that single stroop offers work properly on the dex.  On Keybase, tyler says "The selling bit is weird due to the max int32 size limitation, you can't sell a stoop sized asset for more than 214.7483647".  If anyone has a link to a better writeup of the issue please post it, but my understanding is that if i wanted to sell an NFT for 20,000 USD, and the NFT is actually .0000001 of a token, the price is actually 10 million times higher, so 200,000,000 per 1 NFT, but since price is an Int32, the maximum price is somewhere just over 2 million..  This restriction would need to be lifted.

I'm interested in working with Frederic/Litemint on a SEP for the ecosystem parts of NFTs, but we'd need to understand what kind of core improvements we might see to make this possible.

<3 Mike

[Jonathan Jove]

Hi Mike,

Your ideas here are interesting, and raise several questions for me:

1. What actually needs to be part of the Stellar protocol, and what can be done at the ecosystem level? For example, you mention that it is possible to achieve the goal of selling NFTs for any amount of counter asset by using path payments. I am familiar with this technique, and I agree with you that it isn't particularly obvious or natural. But I wonder if the underlying technical implementation really matters if, for example, it is packaged behind an attractive interface in an SDK? I generally view the protocol as the lowest level building blocks, and if something can be achieved with those building blocks then I often think it can be given an attractive high-level interface. I don't worry about x86 assembly when writing C++.

2. What exactly do people want to do when it comes to selling NFTs? Art is typically auctioned. There is an extensive, and very interesting, theory behind the design of optimal auctions (https://en.wikipedia.org/wiki/Auction_theory); the classical example of an auction that can be proved to be optimal under certain assumptions is second price auction with reserve. I doubt that selling NFTs using the order book would produce the best outcomes for creators.

3. Are there building blocks that could be included in the protocol that could facilitate designs at the ecosystem level? For example, people might want to try a variety of auction strategies in order to maximize profit. But it is very unlikely that we will actually incorporate those strategies natively into the Stellar protocol, especially for some which are more experimental.

As for the specific proposals, both of these would require making non-negligible changes to the order book. Having personally designed and implemented a number of changes to this part of Stellar (CAP-0003, CAP-0004, CAP-0024), I know that it is fraught with difficulty.

1. Allow for indivisible assets: It's not clear to me that this solves the real problem. For example, imagine an artist in Indonesia trying to sell a work in their native currency. At the time of writing this, I am seeing that the exchange rate from IDR to USD is approximately 14,015. So moving the decimal place by 7 digits, which is effectively what indivisible assets would achieve, would be much less effective in expanding the range of possible dollar-equivalent prices in this context. Stellar is a global network, so I am very cognizant of making protocols that work at all scales.

2. Increase the precision on the DEX: This sounds like a small change, but would probably be more work than anyone predicts. As a first example, changing the precision would make it possible for integer overflow to occur in a number of places that it cannot occur today. This would in turn require substantial testing given our intense focus on quality and security.

Personally, I would need to see compelling evidence that the benefits of these changes would be worth the effort and risk involved. Perhaps it is justified, but I don't think that will be clear until we take a deeper dive into what a useful interface to NFTs would look like on Stellar.

I am not an expert on ecosystem proposals, so it would be valuable to me if other people would add their thoughts on this.

Thanks,
Jon

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/88f92473-04cc-44b9-8c91-d9fc79dcfa06n%40googlegroups.com.

[Leigh McCulloch]

Hi Mike,

By indivisible are you meaning that there could be a volume of 10, I could hold 2, and I can't transfer you 1.5, I can only transfer you 1 or 2? Or by indivisible are you meaning that if I hold 2, I can only send 2? I'm assuming the former in the rest of my message.

I think the first proposal, making it possible for assets to be indivisible, seems like the meaningful change to make for NFTs because the system is confusing if a user has to make an offer of 20mUSD to buy conceptually 1 NFT, where the amount that will be spent is actually 20kUSD.

The previous issues by Jed and Johan suggest there are non-NFT uses of indivisibility as well but in many jurisdictions fractional shares are allowed. For assets that are regulated it is also likely the issuer will be using SEP-8 and controlling all movements and could deny fractional amounts if that was required, so the potential non-NFT uses is not clear to me. It'd be helpful to know if FTs need indivisibility so that we know if there are more use cases and gains for the first proposal, or if the benefiting use case would only be NFTs.

@Jon, if the implementation of the first proposal was limited to introducing error conditions in all cases that would reduce a balance by an amount that wasn't zeros right of the fixed decimal for assets that are not divisible, would that require non-negligible changes?

@Mike Are NFTs better suited to OTC-like trades where two parties agree on an exchange and then perform that exchange in a single transaction signed by both parties? I realize that doesn't particularly address the problem of preventing them from being divided, and that doesn't improve interoperability.

Leigh

[Frederic Kyung-Jin Rezeau]

Hi everyone,

Quick answers on points raised by Jonathan Jove:

A marketplace would typically implement below-reserve bidding off-chain (no transfer), yet once the reserve price is met, all decentralized settlements, including most binding contracts, would still benefit from SDEX operations e.g. for the second price auction feature you mentioned, marketplaces can guarantee the discount to buyer (via on-chain contract, multisigners etc), yet there would be no reason for the marketplace/buyer/seller to run the bidding process off-chain regardless of the auction format.

Most sophisticated auction strategies can already be implemented on-chain through contract tools available but, even though there are workarounds with intermediate assets and path payments, pricing limitations are impairing straightforward usage of such SDEX operations—also creating cryptic offers which may not help the ecosystem for encouraging discovery and leveraging opportunities with these assets.

Finally, I wonder about the initial rationale behind the use of int32 for SDEX pricing (only). It seems to me that such change justifies itself with scalability (i.e. without a case for NFT).

If anyone has a link to a better writeup of the issue please post it

Here is my write up on the issue with pricing limitation on SDEX and the solution using path payment that we are using it for our NFT marketplace.

https://blog.litemint.com/nft-sdex-pricing/

Fred

[Michael Feldstein]

On Wed, Feb 17, 2021 at 2:56 PM Jonathan Jove <j...@stellar.org> wrote:

Hi Mike,

Your ideas here are interesting, and raise several questions for me:

1. What actually needs to be part of the Stellar protocol, and what can be done at the ecosystem level? For example, you mention that it is possible to achieve the goal of selling NFTs for any amount of counter asset by using path payments. I am familiar with this technique, and I agree with you that it isn't particularly obvious or natural. But I wonder if the underlying technical implementation really matters if, for example, it is packaged behind an attractive interface in an SDK? I generally view the protocol as the lowest level building blocks, and if something can be achieved with those building blocks then I often think it can be given an attractive high-level interface. I don't worry about x86 assembly when writing C++.

It's possible to build an SDK function to convert a 500USD offer tx into a 500USD->.1CONVERT->1NFT path payment offer tx, but the messiness still seeps through in a few places:

- Signing transactions in freighter or whatever wallet are far less clear about whats being signed, it would be much more user friendly to sign a transaction that just offers 500USD for 1NFT.   This is still an issue even if we fix the precision problem but still use single-stroop representations, it is going to feel very uncomfortable placing offers that look 10 million times higher than the price you were thinking.  If we do indivisible assets it will be a clean way to sign a transaction, "I offer 500USD/NFT for 1NFT" vs "I offer 5,000,000,000 USD/NFT for .0000001NFT"

- Secondary sales are far more difficult because the reseller now needs to issue this CONVERT asset and put offers on the dex which is asking a lot of someone who just wants to sell the thing they bought

2. What exactly do people want to do when it comes to selling NFTs? Art is typically auctioned. There is an extensive, and very interesting, theory behind the design of optimal auctions (https://en.wikipedia.org/wiki/Auction_theory); the classical example of an auction that can be proved to be optimal under certain assumptions is second price auction with reserve. I doubt that selling NFTs using the order book would produce the best outcomes for creators.

Yeah the auction types still need a bit of thinking through.  There's definitely nothing 'optimal' or 'rational' about any of this art crypto stuff, but i think just accepting offers that others put on dex is a good start. One of the real losses about not being turing-complete here is the loss of secondary sales royalties.

I haven't actually seen any second-price-with-reserve (this is ebay style right?)  auctions.  I've seen mostly "Someone puts up an offer and you can choose to accept any of them" or "Once there's a bid, the auction closes in 24 hours and the highest offer is accepted".

 

3. Are there building blocks that could be included in the protocol that could facilitate designs at the ecosystem level? For example, people might want to try a variety of auction strategies in order to maximize profit. But it is very unlikely that we will actually incorporate those strategies natively into the Stellar protocol, especially for some which are more experimental.

As for the specific proposals, both of these would require making non-negligible changes to the order book. Having personally designed and implemented a number of changes to this part of Stellar (CAP-0003, CAP-0004, CAP-0024), I know that it is fraught with difficulty.

1. Allow for indivisible assets: It's not clear to me that this solves the real problem. For example, imagine an artist in Indonesia trying to sell a work in their native currency. At the time of writing this, I am seeing that the exchange rate from IDR to USD is approximately 14,015. So moving the decimal place by 7 digits, which is effectively what indivisible assets would achieve, would be much less effective in expanding the range of possible dollar-equivalent prices in this context. Stellar is a global network, so I am very cognizant of making protocols that work at all scales.

Agree, it seems like we would need to fix that precision issue with or without indivisible assets.

 

2. Increase the precision on the DEX: This sounds like a small change, but would probably be more work than anyone predicts. As a first example, changing the precision would make it possible for integer overflow to occur in a number of places that it cannot occur today. This would in turn require substantial testing given our intense focus on quality and security.

Personally, I would need to see compelling evidence that the benefits of these changes would be worth the effort and risk involved. Perhaps it is justified, but I don't think that will be clear until we take a deeper dive into what a useful interface to NFTs would look like on Stellar.

That's very fair, and i think your questions are great to make me think about exactly what would need to exist for this to be a real solution.  The lack of turing completeness (meaning dependence on core changes) does make it difficult to do some of the more experimental and interesting things.

[Michael Feldstein]

On Wed, Feb 17, 2021 at 8:11 PM 'Leigh McCulloch' via Stellar Developers <stell...@googlegroups.com> wrote:

Hi Mike,

By indivisible are you meaning that there could be a volume of 10, I could hold 2, and I can't transfer you 1.5, I can only transfer you 1 or 2? Or by indivisible are you meaning that if I hold 2, I can only send 2? I'm assuming the former in the rest of my message.

Yes, the former.

 

I think the first proposal, making it possible for assets to be indivisible, seems like the meaningful change to make for NFTs because the system is confusing if a user has to make an offer of 20mUSD to buy conceptually 1 NFT, where the amount that will be spent is actually 20kUSD.

I agree.  This can be obfuscated in app UI, but the wallet/signing messages are still going to be scary and confusing (unless we get wallets on-board with making a prettier message for NFT purchases when they're detected)

 

The previous issues by Jed and Johan suggest there are non-NFT uses of indivisibility as well but in many jurisdictions fractional shares are allowed. For assets that are regulated it is also likely the issuer will be using SEP-8 and controlling all movements and could deny fractional amounts if that was required, so the potential non-NFT uses is not clear to me. It'd be helpful to know if FTs need indivisibility so that we know if there are more use cases and gains for the first proposal, or if the benefiting use case would only be NFTs.

Indeed I can't think of any Fungible Token use cases for this, but I will mention that NFTs can be a lot bigger than just art (non-fractional real estate ownership for example).

 

@Jon, if the implementation of the first proposal was limited to introducing error conditions in all cases that would reduce a balance by an amount that wasn't zeros right of the fixed decimal for assets that are not divisible, would that require non-negligible changes?

@Mike Are NFTs better suited to OTC-like trades where two parties agree on an exchange and then perform that exchange in a single transaction signed by both parties? I realize that doesn't particularly address the problem of preventing them from being divided, and that doesn't improve interoperability.

I can imagine an OTC solution working well for NFTs, but there is some magic in just putting an offer up on the dex, and then the seller accepting it.

 

Leigh

--
You received this message because you are subscribed to a topic in the Google Groups "Stellar Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stellar-dev/FU1EXVRVtpY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/83a70a07-6d04-4051-8a04-a8c0daa8e1ecn%40googlegroups.com.

[Tyler van der Hoeven]

It might be worth exploring the turing complete option here as at the end of the day atomic swaps of asset A for asset B are simple, it's the async gathering of signatures piece that makes that route far from ideal. This is specifically what Turing Signing Servers were designed to solve though. The big issue there being their experimental nature. This could be a great application for testing their viability though. I don't know though if Mike or Fred you've explored the proposal much yet. https://tss.stellar.org. Essentially all we're looking for here is an automated and assured vending machine where you can generate signed swap XDRs along specific programmed criteria.

Between a SEP and a few TSS txFunction templates we could achieve all our NFT dreams, it's just a question of would the ergonomics be widely compelling for mass adoption. 

Ultimately I'm doubtful the DEX is the best place to sell NFTs anyway, there are too many other ways NFTs might need or desire to be sold / monetized outside the current DEX model. Even just the fact it's not an auction to me makes that route pretty unappealing when considering it as an alternative marketplace to all existing ETH based NFTs which are auction based.

I will say I don't like the UX of 0.0000001 but I'm unsure if weird UX is a SEP or CAP issue especially when NFTs tend to be really closely tied to NFT interfaces vs just sitting inside traditional wallets. I don't want to derail meaningful conversation around precision but even if this were solved in Core today and we could cap divisibility we don't actually open up the usability of Stellar as an NFT marketplace when the DEX doesn't support the ways folks will want to sell assets.

Selling 1 stroop for billions of a counter asset isn't hard, getting signature coordination is the hard part. Using the DEX is one way to solve this but it's probably not _the_ way to solve this root issue. Would be curious if focusing on a TSS style solution might be the better way to direct a fix for this root issue.

[Tyler van der Hoeven]

Apologies for the double post.

One potential way to achieve this at the Core level would be expansions to the two part payment functionality that protocol 15 introduced. Adding additional predicate(s) could potentially resolve at least this most basic precision issue. "You (NFT issuer) can claim my 1 million USD balance if {x} transaction hash is submitted." (transaction {x} would be an NFT payment likely to the 1 million USD source account but it's irrelevant really). Essentially it's just saying if transaction X get's signed and submitted you gain access to claim balance Y.

Jon you'd know better how feasible this is but could be a really powerful predicate change with far reaching benefits outside just NFTs and a good stop gap for getting at least some additional NFT traffic through Stellar to see if something more robust like TSS would be useful/necessary. 

[Nicolas Barry]

Yeah I think that keeping matching off chain for those is probably the way to go in this context. The ROI of reworking the order book for this doesn't seem to be there.

At that point we're left with an atomic swap, which can be achieved either with a single transaction (2 ops, multisig) or "on chain" (but I am not sure it's that much better in this case as parties need to be online anyways when matching) with HTLCs (that Leigh wanted for a different reason).

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/40e4fdae-047a-4326-8a7d-357d68db3e90n%40googlegroups.com.

[Frederic Kyung-Jin Rezeau]

Hi everyone,

I wanted to make a quick point. In my opinion, the speculative stand on whether auction is the best way to sell NFTs is not relevant because, on a wider scale, it is the entire digital good industry that benefits from NFTs and collectibles.

Even today, most digital good revenues are not made via auction, so there is no real reason to focus on the idea that auction systems as the main platforms for these new assets which benefit all industries (gaming, movie, music, education, publication and so on...) from in-app purchases to subscriptions to licensing. There are existing funnels and a wide user range that are leveraged by this technology other than the eBay/auction style market/seller, let alone new opportunities due to access to decentralized payment rails and cross-experience content.

In my opinion, we could take a more global stand with the purpose of making Stellar more friendly to opportunities offered by these assets—addressing the SDEX limitation would go a long way in that regard.

[Drew Palmer / Marscoin]

Are NFTs even important to support on Stellar?

Not trying to be evil or snarky, just truly wondering if the core focus is as a transaction/payments platform then is it possibly an unhelpful distraction to move toward more ETH virtual machine capabilities rather than laser focus on transactions.

[Tyler van der Hoeven]

Yes, next question 😋

As Fred pointed out these aren’t just CryptoKitty type assets this is a question needing an answer for any tradable digital asset and is more a question of indivisibility than a specific use case for an indivisible asset. Stellar is a blockchain for efficient value transfer. We have use case goals but they shouldn’t be overly opinionated, we should be and have been quite flexible in supporting various use cases as they arise and we’ve changed the protocol for things with far less demand than indivisibility so requests like this are reasonable. The digital asset transfer industry is also booming and could help bring more value, users and innovation into our ecosystem which would be a net positive.

Another potentially relatively achievable solution would be to add a set options flag of "Authorization indivisible” denoting that trustlines must move the asset in question entirely whenever sending or receiving. So if I were to receive 1 of something I would be forced to also send or sell that entire 1. This would allow flexibility and consistency with how indivisibility is handled while not overly complicating things for a specific use case. I guess you could also set it in the Allow Trust operation, "authorized to sell all” or something. Not sure what the implementation differences would be.

Tyler

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/3677fc6b-8b1c-4b6c-bbdb-a61946854c79n%40googlegroups.com.

[Corey Ballou]

First and foremost, I'm in favor of NFTs. Digital ownership rights is our probable future. I believe the correct solution is that indivisibility is a requirement of most asset classes of NFTs. There's been several proposals on how this could be accomplished. Tyler's latest suggestion of a new AUTH_INDIVISIBLE flag would support this notion of a true 1of1 asset, but not, say, a short print run of 100 pieces of art. I'm in favor of Michael's earliest suggestion whereby you can specify an asset's decimal precision. It's the approach Ethereum takes with smart contracts. I realize it's likely the most difficult of solutions, but it's arguably the most correct for supporting the widest variety of assets. In the case of a true 1of1 NFT, you would set the precision to 0.

I believe impact analysis on overall network throughput would be warranted. We're talking about the potential for user generated content of an unlimited number of assets. What impact would this have on, say, path payments? 

If the presumption is that Stellar could become bloated with 1of1 NFTs, we have to assess its potential impact on the network as a whole.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/cc878643-d976-4a6a-97e0-ba906d8f9468%40Spark.

--

Corey Ballou

CTO • TERN⋮O

co...@ternio.io

[Drew Palmer / Marscoin]

To the extent that Stellar is a blockchain for efficient value transfer why does it need to even think about NFTs. Isn't that a usecase for a different blockchain?

Always happy to be corrected, but NFTs are basically ownership records. Why is that necessary to accommodate in Stellar at all if it requires a AUTH_INDIVISIBLE flag. (and my archive of this thread only trails back to Feb 16 and doesn't show "Michael's earliest suggestion" so apologize if I missed something there)

[Michael Feldstein]

It's a good question and the answer might be 'it shouldn't'.  I think its a good fit because stellar is likely the chain most focused on being a token network, and NFT's are just tokens.   I think NFTs as a concept have value (as hyped and mania'd as they may be right now), so if we want to transfer value, why not transfer this value as well?

If we consider real estate tokenization a valid use case, i think NFTs in general should be considered too.

You received this message because you are subscribed to a topic in the Google Groups "Stellar Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/stellar-dev/FU1EXVRVtpY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/8583e254-d8ee-4754-81e1-06d769a69bd6n%40googlegroups.com.

[Drew Palmer / Marscoin]

if Real Estate is a use case under consideration in addition/rather than collectibles what about condos/coops or joint tenancy? Is that now "somewhat fractionalized?" (tortuous English aside...)

[Frederic Kyung-Jin Rezeau]

> Always happy to be corrected, but NFTs are basically ownership records

I would say that ownership is already a given on any blockchain, the main function of NFT contracts is to deal with value transfer while enforcing specific rules pertaining to scarcity and non-fungibility. e.g. ERC-721 on Ethereum standardizes such transfers—it does not model ownership which Ethereum does.

Provided that NFTs are just a class of items that can represent anything in the digital goods market, Stellar is already on purpose for that transfer function and the question is not exactly about the relevance of it.

According to OpenSea stats (the largest NFT marketplace by volume), the “Buy Now” market makes up for most of the NFT sales (only 1 item out of 80 is sold via auction) so this market is really something Stellar could handle well, especially with better SDEX support.

Because the problem at core here is just the inability to enforce arbitrary integral, or non-fractional, value transfers so we are required to use stroops for this purpose and trading in such small values is not well supported (although not impossible) on the SDEX.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/9ccdff55-ff04-4067-9267-f92309dd9f84n%40googlegroups.com.

[Drew Palmer / Marscoin]

@frederic.rezeau I don't understand what you mean by "modeling ownership."

I am willing to be a testcase for various NFT styles. We have 10,000 copies of "Marsopoly" with Marscoin as dollars and 2000 Ledger wallets on order with Marscoin packaging, and are thinking about a 2001 style monolith. All paid for by us and free to recipients, so have some flexibility on embedding NFT utility. The 3 million lumens we bought last month are allocated to one million new accounts on Lobstr, but we are probably going to generate another 10 million accounts in April, which would make Marscoin users the largest community on Stellar, so it is absolutely critical that I understand even slight variances in terminology like "modeling ownership" and how NFTs will work.

[Frederic Kyung-Jin Rezeau]

> how NFTs will work

I am curious to see what test cases you have in mind. I meant to say that Stellar NFT ownership does not require anything new (done via account trustline balances). And on Ethereum they did not change the protocol either with ERC-721, NFTs are just tokens as said below, hope this clarifies.

Technically, many NFT projects on Ethereum would just work with current Stellar protocol e.g. A major project like Sorare which has just made the news uses basic issuance scenarios that Stellar can already cover.

And without any protocol change, Stellar anchoring can also be an attractive solution for many existing projects from Ethereum, another reason for being able to enforce arbitrary integral value or ignore the fractional part of the value for an asset.

Fred

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/8af91e96-3b0a-4d99-9deb-aa85976208ebn%40googlegroups.com.

[Nikhil Saraf]

Hi everyone,

To summarize, these seem to be the main concerns (please feel free to correct me if I’ve missed anything, or misrepresented anything):

1. max price is 214.7483647 of the non-NFT asset per 1 unit of the NFT. This non-NFT asset can be XLM, USD, BTC or any other token.
2. 1 logical unit of the NFT needs to currently be implemented as 0.0000001 NFT, which is non-ideal and requires special handling by NFT UIs (which is acceptable), but more importantly by wallets that will need special knowledge that these tokens are NFTs so they can show that you own 1 unit of the NFT instead of 0.0000001 unit. This also requires some price adjustments.
3. The solution we eventually end up with needs to be generalizable for broader use cases
4. No way of giving % of future sales to creators of NFTs because there’s no Turing Completeness in Stellar, or conditionals.

The suggestion of a decimal representation per token (on asset issuer account) seems like it could solve the cases of #1, and #2 above, and will also be more broadly generalizable which solves #3 to some degree. This sounds like it would be a fair amount of work to change this in core, and also potentially in horizon and other ecosystem projects too. Seems like it can be a good long-term solution.

The NFT use case could be large enough to warrant the flexibility since NFTs are quite a generalized concept that captures different forms of value tokenization. The experience of using NFTs on Stellar would be much better than it is on other platforms and it will be much more cost-effective too in terms of fees. #4 seems like it’s a much harder challenge without baking complex logical structures within Stellar.

Has anyone tried solving these issues by using SEP-8 as a stop-gap solution? This is of-course non-ideal for something decentralized because of the "permissioned sell" requirement of SEP-8. However, these tokens can be deployed without any changes to core, horizon, and ecosystem wallets and would solve the use cases of #1, #2, and also #4 which is not possible with other solutions. We can make use of multisig to provide some level of decentralization to the SEP-8 sign-offs so there isn't a SPOF (eg: NFT portal, artist, and current owner can sign in a 2 of 3 multisig -- up to 20 signers).

One way to look at the SEP-8 usage proposal in the context of NFTs is that it is a good way to experiment on Stellar with almost the same exact functionality as is available on Ethereum without changing too much within Stellar too soon. Once the NFT ecosystem grows within Stellar we would have learned a lot more about the challenges specific to Stellar that could help inform deeper protocol level changes for better NFT support within Stellar.

Best,

Nikhil

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAJVtNT8HCqq-q%3D7KZqQ7r6uMjNyt5WT_bniM8Xt4oXn7bBqZFQ%40mail.gmail.com.

[Alex Roy]

In our project EverLife.AI, we were looking to model Ownership of an NFT token to be represented by signing rights on the Account. 

- Turing Signing Server based contracts would change signatories to transfer ownership, collect payments and give royalty payments to the original creator account on subsequent sales.
- Allow Trust flag set to false to enforce that the NFT ownership is transferred only in this fashion and avoid fractional payments/trades and get around the divisibility problem.

Hope no red flags down this path till further protocol enhancements come in?

/Alex
EverLife.AI

[Leigh McCulloch]

A thought of one way we could fix representation and semantics:

The core protocol has no concept of a decimal place, everything is in stroops. It is SDKs that introduce the concept of a decimal place when decoding and encoding transactions. We could change the SDKs to insert the decimal place at different spots depending on some definition of how many decimal places the asset has. The question becomes where should that information be stored. It is really important that wherever it is stored is immutable so that the semantics of a prior transaction cannot change.

Therefore, we could encode the number of decimal places into transactions themselves.

This would be a core protocol change, but only to the XDR, and not to logic. We'd make a new asset type that included where the decimal point should be inserted. That new attribute of assets would be for semantics only, it wouldn't be used by stellar-core. The number of decimal places would form part of the identity of the asset, so an NFT:G... asset defined with zero decimal places would be a different asset to NFT:G... defined with one or more decimal places. The existing asset types are assumed 7 decimal places, but new assets would use the new asset type and can choose their number of decimal places.

This is more flexible than making an amount simply indivisible. We could define assets that have two decimal places, or assets that have more than 7.

There is still the issue that amounts are only int64's and offers are defined using int32's, but those issues seem like a broader issue that should be addressed outside of only NFTs.

Thoughts?

[Ludwig Moreno]

It would be great if Litemint app could generate a QR for a newly minted NFT, maybe by using this open-source package: https://openbase.com/js/stellar-qr/documentation . 

Then, with a newly added button in the 'Receive' section of the Litemint Wallet, named "Quick Redeem" -or whatever you want- to open the QR reader, the user could load and redeem the QR from the device file system or from the camera, so that the Litemint Wallet could prepare the transaction envelope with the proper 'accountId' (ie public key), and then send it to the Horizon server in order to process the transaction and write it to the blockchain.

The function could be named "Flash" and would boost the use of Litemint Wallet. Other wallets will gradually adopt it, increasing Stellar adoption during this NFT boom.

The reach and importance of such function is similar to the one that is widely discussed here: https://es.enjin.io/software/beam

NFT is actively reviewed by Binance: https://www.youtube.com/watch?v=BcibnstsCIM

Please, share your thoughts about this.

Ludwig