near-sdk-rs | Rust library for writing NEAR smart contracts | Cryptocurrency library

Currently the answer is to copy the mint function from the standard implementation and customize as you see fit.

The better interface will be coming in the future updates.

If I understand the question correctly you'd like to combine nft_mint with some sort of payable action that will pay the original creator of some "NFT token type"?

You can check the NFT Market repo here: https://github.com/near-apps/nft-market

This repository uses a separate market account and contract to allow NFT Owners to put NFTs up for sale. A little more than what you are looking for I think.

There is also a variant that uses "lazy minting" to only mint the NFTs when a user buys them from the market contract: https://github.com/near-apps/gnr8/

Again, it's a little more than what I think you want because the payment and buying is happening in a separate contract and the NFT transfer and minting is happening in the NFT contract, which is called from the market contract.

If you're looking for something to add your own payable NFT method to, you could start with this: https://github.com/near-apps/nft-series/

Which allows you to define an NFT type and you could charge users to mint 1/N of that type by making the nft_mint_type method payable and NOT require the owner of the type to be the minter.

FYI these approaches are non-standard, but work.

Feel free to reach out directly on Discord if you need any help with the examples above.

Here is some implementation of burn:

ValidAccountId is a wrapper around a AccountId, which validates the string to ensure that it is a valid format. This is usually done when deserializing the JSON sent when calling the contract method. However, here you have to be explicit:

Currently there is no API to burn NEAR tokens directly. One workaround is to set the beneficiary account id to system. system is an account that can never be created and is used internally for refunds. When the beneficiary account does not exist, the tokens transferred through account deletion are automatically burnt.

It's a possible situation when escrow allowances > 0, but account balance = 0. Is it legal flow and why?

AFAIU allowance is just a sanity upper bound that prevents abuse. Two accounts can have two allowance for the same account that together sum up to a number larger than account balance.

It never checks account_id exists or not. Why? Is it secure?

In a sharded blockchain it is impossible to check for account existence without an asynchronous cross-contract call, since that other account might live on a different shard. Additionally, by the time we get a reply from that other shard this account can be created/deleted.

Anyone can call: inc_allowance/dec_allowance?

It can be only called by the owner, see: https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L106

And for let owner_id = env::predecessor_account_id(); will be created new account, new escrow allowance automatically (if not exist). Is that logic correct and why?

Yes. I am not sure, why this would be contradictory.

get_account always created a new account. It looks redundant.

It might be redundant, but it also might be optimized out by the compiler in situations like this one: https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L213

transfer_from is never check owner_id as the real owner of the account. Is there logic to protect transferring only by real owners?

It is implied in this check: https://github.com/near/near-sdk-rs/blob/master/examples/fungible-token/src/lib.rs#L174-L180 If it is not the case of an escrow, then env::predecessor_account_id() should be equal to owner_id. So the receipt/transaction must have been sent from the account of the owner.

Why fungible token doesn't have a name/title?

We are working on adding metadata to our contracts, see our Q1 OKRs here: https://airtable.com/shrw0AD36eIbfEW02

Do the NEAR Protocol have some standard or logic for Fungible Tokens exchange?

We have partners working on implementing something similar, but I don't think we have a standard.

Thank you for trudging into uncharted territory! We are still working to publish core crates in nearcore that the simulator depends on. Once we have this, we can publish it. This will stabilize it and you won't get these types of errors.

For now to fix what you have edit your Cargo.toml to the newest tag for both: