Title: Discussion_on_ERC_7583_for_Inscribing_assets_in_sm
Category: ERCs

Author: ins-evm
Date: 2023-12-26T16:45:12.216Z

Hello everyone,
I’m excited to share with the community a proposal I’ve been working on, aimed at introducing a standard for enabling tokens to be traded both as fungible tokens and non-fungible tokens on the Ethereum. This initiative seeks to establish a unified approach to handling inscription assets on the Ethereum blockchain, enhancing consistency and interoperability of inscription assets across different applications and platforms.


github.com/ethereum/ERCs








Add ERC: Inscription In Smart Contract


master ← insevm:master



          opened 04:34PM - 26 Dec 23 UTC




            shalom-ins
          



+1021
-0






## ERC7583: A framework for inscription assets within EVM.

This EIP proposes …a standardized method for enabling tokens to be traded both as fungible tokens and non-fungible tokens on the Ethereum, providing the necessary flexibility for tokens to function in both capacities. Furthermore, this standard incorporates a standard to embed inscription data within event data. This addition allows for the inclusion of immutable, extra information directly on the Ethereum.






Overview of the Proposal: This protocol represents the implementation of the BRC20 standard within the EVM. BRC20 enables FTs to be traded in the same manner as NFTs. And ERC-7583 not only facilitates the trading of FTs akin to NFTs but also allows for the binding of NFTs with FTs. This integration enables FTs within NFTs to participate in existing DeFi protocols, significantly enhancing the liquidity of NFTs.
You can find the detailed proposal here: ERC-7583 Inscription Standard in Smart Contracts
I believe this proposal can significantly contribute to the Ethereum ecosystem by providing a standardized way to handle inscription assets, which is currently lacking. It has the potential to open up new possibilities for developers and users alike.
Seeking Feedback: I would greatly appreciate any feedback, suggestions, or concerns you may have regarding this proposal. Your input is invaluable in refining and improving this EIP before moving forward.
Looking forward to an engaging and constructive discussion. Thank you for your time and consideration!

Author: HarryLin1024
Date: 2023-12-27T00:06:20.024Z

Why not upgrade directly on the basis of ERC-20?

Author: ins-evm
Date: 2023-12-27T01:47:02.669Z

HarryLin1024:

Why not upgrade directly on the basis of ERC-20?


Because inscriptions can be applied not just to ERC20 tokens, but they are capable of storing any type of data, including images (thus applicable to ERC721), HTML, and even binary files.

Author: alongdlut
Date: 2023-12-27T02:35:37.705Z

Is there any security concern compared to inscription on Calldata?

Author: ins-evm
Date: 2023-12-27T14:55:02.780Z

rex5999:

You are a liar and a thief. You stole the idea of ​​token ethv and now you want to deceive everyone here?


If you possess the similar understanding, I am thrilled, as it means we are kindred spirits. Cheer up, brother! This is an excellent platform where you can express your opinions. A market with immense potential awaits your exploration!

Author: rex5999
Date: 2023-12-27T15:10:46.408Z

You claim that you are the first inscription published on EVM. What is the truth?

Author: ins-evm
Date: 2023-12-27T15:11:30.820Z

alongdlut:

Is there any security concern compared to inscription on Calldata?


We will see calldata limited in each block and pruned over time to address storage implications on scalability in the future phase “The Surge”

Author: ins-evm
Date: 2023-12-27T16:00:26.409Z

rex5999:

You claim that you are the first inscription published on EVM. What is the truth?


image2148×294 54.7 KB
I don’t want to discuss topics here that are not helpful to Ethereum.

Author: SatXt
Date: 2023-12-27T20:43:12.751Z

Hey is there a guide om how to inscribe f on etherscan?

Author: ins-evm
Date: 2023-12-28T01:04:28.593Z

What’s the mean of the “f”?

Author: SatXt
Date: 2023-12-28T03:39:36.174Z

Oh sorry that was typo.
I believe I meant how do we convert the data to inscribe into a hash

Author: ins-evm
Date: 2023-12-28T03:53:55.725Z

SatXt:

Oh sorry that was typo.
I believe I meant how do we convert the data to inscribe into a hash


It’s ok!
In various situations, inscribed data needs to be decode for displaying. So we just encode data to bytes and inscribe into smart contract. Sometimes, we also calculate the hash of the data before inscribing it, depending on the specific requirements of your project.

Author: TUTUBIG
Date: 2023-12-28T04:07:45.557Z

ins-evm:

excited


I think it would be better to add “from” and “to” addresses in this event, like event Inscribe(address from,address to, bytes data)  This will be more convenient to descripe the owner exchange of this inscription.

Author: zzzz
Date: 2023-12-28T06:52:07.326Z

Sir, a good idea is certainly important. Have you considered establishing a community belonging to INSC on DC or TG, so that more like-minded friends can join this discussion? This project is fantastic

Author: FancyKing
Date: 2023-12-28T10:30:43.582Z

By carrying the inscription through events in the EVM and making the inscription compatible with the EVM, will there still be the disadvantage of excessive gas cost? How to solve this?

Author: ins-evm
Date: 2023-12-28T15:29:30.143Z

TUTUBIG:




 ins-evm:

excited


I think it would be better to add “from” and “to” addresses in this event, like event Inscribe(address from,address to, bytes data)  This will be more convenient to descripe the owner exchange of this inscription.


Indeed, the recording of inscribed transactions is missing. However, I believe that inscription event should be treated as a separate event, distinct from the transfer event.
How about this:
interface IERC7583 {
  event TransferIns(address indexed from, address indexed to, uint256 indexed id);
  event Inscribe(uint256 indexed id, bytes data);
}

Add a field id to inscriptions for enabling the mapping of the two events.




Discussion on ERC-7583 for Inscribing assets in smart contract ERCs


    Here are a few of suggestions for the ERC-7583 proposal. 



Give each Inscribe a unique id 



The contract should set a max size of the inscribed data to avoid blockchain bloat. 



Pragmatically sometimes data will need to be stored off chain, e.g. on IPFS. Introduce a standardized way to handle this. 
Example with MAX_DATA_SIZE and inscribeOffChain. 
interface IERC7583 {
    event Inscribe(uint256 indexed id, bytes data);
    event InscribeOffChain(uint256 indexed id, string dataRef);
}

con…
  

@apechef Thank you for your input!

The unique id has already been memtioned here.
And it is a good practical solution for setting a max size of inscribed data! What do you think is the best practice for setting a max limit data size?
I think the off chain could also be stored in ‘Inscribe’ event.





Discussion on ERC-7583 for Inscribing assets in smart contract ERCs


    Including the users address (msg.sender) would follow common practice: 
event Inscribe(address indexed user, uint256 id, bytes data); 
Compare with: 
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
event Approval(address indexed owner, address indexed spender, uint256 value);
  

@apechef Currently, inscriptions are operating within smart contracts on the EVM. For important data like the owner, how about using the storage variables of the smart contract to store it? e.g.
function ownerOf(uint256 insId) external view returns (address owner);





Discussion on ERC-7583 for Inscribing assets in smart contract ERCs


@TUTUBIG @ins-evm Great discussion and ideas. 

Indeed, the recording of inscribed transactions is missing. However, I believe that inscription event should be treated as a separate event, distinct from the transfer event. 

I am not convinced about this. Do you view inscriptions as entities/artefacts which should be traded independently of tokens? What are the use cases which could not be covered by the current Transfer event? 


The unique id has already been memtioned here.
And it is a good p…
  

@apechef I am also considering this point at the moment. If ERC7583 is intended to include transaction-related specifications, positioning it as an extension of ERC721 seems like an ideal choice. In this way, ERC7583 can serve as an alternative to ERC721Metadata. However, this approach also brings certain limitations. Treating ERC7583 solely as an extension of ERC721 may restrict its scalability in broader application scenarios, as not all types of inscriptions need to strictly follow the transaction specifications of ERC721. I look forward to your insights on this issue! 

if you have other ideas about dynamic hashes or similar to add layers of security?

Currently, most users, when inscribing, tend to use a string of characters as input, such as: data:,{"p":"brc-20","op":"mint","tick":"ordi","amt":"10"}. In designing the experimental contract $INSC, to accommodate users’ inscription habits, we provided an entry parameter for users to input their inscription data. However, for this type of simple inscriptive data with rules, it can be entirely generated by the smart contract, and users only need to provide simple parameters, like the quantity to be minted.
In fact, at the content level, we do not need to restrict the hash of the inscription data. As a decentralized application, everyone has the right to inscribe any content. The form of data is only related to the consensus of the community.
Metadata Schema
Added Metadata Schema for FT (Fungible Tokens) and NFT (Non-Fungible Tokens) in Add ERC: Inscription In Smart Contract by shalom-ins · Pull Request #173 · ethereum/ERCs · GitHub. looking forward to receiving suggestions 
image1140×922 43.9 KB

Author: ins-evm
Date: 2023-12-28T15:40:28.243Z

FancyKing:

By carrying the inscription through events in the EVM and making the inscription compatible with the EVM, will there still be the disadvantage of excessive gas cost? How to solve this?


The Ordinals protocol provides a great solution - Recursion.

Author: Texasgun
Date: 2023-12-28T18:30:39.877Z

Hey brother the ins20 twitter account has been very quiet lately. Are there any plans, or announcements coming for the community? Will there be more engagement with the community in the future? Leaving the project in suspense for days at a time doesn’t help much.

Author: ins-evm
Date: 2023-12-28T23:09:06.980Z

Texasgun:

Hey brother the ins20 twitter account has been very quiet lately. Are there any plans, or announcements coming for the community? Will there be more engagement with the community in the future? Leaving the project in suspense for days at a time doesn’t help much.


The best community is right here!

Author: ins-evm
Date: 2023-12-28T23:20:02.626Z

zzzz:

Sir, a good idea is certainly important. Have you considered establishing a community belonging to INSC on DC or TG, so that more like-minded friends can join this discussion? This project is fantastic


Bro, this is the best community right here, and I will encourage everyone to engage in discussions here

Author: SergeantPonzi
Date: 2023-12-28T23:29:16.684Z

Hello, when you say snapshot, does that mean you intend on relaunching the project with the improved code from this github? i’m worried you leave the ins20 community behind that have been supporting the project passively.

Author: Ethlover
Date: 2023-12-28T23:33:02.417Z

So what really does an inscription mean?

Author: ins-evm
Date: 2023-12-28T23:52:05.462Z

SergeantPonzi:

Hello, when you say snapshot, does that mean you intend on relaunching the project with the improved code from this github? i’m worried you leave the ins20 community behind that have been supporting the project passively.


I won’t do that, don’t worry! The ‘snapshot’ is just a way to reward early supporters of the project. INSC Holders will play a crucial role in the upcoming updates .

Author: ins-evm
Date: 2023-12-28T23:54:04.905Z

Ethlover:

So what really does an inscription mean?


Here(Inscriptions - Ordinal Theory Handbook), you will find everything you want to know.

Author: SergeantPonzi
Date: 2023-12-28T23:56:50.042Z

Sounds good, I have been rallying the ins20 community towards this project. When can we have an update regarding the progress on the eip?

Author: SergeantPonzi
Date: 2023-12-29T01:46:51.708Z

@ins-evm Could you help community understand the process to getting this ERC-7583 approved? Who decides? how likely is it we get approved? how far are we already?
it would be helpful to answer these questions to the community so we understand beter

Author: Zorro2019
Date: 2023-12-30T11:49:32.870Z

The project crashed? any way to come back with a better code?Currently, there is only a one-way transformation from ERC-721 to ERC-20. I would suggest that the #INSC team supports a two-way transformation. Is that possible?

Author: ins-evm
Date: 2023-12-31T14:52:57.674Z

That’s a good idea. You can try to think about how to implement it.

Author: apechef
Date: 2024-01-01T22:16:30.336Z

Here are a few of suggestions for the ERC-7583 proposal.



Give each Inscribe a unique id



The contract should set a max size of the inscribed data to avoid blockchain bloat.



Pragmatically sometimes data will need to be stored off chain, e.g. on IPFS. Introduce a standardized way to handle this.
Example with MAX_DATA_SIZE and inscribeOffChain.
interface IERC7583 {
    event Inscribe(uint256 indexed id, bytes data);
    event InscribeOffChain(uint256 indexed id, string dataRef);
}

contract Inscription is IERC7583 {
    uint256 public constant MAX_DATA_SIZE = 256; // Example size limit

    // Function for on-chain data with size check
    function inscribe(uint256 id, bytes calldata data) public {
        require(data.length <= MAX_DATA_SIZE, "Data size exceeds limit");
        emit Inscribe(id, data);
    }

    // Function for off-chain data references
    function inscribeOffChain(uint256 id, string calldata dataRef) public {
        emit InscribeOffChain(id, dataRef);
    }
}

Author: apechef
Date: 2024-01-01T23:29:03.208Z

Including the users address (msg.sender) would follow common practice:
event Inscribe(address indexed user, uint256 id, bytes data);
Compare with:
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
event Approval(address indexed owner, address indexed spender, uint256 value);

Author: SatXt
Date: 2024-01-02T03:14:46.390Z

So, what about the recent attack? Is there gonna be redeployment of the INS-20 contract?

Author: ins-evm
Date: 2024-01-02T16:11:14.350Z

SatXt:

So, what about the recent attack? Is there gonna be redeployment of the INS-20 contract?


Yes, and we need a strategy to find the most loyal crew member.

Author: ins-evm
Date: 2024-01-02T16:32:13.827Z

SergeantPonzi:

@ins-evm Could you help community understand the process to getting this ERC-7583 approved? Who decides? how likely is it we get approved? how far are we already?
it would be helpful to answer these questions to the community so we understand beter


For answers to your questions, you can refer to EIP-1.

Author: Firerus
Date: 2024-01-02T16:39:00.672Z

so I don’t need 2 worry I will get it in the next collection ?

Author: SatXt
Date: 2024-01-02T16:47:32.198Z

And Wen is that gonna be fam

Author: ins-evm
Date: 2024-01-02T16:52:49.037Z

SatXt:

And Wen is that gonna be fam


The preliminary strategy rules will be announced in the next few days, and the specific implementation rules will be launched along with the website. For the exact timing, please follow our X.

Author: ins-evm
Date: 2024-01-02T16:56:46.932Z

Firerus:

so I don’t need 2 worry I will get it in the next collection ?


Yes! Don’t worry about it. We will get through this difficult time ! And this is a good opportunity to practice controlling emotions and to maintain rational thinking

Author: middlemarch
Date: 2024-01-04T19:52:22.924Z

Why not use the existing Ethscriptions standard? It is the most widely used and there is now an open source implementation, which makes it I believe the only end-to-end open source Inscriptions protocol on the EVM:



GitHub



GitHub - 0xFacet/ethscriptions-indexer
Contribute to 0xFacet/ethscriptions-indexer development by creating an account on GitHub.





Using calldata instead of events is cheaper, which is the main point behind Ethscriptions in the first place, and the purge should not affect the decision here as there will be plenty of copies of this data.
It’s not worth making users pay more for data persistence in the case they don’t want to given that Ethereum is not optimized for long term data storage.
(I am a co-founder of Ethscriptions)

Author: Esnp-TM
Date: 2024-01-05T10:43:20.191Z

I believe your ideas are good, and it also proves that the direction of Ethscriptions is correct. You have endorsed the direction of the new type of assets in the script.
In this direction, facing new opportunities, we should honestly acknowledge the existence of Ethscriptions, and time will prove that it was created first. On this basis, there is no problem for the old project ENS to innovate, as long as it respects Ethscriptions as a predecessor. Respect the advanced nature of Ethscriptions.

Author: Inxribe-UNI20
Date: 2024-01-05T10:57:19.202Z

Hi there, we agreed EIP-7583 as:
1/ UNI-EVM also used call-data to mint (for fair launch)
2/ ERC-721 & ERC-20 have a lot of fundamental infrastructures (e.g uniswap, blur, bridge  etc…), We should never give up them and spend billions of resources to re-build, not because of call-data have low gas.
3/ Through EIP-7583, we can obtain call-data & ERC 721 feature, which has far more large imagination. Based on this, users can more convenience to use dapp & liquidity.
4/ We will continuously complete EIP-7583 & provide more function (e.g stake, swap, stablecoin, loan, etc.)
By Inxribe UNI 20 team.

Author: ins-evm
Date: 2024-01-05T13:07:57.372Z

middlemarch:

Why not use the existing Ethscriptions standard? It is the most widely used and there is now an open source implementation, which makes it I believe the only end-to-end open source Inscriptions protocol on the EVM:
GitHub - 0xFacet/ethscriptions-indexer
Using calldata instead of events is cheaper, which is the main point behind Ethscriptions in the first place, and the purge should not affect the decision here as there will be plenty of copies of this data.
It’s not worth making users pay more for data persistence in the case they don’t want to given that Ethereum is not optimized for long term data storage.
(I am a co-founder of Ethscriptions)


Firstly, I want to thank you for joining us here to discuss inscription technology within the Ethereum ecosystem, and I deeply respect and congratulate you on your current achievements.
As you pointed out, there are indeed some differences between our ERC7583 protocol and the direction you advocate. These differences are mainly reflected in our chosen technical specifications and the way inscription data is stored. We believe that in this industry, which respects individual differences and encourages innovation, different solutions can not only coexist but also collectively promote the development of the entire field.
Specifically, ERC7583 prefers to use Event data to store inscription data, aiming to enhance its compatibility and interoperability. This approach allows developers to leverage the powerful capabilities of the EVM for more flexible secondary development of inscriptions. Compared to off-chain indexers, asset ownership determined by smart contracts offers stronger persuasiveness. Additionally, ERC7583 is designed to provide new solutions for interactions between on-chain and off-chain computations. For example, like your music platform, transactions can be conducted through smart contracts while using indexers to parse and play content. Whether it’s gaming, the metaverse, or any other application, customized indexers can be used to integrate on-chain and off-chain elements (This is similar to the concept of the ’ Ethscriptions VM’ that you proposed).
Although ERC7583 and Ethscriptions have their independent development paths, I still hope to invite you with the utmost respect to join us in pushing ERC7583 forward, until it reaches its Final status.

Author: ins-evm
Date: 2024-01-05T13:22:32.480Z

Esnp-TM:

I believe your ideas are good, and it also proves that the direction of Ethscriptions is correct. You have endorsed the direction of the new type of assets in the script.
In this direction, facing new opportunities, we should honestly acknowledge the existence of Ethscriptions, and time will prove that it was created first. On this basis, there is no problem for the old project ENS to innovate, as long as it respects Ethscriptions as a predecessor. Respect the advanced nature of Ethscriptions.


Thank you very much for your response. I completely agree that it is our shared responsibility to learn from and respect history. I sincerely respect and acknowledge the significant achievements of Ethscriptions, and I pay homage to their pioneering status in this field.
At the same time, I eagerly hope that we can work together to jointly promote the development of the ETH inscription ecosystem. We believe that through our combined efforts, this ecosystem will thrive and prosper!

Author: middlemarch
Date: 2024-01-05T14:08:12.502Z

Events and calldata both can only be accessed offchain.
Events are easier to access given today’s indexers, but these were not designed for Ethscriptions! We should “skate to where the puck is going.”
The only functional difference is whether users have to pay once—Ethscription content in calldata—or twice: Ethscription content in calldata and also in an event.
Also this requires someone pay the cost of deploying a contract, which is another dependency.
I believe events have their place and we’ve made use of them, but I don’t see the reason to disallow the original and cheapest method which is calldata-only.
100% of your goals can be achieved without making users pay more. Why force them to do this without a benefit?

Author: ins-evm
Date: 2024-01-05T15:32:28.425Z

Insc20:

I’m not impersonating you, more like warning others about you.
I wish you responded this quickly to the attack when it occurred, it took you nearly 3 days to say anything to the community and confirm that there was a hack.
And it’s taken 2 weeks  and counting to remedy a solution.


In the INSC smart contract, the only role with special access is the proxy, and it has only one function, which is to switch the contract to FT mode. We cannot guarantee that there will be no new vulnerabilities after switching to FT, which is why we haven’t made this decision. If we do switch, it also means that we are acknowledging the state after the hacker attack, which is unacceptable.
Ultimately, we decided to take a snapshot and analyze all the transaction data. Through the ‘refund strategy’, we aim to facilitate the rollback of all transactions. We have also developed a transaction data analyzer as quickly as possible and submitted it to this Github repository.
Currently, there is only one way to ensure compensation for everyone’s assets, and that is to support INS.EVM. By collectively promoting its development, we can help it grow strong once again.

Author: ins-evm
Date: 2024-01-05T15:36:34.521Z

You have now received compensation, but what about others? We are currently making our utmost efforts to promote the development of INS.EVM. What you need to do now is to patiently wait; all the work is proceeding in an orderly manner.

Author: ryanlam
Date: 2024-01-05T15:52:10.945Z

Please stop attacking, we the holders will always support INS-EVM anyway.

Author: ryanlam
Date: 2024-01-05T15:54:22.198Z

Sir, please ignore the noise and continue your great job, we as the loyal supporters are witnessing a great project emerging and will always stand by your side

Author: xubiao1
Date: 2024-01-05T16:01:05.684Z

Sir, please ignore the noise and continue your great job, we as the loyal supporters are witnessing a great project emerging and will always stand by your side
we the holders will always support INS-EVM anyway.

Author: ryanlam
Date: 2024-01-05T16:01:16.564Z

Time will tell, just patiently wait, I can see whether the project is developing or not. Don’t fud please

Author: xubiao1
Date: 2024-01-05T16:06:01.468Z

支持创作者，时间会证明一切

Author: 0x10ma
Date: 2024-01-05T16:15:01.159Z

Going back and organizing the data is a huge task, it’s not easy. Hopefully the project will be moved forward soon, all we can do is be patient and support you, Captain!
Time will tell.
Make INS-EVM great!

Author: ins-evm
Date: 2024-01-05T17:27:51.122Z

middlemarch:

Events and calldata both can only be accessed offchain.
Events are easier to access given today’s indexers, but these were not designed for Ethscriptions! We should “skate to where the puck is going.”
The only functional difference is whether users have to pay once—Ethscription content in calldata—or twice: Ethscription content in calldata and also in an event.
Also this requires someone pay the cost of deploying a contract, which is another dependency.
I believe events have their place and we’ve made use of them, but I don’t see the reason to disallow the original and cheapest method which is calldata-only.
100% of your goals can be achieved without making users pay more. Why force them to do this without a benefit?


You are underestimating the power of the Ethereum developer community. Have you considered not passing data through calldata, but instead generating it directly within the contract and writing it in an event? This is entirely feasible, and in fact, already exists, for example in OKPC. In this case, the consumption of calldata can be negligible, with only the gas consumption for event data.

Author: apechef
Date: 2024-01-05T21:22:06.467Z

@TUTUBIG @ins-evm Great discussion and ideas.

Indeed, the recording of inscribed transactions is missing. However, I believe that inscription event should be treated as a separate event, distinct from the transfer event.

I am not convinced about this. Do you view inscriptions as entities/artefacts which should be traded independently of tokens? What are the use cases which could not be covered by the current Transfer event?


The unique id has already been memtioned here.
And it is a good practical solution for setting a max size of inscribed data! What do you think is the best practice for setting a max limit data size?
I think the off chain could also be stored in ‘Inscribe’ event.



Excellent!
I think it may be okay to leave it up to each contract, but good to include in a description of best practices. The length would depend on the purpose of the contract and what’s it’s aiming to inscribe
Agreed. Keep it simple.


Currently, inscriptions are operating within smart contracts on the EVM. For important data like the owner, how about using the storage variables of the smart contract to store it? e.g.

I may have been unclear. I did not mean the owner, but rather a reference to a user making the inscription.
–
@ins-evm Not specific to your proposal, but rather best practices for implementation: I noted in your contract that you only allowed inscription of a specific hash, and curious if you have other ideas about dynamic hashes or similar to add layers of security?

Author: Esnp-TM
Date: 2024-01-06T02:27:34.640Z

Excellent. Is there a possibility that in the development direction of ENS, it integrates with Ethscriptions, innovates on this basis, and collectively expands Ethscriptions? At the same time, everyone can complement each other, jointly promoting the rise of Ethscriptions on ETH. This way, we can face Odrinals and Brc-20 on BTC, as well as Runes in April, making us more valuable. I would like to hear your thoughts on this, looking beyond the individual products themselves.

Author: cc40513
Date: 2024-01-06T06:47:36.231Z

別鬧了老哥 回家放牛去吧 你在對協議造成傷害

Author: Zorro2019
Date: 2024-01-07T01:19:18.400Z

do you mean it is not possible?

Author: ins-evm
Date: 2024-01-07T02:33:16.339Z

Esnp-TM:

Excellent. Is there a possibility that in the development direction of ENS, it integrates with Ethscriptions, innovates on this basis, and collectively expands Ethscriptions? At the same time, everyone can complement each other, jointly promoting the rise of Ethscriptions on ETH. This way, we can face Odrinals and Brc-20 on BTC, as well as Runes in April, making us more valuable. I would like to hear your thoughts on this, looking beyond the individual products themselves.


Thank you very much for your offer of collaboration, for which I express my sincere gratitude. Currently, our team is focused on achieving our set plans and goals. Once these tasks are completed, we will consider and respond to your proposal for cooperation in more detail. I look forward to discussing potential collaboration opportunities in the near future.

Author: hasdrid
Date: 2024-01-07T08:45:23.947Z

Hello ins-evm, first of all, your project is very good and has ambitious goals. We are very happy to build and develop together!
However, due to the emergence of contract loopholes, a large number of people’s assets have been reduced to zero, which is something we don’t want to see.
Because of this, I am here to make a suggestion to you. I hope you can map the user’s assets to the new contract as soon as possible so that community members can feel at ease. I know this is a very large amount of work, but so many days have passed. It is difficult for people to wait calmly any longer. They all hope that their assets will be protected so that they can continue to develop together with the project!

Author: ins-evm
Date: 2024-01-07T13:43:03.500Z

hasdrid:

Hello ins-evm, first of all, your project is very good and has ambitious goals. We are very happy to build and develop together!
However, due to the emergence of contract loopholes, a large number of people’s assets have been reduced to zero, which is something we don’t want to see.
Because of this, I am here to make a suggestion to you. I hope you can map the user’s assets to the new contract as soon as possible so that community members can feel at ease. I know this is a very large amount of work, but so many days have passed. It is difficult for people to wait calmly any longer. They all hope that their assets will be protected so that they can continue to develop together with the project!


Thank you for the suggestions you provided. We are indeed working towards this goal. As you suggested, we should provide the new mapping assets as soon as possible. Currently, our plan is to make the new mapping assets the first implementation of ERC7583. We won’t wait for ERC7583 to reach its final state, but it should be at least in a relatively stable state to avoid compatibility issues in the future.

Author: hasdrid
Date: 2024-01-07T14:44:36.314Z

Okay, I think everyone who has checked the forum knows your purpose, thank you!
But can you tell us when the new map will be available?
Everyone can wait and build with peace of mind!

Author: MidnightLightning
Date: 2024-01-15T18:57:51.772Z

I responded in the GitHub pull request with a technical issue with the proposal as-written. Posting here to also voice concerns about the overall structure of this EIP:
In general, I feel this doesn’t need to be an EIP, since it doesn’t need to be a standard that multiple contracts implement. If people wish to give meaning to arbitrary data that is just announced/timestamped on an EVM blockchain, it doesn’t need to be implemented by multiple smart contracts (since that mentality is aiming to skew away from smart contracts). Instead, just one contract needs to exist with a method anyone can call, to trigger an event with arbitrary data. And actually many of those already exist from the early days of Ethereum when people were experimenting with simple “greeter” contracts. What benefit is to be gained by a project organizer deploying a smart contract for their project that allows people to trigger “Inscribe” events, but doesn’t use any other smart contract benefits?



 middlemarch:

The only functional difference is whether users have to pay once—Ethscription content in calldata—or twice: Ethscription content in calldata and also in an event.


That “only” is discounting one other thing I think is important: Event indexers already exist. Web3 SDK libraries give easy access to filter and query Events (as they’re exposed by the JSON-RPC node APIs), but calldata isn’t as easily filterable. An additional benefit you get by “paying twice” is the ability for many other nodes to present your data in a more convenient package, and so will show up in some form in explorers, wallets, and portfolio tools without them needing to specifically modify to support it.
If this is to become an accepted EIP, a technical concern with the formatting chosen: If the data value of the event is forced to be a data URI, then why is it defined as a bytes value rather than a string value? I would suggest dropping the requirement that it be a data URI in format, and allow any data to be present. That allows for implementations to use whatever data encoding they prefer (e.g.  protobuf or BSON). Using BSON or Solidity data encoding would encode the data more compactly (and therefore reduce the cost to inscribe). The data URI format needing to start with data: means every inscription has five extra bytes it needs to pay to store.

Author: MidnightLightning
Date: 2024-01-15T19:02:20.925Z

Esnp-TM:

Is there a possibility that in the development direction of ENS, it integrates with Ethscriptions, innovates on this basis, and collectively expands Ethscriptions?


The Ethereum Name Service (ENS) specification allows putting arbitrary key/value pairs on domains/names you own. There are several standard keys that define avatar images and demographic information about the owner, but you can put whatever you want in a domain you own. If you wish to put some structured data there and create a project that derives meaning from that you definitely can. But other users cannot modify the key/value pairs on your domain. So it can be a way for individual users to signal something, but cannot be used to have a back-and-forth “conversation” or log with other users adding data to it.

Author: xicrypto
Date: 2024-02-20T04:12:15.383Z

Support innovation, the ETH ecosystem is in great need of more innovation and this time will promote the use of ETH in more scenarios

Author: ins-evm
Date: 2024-02-20T08:09:29.221Z

MidnightLightning:

I responded in the GitHub pull request with a technical issue with the proposal as-written. Posting here to also voice concerns about the overall structure of this EIP:
In general, I feel this doesn’t need to be an EIP, since it doesn’t need to be a standard that multiple contracts implement. If people wish to give meaning to arbitrary data that is just announced/timestamped on an EVM blockchain, it doesn’t need to be implemented by multiple smart contracts (since that mentality is aiming to skew away from smart contracts). Instead, just one contract needs to exist with a method anyone can call, to trigger an event with arbitrary data. And actually many of those already exist from the early days of Ethereum when people were experimenting with simple “greeter” contracts. What benefit is to be gained by a project organizer deploying a smart contract for their project that allows people to trigger “Inscribe” events, but doesn’t use any other smart contract benefits?



 middlemarch:

The only functional difference is whether users have to pay once—Ethscription content in calldata—or twice: Ethscription content in calldata and also in an event.


That “only” is discounting one other thing I think is important: Event indexers already exist. Web3 SDK libraries give easy access to filter and query Events (as they’re exposed by the JSON-RPC node APIs), but calldata isn’t as easily filterable. An additional benefit you get by “paying twice” is the ability for many other nodes to present your data in a more convenient package, and so will show up in some form in explorers, wallets, and portfolio tools without them needing to specifically modify to support it.
If this is to become an accepted EIP, a technical concern with the formatting chosen: If the data value of the event is forced to be a data URI, then why is it defined as a bytes value rather than a string value? I would suggest dropping the requirement that it be a data URI in format, and allow any data to be present. That allows for implementations to use whatever data encoding they prefer (e.g.  protobuf or BSON). Using BSON or Solidity data encoding would encode the data more compactly (and therefore reduce the cost to inscribe). The data URI format needing to start with data: means every inscription has five extra bytes it needs to pay to store.


Thank you very much for your valuable comments and suggestions. We deeply agree with your opinion that merely relying on an “inscribe” event without the need for standardization through EIP is sufficient.At the same time, limiting data to a data URI format was a decision made in consideration of the richness of protocol content, but it indeed was not a thoroughly considered decision.
Over the past period, we have been deeply reflecting and exploring, trying to find out what the best asset form for inscriptions in the EVM should be. Based on these reflections, we have updated our results in the GitHub repository and developed a marketplace platform to validate the feasibility and practicality of the ERC7583 protocol.
We highly value your opinions and suggestions, which are crucial for the improvement and perfection of the ERC7583 protocol. Therefore, we are very eager to hear more specific suggestions and feedback from you. Would you be willing to provide more advice on how to improve our protocol and its implementation? We look forward to further communication and cooperation with you, and once again, thank you for your time and contribution.

Author: middlemarch
Date: 2024-02-26T00:01:29.760Z

MidnightLightning:

That “only” is discounting one other thing I think is important: Event indexers already exist. Web3 SDK libraries give easy access to filter and query Events (as they’re exposed by the JSON-RPC node APIs), but calldata isn’t as easily filterable. An additional benefit you get by “paying twice” is the ability for many other nodes to present your data in a more convenient package, and so will show up in some form in explorers, wallets, and portfolio tools without them needing to specifically modify to support it.


True, but no “out of the box” event indexers give you enough data to do anything useful because Ethscription state can depend on Ethscriptions created arbitrarily far in the past. So if you want to index Ethscription state you’re going to need a special-purpose indexer.
Do any such indexers built on the event model exist? I am not aware of any, certainly no open source ones.
On the other hand, the calldata model has an open source indexer that works great right here!
https://github.com/0xFacet/ethscriptions-indexer
Why not use this (or a fork of it) versus hoping someone builds a better one using events and forcing users to pay the extra cost in the mean time?

Author: MidnightLightning
Date: 2024-02-27T23:53:43.936Z

middlemarch:

Ethscription state can depend on Ethscriptions created arbitrarily far in the past. So if you want to index Ethscription state you’re going to need a special-purpose indexer


My point was that there is a robust querying mechanism for Events already part of the standard RPC calls that can be made to any node. If you want to query Events of type “Foo” from a specific contract, for a specific block range (“arbitrarily far in the past”), one API call gets that. The RPC infrastructure allows getting the calldata from a transaction, but I don’t believe it has any means to search/query based on calldata. So if you’re creating “inscriptions” that are stored as calldata, yes you’ll need a custom indexer to scape the entire transaction history to find them, and then present some sort of custom querying interface to know about them. If you’re creating “inscriptions” that save their data as Events, you don’t need to create a custom indexer, because all nodes already know how to find and present that data to you on-demand; you don’t need to pre-fetch it and index it, just query it when you want it from a node.
Even if you did build a complex protocol on top of Event data, and needed an index to scrape all the data first, creating an indexer for Event data would be dramatically faster and easier to write, since it would be able to skip all the transactions that were irrelevant without fetching them. Indexing calldata would need to iterate over every transaction, fetching that transaction’s data from a node, and then determining if it’s needed for the protocol.

Author: MidnightLightning
Date: 2024-02-28T00:06:14.925Z

ins-evm:

Based on these reflections, we have updated our results in the GitHub repository…


The latest updates to the GitHub draft lay out a radically different structure, with ERC7583 defining a type of contract that is a (true) ERC20 and (renamed/tweaked) ERC721 contract at once. That hybrid blend of non-fungible and fungible token is something that non-inscription communities have been exploring lately and ERC7631 has come from that. ERC7631 seems to be pursuing the same goals as this updated ERC7583, in that users have their fungible tokens saved as discrete “bundles” of arbitrary value. The key difference is ERC7631 has the non-fungible “bundles” be true ERC721s. A significant downside of this updated ERC7583 is that the non-fungible part looks similar to ERC721s, but isn’t actually, and could confuse or break interfaces that assume they are.
ERC7583 having part of the contract’s state be accessible to other smart contracts (ERC20 interface) and the other part inaccessible (by attempting to save it as “an inscription”) seems like it’s significantly less useful. So, my opinion is that if a project wants the functionality of having a set of non-fungible tokens that “store” fungible token values for a user, we should help standardize ERC7631 as an interface to do that, to have the best compatibility with all other smart contracts in the space.

Author: middlemarch
Date: 2024-02-28T16:13:01.320Z

MidnightLightning:

If you’re creating “inscriptions” that save their data as Events, you don’t need to create a custom indexer, because all nodes already know how to find and present that data to you on-demand; you don’t need to pre-fetch it and index it, just query it when you want it from a node.


Practically I don’t think nodes will just give you everything in one API call. Alchemy as an example has this limit:

You can make eth_getLogs requests on any block range with a cap of 10K logs in the response OR a 2K block range with no cap on logs in the response and 150MB limit on the response size

I don’t think the assumption should be that users have access to a better node than Alchemy.
At a higher level though: events are better for devs, calldata is better for users. My suggestion is that to resolve this tension we look at the actual live ethscriptions protocol that has a robust open source reference indexer and hundreds of thousands of users rather than returning to first principles and deciding events v. calldata in the abstract.
Or is the suggestion that events are so much better than calldata that a new inscriptions protocol will, from a standing start, no users, no reference indexer implementation overtake what is already popular?
When we launched ethscriptions and iterated on it for over a year we considered all these topics and made the choices we did for considered reasons and with significant success.
I believe the best route for this ERC is to build on what’s working, not discard it. Or, if you want to discard it, to first get buy in from users and devs versus leaning on the standardization process itself to get support.

Author: ins-evm
Date: 2024-02-29T15:13:11.478Z

MidnightLightning:




 ins-evm:

Based on these reflections, we have updated our results in the GitHub repository…


The latest updates to the GitHub draft lay out a radically different structure, with ERC7583 defining a type of contract that is a (true) ERC20 and (renamed/tweaked) ERC721 contract at once. That hybrid blend of non-fungible and fungible token is something that non-inscription communities have been exploring lately and ERC7631 has come from that. ERC7631 seems to be pursuing the same goals as this updated ERC7583, in that users have their fungible tokens saved as discrete “bundles” of arbitrary value. The key difference is ERC7631 has the non-fungible “bundles” be true ERC721s. A significant downside of this updated ERC7583 is that the non-fungible part looks similar to ERC721s, but isn’t actually, and could confuse or break interfaces that assume they are.
ERC7583 having part of the contract’s state be accessible to other smart contracts (ERC20 interface) and the other part inaccessible (by attempting to save it as “an inscription”) seems like it’s significantly less useful. So, my opinion is that if a project wants the functionality of having a set of non-fungible tokens that “store” fungible token values for a user, we should help standardize ERC7631 as an interface to do that, to have the best compatibility with all other smart contracts in the space.


I have read the first commit of the ERC7631 implementation code, which was committed three weeks ago. And it is very similar to ERC404(Pandora).
image2878×454 45.4 KB
I don’t know if you are aware of INSC. We deployed it on De-24-2023, at, and it was the first contract to attempt to combine ERC20 and ERC721. INSC was on the top trending list for 4 days until it was hacked.
image767×755 109 KB
Then, we spent a considerable amount of time developing a compensation plan in an effort to ensure our users receive fair compensation. And we also launched a new contract named INSC+ on Jan-17-2024, which introduces more innovation. We made this announcement at that time as well.
image1300×632 137 KB
Because we didn’t fully grasp the cutthroat competition in the crypto industry, we set a restriction that the FT function could only be unlocked after all INSC+ tokens were claimed. Then, Pandora was launched on February 2, 2024. Following a similar story, it gained popularity and became increasingly well-known.
I mentioned this because you wanted me to build on ERC7631, akin to expecting a poor prince to serve a nouveau riche. Our story hasn’t been fully revealed yet. The significant downside of ERC7631 is that it requires using two contracts for one asset. This approach was proven to be ineffective by the project Cirth.
An NFT that points to off-chain content on IPFS or Arweave is incomplete, and thus not a digital artifact.
It’s a sign of weakness to abandon innovation just to conform to the existing NFT market.

Author: MidnightLightning
Date: 2024-03-05T17:06:32.454Z

middlemarch:

Practically I don’t think nodes will just give you everything in one API call.


That’s not my point; it would be impractical to get everything in one API call for most all projects. My point was in order to find what you wanted, less calls are needed when working with Event data than Calldata, and therefore searching through past history could be done live (possibly through a few iterations of eth_getLogs) or through a fast indexing service.
Consider the example: a project creates a protocol that includes users being able to send messages of type A, B, and C, each message having tags that indicate sender, recipient, and some message data.
If built with Events: on a web interface showing a profile for Alice, to display “all messages from Alice”, a single eth_getLogs call could get it (filtering for any message type, but where sender is Alice’s address) in one call, assuming Alice has sent less than 10,000 messages. A web interface wanting to show all recent activity for the whole project could query the latest 2,000 blocks as a “most recent actions” list, and load more if the user paginates through it.
If built with Calldata: on a web interface showing a profile for Alice, to display “all messages from Alice”, all transactions in all blocks from the launch of the project need to be inspected. There’s not a practical call to get that “live”, unless some custom indexer for the project has done the work already.
Consider creating a custom indexer for that theoretical project, to support a web interface wanting to do more complicated things like “list all messages to or from Alice, and any first-level replies to them”.
If built with Events: all events in transactions from the project’s smart contract need to be inspected and indexed. eth_getLogs allows querying chunks of 2,000 blocks at a time for all events for the project. That response object is a much smaller payload than all transactions in those 2,000 blocks, so the indexer doesn’t have to iterate over as much data (all the data returned is relevant; no need to filter/cull it first).
If built with Calldata: all transactions that interact with the project’s smart contract need to be parsed. In order to get “all transactions for a contract”, there’s no RPC call for that. The indexing service would need to go by single blocks, using eth_getBlockByNumber to fetch the block and the transactions in it, iterate over all the transactions and determine if they’re relevant, and then process them.
Am I missing something here that makes it easier to fetch calldata?



 middlemarch:

At a higher level though: events are better for devs, calldata is better for users. 


I’ve not heard that argument before; on what do you base that claim?



 middlemarch:

My suggestion is that to resolve this tension we look at the actual live ethscriptions protocol that has a robust open source reference indexer and hundreds of thousands of users rather than returning to first principles and deciding events v. calldata in the abstract.


This discussion is about creating a potential standard. That is by its nature abstract, since a standard has a goal of being used by many different projects for different purposes. Standards are foundation layers that if built well, robust applications can be built upon them. “We’re already using it, and end-users like it” is not a stellar reason for a thing to become a standard.

Author: MidnightLightning
Date: 2024-03-05T17:23:53.061Z

ins-evm:

I don’t know if you are aware of INSC. We deployed it on De-24-2023, at, and it was the first contract to attempt to combine ERC20 and ERC721.


No, I was unaware of that project previously. I wish you luck with your project, and can appreciate the struggles of trying to show a project achieved a technological feat before others.
However, in this thread, the discussion is on creating a standard, which therefore has a goal to be the best foundation for future projects to work from. Standards are open-source and while there is some prestige to authoring a standard, part of the natural process of standards is that they can evolve and grow through collaboration. Standards can get outdated and replaced by newer ones, without that being a stigma to the original standard.
Reading both ERC7583 (this one) and ERC7631 (“Dual Nature Token Pair”), they both appear to me to be having the same goal (represent a fungible and non-fungible thing together), and I think ideally we shouldn’t have multiple (active) standards for the same goal. This proposal encourages a calldata-based approach, which to me seems to be a significant disadvantage.



 ins-evm:

The significant downside of ERC7631 is that it requires using two contracts for one asset. This approach was proven to be ineffective by the project Cirth .


How is requiring two contracts “ineffective”?



 ins-evm:

An NFT that points to off-chain content on IPFS or Arweave is incomplete, and thus not a digital artifact.


That’s a personal opinion, and you’re welcome to personally label projects as you see fit. However, the ERC721 standard that most NFTs follow doesn’t require pointing to IPFS, Arweave, or similar, so ERC7631 deriving from that makes no opinion on “on-chain” vs “off-chain”, which I think is good, to allow different projects to choose how they wish. You are welcome to innovate and I’m glad you’re pursuing it. My intention was not that you “serve a nouveau riche”, but that in making the transition from “a project implementation” to “a standard”, that the best aspects of all projects who have been innovating in this space are considered.

Author: FancyKing
Date: 2024-03-07T14:26:57.503Z

Then does our INSC+ also use recursive methods?

Author: ownerlessinc
Date: 2024-04-29T14:50:31.955Z

IMO, a lot of the concepts that are here trying to be standardized, were already introduced by @middlemarch and the Ethscriber community. But if I may reinforce what some had previously pointed out: We should always prioritize saving the maximum amount of gas since the main purpose of this standard is to introduce a cheaper way to program historical data in Ethereum. The excess usage of events and especially duplicating entire calldata into event emission is by far the expected approach towards introducing a new standard supposed to save user’s gas. Just by having the calldata as a parameter in the function input we already have it indexed in the blockchain therefore there is no need to emit anything and rather fetch in the correct place.
Another criticism and this goes for all inscription implementers, is how our agenda pushes to apply conditions depending on the data passed, which is exactly how smart contracts operate. But if we want to automatize inscriptions at the smart contract level we should be looking into reserving some bytes, like the function selector, to specify what to do with the data and to warn the indexer about the type of data he is handling.
Another problem that should be tickled by the smart contract developers and indexer implementers is the subsequential internal calls. Current approaches assume the first calldata (input data) carries the inscription content, but this doesn’t provide enough backward compatibility with the EVM. The desirable scenario is when even low-level calls to other contracts carry a valid inscription and one where even more than one inscription could be tackled in a single transaction; e.g.: a contract that builds dynamic SVG’s as inscriptions upon mint. Using event emissions completes this task with ease, but it would also result in double gas spending. Sending a low-level call to a “fallbackless” address with zero value with the msg.data as the content prevails as the ultimate source of cheap.
If both standards are assumed to be valid in the future, we should also work on facilitating the job for indexers and dApps looking forward to implementing inscriptions on the VM. I assume this was proposed already in the past but I believe there should be a selector specially made for inscription identification when invoked as calldata, a default and easy-to-remember prefix such as 0xFFFFFFFF. While the event emission would also need a specific name to describe its inscription property like “ins_data”.
And far more important, the order in which we validate the calldatacopy() that will be read as the standard invocations:
input data (1st inscription)
├── internal calldata (2nd)
├── event emission (3rd)
        ├── internal calldata (4th)
        ├── event emission (5th)
                ├── ...

I hope these thoughts tickle everyone’s brain to find a cohesive path toward delivering a standard that the world can follow and resulting in gas savings for the ecosystem.