Add ERC: Instruction Specific Address #762
Conversation
…ey features, specifications, and examples
eip-review-bot
changed the title
|
The commit ee9238a (as a parent of 56f52ef) contains errors. |
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
| --- | ||
| eip: 7838 | ||
| title: Instruction Specific Address | ||
| description: An interface for approval-less contract interactions, detaching wallets from DApps and enabling seamless CEX integration. |
There was a problem hiding this comment.
I'd recommend focusing more on a technical description here, instead of listing use cases. Also, drop "an interface for". It doesn't add any useful information, and the field had a maximum length.
|
|
||
| ## Abstract | ||
|
|
||
| This EIP introduces the Instruction Specific Address (ISA) mechanism, which allows for approval-less interactions with decentralized applications (DApps) through the use of dynamically generated single-use addresses. By enabling transactions without wallet connections or approvals, ISA enhances user security, simplifies interactions, and aligns Web3 interfaces with familiar Web 2.0 paradigms. |
There was a problem hiding this comment.
Small risk of overlap with Instruction Set Architecture. Not a problem, just wanted to mention it.
|
|
||
| ## Abstract | ||
|
|
||
| This EIP introduces the Instruction Specific Address (ISA) mechanism, which allows for approval-less interactions with decentralized applications (DApps) through the use of dynamically generated single-use addresses. By enabling transactions without wallet connections or approvals, ISA enhances user security, simplifies interactions, and aligns Web3 interfaces with familiar Web 2.0 paradigms. |
There was a problem hiding this comment.
Your abstract should contain a high-level technical overview of how the proposal works. Use cases should be in the motivation section.
|
|
||
| ## Rationale | ||
|
|
||
| ### Approval-less Contract Interactions |
There was a problem hiding this comment.
This subsection is justifying the proposal as a whole, and so belongs in the motivation section. The Rationale section is for explaining choices made within the document, for example how you chose 0xff as the prefix.
| - **Wallet Tunneling:** Without wallet connections, DApps cannot tunnel into user wallets to execute unintended actions. | ||
| - **Approval-based Risks:** By removing the need for token approvals, ISA eliminates scenarios where excessive allowances are exploited. | ||
|
|
||
| ### Security Enhancements |
There was a problem hiding this comment.
This subsection is kinda walking the border between motivation and rationale. If you make it more specific, it can probably stay here.
| - **First CTA is Action, Not Wallet Connection:** Users are encouraged to engage with the DApp's functionality first, removing the "connect wallet" barrier. | ||
| - **Unified Chain Experience:** By decoupling wallet requirements, ISA creates a consistent and seamless experience across platforms and ecosystems. | ||
|
|
||
| ### Compatibility with Existing Standards |
There was a problem hiding this comment.
This belongs in the backwards compatibility section.
| - **[EIP-7683](./eip-7683.md) (Cross-Chain Intents):** ISA supports interaction paradigms that abstract user intent across chains. | ||
| - **Broad Compatibility:** ISA ensures that its features are generic and protocol-agnostic, allowing integration with future standards. | ||
|
|
||
| Let me know if this meets your expectations or if further elaboration is needed! If all is good, we can proceed to the next section. |
There was a problem hiding this comment.
You should write proposals as if they were already final. This paragraph would be quite strange in a finished standard.
You can use HTML-style comments if you'd like <!-- comment -->
| The `DepositReceiver` contract handles transactions for ISAs, processes user-defined logic, and emits events for transaction completion or failure. | ||
|
|
||
| ```solidity | ||
| // SPDX-License-Identifier: MIT |
There was a problem hiding this comment.
Code within the document must be CC0-1.0 licensed. You can put MIT code in the assets directory and link to it instead if you prefer.
| The `ISAFactory` contract generates deterministic ISA addresses using the `CREATE2` opcode and emits events for transparency. | ||
|
|
||
| ```solidity | ||
| // SPDX-License-Identifier: MIT |
| The `ExecutionContract` processes and forwards ISA transactions, ensuring transparency by emitting events for all state changes. | ||
|
|
||
| ```solidity | ||
| // SPDX-License-Identifier: MIT |
ERC-7838: Instruction Specific Address (ISA)
The Instruction Specific Address (ISA) standard introduces a mechanism for approval-less interactions with decentralized applications (DApps) through dynamically generated single-use contract addresses. This standard enables seamless and secure DApp interactions without requiring wallet connections, approvals, or plugin dependencies, enhancing usability, security, and accessibility.