Discussion on ERC-7583 for Inscribing assets in smart contract

ERCs
22

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.

1 Like
23

So what really does an inscription mean?

24

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 :performing_arts:.

1 Like
25

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

26

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

30

@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
37

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?

38

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

41

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);
    }
}
42

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);
43

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

45

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

1 Like
46

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

2 Likes
47

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

48

And Wen is that gonna be fam

49

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
50

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

1 Like
52

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
53

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.

54

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.