You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Where is this metadata stored? - The Jetton standard supports storing metadata either on-chain or in an off-chain URL (a JSON file hosted somewhere). It is our belief that the best practice is storing metadata on-chain. Why? Let's explore the alternatives:
On-chain - On-chain data is immutable, users can be guaranteed that important fields like the symbol will not change without their consent. On-chain data is also guaranteed to always be available. This deployer always stores metadata on-chain.
Off-chain IPFS (ipfs:// URL) - IPFS data is immutable so it's safe like on-chain. But IPFS data is not guaranteed to always be available. Availability depends if someone is willing to pin the data (similar to seeding in torrents). If this someone goes out of business or suffers downtime, token metadata will disappear. This is an unnecessary risk in our eyes.
Off-chain website (https:// URL) - This is by far the worst option. The owner of the website could change the metadata without user consent (not necessarily on purpose if the website is hacked). The website can also be taken down and the metadata will disappear. Users should never invest money in tokens that have their metadata stored this way.
What about the Jetton Logo URI, if it's stored on a website, can't it change? Yes, it can change and this is a feature. We believe that logos can go through rebranding without putting users at risk. Satoshi Nakamoto didn't design the current logo of Bitcoin when he wrote the initial code.
Scaleton already has partial support for jettons created with metadata onchain, because it allows importing by address and then transferring them. We think it would make an important addition to support reading the metadata from the chain and displaying the name & symbol automatically.
An example code for parsing such metadata can be found here
The text was updated successfully, but these errors were encountered:
Creator of the open source Jetton Deployer here.
We have chosen to store jettons deployed with our tool on-chain.
Quoting from our readme on the issue:
Where is this metadata stored? - The Jetton standard supports storing metadata either on-chain or in an off-chain URL (a JSON file hosted somewhere). It is our belief that the best practice is storing metadata on-chain. Why? Let's explore the alternatives:
On-chain - On-chain data is immutable, users can be guaranteed that important fields like the symbol will not change without their consent. On-chain data is also guaranteed to always be available. This deployer always stores metadata on-chain.
Off-chain IPFS (
ipfs://
URL) - IPFS data is immutable so it's safe like on-chain. But IPFS data is not guaranteed to always be available. Availability depends if someone is willing to pin the data (similar to seeding in torrents). If this someone goes out of business or suffers downtime, token metadata will disappear. This is an unnecessary risk in our eyes.Off-chain website (
https://
URL) - This is by far the worst option. The owner of the website could change the metadata without user consent (not necessarily on purpose if the website is hacked). The website can also be taken down and the metadata will disappear. Users should never invest money in tokens that have their metadata stored this way.What about the Jetton Logo URI, if it's stored on a website, can't it change? Yes, it can change and this is a feature. We believe that logos can go through rebranding without putting users at risk. Satoshi Nakamoto didn't design the current logo of Bitcoin when he wrote the initial code.
Scaleton already has partial support for jettons created with metadata onchain, because it allows importing by address and then transferring them. We think it would make an important addition to support reading the metadata from the chain and displaying the name & symbol automatically.
An example code for parsing such metadata can be found here
The text was updated successfully, but these errors were encountered: