elventools / elven-nft-minter-sc Goto Github PK

• there is a problem with the general limit per address when we have the mint process split into drops
• when the drops are set, there should be a limit per drop
• think how to do this best not to mess the code too much

Because of performance improvements, we have some tradeoffs in the user experience. For example, we are forced to run the initial shuffle function. There were changes in the logic, and maybe it could be moved to the init. It shouldn't consume much more gas, and it shouldn't be a problem when SC is upgraded. But it needs a couple of tests.

edit: consider moving it to issue collection token callback maybe?
edit: it will be probably moved to issue_token callback, seems to work ok like that

The only assets, for now, are the ipfs schema with the base CID and the image file name, and additionally, there is an ipfs gateway URI with the same CID and image name.

Some marketplaces require additional Assets/URIs entries like metadata JSON or collection JSON files. IMO this isn't a place for them. The metadata file for the image is encoded in the attributes, and it can include all additional URIs inside.

But I could implement it as an option. Should it be implemented? Can someone explain why marketplaces require that?

The name for NFT is taken from the collection name, which has its limitations: https://docs.elrond.com/developers/nft-tokens/#parameters-format; it would be good to have an option to provide the name for the actual NFT token when deploying the contract and not only use the collection name for that as it is now.

Corresponding CLI issue: ElvenTools/elven-tools-cli#29

There is a lot of new code in the ElrondNetwork organization. The core team started work on a more advanced minter smart contract, similar to this one, but of course, there will be a lot more stuff. There is an excellent way of getting the random indexes for the minting process (at least from what I understand):

• https://github.com/ElrondNetwork/sc-nft-collection-minter/blob/main/nft-minter/src/unique_id_mapper.rs
• https://github.com/ElrondNetwork/sc-nft-collection-minter/blob/main/nft-minter/src/nft_module.rs#L268

It would be good to do some research on that. It will probably remove the need to have the populateIndexes calls for initial setup.

edit: newest elrond-wasm has UniqueIdMapper the same which is used in the sc-nft-minter

There are changes in the SC and CLI. We need to document them.

There is a couple of ways of creating the collection sell and distribution. There should be a longer explainer article. Topics:

• allowlist
• drops
• giveaway
• pausing
• changing prices
• limits per address (per drop)

If there are only 5 NFTs left to mint and you mint 6 NFTs at once the transaction will fail.
The mint should loop through each mint and check if's available for minting. Or this will trigger more gas fees?

It would be good to have a docs section on elven.tools website with examples written for erdpy CLI usage for every endpoint and query. This will also be a perfect occasion to test all of them with erdpy properly.

Just a reminder: It is much simpler when you are using the CLI

There is a bug related to a setting or unsetting drops. The logic assumes that it will clear related storage, but it takes too much gas when there are many items already.

Until solved, the functionality of the drop will be unusable (with CLI in most cases, without the CLI, it can work for drops with a small number of tokens and adjusted gas limits)

The 'pause and resume minting' functionality could be used as a temporary workaround.

I use elven-tools nft-minter , the problem is on explorer for collection now appear 2 more things Rarities and Attributes there u have a link : https://explorer.multiversx.com/nfts/STAFF-1b295e-13

And there is my explorer thing : https://devnet-explorer.multiversx.com/nfts/NATURE-bc41aa-02

u can do something about that , a little update for that creator , i use windows and i like more to work on windows than ubuntu and i don t know at all to use mxpy or erdpy cuz i started learn what u created there :))

It would be nice if you are trying to pre-mint a collection to be able to mint all the NFTs from the creator wallet not having to pay the mint price as it just gets sent to the same wallet (and royalties).

Maybe a CI flag or something? Happy to see if I can implement it, but I am very unfamiliar with rust.

Thanks for your work so far. It's awesome.

I had a use case that I needed the ability to turn on minting, but only want the owner of the collection to be able to mint. This is because we have a controlled collection that I don't want to be publically purchasable (yet). I went ahead and coded that functionality into the SC & the CLI as commands.

I'll attach a PR so you can check it out. I am not in love with my naming convention...

A separate issue because the SC would need some more work and tests. I think the sha256 custom logic could be removed and replaced with self.crypto().sha256_legacy_managed::<>(), but it will need some tests.

Hey @juliancwirko, I am using the minter SC since April and I wanted to upgrade it to the new version.

To do so I have to update is in .elventoolsrc with the version I want to target

{
    "chain": "mainnet",
    "nftMinterSc": {
        **"version": "v1.10.0",**
        "deployNftMinterSC": "erd1qqqqqqqqqqqqqpgq......."
    }
}

And then I have to trigger the init endpoint with elven-tools nft-minter init ?

Is it the only things to do ?

The Elrond's API service will take the data from the metadata JSON file and recreate the metadata object to be returned when calling the nft API endpoint, similar to the custom ipfs gateway and media object. The process is probably optimized and delayed. They won't be created after the NFT was created but after some time. What should be done here is good research on the API repository to be 100% how it works precisely. There are also probably differences between different NFT endpoints (id, search, etc.).

If someone has more info about that, please jump in.

• giveaway endpoint is only for the owner, but it doesn't respect the limits per address, so it needs some checks and improvements for big amounts in one transaction because it will reach the max gas limit per one transaction - it should be probably also improved for the standard mint endpoint. Something around 55 tokens per one transaction should be ok. So it will likely be never reached because most of the collections will add lower limits than that. But it should adequately handle that.

• review the initial mappers' setup
• add set_if_empty instead of set wherever it makes sense, not to overwrite these when upgrading, for example, cids, provenance, etc.

I don't think it's intuitive that you need to have image names starting at number 0 (instead of 1).

0.png <--
1.png

I would expect that it would start at 1. Not sure if this was a change that was introduced in the new shuffle mechanism or what!

Example tx: https://devnet-explorer.elrond.com/nfts/NTLPRK-c73cc4-01

It would be good to have something like esdt_nft_create_as_owner, but It isn't possible.

There will be a payable by smart contracts code metadata option, so it will probably be the final solution for now.

It should land in v0.27.0, so changes to the CLI would be required

The shuffling mechanism requires some optimization or a different approach because there are problems with gas when there are a lot of minted tokens already. It works well initially, but when there are more and more tokens minted, the mint endpoint starts to fail.

getTotalSupply, isMintingPaused, getTotalSupplyOfCurrentDrop

https://stackoverflow.com/questions/71108759/vecmapper-extend-from-slice-differences-between-testnet-and-devnet

There are some limitations regarding Rust's dynamic allocation, which can cause some sc calls to fail. We recommend using managed types instead, which only allocate memory inside the VM, or use static buffers.

The simplest and fastest solution is to use only VecMapper and 'push', which will consume over twice as much gas. As a temporary solution, it should be a quick fix.

The shuffle mechanism works well when minting, but there was a problem with the shuffle open endpoint. It should be available for everyone, but the logic needs to change. For now, as a workaround fix, there will be a possibility to call it only once after deployment and only by the owner. I will work on the final solution soon.

v1 is a candy machine like Smart Contract. I think in v2, I could try to implement raffle-like SC. Let's see.

The Smart Contract takes only the EGLD as payments and operates only on EGLD. Research on payment with ESDT is required.

Question: How do marketplaces manage royalties? Shouldn't they use sell_nft, which is design for that?

For now, this smart contract is open for taking royalties and has an option to claim the funds on it (by owner only), but if marketplaces don't send them automatically, we are missing a claim_royalties_from_marketplace endpoint. IMO, the contract owner should think only to make the contract payable. Otherwise, the owner of the contract needs additional logic to get royalties.

How do marketplaces manage that?

• automated tests are required

waits for black-box testing docs (??)

Add remove address from allowlist option and test how big impact on performance and gas usage will have to clear a big list at once.

Maybe the solution would be to use an abstraction over singlevaluemapper like here: https://github.com/ElrondNetwork/elrond-wasm-rs/blob/master/elrond-wasm/src/storage/mappers/whitelist_mapper.rs

It could also be good to split into a couple of allowlists the same as 'drops,' using the id of the allowlist.

It would be great to change the royalties, if it's possible on Elrond chain and it's not encoded on the SC at deploy.
But also make a limitation, to avoid very high changes after the launch.
If it's set to 20% at deploy, you can change it only 1-10% after that.

For now, in the assets in the explorer, there are two uris for the same image. One with the ipfs:// schema and one with the ipfs.io gateway. I think it is worth removing the gateway entry and leaving only the ipfs://schema-based URI. There are at least three reasons:

1. There is an Elrond gateway anyway, so everyone can use it or take the cid and use a different gateway.
2. The Explorer is now supporting previews also for the ipfs:// based uris (on hover)
3. It is misleading for many people. They see one gateway, and then there is another one after mint. With the ipfs:// based uris, it will be more precise.
4. It will also be better for the SC because the performance will be better.

Cons:

1. You won't be able to click on the link in the assets section in the explorer. You would need to use the gateway with the displayed CID.
2. Again, I don't know what with marketplaces. They shouldn't rely on the assets link as a whole. They should have their logic for that.

https://github.com/juliancwirko/elven-nft-minter-sc/blob/afb9444a62d6e9cc3f232247c3e26867c6fbb382/src/lib.rs#L332

If tokens variable is not sent in the transaction then it's 0 at the time you verify if you have enough tokens to mint.
This is before you set tokens to 1.

https://github.com/juliancwirko/elven-nft-minter-sc/blob/afb9444a62d6e9cc3f232247c3e26867c6fbb382/src/lib.rs#L344

Hi sorry to open the topic again, how do I add the stuff in the picture (Social, Atributes and Rarites)
And if you can't use what you have created for the moment, do you think you can make an update please?

Soon I want to get a collection of NFTs, and I would like to add these because I don't know how to use mxpy or erdpy, no matter how hard I try to install them there are a lot of problems .....

Link :
https://explorer.multiversx.com/nfts/COW-cd463d-16af

• minting enabled after public sale starts, allowlist has the priority

When issuing:

pub struct NonFungibleTokenProperties {
    pub can_freeze: bool,
    pub can_wipe: bool,
    pub can_pause: bool,
    pub can_change_owner: bool,
    pub can_upgrade: bool,
    pub can_add_special_roles: bool,
}

and special roles: https://docs.elrond.com/developers/nft-tokens/#roles
ESDTRoleNFTCreate is mandatory, and it is already handled