Custom ERC1155 contract

[hensha256]

This will enable us to have optimisations and simplifications over the generic OZ one.

Personalisation of the transfer function:
If the to address is the PoolManager, and the PoolManager is locked, automatically burn the tokens and update the account delta - no need to call the receiving hook

[moodysalem]

probably also want to have a permit-style function in the 1155

[hensha256]

As written by @moodysalem in #132 we could also have a temporary approve method using TSTORE

temporary approve would be a method that uses a transient storage slot to store the approval, and that allowance would be used before a persistent storage allowance

[MicahZoltu]

Implement ERC1155Metadata_URI and use an IPFS URI for token metadata, or don't use EIP-1155.

---

Currently, there is no way to render an EIP-1155 token, transfer, or balance in a privacy preserving way because getting the name, symbol, and decimals (a requirement for rendering the token in a way meaningful to the user) requires making a request to a third party endpoint which reveals the user's IP and which token they are looking at to a centralized third party.

On top of that, with all of the metadata off-chain there is a data availability and censorship problem where the centralized server publishing the metadata may disappear in the future or censor users from certain IP addresses, at which point the user just has an address and an amount that they can't make sense of.

You can partially mitigate the problem by using an ipfs:// URL, but this still suffers from a potential data availability problem as IPFS doesn't have any availability guarantees. Also, an ipfs:// URL will need to be manually handled in most browsers for the time being.

My recommendation is to create a new token standard that stores token metadata on-chain, as it makes integrations substantially easier and doesn't take much space per token relative to other storage costs (e.g. balances). An implementation could pack decimals (1 bytes), symbol (8 bytes), and name (23 bytes) into a single storage element if they wanted, and you could have a description and image that are the same across all tokens within a given ERC-1155 contract.

If you are set on using 1155, then the metaadata URI extension should be added since ancient events should not be relied on for data storage and the URI should be an immutable variable that points to an IPFS content hash with ipfs:// scheme. This means that your metadata will need to be the same for every token, since you can't trustlessly update the URI for 1155 tokens.

[zerosnacks]

A tip if you are looking to start with a highly optimized ERC1155 base contract: https://github.com/Vectorized/solady/blob/main/src/tokens/ERC1155.sol

[netnose]

@MicahZoltu i think that a data URI can be a good fit. It respects EIP-1155 and preserves users privacy.
Solidity can build data URIs dynamically and the impact on gas fees is just on deployment phase.

Uniswap v3 uses this strategy: https://github.com/Uniswap/v3-periphery/blob/main/contracts/libraries/NFTDescriptor.sol

[MicahZoltu]

A data-URI generated on chain is a neat workaround, and I would accept that as being immutable, trustless, and censorship resistant. It seems quite gas wasteful compared to just storing the data in a native format, but if one insists on using EIP-1155 this is a good workaround!

[netnose]

Why do you think it is gas wasteful?
The functions returning the data URIs will be used in reading operations, are gas-free.
Data used to build the URIs is already stored on-chain and no additional storage is required to build them.

Am I missing something?

[MicahZoltu]

Good point about callers being off-chain. And I suppose you can pre-construct most of the data-URI and only fill in the specific unit details when you construct it. Consider me convinced on the data URI solution!

[zhongeric]

Closed by #379