~~The latter does not even require storing information into any kind of cache, which makes it ideal for one-off cloud executions.~~ > Edit: it wasn't made clear at first so I didn't realize, but `etherscan.io`'s free plan only allows for 900 calls per day, so this no-information-storage strategy can't really work, unfortunately. For the Waifumon, I call this free API from `etherscan.io` and simply parse the list of all the transfers which occurred, to identify, for each NFT, which account ends up having it in the end. With a Javascript `Map`, this ends up being `O(n • log(n))` in the number of NFT transfers, which makes it absolutely negligible compared to the time it takes for the network calls of the API itself.

@Nacho @HPrivakos So I know I'm very late here, as I only arrived fairly recently, but I reached out to parties involved and got no answer, so I will express my concerns here. Why is anyone talking about implementing a database when the database is already there, in the form of the blockchain ? A PRO subscription to `etherscan.io` is all that is needed to get the latest state of a NFT (with [erc721-token-inventory-by-contract-address](https://docs.etherscan.io/api-endpoints/tokens#get-address-erc721-token-inventory-by-contract-address)). With a bit more engineering, it is also possible to use the FREE `etherscan.io` plan, where only the list of NFT transfers is available (with [erc721-token-transfer-events-by-address](https://docs.etherscan.io/api-endpoints/accounts#get-a-list-of-erc721-token-transfer-events-by-address)).

Linked Wearables Redesign This proposal is now in status: PASSED. Voting Results: * Yes 98% 12,505,531 VP (62 votes) * No 1% 1,463 VP (6 votes) * Abstain 1% 1,410 VP (2 votes)

Stop removing or hide my reply to @DedHeadJ ! This is censorship!

I would also like to know why this was deleted. I see nothing in this statement that would warrant a deletion. Who is responsible for removing this and why was this removed?

> That’s a time consuming and expensive solution to implement for something which is not an issue with the current implementation. Yes, but a possible workaround. > Bitcoin Ordinals for example are quite popular and not supported by Alchemy, there are a lot of non-EVM chains lately. Avalanche, Blast (used by DG), Bitcoin Ordinals, BNB, Polkadot, Tron, etc… are not supported by Alchemy. Sure we can used different RPC for each, but if we need 15 RPCs to be able to support 15 different chains, it might not be the best So far, I will see this as a downside if we want a better onboarding and UX. It is hard to have a solution that covers all the use cases that scale and keeps good asset quality and UX.

[quote="Nacho, post:9, topic:22450"] but they can create a contract answering the `ownerOf` call and support it somehow by doing some on-chain operations. [/quote] That's a time consuming and expensive solution to implement for something which is not an issue with the current implementation. [quote="Nacho, post:9, topic:22450"] Not-supported chains are a downside of this solution, but I’m curious about how they can bring value to Decentraland. If they are not still supported, chances are that the community is not big enough. [/quote] Bitcoin Ordinals for example are quite popular and not supported by Alchemy, there are a lot of non-EVM chains lately. Avalanche, Blast (used by DG), Bitcoin Ordinals, BNB, Polkadot, Tron, etc... are not supported by Alchemy. Sure we can used different RPC for each, but if we need 15 RPCs to be able to support 15 different chains, it might not be the best :)

[quote="HPrivakos, post:4, topic:22450"] Is that something that can be hosted on each catalysts instead of a service hosted by the Foundation? It would incur slightly higher cost for the catalyst owners, but as you said the cost is minimal with the current number of requests. [/quote] Do you mean the map between the NFT and the wearable? We will need to define a new entity type, but we can evaluate it. Not-supported chains are a downside of this solution, but I'm curious about how they can bring value to Decentraland. If they are not still supported, chances are that the community is not big enough. Regarding Aaron's example, yes. We can't support that case out of the box, but they can create a contract answering the `ownerOf` call and support it somehow by doing some on-chain operations.

Hi Aaron, you know I support you! I genuinely love my green Fairy pet and ALWAYS wear it. For me you would do much better to resubmit your proposal with some technical guidance. When I read you belittling others it makes me have less confidence in you. I would vote YES on a new proposal as long as the correct information was added, and I do believe the community is behind you. I wish you all the best! Jenn 

1000% this! Decentraland the first metaverse yet the last to do this is completely wild. There a reason why @MakeAnft and I last ones working on the current process and why everyone else left. Less bullying from the payroll trolls :money_with_wings: :troll: and more solutions to support inclusivity and onboarding of all other communities to get Decentraland back to where it should be. The OG and the best metaverse. :saluting_face:

While the technicalities of this are outside of my area of expertise, I FULLY SUPPORT any and all ways to get other NFT projects to Decentraland via Linked Wearables. Maybe we need other options outside of the Linked Wearable program? I am thoroughly impressed by how easy it is for projects like A Kid Called Beast, Vipe Heroes, Grifters, etc. to go and be their avatar on other platforms in less than 5 minutes. It's only my opinion, but I think that a metaverse that doesn't easily support your ability to run around as your avatar is antiquated and will not remain relevant in Web3. So far, 2024 has been the year of the VRM download, we have to make it even easier to come be your avatar in Decentraland. Devs, do you own any Beasts, Vipes, PudgyPenguins, Apes, etc. and have run around with them on other platforms? If not, please understand this is a huge part of Web3 culture. People are building their entire brands around their VRM's, and will go wherever they can use them easily.

Is that something that can be hosted on each catalysts instead of a service hosted by the Foundation? It would incur slightly higher cost for the catalyst owners, but as you said the cost is minimal with the current number of requests. Another concern I have is that this solution would remove all flexibility that was possible via a custom API. We will only be limited to NFTs on chains supported by Alchemy (even if they support the most common chains already) and we might be limited by the options offered by this Foundation service, example: mapping one nft to one address or "if this address has any of those nft", but probably not more custom solutions like if this address has between 10 and 20 NFTs from this collection then give access to that linked wearables. Aaron is trying to do a "Golden ApeCoin NFT Shields to the top 690 ApeCoin Holders." for example, that'd probably not be possible with that new solution. https://decentraland.org/governance/proposal/?id=e76cf2ec-f030-4032-92bf-94c315237fe6 Neither would be most of those: https://decentraland.org/governance/proposal/?id=89b36ab8-8121-4b42-adff-947c68c424f7

Hi Kyllian. The new service will be hosted by the foundation but open source. It will only store a map of `chainId:contractAddress:nftId <> Decentraland wearable urn`. Doing this on-chain will incur high costs. Forcing third parties to build their APIs is ok for decentralization but is against mass adoption. It is a tradeoff. We tried the first model and generated a lot of friction, bad experiences for users, and communities facing the impossibility of hiring developers to build and maintain an API for them. About data accessibility, for example, we can create a process to create public DB snapshots. About the NFT API cost, it will depend on the qty of third parties, NFTs and users. There are a lot of NFT APIs out there. We only need to answer the question, "Tell me which NFTs an address has for all of these smart contracts". It is obvious that the current "registration" process needs to change. Third parties may pay the DAO, and part of that can be used to pay the API. For example, the Alchemy one costs $199 for 1.5 billion requests. We are doing 1M requests nowadays.

That proposal is lacking too much information to be a governance proposal. [quote="dao, post:1, topic:22450"] * * Fetching all Linked Wearables for the backpack using a new service that will feed from the builder. [/quote] So the new service will be hosted by the Foundation? We are centralizing a previously decentralized process. [quote="dao, post:1, topic:22450"] This new cost will be covered by a new third-party registration process, but it is beyond the scope of this poll. [/quote] The pricing is quite important when changing the whole linked wearables process. We shouldn't approve this change with those questions still pending. How much will that cost to the DAO? How much will that bring to the DAO? This would make yet another part of Decentraland highly reliant on the Foundation, which I don't think we should be comfortable doing. Redeploying the service is not even a solution to help with this as they say they will keep some data in database, so redeploying the service will be useless without a dump of the database.