Network | Contract Address |
---|---|
Goerli Testnet | 0xFa8f9C0EBD0a2cEA53dfa3c2485e1a8648CaB59e |
- Deployer Address: 0xA63858Ace9838a457139c26886a2d155Cc3dFc2e
- Contract created on Goerli during TxHash# 0x60edeff57d35cd850650ad676cad5280e3e9a2c949332d5d09de4a8ebdceac84
- Deployed version: 5.20.2
Simply put, the proposed contract implementation deploys a "Delegation Management" that exists purely on-chain. This means that all data and their provenance are part of the contract's state.
- It is often the case that wallet owners wish to assign delegation rights (in this context let's refer to assigners as "Delegators") to some other wallet address to act on their behalf.
- A Delegator can assign a delegation address for a specific use case on a specific NFT collection for a certain duration.
- We note that the action of "delegation" does not assign any ownership (including its assets) on the Delegator's wallet.
Use-Case | Action |
---|---|
1 | All (1-15) |
2 | Minting / Allowlist |
3 | Airdrops |
4 | Voting / Governance |
5 | Avatar Display |
6 | Social Media |
7 | Physical Events Access |
8 | Virtual Events Access |
9 | Club Access |
10 | Metaverse Access |
11 | Metaverse Land |
12 | Gameplay |
13 | IP Licensing |
14 | NFT rentals |
15 | View Access |
16 | Sub-delegation |
99 | Consolidation |
-
Interacting with dApps often requires signing of messages for performing certain operations. Accidentally signing a malicious transaction can authorize access to your assets.
-
Delegation assignments make sense in cases where it is extremely risky to connect and sign messages from a cold wallet that is used for storing valuable fungible or non-fungible assets. Delegation addresses can be used to represent a Delegator and act on the Delegator's behalf under certain actions:
-
An action could be:
- claiming token airdrops
- minting tokens from collections that require an entry to their allowlist(s)
- verifying/proving token ownership e.g., apps that implement some token gated policy
- or any other activity that relates to the above use-cases
-
Overall, this contract proposal is useful for use-cases where dApps require a global, on-chain registry that maps the "delegation" relationship between wallet addresses.
-
Current implementation enables the following functionality:
- Delegator assigns a delegation address on a specific use case on a specific NFT collection for a certain duration. The Delegator can assign all tokens or a specific token to the delegation address.
- Delegator revokes delegation rights from a delagation address on a specific NFT collection given a specific use case
- Delegator updates a delegation address for a specific use case on a specific NFT collection for a certain duration
- Batch registrations of delegation addresses
- Revoke all delegation rights assigned by a Delegator
- Functions to change the status of a Global/Collection/Collection&UseCase Lock
- Function that returns an array of all delegations (active AND inactive) assigned by a delegator on a specific use case on a specific NFT collection
- Function that returns an array of all delegators (active AND inactive) given a delegation Address for a specific use case on a specific NFT collection
- Function that returns an array of all active delegations on a certain date for a specific use case on a specific NFT collection
- Function that returns an array of all active delegators on a certain date for a specific use case on a specific NFT collection
- Retrieve functions to get the status (true/false) of a delegation
- Retrieve function to get the status (true/false) of a delegation given a token id
- Retrieve function to check if the delegation address performing any actions is the most recently delegated one
- Retrieve function to check the status (true/false) of an active delegator on a given date
- Retrieve functions to get all the tokends ids as well as the expiry dates of a delegation address/delegator
- Retrieve function to get the most recent delegation address delegated on a specific usecase
- Retrieve function to get the most recent delegator given a delegation Address
- Function to support the subDelegation process
- Function to check if a Consolidation between 2 addresses exists
- Functions to retrieve the status of a Global/Collection/Collection&UseCase Lock
- Other functions that support smart contract's processes like retrieving of hashes etc.
The contract is free from any dependencies.
We took the design decision to implement core functionality and include it as part of the core contract without referring to any external libraries that could (potentially) introduce additional attack vectors or vulnerabilities outside our control; since these are maintained by teams that are outside the control scope of our core implementation. Therefore, we are adopting a self-contained contract philosophy.