0xNelliI built an Onchain App: Front-end - Part 1
The code for the first stage of development explored in this article can be found here. Please use this to provide additional context in the event that any parts of this article are unclear. Additionally, if aspects of this article are unclear or do not follow best practices please let me on 𝕏.Project SetupSvelteKit InitialisationAs aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release o...
0xNelliTransparent Proxies & Upgradeability
The Goal of the Proxy PatternSmart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts. Upgradeability is achieved by separating storage and logic. A proxy contract contains the stat...
Fledging Security Researcher | Software Engineer | Onchain Enthusiast
0xNelliI built an Onchain App: Front-end - Part 1
The code for the first stage of development explored in this article can be found here. Please use this to provide additional context in the event that any parts of this article are unclear. Additionally, if aspects of this article are unclear or do not follow best practices please let me on 𝕏.Project SetupSvelteKit InitialisationAs aforementioned in the previous article, I am using SvelteKit to build out my frontend. It is important to note that while Svelte recently announced the release o...
0xNelliTransparent Proxies & Upgradeability
The Goal of the Proxy PatternSmart contracts are immutable, therefore it is not possible to change the logic of a smart contract once it has been deployed. However, the ability to update code is often vital, whether to add new features or to patch critical bugs and defects. This is what the proxy pattern offers to developers, a means of updating code by introducing upgradeability to smart contracts. Upgradeability is achieved by separating storage and logic. A proxy contract contains the stat...
Fledging Security Researcher | Software Engineer | Onchain Enthusiast
Subscribe to 0xNelli
Subscribe to 0xNelli
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
The ERC-1155 standard specifies an interface that supports multiple tokens governed by a single contract. Additionally, tokens controlled by the contract can have different types of fungibility.
Supported fungibility types include:
Fungible (ERC-20 like)
Semi-fungible
Non-fungible (ERC-721 like)
It also introduces a number of QoL features, such as bulk approvals, where one approval applies to all token types held by the contract. This removes the need for users to approve an individual token each time they transact with it. Moreover, it introduces batched transactions. As the contract supports multiple tokens, it provides a mechanism to query balances for multiple tokens in one transaction or to transfer multiple token types in one transaction. Finally, it also implements safe transfers to ensure that the receiving entity supports the ERC-1155 token type.
This fungibility type refers to a token that possesses unique metadata and properties but can be held by multiple addresses. For example, a game may require a key to gain access to a specific level or hidden content. The token representing the key is unique and would have metadata and properties related to the content it unlocks. However, many users of the game may hold the token.
This type of token has characteristics of both an ERC-20 and ERC-721. It represents a unique asset with its own properties and metadata, like an ERC-721. However, these tokens have multiple owners and are interchangeable with one another, as they represent the same asset, much like an ERC-20.
Batch operations introduce significant gas savings as they permit multiple balance queries or transfers to be completed in a single transaction. This is only possible as the ERC-1155 standard maintains the state of multiple tokens in a single contract.
Batch Query Balance:
Queries an array of addresses (accounts) for the balance they hold of the token type id. Returns an array of token balances in the order of the accounts provided to the function call.
balanceOfBatch(address[] accounts, uint256[] ids) -> uint256[]
The length of accounts must equal the length of ids
You can query multiple addresses for the balance of different tokens the contract holds
E.g. query two addresses the balance of gold(fungible), potions(semi-fungible) and unique swords(non-fungible) the each own all in one transaction
Batch Transfer:
You can transfer multiple different types of tokens from one address to another in the same transaction.
safeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] amounts, bytes data);
ids and amounts must have the same length
to must implement onERC1155BatchReceived
OpenZeppelin extended the batch features included in the ERC-1155 standard, introducing a mintBatch and a burnBatch.
Mint Batch:
Mint multiple tokens in one transaction. The mint can also include multiple types of tokens, e.g. mint ERC-20 and ERC-721 tokens to the same address in a single transaction.
_mintBatch(address to, uint256[] ids, uint256[] values, bytes data);
ids and values must have the same length
to cannot be the zero address
The to address must implement onERC1155BatchReceived
Burn Batch:
Burn multiple tokens in a single transaction.
_burnBatch(address from, uint256[] ids, uint256[] values);
from cannot be the zero address
from must have at least the amount of tokens specified in the values parameter of the token represented by the array position
ids and values must have the same length
This is an additional extension that can be used to track the total supply of each of the tokens in the ERC-1155 contract. The only balance related functionality enshrined in the ERC-1155 standard is the balanceOf and balanceOfBatch functions, that only reveal information about the tokens an address holds.
This extension adds the following functions:
totalSupply(id) which returns the total amount of tokens with the id id.
totalSupply() which returns the number of tokens the ERC1155 contract holds.
exists(id) returns a bool as to whether the token of id exists
The ERC-1155 standard specifies an interface that supports multiple tokens governed by a single contract. Additionally, tokens controlled by the contract can have different types of fungibility.
Supported fungibility types include:
Fungible (ERC-20 like)
Semi-fungible
Non-fungible (ERC-721 like)
It also introduces a number of QoL features, such as bulk approvals, where one approval applies to all token types held by the contract. This removes the need for users to approve an individual token each time they transact with it. Moreover, it introduces batched transactions. As the contract supports multiple tokens, it provides a mechanism to query balances for multiple tokens in one transaction or to transfer multiple token types in one transaction. Finally, it also implements safe transfers to ensure that the receiving entity supports the ERC-1155 token type.
This fungibility type refers to a token that possesses unique metadata and properties but can be held by multiple addresses. For example, a game may require a key to gain access to a specific level or hidden content. The token representing the key is unique and would have metadata and properties related to the content it unlocks. However, many users of the game may hold the token.
This type of token has characteristics of both an ERC-20 and ERC-721. It represents a unique asset with its own properties and metadata, like an ERC-721. However, these tokens have multiple owners and are interchangeable with one another, as they represent the same asset, much like an ERC-20.
Batch operations introduce significant gas savings as they permit multiple balance queries or transfers to be completed in a single transaction. This is only possible as the ERC-1155 standard maintains the state of multiple tokens in a single contract.
Batch Query Balance:
Queries an array of addresses (accounts) for the balance they hold of the token type id. Returns an array of token balances in the order of the accounts provided to the function call.
balanceOfBatch(address[] accounts, uint256[] ids) -> uint256[]
The length of accounts must equal the length of ids
You can query multiple addresses for the balance of different tokens the contract holds
E.g. query two addresses the balance of gold(fungible), potions(semi-fungible) and unique swords(non-fungible) the each own all in one transaction
Batch Transfer:
You can transfer multiple different types of tokens from one address to another in the same transaction.
safeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] amounts, bytes data);
ids and amounts must have the same length
to must implement onERC1155BatchReceived
OpenZeppelin extended the batch features included in the ERC-1155 standard, introducing a mintBatch and a burnBatch.
Mint Batch:
Mint multiple tokens in one transaction. The mint can also include multiple types of tokens, e.g. mint ERC-20 and ERC-721 tokens to the same address in a single transaction.
_mintBatch(address to, uint256[] ids, uint256[] values, bytes data);
ids and values must have the same length
to cannot be the zero address
The to address must implement onERC1155BatchReceived
Burn Batch:
Burn multiple tokens in a single transaction.
_burnBatch(address from, uint256[] ids, uint256[] values);
from cannot be the zero address
from must have at least the amount of tokens specified in the values parameter of the token represented by the array position
ids and values must have the same length
This is an additional extension that can be used to track the total supply of each of the tokens in the ERC-1155 contract. The only balance related functionality enshrined in the ERC-1155 standard is the balanceOf and balanceOfBatch functions, that only reveal information about the tokens an address holds.
This extension adds the following functions:
totalSupply(id) which returns the total amount of tokens with the id id.
totalSupply() which returns the number of tokens the ERC1155 contract holds.
exists(id) returns a bool as to whether the token of id exists
No activity yet