/cli-cast

EIP-7702 Delegation Revocation

Use Cast's native authorization commands to clear delegation. Follow the EIP-7702 specification and verify that each selected chain's active fork supports type-4 transactions through $evm-atlas and current official chain documentation. All state, simulation, estimation, and verification reads belong to atlas under SKILL.md.

Select the Signer and Native Route First

Before transaction preparation or secret access, check the installed capabilities in a clean environment:

env -i PATH="$PATH" cast wallet sign-auth --help
env -i PATH="$PATH" cast send --help
env -i PATH="$PATH" cast recover-authority --help
env -i PATH="$PATH" cast from-rlp --help

Check each producer's exit status; when filtering, capture successful help first as in browser-signing.md. Do not infer authorization signing from send --browser or ordinary message signing. Check hardware support for this operation as well as the CLI flag; a listed device is not proof its firmware can sign the authorization digest.

Resolve the public authority, public sender, and supported signer for each before investing in simulation. Reuse an existing encrypted keystore, supported hardware signer, or an explicitly supported target-project secret consumer, subject to SKILL.md's signer preferences and the user's restrictions. Discover a project's secret-manager adapter and its owning instructions at runtime; do not assume a particular repository or secret-manager setup. Preparation does not load credentials. Never ask for secrets in chat, print them, or expose them through command logs.

If the necessary integration is absent, report the precise missing prerequisite and supported next step: an existing supported signer, an authorization produced through an approved supported route, or separately authorized adapter work in its owning project. Do not invent keystore cryptography, automate secret-entry terminals, or build a signing/approval framework incidentally. In a browser-only flow without authorization-signing support, stop before a signing request; never fall back silently. See browser-signing.md for using an existing authorization with a browser outer transaction.

Bind the Authorization and Nonces

The authority signs permission to change its own code. The sender signs, funds, and submits the containing transaction; it may be the authority or a separate fee payer. Revocation sets the authorization's delegate to 0x0000000000000000000000000000000000000000. This delegate is distinct from the outer transaction's to address. An ordinary transfer to zero does not revoke delegation. Review the outer destination, value, and calldata independently; type 4 requires a destination and cannot create a contract.

Prepare one clearing authorization per selected chain. Review authority, chain ID, zero delegate, authorization nonce, signer, and intended transaction sender. Use the selected chain's nonzero ID explicitly; wildcard chain ID 0 requires explicit cross-chain scope authorization. Never infer it from a multi-chain request or bypass its warning with --force. Repeat state checks, fee accounting, approvals within their stated scope, and outcome verification for every chain.

Ask atlas for a canonical checkpoint (block number/hash), authority code and nonce, sender nonce and balance, and pending nonce evidence for both accounts. Code 0x already satisfies clearing at that checkpoint; report the observed state without manufacturing a revocation transaction. A delegation indicator is 0xef0100 followed by a 20-byte delegate; other code requires investigation. Resolve pending activity and nonce changes before signing, then refresh again before submission. A single provider's pending count does not exclude every outstanding authorization.

For one tuple and no intervening nonce changes:

A successfully applied authorization increments the authority nonce once more. Do not reuse the table blindly for multiple tuples or pending sequences; reconcile their processing order. If state changes invalidate the reviewed nonce, stop and rebuild/review the changed payload instead of retrying the old signature.

Check installed behavior against the matching wallet source and transaction builder's resolve_auth. sign-auth --nonce supplies the authorization nonce directly; --self-broadcast derives a nonce by RPC and adds one, and currently conflicts with --nonce. Use atlas's explicit --chain and computed --nonce, omitting --self-broadcast, so sign-auth performs no implicit standalone chain/nonce lookup. For address-valued send --auth, pass the outer nonce N; Cast adds one internally. Never add that increment twice.

Approval and Simulation

Use staged approval when exact simulation needs a real signature or a separately approved authorization artifact is required. This conditional route does not add stages to ordinary transactions. Existing explicit approval covering a concrete payload and its subsequent use remains valid; do not request it again merely because work enters a new phase.

1. Review authorization intent without signing. Present all authorization fields, signer, intended sender, exact signing command, and intended use. Name the later simulation/provider disclosure the approval covers. The signature authorizes code clearing and is independently submit-able by anyone while its chain/nonce conditions hold; it is not bound to the outer transaction's sender, fees, destination, calldata, or value. Require explicit approval of this payload and scope before accessing secrets or creating the signature. This approval does not itself authorize an outer transaction signature or broadcast.
2. Sign and recover locally. Refresh nonces through atlas, create the approved authorization using the selected supported signer, decode it, and recover its authority as below. Do not broadcast. Handle the signature as an authorization capability: keep it out of ordinary logs and transmit it to a simulation provider only when the approval covers that disclosure. A failed simulation does not cancel an already issued authorization.
3. Simulate, estimate, and review the outer transaction. Through atlas, use the actual authorization in the exact type-4 call object/authorizationList, with reviewed sender, nonce, destination, value, calldata, and fees. Require evidence that the provider applies the tuple and models its nonce transition and gas effects. An accepted RPC field, dummy signature, skipped tuple, or code-only state override does not prove the complete signed transaction. If the provider lacks support, resolve a supported simulation route under SKILL.md or report the exact gap. Complete chain-specific fee accounting and present the concrete transaction under SKILL.md's Review before its signature/send.
4. Refresh and submit within approval. Recheck authority code/nonces, sender nonce/balance, pending activity, fee validity, and affordability through atlas. Preserve the approved authorization and outer fields. Changed payloads require a revised review and simulation; wallet gas edits retain only the existing browser exception. Submit with the exact approved signer and command, then verify both outcomes below.

The one-command local route is available only when simulation can establish the complete reviewed authorization's effects without first creating its signature, or equivalent exact evidence is already available. State the simulation method and its limits. Its transaction review must include the authorization intent and explicitly approve both signatures and broadcast. If simulation instead requires an actual signature, select the staged route; never invoke cast send to obtain a preparation artifact.

Native Commands

These are signing/broadcast templates, executable only at their approved phase. Populate public variables from the review and atlas; use the selected fee policy. KEYSTORE_FILE denotes an existing approved keystore, not a request to create one. Replace its signer option only with the reviewed supported signer. RPC_URL means the continuous transport selected under SKILL.md, including its alias and stderr rules.

For an approved local self-broadcast, AUTHORITY equals the sender and TX_NONCE is N:

ZERO_DELEGATE='0x0000000000000000000000000000000000000000'
cast send "$TX_TO" --data "$CALLDATA" --value "$VALUE_WEI" \
  --auth "$ZERO_DELEGATE" --chain "$CHAIN_ID" --nonce "$TX_NONCE" \
  --from "$AUTHORITY" --keystore "$KEYSTORE_FILE" --rpc-url "$RPC_URL" \
  --gas-limit "$GAS_LIMIT" --gas-price "$MAX_FEE_WEI" \
  --priority-gas-price "$PRIORITY_FEE_WEI" --async

For a separately approved authorization, AUTH_NONCE is N + 1 for self-broadcast or A for a different payer:

ZERO_DELEGATE='0x0000000000000000000000000000000000000000'
SIGNED_AUTH=$(cast wallet sign-auth "$ZERO_DELEGATE" \
  --chain "$CHAIN_ID" --nonce "$AUTH_NONCE" --keystore "$KEYSTORE_FILE") || exit 1

Decode locally with cast from-rlp "$SIGNED_AUTH". Its six fields are [chain_id, address, nonce, y_parity, r, s]; verify chain, zero delegate, and nonce against the approved intent. Losslessly map those fields to the authorization JSON keys chainId, address, nonce, yParity, r, and s, preserving integer precision and using RPC hex quantities (0x0 for integer zero, not RLP's empty 0x). Recover with cast recover-authority "$AUTH_JSON" and require an exact address match with the reviewed authority. The RLP artifact is not a plain message signature; do not pass it to wallet verify as one. Keep the decoded tuple and signed RLP bound together through simulation and submission; recovery alone does not prove on-chain nonce validity.

After simulation and transaction approval, submit the same signed authorization. The sender's signer can differ:

cast send "$TX_TO" --data "$CALLDATA" --value "$VALUE_WEI" \
  --auth "$SIGNED_AUTH" --chain "$CHAIN_ID" --nonce "$TX_NONCE" \
  --from "$SENDER" --keystore "$SENDER_KEYSTORE_FILE" --rpc-url "$RPC_URL" \
  --gas-limit "$GAS_LIMIT" --gas-price "$MAX_FEE_WEI" \
  --priority-gas-price "$PRIORITY_FEE_WEI" --async

For a supported browser outer transaction, replace the keystore option with --browser, following browser-signing.md; do not combine signer options. Always preserve the authorization list and type.

Type-4 revocations use EIP-1559 fee caps, not --legacy. Retain the default Ethereum Rabby Slow policy unless another compatible policy is selected. Include authorization intrinsic costs, applicable refunds, and chain-specific additional fees in the full estimate/reserve under SKILL.md and current official sources. Do not subtract expected refunds from upfront funding or reuse a 21000-gas exact-zero transfer assumption. A legacy sweep, if separately requested, is a separate reviewed transaction after clearing is verified.

Verify and Recover

Have atlas obtain the outer transaction and canonical receipt, reconcile the selected tuple's chain, recovered authority, delegate, and nonce against transaction evidence, and query eth_getCode for the authority at a canonical checkpoint at or after inclusion. Require code 0x for successful clearing. Reconcile nonce transitions and tuple ordering as needed to establish application; investigate later transactions or reorgs when evidence conflicts. Code already empty before inclusion does not by itself prove this tuple applied.

Report the transaction outcome and authorization outcome separately, with the code checkpoint and ordinary receipt, fee, nonce, and explorer evidence:

• A successful outer receipt can contain a skipped authorization. Unchanged delegation means clearing was not achieved; missing application evidence is unresolved, not success.
• An applied authorization survives a reverted transaction body. Recognize cleared code even when receipt status is failure; do not blindly submit another revocation.
• For an uncertain broadcast, preserve SKILL.md's no-retry handling and the browser recovery rules. Check transaction existence and actual authority state before any retry, replacement, or new authorization.

Clearing delegation removes code; it does not erase account storage or revoke unrelated token approvals. Keep those effects and any separately requested cleanup distinct.