ERC-721 is perfect for unique assets, ERC-20 for fungible ones. But what do you do when your project needs both types simultaneously? A typical scenario: in a game, gold and resources are fungible tokens, characters are NFTs, potions are semi-fungible (100 units of one type). Before ERC-1155, this required deploying multiple contracts—expensive and inconvenient. We develop a unified multi-token contract based on EIP-1155 that solves this problem with significantly lower gas overhead. In this article, we'll cover technical details from ID scheme design to OpenSea integration. Our experience shows that switching to ERC-1155 reduces gas costs by 40–60%, saving thousands of dollars per month on active trading volumes. Contact us for a consultation—we'll assess your project in one day.
Comparison: ERC-1155 vs ERC-20+ERC-721
| Criterion | ERC-1155 | Separate ERC-20 + ERC-721 |
|---|---|---|
| Number of contracts | 1 | 2+ |
| Gas for batch transfer | 1 transaction | N transactions |
| Gas savings | 40–60% | — |
| Semi-fungible | Yes | No |
| Operator approval | Global (all tokens) | Per contract |
| Integration complexity | Medium | High |
ERC-1155 performs batch transfers 3 times faster in gas terms compared to separate ERC-20 and ERC-721 contracts, making it ideal for high-volume games.
How batch transfer works in ERC-1155
Key advantage: transfer multiple token types in a single transaction. Instead of N transferFrom calls:
// ERC-721: N transactions for (uint i = 0; i < tokenIds.length; i++) { nft.transferFrom(from, to, tokenIds[i]); // N*gas } // ERC-1155: single transaction erc1155.safeBatchTransferFrom(from, to, ids, amounts, data); // ~gas Gas savings with batch transfer: 40–60% compared to separate transactions. This is critical for games with frequent in-game transfers. In one MMORPG case with 10,000 daily transactions, we cut gas costs by $2,000 per month.
Why use OpenZeppelin for ERC-1155?
OpenZeppelin ERC1155 is a battle-tested base contract. It correctly implements callback safety and includes useful extensions. We always start from it:
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol"; import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Burnable.sol"; import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol"; import "@openzeppelin/contracts/access/AccessControl.sol"; import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155URIStorage.sol"; contract GameItems is ERC1155, ERC1155Burnable, ERC1155Supply, AccessControl { bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE"); mapping(uint256 => string) private _tokenURIs; constructor() ERC1155("") { _grantRole(DEFAULT_ADMIN_ROLE, msg.sender); _grantRole(MINTER_ROLE, msg.sender); } function mint(address to, uint256 id, uint256 amount, bytes memory data) external onlyRole(MINTER_ROLE) { _mint(to, id, amount, data); } function mintBatch(address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data) external onlyRole(MINTER_ROLE) { _mintBatch(to, ids, amounts, data); } } OpenZeppelin Contracts are audited by independent security firms and used in thousands of production contracts.
ID scheme design: our practical approach
For complex projects (e.g., MMORPG with thousands of items), we use bit-packed IDs—different parts of a uint256 encode category, rarity, type, and instance. This allows filtering tokens without storing additional data:
// Example: upper 128 bits = type, lower 128 bits = instance ID uint256 constant TYPE_MASK = uint256(type(uint128).max) << 128; uint256 constant NF_INDEX_MASK = type(uint128).max; function getTokenType(uint256 id) internal pure returns (uint256) { return id & TYPE_MASK; } function isNonFungible(uint256 id) internal pure returns (bool) { return id & TYPE_MASK == id; // instance ID = 0 means base type } This scheme offers flexibility: within one contract you can issue both mass consumables and legendary swords with unique IDs. For projects with simple logic, sequential numbering works—it's cheaper in computation but harder for analytics.
| ID scheme | Flexibility | Gas cost | Use case |
|---|---|---|---|
| Sequential | Low | Low | Simple token collection |
| Bit-packed | High | Medium | MMORPG with categories |
| Hashing | Medium | High | Dynamic properties |
On-chain metadata for simple tokens
For basic assets (game currency, resources), we store attributes directly in the contract, generating JSON via uri():
function uri(uint256 id) public view override returns (string memory) { ItemDefinition memory item = itemDefinitions[id]; return string(abi.encodePacked( 'data:application/json;base64,', Base64.encode(bytes(abi.encodePacked( '{"name":"', item.name, '","description":"', item.description, '","attributes":[{"trait_type":"rarity","value":"', item.rarity, '"}]}' ))) )); } This eliminates dependency on external APIs and reduces censorship risks.
Typical mistakes and how to avoid them
Supply tracking
Use ERC1155Supply and explicit checks in mint. Without it, totalSupply won't update automatically during batch mint.
Reentrancy
_mint calls onERC1155Received. Always apply ReentrancyGuard to prevent reentrancy attacks.
Callback safety
Ensure recipient contracts implement IERC1155Receiver; otherwise safeTransferFrom will revert.
Operator approvals
In ERC-1155, approval is given for all tokens at once. We recommend a whitelist of trusted operators to minimize risks.
What's included in our work
- ID scheme design tailored to business logic
- Smart contract development in Solidity with modular tests (Foundry)
- Deployment on Ethereum, Polygon, Arbitrum, or BNB Chain
- OpenSea integration via EIP-2981 (royalties)
- Full documentation and post-launch support
Why choose us
We have deep expertise in Web3 development, having delivered 30+ projects on Ethereum, Polygon, and Solana. Every contract undergoes internal audit using Slither and Mythril. We guarantee security and standard compliance.
Want to discuss multi-token contract development? Contact us—we'll assess your project in one day. Order ERC-1155 token development with security guarantee and audit.