{"id":"EIP-3074","name":"AUTH and AUTHCALL Opcodes","status":"Withdrawn","chain":"ethereum","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"}],"supersededBy":"EIP-7702","uxImpact":"Withdrawn historical reference: do not build new AUTH/AUTHCALL flows. EIP-3074 was never activated on Ethereum mainnet, and its official proposal says it was superseded by EIP-7702. EIP-7702 uses a different delegation mechanism and is not a drop-in replacement for EIP-3074's invoker authorization.","officialUrl":"https://eips.ethereum.org/EIPS/eip-3074","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","historical":true,"kind":"proposal","hasDetailedContent":true,"content":{"id":"EIP-3074","sources":[{"label":"Official EIP-3074 specification","url":"https://eips.ethereum.org/EIPS/eip-3074","type":"official-spec"},{"label":"Official EIP-7702 specification","url":"https://eips.ethereum.org/EIPS/eip-7702","type":"reference"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"Withdrawn historical reference: do not build new AUTH/AUTHCALL flows. EIP-3074 was never activated on Ethereum mainnet, and its official proposal says it was superseded by EIP-7702. EIP-7702 uses a different delegation mechanism and is not a drop-in replacement for EIP-3074's invoker authorization.","applicability":{"whenToUse":["Historical protocol research comparing EIP-3074's AUTH/AUTHCALL design with EIP-7702.","Reviewing why the proposal was withdrawn and how its invoker authorization model shaped later account UX discussions.","Documenting archived research, security assumptions, or product decisions that mention EIP-3074."],"whenToAvoid":["New wallet, batching, sponsorship, or delegation design work that needs a currently supported standard.","Treating AUTH/AUTHCALL as Ethereum mainnet functionality or assuming EIP-7702 is a drop-in replacement.","Reusing EIP-3074 invoker authorization copy, prototypes, or mockups as implementation guidance."]},"designerTakeaways":["EIP-3074's historical model paired a signed authorization with an invoker contract that could call as the signer.","Batching and sponsored transactions were motivating use cases, not current product requirements from this withdrawn proposal.","Its invoker trust, replay protection, and disclosure concerns remain useful topics when reviewing archived wallet UX.","EIP-7702 is the stated replacement, but its delegation mechanism is different and not a drop-in replacement."],"problemsSolved":[],"uxPatterns":[],"antiPatterns":[{"pattern":"Treating EIP-3074 as a current implementation target","why":"The official EIP is Withdrawn, was superseded by EIP-7702, and was not activated on Ethereum mainnet.","instead":"Label archived AUTH/AUTHCALL material as historical reference.","severity":"critical"},{"pattern":"Hiding the invoker trust model in historical analysis","why":"EIP-3074 delegated control through an invoker contract, so an untrusted or flawed invoker could put the signer at risk.","instead":"Document invoker identity, signed scope, replay protection, and revocation assumptions when reviewing archived designs.","severity":"critical"},{"pattern":"Treating EIP-7702 as a drop-in replacement","why":"EIP-7702 replaces EIP-3074 through a different delegation mechanism and wallet integration model.","instead":"Compare the account-delegation model and support requirements before carrying findings across.","severity":"high"},{"pattern":"Showing authorization scope only after signing","why":"The historical invoker model could leave users unable to assess the contract and call scope before authorization.","instead":"Call out pre-signing invoker and call-scope disclosure when critiquing archived wallet UX.","severity":"high"},{"pattern":"Assuming sponsorship removes all user risk","why":"Sponsored execution still depended on invoker validation, replay protection, and failure handling.","instead":"Include relayer, replay, and failure conditions in historical security notes.","severity":"medium"}],"specConstraints":[{"id":"sponsored-tx-motivation","constraint":"The proposal’s motivation is to let EOAs use held assets in sponsored transactions without holding Ether for gas.","appliesTo":"application","normativity":"normative","specQuote":"With the extraordinary growth of tokens on Ethereum, it has become common for EOAs to hold valuable assets without holding any ether at all. Today, these assets must be converted to ether before they can be used to pay gas fees. However, without ether to pay for the conversion, it's impossible to convert them. Sponsored transactions break the circular dependency.","specSection":"Motivation","specUrl":"https://eips.ethereum.org/EIPS/3074#motivation","designImplication":"Treat sponsored execution as historical motivation only; do not imply this withdrawn proposal is an available wallet capability."},{"id":"invoker-immutability","constraint":"Invoker contracts must not be upgradeable because changed code could compromise accounts that signed over the invoker.","appliesTo":"account-implementation","normativity":"rationale","specQuote":"An important note is that invoker contracts **MUST NOT** be upgradeable. If an invoker can be redeployed to the same address with different code, it would be possible to redeploy the invoker with code that does not properly verify `commit` and any account that signed a message over that invoker would be compromised. Although this sounds scary, it is no different than using a smart contract wallet via `DELEGATECALL`. If the wallet is redeployed with different logic, all wallets using its code could be compromised.","specSection":"Rationale > Invoker Contracts","specUrl":"https://eips.ethereum.org/EIPS/3074#invoker-contracts","designImplication":"For archived AUTH/AUTHCALL concepts, show invoker code identity and immutability evidence before treating a sponsor as trusted."},{"id":"account-auth-compat","constraint":"The proposal’s AUTH model can preserve old ECDSA authorization even as accounts evolve toward other authentication methods.","appliesTo":"account-implementation","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nAlthough this EIP poses no issues for backwards compatibility, there are concerns that it limits future changes to accounts by further enshrining ECDSA signatures. For example, it might be desirable to eradicate the concept of EOAs altogether, and replace them with smart contract wallets that emulate the same behavior. This is fully compatible with the EIP as written, however, it gets tricky if users can then elect to \"upgrade\" their smart contract wallets to use other methods of authentication -- e.g. convert into a multi-sig. Without any changes, `AUTH` would not respect this new logic and continue allowing the old private key to perform actions on behalf of the account.\n\nA solution to this would be at the same time that EOAs are removed, to modify the logic of `AUTH` to actually call into the account with some standard message and allow the account to determine if the signature / witness is valid. Further research should be done to understand how invokers would need to change in this situation and how best to write them in a future-compatible manner.","specSection":"Backwards Compatibility","specUrl":"https://eips.ethereum.org/EIPS/3074#backwards-compatibility","designImplication":"Keep this historical authorization model separate from newer account-delegation designs and disclose its authentication assumptions."},{"id":"invoker-commit-binding","constraint":"Secure invokers should bind replay protection, value, gas, destination, and calldata into the signed commit.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"### Secure Invokers\n\nThe following is a non-exhaustive list of checks/pitfalls/conditions that invokers *should* be wary of:\n\n - Replay protection (ex. a nonce) should be implemented by the invoker, and included in `commit`. Without it, a malicious actor can reuse a signature, repeating its effects.\n - `value` should be included in `commit`. Without it, a malicious sponsor could cause unexpected effects in the callee.\n - `gas` should be included in `commit`. Without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee.\n - `addr` and `calldata` should be included in `commit`. Without them, a malicious actor may call arbitrary functions in arbitrary contracts.\n\nA poorly implemented invoker can *allow a malicious actor to take near complete control over a signer's EOA*.","specSection":"Security Considerations > Secure Invokers","specUrl":"https://eips.ethereum.org/EIPS/3074#secure-invokers","designImplication":"If documenting the historical flow, show every committed execution field and warn that missing one can give a relayer broad control."},{"id":"tx-origin-risk","constraint":"Allowing tx.origin as the authorized signer can break sandwich and reentrancy protections.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"### Allowing `tx.origin` as Signer\n\nAllowing `authorized` to equal `tx.origin` has the possibility to:\n\n - Break atomic sandwich protections which rely on `tx.origin`;\n - Break reentrancy guards of the style `require(tx.origin == msg.sender)`.\n\nThe authors of this EIP believe the risks of allowing `authorized` to equal `tx.origin` are acceptable for the reasons outlined in the Rationale section.","specSection":"Security Considerations > Allowing tx.origin as Signer","specUrl":"https://eips.ethereum.org/EIPS/3074#allowing-tx-origin-as-signer","designImplication":"Keep tx.origin authorization visibly exceptional and show the affected security assumptions in any legacy integration review."},{"id":"relayer-risk","constraint":"Sponsored relayers can spend unreimbursed gas when authorization is invalidated or assets are swept.","appliesTo":"application","normativity":"security-considerations","specQuote":"### Sponsored Transaction Relayers\n\nIt is possible for the `authorized` account to cause sponsored transaction relayers to spend gas without being reimbursed by either invalidating the authorization (i.e. increasing the account's nonce) or by sweeping the relevant assets out of the account. Relayers should be designed with these cases in mind, possibly by requiring a bond to be deposited or by implementing a reputation system.","specSection":"Security Considerations > Sponsored Transaction Relayers","specUrl":"https://eips.ethereum.org/EIPS/3074#sponsored-transaction-relayers","designImplication":"Historical sponsored-flow documentation should show relayer reimbursement/bond or reputation safeguards and the user-visible failure path."}],"technicalNotes":"EIP-3074 proposed AUTH (0xf6) and AUTHCALL (0xf7): an invoker contract could validate a signed authorization and call as the authorized EOA. The official page marks the proposal Withdrawn with the reason \"Superseded by EIP-7702.\" EIP-7702 instead installs an EOA delegation indicator through a type-0x04 set-code transaction. The mechanisms and UX assumptions differ, so archived EIP-3074 material is not an implementation specification.","relatedStandards":[{"id":"EIP-7702","relationship":"Explicit replacement: EIP-7702 supersedes EIP-3074, but uses a different delegation mechanism and is not a drop-in replacement for EIP-3074's AUTH/AUTHCALL invoker authorization."}]},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/eip-3074","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=EIP-3074","type":"discussion"},{"label":"Official EIP-7702 specification","url":"https://eips.ethereum.org/EIPS/eip-7702","type":"reference"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/EIP-3074","markdown":"https://www.eipsfordesigners.com/standards/EIP-3074/content.md","agent":"https://www.eipsfordesigners.com/standards/EIP-3074/agent.md","api":"https://www.eipsfordesigners.com/api/standards/EIP-3074","official":"https://eips.ethereum.org/EIPS/eip-3074","discussion":"https://ethereum-magicians.org/search?q=EIP-3074"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}