- Jul 11, 2023: Initial draft;
IMPLEMENTED
This ADR defines the new architecture of a POAP v2 Smart Contract that will replace the
current cw721-poap, poap-manager, and poap smart contracts.
The name POAP stands for Proof of Attendance Protocol, which is a simple NFT that attests to the fact that a user has participated in a particular event.
Currently, we have implemented the ability to create and manage POAPs with three smart
contracts: cw721-poap, poap-manager, and poap. Although this division works and makes sense under the Single
Responsibility Principle, there are several downsides to it. First, users can easily upload and instantiate multiple
instances of each of those contracts, leading to an unnecessary amount of contracts on the chain. Second, it makes it
harder for newcomers to understand the interactions between the three contracts. Lastly, having multiple smart contracts
for something as simple as a POAP seems excessive, as ideally, a POAP should have minimal operations.
The decision is to merge all POAP-related operations into a single smart contract called poap, replacing all existing
POAP-related smart contracts.
To ensure compatibility with the cw721 standard, we
will create a smart contract that extends
the cw721-base contract and implements the
necessary interfaces. By doing this, we can enable the transfer of POAPs in the future, if desired by the
administrators, and ensure proper display in end clients. The following specifications outline the custom messages that
the poap contract should support.
To instantiate this smart contract, the user needs to provide:
| Variable | Type | Description |
|---|---|---|
admin |
Address | Identifies the user that controls the contract |
poap_name |
String | Identifies the name of the minted NFTs |
poap_symbol |
String | Identifies the symbol of the minted NFTs |
poap_metadata_uri |
String | Identifies the URI where users can view the associated metadata for the POAPs, ideally following the ERC-721 metadata scheme in a JSON file |
The user can also provide the following:
| Variable | Type | Default | Description |
|---|---|---|---|
minter |
Address | Undefined | Additional address that is allowed to mint tokens on behalf of other users |
poap_is_transferable |
Boolean | False |
Specifies whether each POAP can be transferred from one user to another |
poap_is_mintable |
Boolean | True |
Indicates whether users can mint the POAPs |
poap_mint_start_time |
Timestamp | Undefined | Identifies the timestamp at which the minting of the POAP will be enabled. If not set, the minting is always enabled. |
poap_mint_end_time |
Timestamp | Undefined | Identifies the timestamp at which the minting of the POAP will be disabled. If not set, the minting will never end. |
The MsgExecute should allow the following operations:
Operations allowed for any user:
- Mint a new POAP if the minting conditions are met.
- Transfer a POAP they own to another user if transferring is allowed.
- Burn a POAP they own.
If set, the minter associated with the contract should be allowed to perform the following:
- Mint POAPs for a single user (
mintToSingleUser). - Mint POAPs for multiple users (
mintToManyUsers).
Note
Theminteris not subject to the POAP minting conditions. This means that they act like an admin and can mint tokens for other users even if the minting of the POAP is currently disabled.
The admin of the contract should be allowed to perform the following:
- Update the
minteraddress. - Update the POAP-related limitations (transferability, mintability).
- By consolidating everything into a single smart contract, managing POAP instances becomes easier for users.
- Most open issues regarding the POAP system can be resolved, making it more versatile.
- Users of the current POAP smart contracts may need to migrate to the new contract to access future support for new features.
(None known)