ERC-7838: Instruction Specific Address (ISA)

The Instruction Specific Address (ISA) standard introduces a mechanism for approval-less interactions with decentralised 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.

PR:

8 Likes

// Emit event for failed transaction

If you’re reverting, the event won’t persist.

The transaction does not revert in the processCallOps function itself. Instead, it gracefully handles the failed call and explicitly emits the ExecutionFailed event.

Since the emit statement is outside the reverted call’s context, it is part of the main transaction’s execution and will be recorded in the transaction logs.

1 Like
        if (!success) {
            // Emit event for failed transaction
            // Revert with the original error data
            assembly {
                let ptr := mload(0x40)
                let size := returndatasize()
                returndatacopy(ptr, 0, size)
                revert(ptr, size)
            }
        }

that comment appears in a block that reverts.

True, need to handle this properly. These are just examples of philosophy that ERC is trying to expand on, but point noted.

Could ISAs render traditional wallet-based UX paradigms obsolete, what new UX standards might emerge as a result?

  1. Self-Destruction:
  • After execution or refund, the ISA self-destructs to free resources and ensure it cannot be reused.
    selfdestruct(payable(refundRecipient));

I assume it is in conflict with the roadmap wrt selfdestruct.

does ERC-7838 ensure ISAs can’t be reused if selfdestruct is removed?

The ISA does not rely on selfdestruct. It uses it for gas refunds during contract creation, but it would still function without it, though it would result in slightly higher gas fees for the relayer.