[ethresear.ch] [Security] Scoped Capability Tokens for STVA

description:

Short-lived, purpose-limited, revocable authorization tokens (EIP-712 typed data or ERC-1271-compatible) that grant only specific actions (e.g. upgrade implementation to 0x…transfer X of token Y to Z install module with permissions P).

They eliminate ambient authority and broad approvals.

Highest synergy because they compose cleanly with independent simulation (the simulation result can be bound into the capability) and with account authority lifecycle (capabilities are issued, used, and revoked under explicit lifecycle rules).

Wallets and hardware devices can require a matching capability before presenting a high-risk payload for signature.

author: @MATOBOYCRYPTO65

discussions-to: https://ethereum-magicians.org/t/scoped-capability-tokens-for-stva/30124

status: Draft

type: Standards Track

category: ERC

created: 2026-10-29

Abstract:

Defines a standard format and verification interface for scoped, time-bound, purpose-limited capability tokens used in Secure Transaction Verification and Authorization (STVA).

Capabilities attenuate authority, are independently verifiable offline, support revocation, and bind to simulation results or intent hashes.

Motivation:

Broad, long-lived approvals and owner/module keys are a primary vector in high-value losses. Capabilities enforce least privilege at signing time.

Specification:

Capability is an EIP-712 typed structured data object (or ERC-1271 signature over its hash).

Core fields:

issuer (address)

subject (address or account that may exercise it)

scope (bytes32 hash of structured scope: action type, target, value bounds, calldata selector/mask, permissions)

validAfter validUntil (uint48)

nonce or salt (anti-replay)

simulationResultHash (optional binding to Independent Simulation Result)

intentHash (optional)

chainId

Issuance: any authority (EOA, multisig, smart account) signs the capability.

Consumption: the account or verifier checks signature, expiry, scope match against the proposed transaction/UserOperation, and (if present) simulation binding. On success the capability MAY be marked spent (on-chain nullifier or off-chain single-use tracking).

Revocation: issuer publishes a revocation list entry or on-chain revocation registry keyed by capability hash nonce.

Compliance levels: Basic (expiry + scope check), Standard (+ independent hash recompute), Strict (+ simulation binding + hardware display of scope).

Interface:

interface IScopedCapability

struct Capability

address issuer;

address subject;

bytes32 scope; keccak256 of structured Scope

uint48 validAfter;

uint48 validUntil;

bytes32 salt;

bytes32 simulationResultHash; optional

bytes32 intentHash; optional

uint256 chainId;

struct Scope

bytes4 selector; or bytes32 actionId

address target;

uint256 valueMax;

bytes calldataMask; optional restriction

bytes32 permissions; for modules ownership changes

Verify a capability against a proposed action

function verifyCapability

Capability calldata cap,

bytes calldata signature,

bytes32 txOrUserOpHash,

bytes calldata actionData

external view returns (bool valid);

Optional on-chain spend nullify

function spendCapability(bytes32 capabilityHash) external;

event CapabilityRevoked(bytes32 indexed capabilityHash, address indexed issuer).

Discussion points:

Exact Scope encoding (ABI vs. human-readable JSON + hash).

On-chain vs. purely off-chain revocation lists.

Binding strength to simulation results.

Integration with ERC-1271 smart-account signatures and EIP-7702.