_mintSingle is exposed as external and I believe this should be restricted to internal because :

• This can lead to unexpected behaviors if used by others without being aware that the function can mint tokens
• The contract should be flexible in a way to use the core implementation without the need to delete undesirable behaviours
• The function is not part of ERC1155

PS: Thanks for sharing this implementation.

Summary

This function allows the devs (or a friendly whale, if desired) to prepay some of the gas for minting. Setting the _owners storage from address(0) to the owner costs 22,100 gas (20,000 storage + 2,100 cold access).

Addresses are 20 bytes long and don't use the left 12 bytes. This function sets the leftmost bit to 1. It leaves the other bits unaffected. This is to safeguard against someone overwriting addresses after mint.

This can result in net savings for the community if the gas is prepaid during a cheap period, and minting happens during an expensive period.

Unit Economics

It costs 5,000 gas to go from non-zero to non-zero storage. By prepaying 22,100 gas, the minter saves 17,100 gas. It would seem that 5,000 gas is "wasted." However, this can result in a net gain for the community if done during a low congestion period. Example:

low gas period: 20 gwei minting period: 100 gwei

Cost in Ether to prepay the storage slot: 20 * 22,100 / 1 billion = 0.000442 Cost in Ether to store new address during mint with prepayment: 100 * 5,000 / 1 billion = 0.0005 Cost in Ether to store new address during mint sans prepayment: 100 * 22,100 / 1 billion = 0.00221

Net savings: 0.00221 - 0.0005 - 0.000442 = 0.001268 Ether per address. This is substantial when thousands of addresses are involved.

Implementation Details

If thousands of addresses are involved, the prepayment must be done in several transactions to avoid running into the gas block limit. Thus, start and end are provided to enable breaking up the transaction.

If the devs so desire, they can incentivize early minters by prepaying only the first hundred or so token ids.

Credits

This methodology was inspired by https://gastoken.io/

Notable changes:

• Reorganizes to a hardhat project structure
• Adds the basic tests and test dependencies in tests/
• Adds contracts/Mocks for unit tests
• Adds hardhat-config
• Converts GitHub imports to @openzeppelin package imports

tl;dr

This PR has a lot in it, the main changes are:

• moving the contract to the contracts folder
• changing imports to @openzeppelin imports (for hardhat compilation the tests runner can read)
• addition of test and mocks

ERC1155.test.js is the main Unit test entry point. to run tests, install dependencies with yarn then npx hardhat test tests/ERC1155.test.js

The other folders and files inside tests are additional utils and tests the main test file needs.

Mocks

the mock contracts are also used for unit tests and must be included-they also act as sample implementations

all tests passing.

84 tests are run and pass, these are the same tests used in the ERC1155 token tests from OZ, with the modification that calls to _mint only pass in an amount of 1

I took the liberty of adding to the readme. open to changes there. 🙇

Fixes a typo that prevents tokens from being transferred when calling _safeBatchTransferFrom Previously, was failing silently while passing all checks and emitting events while not actually transferring the tokens.

Hi @DonkeVerse @jeffreyscholz

I am building two ERC1155 NFT implementations that also restricts themselves for 1/1 NFTs applications, and I am wondering whether we can have a common interface that can potentially be a standard in the future.

• https://github.com/ctor-lab/ERC1155Delta
• https://github.com/ctor-lab/ERC1155Soul

Since the implementation of ERC1155Delta doesn't allow querying the ownership information from the id in order to achieve constant-gas batch minting. Therefore, ownerOfERC721Like will not work in this implementation.

Instead, I am proposing to use the following interface for the ownership verification purpose.

 function isOwnerOf(address account, uint256 id) external view returns(bool);

Also, adding this interface to supportsInterface so the third-party contract can recognise it and enables applications that is only available to 1/1 NFTs.

Read your article regarding this on Medium, and thank you for putting this together.

When using the ERC1155, my use case was a collection of items, but there will always be just 1 item. I know I could use EIP721, but I'm really enjoying the gas savings.

On my mint and reserve functions, I always set "amount" to 1, as you suggested. But for batch transfers, I implemented the following. Curious if this is overkill or not. Here, I always want to ensure the "amount" will able be 1. I wasn't sure if this would already be taken care of due to the minting function.

function _beforeTokenTransfer(address operator, address from, address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data)
        internal
        whenNotPaused
        override
    {
        uint256[] memory _amounts = new uint256[](ids.length);

        for (uint i = 0; i < ids.length; i++) {
            _amounts[i] = 1;
        }

        super._beforeTokenTransfer(operator, from, to, ids, _amounts, data);
    }

If this isn't the correct place to ask this question, totally understand and can move it over to the Medium article.