ADR-17: Wearable Collection Approval And Economics

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-17
Feedback:
GitHub decentraland/adr (pull requests, new issue, open issues)
Edit this documentation:
GitHub View commits View commits on githistory.xyz

Context and Problem Statement

Decentraland Wearables are a key aspect of the experience. The ability to customize your experience with different wearables and the ability for content creators to come and contribute to the look and feel of Decentraland avatars is key for decentralization.

We currently have a need to add an anti-spam mechanism to the flow; given that the previous designs were not intended to run on L2 and the Ethereum Gas Fees was a high enough barrier to entry.

Considered Aspects for Approvals & Burning

Aspect A: Approval by committee members

The first aspect considered in this proposal is the establishment of a committee of community members with the technical knowledge required to detect and prevent issues with the wearabless anyone creates. These issues include:

Details on the Committee mechanics

Questions from the meeting (and their answer):

Roles, Contracts, Capabilities (without considering L1/L2 bridges):

G dao DAO group Approver's Committee dao->group Set Members (Add, Remove) com_member Committee Members group->com_member has N manager Collections Owner/Manager com_member->manager can approve/reject collections manager->dao  owned by new_collection Collection Contract manager->new_collection can reject        factory Collection Factory factory->new_collection  is deployer of new_collection->manager owned by creator Content Creator creator->factory can deploy new contracts

This graph is illustrative and can vary

Aspect B: Paying MANA to get reviewed

Because the Collection Manager and Factory is going to live in L2, the cost to create a large number of collections and send them for approval might be too cheap relative to the cost of the committee to review and make a decision on approving/rejecting these collections.

Thus, we add a demand for content creators to pay the DAO a fee (maybe in the order of magnitude of 1000 MANA) before any committee member can reject it.

Characterstics:

The fee is decided in base of the amount of items in the collection. It may not be affected by the rarity.

Sequence Diagram: Manual approval of a collection

MarketplaceCommittee MemberContent ManagerContent CreatorMarketplaceCommittee MemberContent ManagerContent CreatorSubmit Collection\n(pays X MANA per item)ApproveEnable Collection

Sequence diagram: Rejection and eventual approval of a collection

MarketplaceCommittee MemberContent ManagerContent CreatorMarketplaceCommittee MemberContent ManagerContent CreatorSubmit Collection\n(pay X MANA per item)RejectModify itemsRe-submitApproveEnable Collection

Aspect C: Staking MANA to issue items

With the goal of managing items that might become uninteresting over time, or maybe invalid as the platform evolves, this aspect allows owners of an NFT to recover some MANA by burning the items.

Questions of the meeting:

Aspect D: Economic Incentives

This proposal has some bad incentives for creators that might not be able to meet the financial requirements to submit a collection. Given that they already have skin in the game because of their dedication and technical work provided, we need some way to re-encourage participation for the issuance of items.

Alternative: Grants

Content creators might submit a proposal to the DAO/Forum requesting for a "Grant to create a collection". Thus, the creator can receive an amount of MANA as a grant that allows them to create a collection, add items to it, and go through the approval process without the financial burden imposed by the submission fees and staking required.

Alternative: Licenses

allowances on-chain for Ethereum addresses to deploy a collection (1 licence = 1 collection).

This way, the community or the committe will decide beforehand.

Decision Outcome Per Aspect

Open Questions

Participants


License

Copyright and related rights waived via CC0-1.0. DRAFT Final