EIP-3074 — AUTH and AUTHCALL

Back to Account & Authentication

EIP-3074: AUTH and AUTHCALL Opcodes

EIP-3074 proposed two new EVM opcodes — AUTH (verify a signature setting an "authorized" register) and AUTHCALL (perform a call as the authorised account). Together they let an "invoker" contract perform actions on behalf of an EOA after verifying an off-chain signature.

EIP-3074 was eventually superseded by EIP-7702 (which has cleaner semantics) but the use cases are identical: meta-transactions, batch operations, gasless UX.

Neo Equivalent

The use case is exactly what witness scopes do already. A user signs a transaction with WitnessScope.CustomContracts listing the invoker contract; the invoker calls Contract.Call(token, "transfer", ...) and Runtime.CheckWitness(user) succeeds inside the token because the user's witness is in scope.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

// EIP-3074 (never deployed) sketch:
//
// AUTH opcode:
//   stack: [commit, y_parity, r, s] -> [signer]
//   if ecrecover(keccak("\x03" || chainid || invoker || commit), v, r, s) is valid:
//     set authorized = signer
//
// AUTHCALL opcode: like CALL but msg.sender becomes `authorized`.

contract Invoker {
    /// Off-chain user signs (chainid, invoker, commit) where `commit` is a hash
    /// of the action they're authorising. The invoker submits this on-chain.
    function relay(
        bytes32 commit,
        uint8 v, bytes32 r, bytes32 s,
        address target, uint256 value, bytes calldata data
    ) external {
        // assembly { auth commit v r s }    // sets authorized register
        // assembly { authcall target value data }   // call as authorized

        // Pre-7702 implementations had to roll their own — typically with an
        // "AccountFactory" that deploys a per-user proxy.
    }
}

using System;
using System.ComponentModel;
using System.Numerics;
using Neo;
using Neo.SmartContract.Framework;
using Neo.SmartContract.Framework.Attributes;
using Neo.SmartContract.Framework.Native;
using Neo.SmartContract.Framework.Services;

namespace R3E.Examples;

/// <summary>
/// Neo equivalent of EIP-3074: a "relayer" contract that performs operations
/// authorised by the user's transaction-level signature. No new opcodes needed —
/// witness scopes do the job.
/// </summary>
[DisplayName("Relayer")]
[ContractPermission("*", "*")]
public class Relayer : SmartContract
{
    public static object Execute(UInt160 user, UInt160 target,
                                 string method, object[] args)
    {
        // Witness check: the user must have signed this transaction with a
        // scope that includes the target contract.
        if (!Runtime.CheckWitness(user)) throw new Exception("user must sign");

        // Now call target on the user's behalf.
        // CheckWitness(user) inside `target` will succeed because the user's
        // witness is in scope.
        return Contract.Call(target, method, CallFlags.All, args);
    }

    public static object[] ExecuteBatch(
        UInt160 user, UInt160[] targets, string[] methods, object[][] args)
    {
        if (!Runtime.CheckWitness(user)) throw new Exception("user must sign");
        if (targets.Length != methods.Length || methods.Length != args.Length)
            throw new Exception("length mismatch");

        var results = new object[targets.Length];
        for (int i = 0; i < targets.Length; i++)
            results[i] = Contract.Call(targets[i], methods[i], CallFlags.All, args[i]);
        return results;
    }
}

What Witness Scopes Buy You

When the user builds the transaction:

new TransactionBuilder()
  .invoke(relayer, "executeBatch", [user, targets, methods, args])
  .signers([{
    account: user,
    scopes: WitnessScope.CustomContracts,
    allowedContracts: [relayer, ...targets]
  }])
  .build()

The user is explicitly authorising relayer to act on their behalf, but only within calls into relayer and the listed targets. There's no concept of a persistent "authorized register" that could leak across calls — scopes are transaction-bound.