Diegorb1329/eth_magicians_forum huggingface dataset:
Title: ERC_5559__Cross_chain_Write_Deferral_Protocol
Category: ERCs

Author: sshmatrix
Date: 2024-04-15T11:59:11.065Z

The following proposal is a superseding version of EIP-5559: Cross-Chain Write Deferral Protocol, aka CCIP-Write, replacing Ethereum L1 storage with L2 chains and cryptographically secure databases with an aim to cut gas costs and further privacy while retaining the secure aspects of on-chain storage. Methods in this document specifically target security and cost-effectiveness of write deferrals in context of databases. The cross-chain data written with these methods can be retrieved by generic EIP-3668-compliant contracts completing the cross-chain data life cycle.
ERC Link: ERCs/ERCS/erc-5559.md at master · namesys-eth/ERCs · GitHub
Happy to hear comments & feedback.

Author: sshmatrix
Date: 2024-04-30T01:50:26.807Z

This proposal has been amended to a standalone ERC and discussions now exist at: New ERC: Cross-chain Storage Router Protocol
Title: ERC_7625__Smart_Contract_ID___Tokenization_Standar
Category: ERCs

Author: SaulBuilds
Date: 2024-02-17T10:00:49.116Z

Looking to gain as much feedback as possible for erc-7625 and open to taking on co contributors as well.
My idea is simple and I believe a standard where contractId’s can be assigned as tokenId’s are to NFT’s can create a robust marketplace opportunity for smart contracts to be aquired and/or a new layer of functionality added to NFT’s attached to RWA’s.
Please feel free to reach out to me on here, looking forward to connecting with some of you to make this proposal and standard the best it can be.
the git for erc-7625 can be found here
let me know your honest thoughts and if you have any input in relation to the interface or naming conventions. I went with ‘contractId’ as to not conflict with any tokenId conventions commonly found in NFT’s.
(GitHub - SaulBuilds/erc7625Draft)
I also have a github with further forms of the reference implementation and the start to my test suite. Penetration testing and more fuzz testing tomorrow. Thanks for the look everyone.
Title: ERC_7753__Algorithmically_generated_NFT
Category: ERCs

Author: chen4903
Date: 2024-08-09T12:12:01.153Z

A non-fungible token standard that uses mathematical algorithms to draw and store images without any servers or storage space.
The current NFT solutions store images on IPFS or third-party servers, consuming storage space and being separate from the blockchain. Our goal is to represent image information using mathematical algorithms stored in smart contracts, tightly integrating with the blockchain. This approach uses no storage space and allows anyone to render the image information at any time based on the algorithm stored in the smart contract.
Here’s an example of using mathematical algorithms to draw dynamic flames.

github.com/ethereum/ERCs








Add ERC: Algorithmically generated NFT


master ← chen4903:master



          opened 01:13PM - 08 Aug 24 UTC




            chen4903
          



+88
-0






A non-fungible token standard that uses mathematical algorithms to draw and stor…e images without any servers or storage space.

Author: abcoathup
Date: 2024-08-09T22:10:22.167Z

The proposal doesn’t cover that onchain NFTs using data URIs have existed for some time.


simondlr.com



Flavours of On-Chain SVG NFTs on Ethereum — simondlr.com
NFTs, as unique items on the blockchain, has a URI that points to data containing the metadata & the corresponding visuals. This URI can be an HTTP link, pointing to a video or image hosted on a normal server, or other services like IPFS...





What should be returned by tokenURI?
ERCs don’t need to include admin methods e.g. setTokenAlgorithm

Author: chen4903
Date: 2024-08-10T06:08:48.178Z

Storing SVG files often requires writing a large amount of data, which can significantly increase gas consumption. However, by using mathematical algorithms, a large number of different images can be represented through just a few simple formulas and variables, resulting in minimal storage requirements (only a few formulas and variables). Moreover, representing images through mathematical algorithms has a modular nature, allowing for significant changes to an image by adding, removing algorithms, or altering variables.
I think we could: instead of traditionally using URLs(tokenURI) to point to images, we can switch to pointing to mathematical algorithms.

Author: bestape
Date: 2024-08-18T09:16:05.487Z

Have a look at iNFT as a proof-of-concept example that uses a base64 onchain-stored wrapper of IPFS-stored JavaScript that generates SVG tessellations.
Would this solution work for your math as well?

Author: SamWilsn
Date: 2024-10-14T02:58:27.576Z

I am going to echo @abcoathup’s comment that ERCs shouldn’t include functions that are only going to be called by the contract’s owner. The owner already knows how to interact with their contract, and over-specifying interfaces hurt flexibility.
I’d also suggest renaming the event to AlgorithmChange, and the getter to just algorithmOf to match ERC-721’s naming convention.
Title: ERC_7644__ERC_721_Name_Registry_Extension
Category: ERCs

Author: bizliaoyuan
Date: 2024-03-02T03:22:43.122Z

https://github.com/ethereum/ERCs/pull/292
Abstract
This standard enhances ERC-721 by giving each token a unique name and an expiry date, allowing other token holders to claim the name once it expires.
Rationale
Here are a few design decisions and why they were made:
Intuitive Token IDs
Current token IDs are predominantly numeric, lacking intuitiveness. The extension of the ERC-721standard to support Named Tokens aims to facilitate the acceptance and use of this standard within the NFT marketplace. By moving beyond mere numbers to include distinctive names, token IDs can more directly reflect the unique identity or value they represent.
Expanding NFT Use Cases
By allowing each token to possess a unique name, we unlock new application scenarios in ecosystems built around scarce username resources, such as domain name registration systems. In such scenarios, domain owners can demonstrate ownership directly by holding the corresponding token, thereby broadening the application spectrum and enhancing the value of NFTs.

Author: Kureev
Date: 2024-03-05T03:10:21.842Z

I wonder which exact problem would that solve? Right now you can set an asset name in the metadata, isn’t it enough?
As for the proposed solution for the domain names, I don’t see why they can’t be attached to the account directly through your registration system. In the proposed solution you add an extra layer: registry → nft → account and suggest to determine registration based on the token if I understand it correctly. However, you also suggest to “expire” the name attached to the token. In the case of the expiration, what would token indicate/what would be the value of the token?
On the other hand, you can write a domain name registry contract and create a simple mapping(address => Registration) where Registraction is a struct with params like expiration date etc. This way you don’t need tokens to prove ownership, don’t have a problem giving meaning to the tokens that are expired and there is no need to extend the standard.
However, if you’d like to use token as collateral or transfer ownership rights through the NFT transfer I think you can set an expiration date on the token itself by checking block time upon transferring attempt and again, map token id to the domain name in another smart contract. This way you achieve the same goals without extending the contract.
I think this is similar (in a way) to my Metadata Manager ERC: you can build an abstraction that works on top of existing standard instead of extending the standard itself. The only difference in your use-case is adding logic for the expiration and duplication checks unless I misunderstood the idea.

Author: SamWilsn
Date: 2024-03-05T16:32:36.133Z

TokenMintedWithName would be emitted alongside the Transfer event from ERC-721? Seems redundant.
Title: Only_using_EVM_contracts_to_solve_web2_platform_re
Category: ERCs

Author: ZWJKFLC
Date: 2024-03-07T06:39:43.923Z

Nowadays, CEX uses a very complex system to achieve payment collection, which requires precautions against issues such as key security.
I have a solution now, which is to type ETH/TOKEN to an address without changing user interaction, and then implement this set of functions only in the form of a contract, and it is very easy for developers to develop. I would like to ask, is there any significance in doing it, or is there anyone who needs it?
Only use contracts to implement the following functions and features
 getwalletadd(
    address Withdrawal_address,uint256 order/account/path
) public view return(address Payment_address)
//Get the address where users can make payments
//Withdrawal_address：It means the final payment address where eth/token goes.
//order/account/path：Transaction order or account ID on the web2 platform
//Payment_address：The address where consumers need to send money

imputationeth(address Withdrawal_address,uint256[] orders/accounts/paths)
//Collect Payment_address's eth to Withdrawal_address

User interaction habits have not changed during the entire process.
The secret key of Withdrawal_address is not required and eth can collect Withdrawal_address
And only contracts are used to ensure security. Only a single-digit interface is needed to access evm payment eth/token, and the gas fee is much lower than CEX. No maintenance costs required.
Title: ERC_6066__Signature_Validation_Method_for_NFTs
Category: ERCs

Author: jpitts
Date: 2023-03-02T19:58:03.739Z

As @boyuanx gave an lightning EIP talk today I am posting this here so we can discuss it.


Ethereum Improvement Proposals


ERC-6066: Signature Validation Method for NFTs
A way to verify signatures when the signing entity is an ERC-721 or ERC-1155 NFT

Author: stoicdev0
Date: 2023-03-03T21:26:16.852Z

Really interesting idea!
One doubt: why are you using a bytes4 return of a magic value instead of a simple boolean?
Title: ERC_7780__Validation_Module_Extension_for_ERC_7579
Category: ERCs

Author: kopykat
Date: 2024-10-05T09:22:38.804Z

Discussions for Add ERC: Validation Module Extension for ERC-7579 by kopy-kat · Pull Request #666 · ethereum/ERCs · GitHub
This proposal introduces three new module types on top of the existing modules described in ERC-7579. The modules are policy, signer and stateless validator. None of these modules are required to be implemented by accounts, but accounts can choose to implement them or other modules can choose to make use of them for additional composability.
Title: ERC_7803__EIP_712_Extensions_for_Account_Abstracti
Category: ERCs

Author: frangio
Date: 2024-10-22T18:25:51.277Z

Discussion topic for EIP-7803:


github.com/ethereum/ERCs








Add ERC-7803: EIP-712 Extensions for Account Abstraction


master ← frangio:712-aa



          opened 06:04PM - 30 Oct 24 UTC




            frangio
          



+157
-0






Moved from https://github.com/ethereum/EIPs/pull/8985







This EIP improves on EIP-712 signatures to better support smart contract accounts by 1) introducing signing domains as a way to prevent replay attacks when private keys are shared across accounts, and 2) allowing dapps and wallets to coordinate on the method that will be used to authenticate the signature.

Update Log

2024-10-21: First draft
2024-10-30: Moved from EIPs to ERCs
Title: About_the_ERCs_category
Category: ERCs

Author: matt
Date: 2023-11-02T01:32:16.440Z

(Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters.)
Use the following paragraphs for a longer description, or to establish category guidelines or rules:


Why should people use this category? What is it for?


How exactly is this different than the other categories we already have?


What should topics in this category generally contain?


Do we need this category? Can we merge with another category, or subcategory?

Author: etherpilled
Date: 2024-10-31T12:38:30.778Z

Hi, I am trying to submit an ERC standard but I don’t see where I can create it. My profile is new so it might be that or I am missing something? Thanks

Author: JohnCrunch
Date: 2025-02-08T15:38:53.221Z

Ditto. Trying to submit an ERC for conversation (according to protocol). But I cannot find the button to submit on this forum!
Title: ERC_7196__Simple_token_designed_for_smart_contract
Category: ERCs

Author: wenzhenxiang
Date: 2023-06-20T17:00:52.477Z

ERC20 tokens are Ethereum-based standard tokens that can be traded and transferred on the Ethereum network. But the essence of ERC20 is based on the EOA wallet design. EOA wallet has no state and code storage, and the smart contract wallet is different.
Almost all ERCs related to tokens are adding functions, our opinion is the opposite, we think the token contract should be simpler, more functions are taken care of by the smart contract wallet.
Our proposal is to design a simpler token asset based on the smart contract wallet,
It aims to achieve the following goals:

Keep the asset contract simple, only need to be responsible for the transaction function
approve and allowance functions are not managed by the token contract , approve and allowance should be configured at the user level instead of controlled by the asset contract, increasing the user’s more playability , while avoiding part of the ERC20 contract risk.
Remove the transferForm function, and a better way to call the other party’s token assets is to access the other party’s own contract instead of directly accessing the token asset contract.
Forward compatibility with ERC20 means that all fungible tokens can be compatible with this proposal.

Examples
The third party calls the user’s token transaction(transferForm),
Judges whether the receiving address is safe (safeTransferForm),
permit extension for signed approvals (ERC-2612,``permit)
authorizes the distribution of the user’s own assets(approve, allowance),
and adds the transfer hook function. (ERC-777, hook)
The above work should be handled by the user’s smart contract wallet, rather than the token contract itself.
this EIP is forward compatible with ERC-20. ERC-20 is backward compatible with this EIP.
I want to hear everyone’s opinions.
Title: Web2_platform_eth_token_docking_solution
Category: ERCs

Author: ZWJKFLC
Date: 2024-08-10T07:25:55.100Z

github.com/ethereum/ERCs








Add ERC: web2 platform eth/token docking solution


master ← ZWJKFLC:master



          opened 07:21AM - 10 Aug 24 UTC




            ZWJKFLC
          



+61
-0






When opening a pull request to submit a new EIP, please use the suggested templa…te: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

 - The PR edits only existing draft PRs.
 - The build passes.
 - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
 - If matching on email address, the email address is the one publicly listed on your GitHub profile.







Using multi-layer proxy contracts to achieve key-free and secure cryptocurrency payment solutions
Title: RFC__ERC721_token_metadata_update_notification
Category: ERCs

Author: vrypan
Date: 2023-04-17T09:25:52.382Z

More and more NFT tokens use metadata that change over time: traits, name, staking status, artwork.
Some marketplaces allow users to manually refresh metadata, but this is problematic: For example, a potential buyer may not be aware that the metadata of the token they are about to purchase have changed. Also, this is a market-specific solution, which often leads to marketplaces having a different representation of the token metadata depending on when they updated them.
I think that if ERC-721 was put together today, there would have been an even emission to indicate that metadata have changed.
The simplest approach would be something like event MetadataUpdated(uint tokenId); and the NFT smart contract could emit this event to notify that the metadata of tokenId has been updated.
I intend to submit an ERC proposal, but I would like to hear some feedback first.
I can see for example, how this could be abused. Should there be some kind of TTL? How are marketplaces (and other apps) treat very frequent MetadataUpdated() event emissions? Should there be a way to signal that all token metadata must be refreshed (typical case is artwork reveal, but there are many more similar ones)?

Author: abcoathup
Date: 2023-04-24T07:30:15.871Z

There is already an ERC for this:

Ethereum Improvement Proposals


ERC-4906: EIP-721 Metadata Update Extension
Add a MetadataUpdate event to EIP-721.
Title: New_ERC__Wallet_Signing_API
Category: ERCs

Author: lsr
Date: 2025-01-29T18:43:21.888Z

Abstract
Defines a new JSON-RPC method which enables apps to ask a wallet to sign EIP-191 messages.
Applications can use this JSON-RPC method to request a signature over any version of signed_data as defined by EIP-191. The new JSON-RPC method allows for support of future EIP-191 signed_data versions.
The new JSON-RPC method also supports EIP-5792-style capabilities, and support for signing capabilities can be discovered using wallet_getCapabilities as defined in EIP-5792.
Motivation
Wallets and developer tools currently support multiple JSON-RPC methods for handling offchain signature requests. This proposal simplifies wallet & tooling implementations by consolidating these requests under a single wallet_sign JSON-RPC method. This also leaves room for new EIP-191 signed_data versions without needing to introduce a new corresponding JSON-RPC method.
Furthermore, this new wallet_sign method introduces new functionalities via EIP-5792-style capabilities.
Title: ERC_7754__Tamperproof_Web_Immutable_Secure_Transac
Category: ERCs

Author: uni-guillaume
Date: 2024-08-09T21:23:55.698Z

Discussion for: https://github.com/ethereum/ERCs/pull/585/files
This EIP written in close collaboration with @remarks propose a new security mechanism to guarantee data integrity between dapps and wallets.
It introduces a new RPC method to be implemented by wallets, wallet_signedRequest, that enables dapps to interact with wallets in a tamperproof manner via “signed requests”. The dapp associates a public key with its DNS record and uses the corresponding private key to sign payloads sent to the wallet via wallet_signedRequest. Wallets can then use use the public key in the DNS record to validate the integrity of the payload. Wallets can subsequently confirm data integrity to their users

Author: radek
Date: 2024-08-10T21:25:08.360Z

Nice. Addresses one of the attack vectors that lead to blind signing of malicious tx.
We were also considering using DNS record during ETHBrno seucirty, but rather for the browser wallet to check the hashes of the downloaded JS. (As some of the attacks were executed using injected JS to Google Tag Manager).
a) Would you expand this ERC to also consider such injections?
b) Can you elaborate more on PK handling, esp. when no BE is used?

Author: uni-guillaume
Date: 2024-08-12T17:53:11.075Z

a) would definitely be open to it. I’m not familiar with the attack you describe (are you open to DM about it so i can learn more ?) . Wouldn’t the current solution prevent a script injection via google tags ? with the private key on the backend, i don’t see how any injection could tamper with the data, but if there is a way, i am all for modifying this ERC to cover it.
b) PK handling without a backend is not really possible unfortunately, as any code injection would steal the key. We opted to focus on PK + signing on the backend in the first version of this ERC to keep it simple and comprehensive. BE signing is the most flexible and secure way to guarantee data integrity, at the cost of a somewhat expensive setup (backend endpoint to create and sign TX + key management/rotation). We have however discussed possible future improvements that would help pure front end dapps. We could CSP-like entries to the manifest, such as allow/block list of contract address the dapp can interact with, allow/block list of ERC-712 functions that can be used, etc I think your suggestion about code signing would fit very well in that approach. I am unfamiliar with the way an extension can verify the JS payload signature of a web page, but happy to learn about it in DM
Title: ERC_7913__Key_Verifiers
Category: ERCs

Author: Amxx
Date: 2025-03-25T14:36:48.243Z

Update Log

2025-03-21: initial draft Add ERC: Key Verifiers by Amxx · Pull Request #986 · ethereum/ERCs · GitHub

Author: xinbenlv
Date: 2025-04-06T23:34:04.709Z

Hi @amxx glad to see this ERC which generalize the signature verifications.

A signer is a bytes object that is the concatenation of an address and optionally a key: verifier || key. A signer is at least 20 bytes long.

Question, was it intentional that byte packing rules was left out in verifier || key as out of scope in this ERC?

Author: Amxx
Date: 2025-04-07T09:31:50.694Z

There have been internal discussion with the other authors has to was is in scope and what is not.
IMO the encoding (verifier || key) and the verification process that is documented in the “Reference Implementation” section should be standard. It was decided otherwise so that this ERC is not depending on 1271. Currently, only the verifier interface is in scope.
Do you think signer encoding should be more formally standardized?

Author: xinbenlv
Date: 2025-04-07T10:25:21.950Z

IMHO in scope or out of scope, it’s fine either way. Just need to clarify in spec. So if you choose to leave it out of scope, please consider mentioning in Spec section too.
Title: ERC7602_Ethereum_Mixing_Transaction_Supervision
Category: ERCs

Author: Evelynlhn
Date: 2024-01-23T02:26:12.615Z

The EIP proposes a standard for monitoring and regulating mixing transactions on the Ethereum blockchain, aiming to address the challenges associated with privacy-enhanced transactions and potential misuse in illegal activities.

Author: hiddenintheworld
Date: 2024-01-23T02:43:49.035Z

Please provide extra information of this EIP here and submit it on Github before the name “EIP-8888” is set

Author: numtel
Date: 2024-01-27T19:44:24.659Z

What’s the motivation behind this?
I’ve been working on a fork of Semaphore that also encrypts the identity commitment as a public output of the proof in order to create a mixer that can respond to requests to decrypt transactions by recognized courts for criminal investigations.
https://github.com/numtel/zk-group-decryptable
Title: BLS_keys_related_ERC_discussion__ERC_2333__2334__2
Category: ERCs

Author: CarlBeek
Date: 2024-04-23T17:55:26.404Z

Posting this for discussions related to ERCs 2333, 2334, 2335. Previous discussions were hosted as GitHub issues:
ERC 2333 discussion issue
ERC 2334 discussion issue
ERC 2335 discussion issue
Title: Draft__Trustless_off_layer_1_governance
Category: ERCs

Author: dkeysil
Date: 2023-12-05T23:15:50.254Z

Decentralized Autonomous Organizations (DAOs) largely operate on the Ethereum blockchain, where every action incurs a significant ETH expense. This high cost of participation disproportionally affects smaller token holders, limiting their engagement in critical decision-making processes such as proposal surveys. Consequently, power tends to be concentrated among larger token holders, potentially undermining the very essence of decentralization.
With ZK rollups (e.g. Taiko) we get access to the trustless and cryptographically verified block hash from layer 1, so we are able to rebuild BlockHeader, get proof from L1 with eth_getProof, replace state root in the passed BlockHeader and compare it with the L1 block hash stored in the protocol smart contract. This makes it possible to verify any stored data from the L1 blockchain - in our case, it’s the amount of tokens at a specific block number (snapshot block number).
This setup would allow DAO token holders from Ethereum’s Layer 1 to vote with significantly reduced costs, fostering a more inclusive and democratic decision-making process.
Schema of the vote process that requires zero L1 transactions:
image1200×675 74.7 KB
I think it’s possible to make ERC out of this idea, so I want to ask there for a discussion of this idea and help to make ERC out of it.
Title: Gas_fee_ambiguity_in_ERC_4337__Who_pays_the_gas_fe
Category: ERCs

Author: DavidKim
Date: 2023-02-17T14:41:50.720Z

Hi everyone, thanks for reading this question. This was a question I got while reading the AA standard proposal.
I hear that by imposing account abstraction specified in ERC-4337 EOA is not the only one that can initiate a transaction.
What I’m confused about is the actual entity that pays the gas fee and the relationship with the paymaster.

From Vitalik’s article, it says that the bundler is paying for the transaction.
The bundler pays the fee for the bundle transaction in ETH, and gets compensated though fees paid as part of all the individual UserOperation executions. Bundlers would choose which UserOperation objects to include based on similar fee-prioritization logic to how miners operate in the existing transaction mempool. A UserOperation looks like a transaction; it’s an ABI-encoded struct that includes fields such as:
In this case, is the bundler an EOA that originates the transaction? Also, if the bundler pays the fee for transaction for each UserOperation what will it get in return? (e.g. Paymaster pays the bundler the transaction fee it gives?)
To sum up,

Is bundler an EOA that monitors the mempool of UserOperation which initiates the transaction?(If it’s the case, then it’s still the EOA that originates the tx right?)
What is the incentive model of Bundler? and the relationship between paymaster and bundler? (Why should the bundler pay the gas fee for Bundle transaction that includes UserOperation)
If Paymaster pays for the gas fee on behalf of a user, should it hold native ETH balance to pay it? Can a Paymaster pay the Entrypoint Contract with an ERC20 token?

Thank you for answering in advance 
----- UPDATE -----:
After doing some research with the AA and the history of it(e.g. EIP-3074 & EIP-2938) I noticed that the question was incorrect. The answer to it was that there is no consensus layer changes to the EVM so still contracts(CA) would not be able to initiate a transaction like EIP-2938 is proposing to do.
This EIP-4337 is using bundler as a relayer(decentralized) to make a transaction instead, and providing a standard interface of contracts & RPCs to standardize the system for this AA system (mempool + contracts - entrypoint, wallets, paymaster, etc).
Title: ERC_7786__Cross_Chain_Messaging_Gateway
Category: ERCs

Author: Amxx
Date: 2024-10-14T13:16:08.436Z

Official discussion thread for Add ERC: Cross-Chain Messaging Gateway by Amxx · Pull Request #673 · ethereum/ERCs · GitHub

Author: philippecamacho
Date: 2024-12-06T16:21:59.994Z

What is the purpose of the return argument (bytes4) in executeMessage?

Author: frangio
Date: 2024-12-06T16:46:48.884Z

This is to mitigate selector clashes, to make sure the receiver acknowledges the protocol it’s engaging in.

Author: philippecamacho
Date: 2024-12-10T21:40:56.225Z

What would be an example of an attack / things going wrong if the Gateway does not check the return value of executeMessage?

Author: philippecamacho
Date: 2024-12-11T01:02:08.613Z

I think I get it now, this is for ensuring that the Destination Gateway only can call the executeMessage function of the receiving application and not something else.

Author: ellie
Date: 2024-12-12T15:40:26.241Z

I love this ERC!
This ERC uses a ‘push’ mechanism rather than a ‘pull’ mechanism for messaging.  In my mind, a ‘push’ mechanism like the one described essentially uses a ‘pull’ mechanism under the hood - Whoever is calling the executeMessage function is pulling the message from the Destination Gateway.  I don’t think there’s anything wrong with either approach; I just find it to be a useful mental model.

Author: ernestognw
Date: 2025-01-07T19:39:42.636Z

Links to reference implementation with Axelar Network and audits:

Audit
AxelarGatewayBase
AxelarGatewayDestination
AxelarGatewayDuplex
AxelarGatewaySource
ERC7786Receiver

Author: u59149403
Date: 2025-05-04T03:15:14.810Z

Amxx:

Official discussion thread for Add ERC: Cross-Chain Messaging Gateway by Amxx · Pull Request #673 · ethereum/ERCs · GitHub


ERC contains this text: “The sender account (in the source chain) and receiver account (in the destination chain) MUST be represented using CAIP-10 account identifiers”. Unfortunately CAIP-10 for Ethereum addresses ( EIP155 Namespace, aka EVM Chains - Addresses | Chain Agnostic Namespaces ) contains this: “Anywhere “Postel’s Law” can apply, implementers SHOULD produce checksum-case secure addresses (whether in CAIP-10 or native format), and SHOULD accept both checksum case and legacy lowercase addresses, except where the security concerns of the particular usecase outweigh interoperability”.
In other words, CAIP-10 for Ethereum doesn’t contain definitive answer whether address should be lowercase or EIP-55 encoded. I think this is bad, so I reported this to CAIP: CAIP-10 and CAIP-19: mandate case-normalization · Issue #351 · ChainAgnostic/CAIPs · GitHub . But, as well as I understand, CAIP editors don’t plan to change anything here.
So, ERC-7786 should make its own decision here.
Also, another option may be to use CAIP-50 instead (it is binary) or CAIP-350 a. k. a. ERC-7930 (it is binary, too) ( New CAIP profile: interoperable address binary specification by 0xteddybear · Pull Request #350 · ChainAgnostic/CAIPs · GitHub , ERC 7930: Interoperable Addresses )
Title: ERC_7741__Authorize_Operator
Category: ERCs

Author: jeroen
Date: 2024-07-12T16:43:05.781Z

Discussion for  Add ERC: Authorize Operator #536