Add ERC: Inscription In Smart Contract

[shalom-ins]

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.

[eip-review-bot]

File ERCS/erc-7583.md

Requires 1 more reviewers from @axic, @g11tech, @SamWilsn, @xinbenlv

[JXRow]

function inscribe(bytes calldata data) dosen't include transferTo, how to transfer to user?

[shalom-ins]

function inscribe(bytes calldata data) dosen't include transferTo, how to transfer to user?

You can integrate it with the ERC721 protocol to enable transaction functionality. Since inscriptions are not solely used for transactions, this proposal does not set forth any transaction-related specifications.

[JXRow]

function inscribe(bytes calldata data) dosen't include transferTo, how to transfer to user?

You can integrate it with the ERC721 protocol to enable transaction functionality. Since inscriptions are not solely used for transactions, this proposal does not set forth any transaction-related specifications.

I kown that, so I suggest that the function inscribe(bytes calldata data) should be function inscribe(address to, bytes calldata data), inscription needs the param "address to"

[shalom-ins]

function inscribe(bytes calldata data) dosen't include transferTo, how to transfer to user?

You can integrate it with the ERC721 protocol to enable transaction functionality. Since inscriptions are not solely used for transactions, this proposal does not set forth any transaction-related specifications.

I kown that, so I suggest that the function inscribe(bytes calldata data) should be function inscribe(address to, bytes calldata data), inscription needs the param "address to"

I believe that inscription id cannot be omitted because having an id allows for very flexible operations on inscriptions using the EVM, including the owner of inscriptions.

[github-actions]

The commit 583169e (as a parent of 0491663) contains errors.
Please inspect the Run Summary for details.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[SamWilsn]

It might be nice to define what "inscription data" is inside the description field. Would make it more visible to those unfamiliar (myself included.)

If you're short on characters (there's a limit of ~144), consider removing "framework" and "smart contract". The former doesn't add much information, and the latter is generally understood for ERCs.

[SamWilsn]

I've tried to cut out some fluff in your abstract:

Suggested change

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.

This EIP enables tokens to be traded both as fungible tokens and non-fungible tokens, providing the necessary flexibility for tokens to function in both capacities. Further, it embeds inscription data within event data. This addition allows for the inclusion of immutable extra information directly on chain.

Again, it'd be nice to explain what "inscription data" is somewhere early on.

[SamWilsn]

Suggested change

	---
	requires: 20, 165
	---

[SamWilsn]

When talking about interfaces, use backticks (`):

Suggested change

	**Every [ERC-7583](./eip-7583.md) compliant contract MUST implement the ERC-7583 and [ERC-165](./eip-165) interfaces.**
	**Every [ERC-7583](./eip-7583.md) compliant contract MUST implement the `IERC7583` and `ERC165` interfaces.**

[SamWilsn]

Is IERC20 mandatory or optional? You should make that clear in the text above this code fence.

[SamWilsn]

Suggested change

	The BRC20 protocol is a standard within the Bitcoin ecosystem that introduces a new way of transacting Fungible Tokens (FTs), allowing these tokens to be traded in a manner similar to Non-Fungible Tokens (NFTs). Specifically, the BRC20 protocol enables a number of FTs to be bundled together and traded as a single entity, offering more flexibility and possibilities for fungible token transactions. Within the Bitcoin ecosystem, the BRC20 protocol is primarily executed through off-chain interpreters. This approach relies on external participants and infrastructure to recognize and process these special transactions.
	In the Ethereum Virtual Machine (EVM), smart contracts provide powerful computational capabilities and a flexible programming model, making it feasible to implement the transaction modes described by the BRC20 protocol on Ethereum.

None of this text is explaining technical decisions made within this proposal. You might be able to move this to Motivation if you'd like to keep it.

The Rationale section should be used to explain choices made within the EIP itself, while the Motivation section justifies the EIP as a whole. My favourite analogy is:

Motivation: why do we need to build a shed?
Rationale: why did we decide to paint the shed red?

[SamWilsn]

We prefer CC0-1.0 for assets if you can, but MIT is fine if not.