Enable Delegations in Decentraland Protocol

by 0x87956abc4078a0cc3b89b419928b857b8af826ed (Nacho)

Linked Draft Proposal

Enable Onchain Delegation Support in Decentraland Protocol

Summary

This proposal aims to integrate wallet delegation support into the Decentraland protocol by leveraging the Catalyst network.

Abstract

Currently, Decentraland users are limited to a single wallet per profile. This design restricts users from showcasing the full extent of their NFT collections, especially those stored in more secure, offline wallets. Furthermore, companies building on Decentraland and offering wearables often face friction when interacting with users who utilize multiple wallets, particularly in Web2 login flows that abstract wallet management.

This proposal suggests enabling support for wallet delegation mechanisms, allowing users to delegate ownership rights from secure wallets to hot wallets or Web2-managed wallets. This change will require Catalyst's changes to support delegation checks when validating wearable ownership during profile deployment.

Another use case could be enabling LAND owners to grant deployment rights through delegations.

Motivation

This proposal has been created based on the following pillars:

• Security: Users are currently incentivized to keep valuable NFTs in hot wallets for in-world use, which increases the risk of loss.
• Usability: Delegation would enable users to showcase and utilize assets from multiple wallets, enhancing the experience for collectors, creators, and companies using Linked Wearables.
• Adoption: Organizations using Web2 login solutions (like Magic and those using not fully supported Smart Contracts Wallets) face friction due to wallet fragmentation. Delegation would streamline integration and user experience.
• Protocol scalability and modularity: Supporting delegation introduces a standardized method for expanding wallet logic without custom integrations.

Specification

After researching existing delegation standards like Snapshot and delegate.xyz, we concluded that none of them are fully suitable for our needs, each has critical limitations that prevent direct integration. Instead of relying on an external protocol, we’ve decided to take the best ideas from each and implement delegation directly within the Catalyst network as a new entity type.

This approach ensures that all delegation data is:

• Verifiable through the existing Catalyst network (just like Decentraland asset deployments),
• Low-latency, since validation happens within the same infrastructure,
• And trustless, without needing to depend on third-party services or architectures.
• Modify the Catalyst logic responsible for NFT ownership verification during profile deployment:
  • Currently: Check if the user's address owns the NFT.
  • Proposed: Check if the user address owns or has delegated access to the NFT through an approved delegation registry
• No further changes are required at the protocol level.
• We may need to enhance the SDK and Client support.

Impacts

• This change does not introduce any new negative risks. Since delegation will live within the Catalyst network, alongside deployments, it shares the same availability characteristics. If the Catalyst network goes down, both asset deployments and delegation data would be temporarily unavailable, as expected.
• The size of the Catalyst database will grow due to the new delegation data. However, database storage remains relatively inexpensive, and we can implement compression strategies later to optimize storage usage.
• For users who set operator rights for LAND deployments, this approach will significantly reduce costs, as delegations will be handled entirely through the Catalyst network without incurring any transaction fees.

Implementation Pathways

1. Delegation Entity Format

We will define a new entity type within the Catalyst network to represent delegations. This entity will use a URN format to ensure consistency and indexability:

urn:decentraland:polygon:delegation:{wallet_in}

Example: urn:decentraland:polygon:delegation:0xNacho

In this case, 0xNacho is delegating the usage of their assets to other wallets

2. Payload Format

Each delegation entity will store a JSON payload with three optional delegation scopes:

• TYPE_ALL: Delegates all assets from the wallet.
• TYPE_CONTRACT: Delegates all assets from a specific collection (contract).
• TYPE_NFT: Delegates a specific NFT (contract + token ID).

{
  "TYPE_ALL": {
    "wallet_out": "0xNico",
    "expiration": 1746528746
  },
  "TYPE_CONTRACT": [
    {
      "wallet_out": "0xMati",
      "contract": "0x8a7643522886f60352e041b67b788dcf0f3666dc",
      "expiration": 1746528746
    }
  ],
  "TYPE_NFT": [
    {
      "wallet_out": "0xYemel",
      "contract": "0x8a7643522886f60352e041b67b788dcf0f3666dc",
      "token_id": 1,
      "expiration": 1746528746
    }
  ]
}

At least one delegation type must be defined to grant permissions. However, if the user wants to remove/revoke all delegations, they can simply submit an empty payload, like this:

{}

3. Delegation Resolution Logic (examples)

• 0xNico can use all wearables and emotes owned by 0xNacho, except those from collection 0x8a76...6dc.
• 0xMati can use all assets from collection 0x8a76...6dc, except token ID 1.
• 0xYemel can use only token ID 1 from collection 0x8a76...6dc.

4. Catalyst Integration

• This delegation payload will be deployed and validated like any other Decentraland entity (e.g., scenes or wearables).
• The content-validator must be updated to:
  • Accept and validate this new entity type deployment
  • Update the logic for Decentraland assets deployment to include delegations
    • Fetch valid delegation entities for a given wallet_in and wallet_out.
    • Validate access based on wallet, contract, and token ID.
    • Respect expiration timestamps.

5. UI & Client Integration

• A UI piece must be implemented to allow users to add, edit, and revoke delegations.
• On the client side backpack:
  • Users should see and filter both:
    • NFTs they’ve delegated to others. If the user has delegated an asset, it won’t be in the backpack
    • NFTs delegated to them
• In the case of LAND deployments, the creator hub and SDK CLI must be updated

Conclusion

Adding wallet delegation support enhances Decentraland’s security, flexibility, and inclusivity. It empowers users to keep their assets safe without sacrificing usability, and it removes friction for users and projects integrating with Web2 login solutions, as well as those using Linked Wearables. By incorporating a delegation standard, Decentraland can evolve without introducing proprietary complexity, enabling a safer and more seamless user experience.

This proposal is summarized due to technical limitations. To view it complete and vote on it, visit the DCL DAO Governance dApp