Thread by @austin_flowty

When we started onboarding to Dapper Wallet, we had two options:
1. Maintain Royalties manually (this is what was suggested to us originally)
2. Utilize royalties metadata standards

We chose the latter 🧵

https://twitter.com/flowty_io/status/1619032945054085120

To start, if you aren't familiar with it, you should check out the Royalties metadata standard on flow. You can find that here:
github.com/onflow/flow-nf…

Why would a marketplace choose the first option? Well, it makes the contract work easier. In order to go with option 2, you have to start accounting for things you otherwise wouldn't need to care about. Like whether or not an account can receive a certain token.

What does that mean? Well it has to do with how the @flow_blockchain works! Unlike ethereum, you have to configure your wallet to receive items before they can actually reach you. So if we needed to send USDC tokens to you, but you can't get them, what are we supposed to do?

We put our heads together a while ago and came up with a solution for the whole community for that problem. If you'd like to learn more about that, check out my thread about what we ended up calling the "Lost and Found"

https://twitter.com/austin_flowty/status/1559184554090323968

The summary for Lost and Found? Build a central escrow anyone can send things to, ensuring that only the right redeemer can get the items meant for them. This is actually the preferred approach folks at @dapperlabs suggested for when a royalty isn't valid!

Unfortunately, that doesn't work for all cases. Dapper Balance (Dapper Utility Coin) and Dapper Flow (Flow Utility Token) aren't like other Fungible Tokens. They are not permitted to exist in any account other than their contract address. This is vital to Dapper's compliance work

So if we can't escrow tokens, what do you do if it isn't configured? Well, we have to skip them. If we didn't, a royalty recipient could make their receiver invalid and make any NFT that uses it unable to be sold on marketplaces that use the royalties standard

There is actually still more work to be done there, we have a pending pull request to the fungible token repo to help us make that more verbose (and the ball is in our court to wrap it up)

github.com/onflow/flow-ft…

Anyway, so what happens if you don't specify any royalties on your collection's NFTs? Unfortunately, it means no royalties. Luckily, this can be fixed at any time! Let's look at an example.

@cuveecollective adhere to Metadata Standards in that they have a "Royalties" struct, but it is actually empty. This means that to anyone following the spec as it is written, this collection is signaling that it has NO royalties.

flow-view-source.com/mainnet/accoun…

All that you have to do is update your contract to specify royalty cuts and you're good to go! Something like this would work (don't forget to test things out)

gist.github.com/austinkline/fb…

With this, or something similar, all listings on @flowty_io on all our various products would pick this up. Our good friends at @flovatar are a great example of this!

In the @flovatar contract, they specify two royalties. 5% for them, and 1% for the original minter. And as expected, you can see us pick that up in our marketplace. This is where those original options matter! Marketplaces who hard code royalties can miss the other 1%

Metadata standards are there for a reason, and we're very proud of the work we've done to get them into shape. If any collection out there wants to be sure that things are setup properly on their side, reach out! We'll help you get sorted out!

If any of this is unclear, give me a shout! There is much to do before this becomes the norm, but it will help the future of the @flow_blockchain that we start to bring these together. The longer we wait, the harder it will be. Thanks for reading! 🫡