casper-ecosystem / cep-78-enhanced-nft Goto Github PK

Bug due to metadata entrypoint querying under incorrect namedkey, resulting in a MissingNFTMetadataKind error

Update the CEP 78 contract: Create a new modality for minting called "limited". This can be used to support whitelisting capabilities in either the contract or account.

Provide contract compatibility for multiple, simultaneous consumers - via a modality for multiple metadata schemas at once (for the same contract).

i.e. extension of nftmetadatakind to support multiple schemas.

TBD:
Configuration settings around Required, Optional, Default.

gas cost of minting tokens should be consistent regardless of how many have previously been minted; currently the costs can be cumulative due to ownership tracking implementation details.

Address cumulative storage cost issue

Problem Statement - Currently, there is a gap in the Assigned and Transfer mode, where the owner of an NFT token doesn't obtain the read-only reference they would if they minted it themselves.
Solution - The transfer function should additionally send the read-only reference allowing users to "claim" their NFT.

believe an Arcadia developer reported this. Will be a challenge to external developers wanting to adopt CEP-78

Requires retooling each version of off-chain smart contract. Want to address for adaptability.

Objective - To implement metadata mutability modality

Currently the only problem we identify is that set_approve_all function has missing entry point parameters, and also it does not check if a token is burnt or not, but we didn't see any high security issue with this.

The dictionary token_issuers stores the first owner of a token. But, the name suggests to me that it's storing the minter of that token. Is it correct?

This is an epic to track the tickets related to cep-78-enhanced-nft standard

Objective - To create an SDK for cep-78-enhanced-nft.

Provide contract compatibility for multiple, simultaneous consumers - via a modality for multiple metadata schemas at once (for the same contract).

i.e. extension of nftmetadatakind to support multiple schemas.

TBD:
Configuration settings around Required, Optional, Default.

When calling the metadata() function an error is raised that says the NFT_METADATA_KIND is not set.
METADATA_MUTABILITY is also not found in storage.
I think I have identified the reason for this issue and will try to resolve it.
The attached screenshots show that the 2 missing parameters are passed to the init() function, but are not defined as parameters for the init() entry point => this explains why they are not set.
I test my fix tomorrow and propose a commit.

https://docs.google.com/document/d/1e7xus87EzHFJ51VqEJeyk9Sfsoo5gOsunW88qFT90RI/edit?usp=meetingnotes&showmeetingnotespromo=true

Add support for batch actions (e.g. batch mint; batch transfer; etc).

Create a roadmap

Objective - To add a modality to the NFT contract for Burnable/NonBurnable.

Update the NFT contract to allow users to specify a schema and provide the functionality to enforce that a minted token's metadata conforms to the schema. Additionally, introduce and implement the MetadataMutability modality that allows users to modify (or prevent) the metadata.

To support the updated SDK for CEP-78, we need to include npm - possibly other libraries. Please work with the engineers to ensure the pipeline is updated to include all dependencies.

Objective - The objective of this epic is to analyse, and create example code and scripts for teams to migrate from cep-47-nft to cep-78-enhanced-nft.

Following are the related tickets created and will be tracked as part of this epic.
Note - There are two possible migration strategies that require a detailed feasibility study as part of this epic/plan.

1. Vanilla cep-47-nft to Vanilla(Enhanced) cep-78-enhanced-nft migration
2. Custom cep-47-nft to Enhanced cep-78-enhanced-nft

• #26
• #27

Aggregating multiple, distinct underlying assets

Close gap in implementation guidance / docs concerning use of WASM client.
(Is a departure from paradigm used in CEP-47 and tripping up external consumers, e.g. IPwe).

output
Infographic + writeup

https://docs.google.com/document/d/1kVw2btNU99N15kpArdZtRE17Xm4AxXf-RV1nWY93Ifs

New NFT Standard Support

so it can cause overwriting previously installed contract on the same account.
maybe it's a good idea to use collection_name as a part of named key?

First make sure the addition of cep-47 events does not break anything, then update the SDK to support both models correctly.

Objective - Solution Architect(s) to produce a design specification for the implementation of cep-78

Definition of Done - Create a design specification that can be referred and used by developers and other teams to build their NFT solution using the cep-78 standard.

This is a new standard, and the intention is that the path forward is a replacement, not an upgrade.

Support for multiple owner accounts to a single token (with fractional shares)

Examine lift involved to port (or replicate similar) event emitter functionality from CEP-47

ordinal, hash - add another "let me decide".

use case: token already has an id in production that does not conform to ordinal or hash.

NEEDS FURTHER IDEATION