Network | Deployer | Contract Address |
---|---|---|
Ethereum | 0x707e25f...C74bc6eE8F | 0x2202cb9c00487e7e8ef21e6d8e914b32e709f43d |
Polygon | 0x707e25f...C74bc6eE8F | 0x2202cb9c00487e7e8ef21e6d8e914b32e709f43d |
Binance SC | 0x707e25f...C74bc6eE8F | 0x2202cb9c00487e7e8ef21e6d8e914b32e709f43d |
Avalanche | 0x707e25f...C74bc6eE8F | 0x2202cb9c00487e7e8ef21e6d8e914b32e709f43d |
Klaytn | 0x707e25f...C74bc6eE8F | 0x2202cb9c00487e7e8ef21e6d8e914b32e709f43d |
Arbitrum | 0x707e25f...C74bc6eE8F | 0x2202cb9c00487e7e8ef21e6d8e914b32e709f43d |
Network | Deployer | Contract Address |
---|---|---|
Sepolia | 0xAcf42B8...DE9953c2a0 | 0x8f86c644f845A077999939C69Bc787662377d915 |
Simply put, the contract deploys a "Delegation Management Registry" 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.
- The action of "delegation" does not assign any ownership over—nor control of assets in—the Delegator's wallet.
-
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 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.
#N | Use Case |
---|---|
1 | All |
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 | Manage Access |
17 | Mint To Address |
18 | Team |
19 | Artists |
20 to 949 | Reserved by NFTDelegation.com for future active (canonical) use cases |
#N | Use Case |
---|---|
950 to 997 | Reserved for Future Special Use Cases |
998 | Delegation Management (Sub-delegation) |
999 | Consolidation |
Note: Special Use Cases are not captured by Use Case #1 ("All").
#N | Use Case |
---|---|
1000+ | Application-specific use cases |
-
Use cases #1 to #19 are active canonical (official) use cases.
-
#20 to #949 are reserved for additional canonical use cases, to be added from time to time by NFTDelegation.com.
-
#950 to #997 are reserved for future Special use cases.
-
#998 is for Delegation Management (Sub-delegation) (giving the right to another address to add or remove delegations on the initial address's behalf).
-
#999 is for Consolidation (linking addresses together).
-
#1,000+ are available to any team who wants to create an application-specific use case.
-
Any team can call the updateUseCaseCounter() function to increment/create another use case for their own use.
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
- Batch revocations of delegation addresses
- 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 the tokens ids as well as the expiry dates of a delegation given a delegator/delegation address
- 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 registration of Delegation Managers
- Function to check the consolidation between 2 addresses
- Other functions that support the smart contract's processes like retrieving of hashes etc.
Want to learn more? Explore documentation
Write Functions
Retrieve/Read Functions
Delegation Management (sub-delegation) allows you to reduce the number of delegation transactions you perform with your "Vault Wallet" by delegating all contract interactions, including changing delegations, to a "Delegated Wallet." This ensures your Vault remains cold (not connected) after the initial Sub-delegation.
With your "Vault Wallet" you just need to perform one transaction registering a delegation address with Delegation Management (sub-delegation) rights. (See how to register a delegation address). Then you can use your sub-delegated wallet to register a delegation address on behalf of a Delegator.
A consolidation is used when you want to establish an ownership connection between two addresses, such as combining the Total Days Held (TDH) of multiple wallets that you control on seize.io.
To create a consolidation between two wallets (e.g., Wallet A and Wallet B), both wallets must register a consolidation with each other. This means that you need to register a delegation address with consolidation from Wallet A to Wallet B and vice verse, in a second transaction: from Wallet B to Wallet A.
The contract is free from any dependencies.
We made 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.
Sample hardhat tests are provided.
- Download the github repo
- Open command prompt and navigate to the hardhat folder
- Install hardhat using
npm i
- Compile smart contracts using
npx hardhat compile
- If you get
Error HH502
then please upgrade to the laetst hardhat -npm up hardhat
- Run the tests that exist within the test folder using
npx hardhat test