Sounds good, I have been rallying the ins20 community towards this project. When can we have an update regarding the progress on the eip?
@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
2 Likes
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?
That’s a good idea. You can try to think about how to implement it.
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);
}
}
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);
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.
1 Like
so I don’t need 2 worry I will get it in the next collection ?
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.
1 Like
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
1 Like
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:
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)
4 Likes
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.
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.
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.
1 Like
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!
1 Like
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?
1 Like
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.
1 Like