policy:
  allow_implicit_invocation: true

# Browser Wallet Signing

Check capabilities and establish the public sender during preparation. Open a signing request only after the transaction
or message review in `SKILL.md` has been explicitly approved.

## Availability

Confirm the installed Cast supports browser signing:

```sh
CAST_SEND_HELP=$(env -i PATH="$PATH" cast send --help) || exit 1
printf '%s\n' "$CAST_SEND_HELP" | rg --no-config -- '--browser'
```

Check the help command's exit status as well as the match. Use a clean environment for help output because Cast may
print environment-backed credential defaults. Browser support is specific to each subcommand; `send --browser` does not
imply `wallet address --browser` or `wallet sign --browser` exists.

If unavailable in a browser-only workflow, stop without a signer fallback. Otherwise the signer preferences in
`SKILL.md` apply. Browser signing requires an interactive browser and local port `9545`; it does not work in ordinary
headless CI or SSH sessions.

### EIP-7702 Authorization Boundary

Read [eip7702.md](eip7702.md) before preparing delegation or revocation. Check `cast wallet sign-auth --help` in a clean
environment separately: `send --browser` does not establish authorization-signing support. When `sign-auth` lacks
browser support, a browser-only request needing a new authorization is blocked before opening a signer. Report the
missing capability and supported next step; never substitute message/typed-data signing or introduce secret-entry
automation. A different signer requires authorization under the user's signer constraints.

An already approved, verified authorization can accompany `cast send --auth "$SIGNED_AUTH" --browser` when the installed
Cast and connected wallet support that type-4 transaction. The browser signs the outer transaction as its sender/fee
payer; the authorization's recovered authority may differ. An address-valued `--auth` needs a local signer and cannot
obtain a new authorization through the browser sender. Preserve the full reviewed authorization list and transaction
type in the wallet; reject unsupported transport, dropped tuples, or substituted authorizations. Apply the existing
fee-edit exception only to gas settings. Verify authorization application and account code after inclusion as well as
the receipt.

## Resolve the Sender

Use the public address supplied by the user or already known from the connected wallet as `OWNER` for preparation.
Resolve ENS through `$evm-atlas`. Do not load key material to discover an address. Use `cast wallet address --browser`
only if that exact subcommand's current help exposes `--browser`; otherwise ask for the public address.

`cast send --browser` does not enforce `--from` or `--nonce`: the wallet signs with its active account and may
substitute that account's nonce, so a mismatch broadcasts from the wrong sender. Immediately before each approved
broadcast, run `cast wallet address --browser` (when its help exposes `--browser`) and require the result to equal the
reviewed `OWNER`; otherwise have the user confirm the active wallet account first. On a mismatch, stop and ask the user
to switch accounts; an account change requires a revised review. After broadcast, verify the transaction's `from` and
nonce against the review as part of receipt verification.

## Approved Broadcast

Run the exact reviewed command, for example:

```sh
cast send "$CONTRACT" 'transfer(address,uint256)' "$TO" "$AMOUNT" \
  --rpc-url "$RPC_URL" \
  --from "$OWNER" \
  --gas-price "$RABBY_SLOW_MAX_FEE_WEI" \
  --priority-gas-price "$RABBY_SLOW_PRIORITY_FEE_WEI" \
  --async \
  --browser
```

`$RPC_URL` is the reviewed continuous-provider transport selected under `SKILL.md`; never use it for a standalone read.

The example uses the default Ethereum fee policy. Use the user- or consumer-selected policy from `SKILL.md` when one is
specified. For a fixed legacy policy, replace the fee pair with `--legacy --gas-price "$GAS_PRICE"` and preserve the
reviewed gas limit. Do not pass EIP-1559 priority-fee flags with a legacy transaction.

Unless the reviewed workflow fixes its fees, the user may deliberately edit the gas limit, gas price, max fee per gas,
or max priority fee per gas in Rabby's confirmation UI, including by selecting a different tier. Treat their approval of
the final wallet screen as authorization for those gas settings. Apply `SKILL.md`'s chain-specific accounting to the
resulting reserve, additional fees, and affordability; an execution fee cap may not cap the total cost. Do not reject,
stop, request another approval, or resimulate solely because those values differ from the reviewed command.

This exception applies only to gas settings changed and approved in the wallet UI. Confirm the chain, account, target,
calldata, native value, nonce, and authorization list (if present) still match the reviewed transaction; reject the
request if any of those fields change.

For a workflow whose transfer value depends on its fee reserve, including exact-zero and best-effort sweeps, preserve
the reviewed transaction type, gas limit, and gas price or both EIP-1559 fee caps. Reject wallet changes before signing
and rebuild, simulate, and review the dependent transfer value. Cast 1.8.3+ forwards an explicit `--legacy` type to the
browser wallet; earlier versions could drop it at the provider boundary, so confirm the wallet screen shows the reviewed
type. If the wallet cannot preserve a legacy request, stop without submitting an EIP-1559 substitute.

Do not combine `--browser` with another signer flag. Capture the transaction hash, then have `$evm-atlas` verify the
receipt before reporting success.

## Timing

Wallet approval is an unbounded human-interaction step, not network latency: the wait is for a person to notice and
click a prompt, which can exceed a typical command timeout. Run the broadcast command with a generous timeout, or in the
background, so the process outlives the approval wait. A short synchronous timeout risks killing the process after the
wallet has already broadcast but before `cast` prints the hash back — the transaction still lands on-chain, but the
operator loses the hash and cannot immediately confirm it.

Add `--async` to every browser-signed broadcast, not only as a fallback: it prints the transaction hash as soon as
signing and broadcast succeed and exits without also waiting for a receipt, shrinking the window in which a timeout can
outrace the printed output. Poll for the receipt separately afterward.

## Recovering From a Killed or Timed-Out Process

If the process is killed or times out before printing a hash, its exit status alone does not prove nothing was broadcast
— the wallet may have submitted the transaction via its own configured RPC provider, independent of the `--rpc-url`
passed to `cast`, and mempool visibility lags and varies across providers (especially behind a load-balanced RPC
aggregator). Do not treat a single provider's pending-transaction count or a single provider lookup miss as proof of
non-broadcast. Before concluding nothing was sent:

- Ask `$evm-atlas` to repeat the raw `eth_getTransactionByHash` lookup over 30-60 seconds to allow mempool propagation,
  rather than accepting one immediate miss as final.
- Ask the user to check their wallet's own pending-activity view — the wallet knows definitively whether it submitted
  the transaction, independent of any RPC endpoint the agent queries.

Only report the outcome as resolved (confirmed or genuinely never sent) once one of these gives a positive or a stable,
repeated negative result.

## Message Signing

Cast supports browser signing of plain messages and EIP-712 typed data. Confirm the installed version's capabilities
before preparation, using clean-environment help:

```sh
env -i PATH="$PATH" cast wallet sign --help
env -i PATH="$PATH" cast wallet verify --help
```

Require `sign` to expose `--browser` and `--from`; for typed data, also require `--data` and `--from-file` on both
subcommands. If unavailable, stop a browser-only flow without loading a key or substituting a transaction signature.

Use an EIP-712 JSON file containing `domain`, `types`, `primaryType`, and `message`. An API's `values` object is not a
Cast `message`: use the consuming workflow's validated adapter and preserve the domain, type definitions, and all signed
values exactly. Keep large integers as exact decimal strings or losslessly parsed integers. Do not infer a primary type
from JSON key order or sign the raw API response.

Present the exact plain-message bytes or full decoded EIP-712 domain, primary type, and payload. Review the owner,
chain, verifying contract, authorizations, amounts, nonces, deadlines, and intended recipient of the signature where
applicable. Bind the browser account to `OWNER`. Only after approval, sign and verify the same payload:

```sh
SIGNATURE="$(cast wallet sign --data --from-file "$TYPED_DATA_JSON" --from "$OWNER" --browser)" || exit 1
cast wallet verify --address "$OWNER" --data --from-file "$TYPED_DATA_JSON" "$SIGNATURE" || exit 1
```

For plain messages, use `cast wallet sign "$MESSAGE" --from "$OWNER" --browser`, then
`cast wallet verify --address "$OWNER" "$MESSAGE" "$SIGNATURE"`. Do not use `--no-hash` for EIP-712 documents or
ordinary prefixed messages.

Message signing is a human-interaction wait: preserve the process until the wallet responds. `--async` applies to
broadcasts, not `wallet sign`. Treat sign or verify failure as blocking; never return or submit an unverified signature.
This local recovery check requires a signature recoverable to `OWNER`; it does not verify EIP-1271 contract-wallet
signatures. If that check cannot establish the reviewed signer, stop this flow.

Return the verified signature and signer address. Submit it elsewhere only when approval explicitly covers that
submission. For Permit2, the consuming workflow must bind the permit to its reviewed quote and state; a refreshed quote
or changed payload requires a new review and signature. Never silently reuse or modify a signed payload.

## Failure Handling

On a port conflict, missing browser, rejected wallet request, timeout, chain mismatch, or account mismatch, stop and
report the failure. Do not silently fall back to a private key or retry a broadcast. If the user selects another signer,
update the transaction review when the sender or command changes.

Classify each failure before retrying:

- `Wallet connection timeout` before `Wallet connected`, or `ChainSwitch rejected`: nothing was signed. Confirm the
  sender nonce is unchanged, then retry the same reviewed command.
- A signed request rejected by an RPC for another chain, such as `nonce too low` with a different chain ID or `minNonce`
  in the error: the wallet's network state is inconsistent. The printed hash was signed; look it up on the reviewed
  chain and confirm the nonce is unchanged. Ask the user to reset the `localhost:9545` site network in the wallet before
  retrying.
- Each command switches the wallet to its chain. Sending first on the already connected chain avoids a switch prompt.

# EIP-7702 Delegation Revocation

Use Cast's native authorization commands to clear delegation. Follow
[the EIP-7702 specification](https://eips.ethereum.org/EIPS/eip-7702) 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:

```sh
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](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.

| Route                                                             | When to use it                                                                                             | Signing boundary                                                                                                                                                      |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cast send --auth "$ZERO_DELEGATE"` with a supported local signer | Authority is also the transaction sender and no separately signed artifact is needed before final approval | Cast constructs the authorization with the selected chain and transaction nonce plus one, then signs and broadcasts the outer transaction. This is never preparation. |
| `cast wallet sign-auth`, then `cast send --auth "$SIGNED_AUTH"`   | Exact simulation needs a signature, the fee payer differs, or the outer transaction uses a browser         | Approve the authorization before creating it; submit the unchanged verified artifact only within its approved use and the transaction approval.                       |

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](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:

| Sender relationship | Outer transaction nonce          | Authorization nonce                                                   |
| ------------------- | -------------------------------- | --------------------------------------------------------------------- |
| Self-broadcast      | Authority's applicable nonce `N` | `N + 1`: the sender increment happens before authorization processing |
| Separate fee payer  | Payer's applicable nonce `P`     | Authority's applicable nonce `A`, without a self-broadcast increment  |

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](https://github.com/foundry-rs/foundry/blob/master/crates/cast/src/cmd/wallet/mod.rs) and
[transaction builder's `resolve_auth`](https://github.com/foundry-rs/foundry/blob/master/crates/cast/src/tx.rs).
`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`:

```sh
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:

```sh
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:

```sh
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](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](ethereum-gas.md) 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.

# Ethereum Slow Gas

This is the default policy for Ethereum mainnet transactions. The user or consuming skill may explicitly select another
policy under `SKILL.md`, including fixed legacy pricing for an exact-zero sweep. In that case, use and review the
selected policy instead of fetching or enforcing this fee pair. Do not treat an API failure as an implicit override.

Rabby's keyless gas-market endpoint supplies the same `slow`, `normal`, and `fast` tiers used by the wallet, including
separate EIP-1559 max-fee and priority-fee values. It is a public runtime API, not a documented third-party SLA; stop on
an outage or schema change instead of substituting another source.

## Fetch the Quote

Resolve `scripts/rabby-slow-gas.sh` relative to this skill and run it immediately before simulation and review:

```sh
RABBY_SLOW_QUOTE=$("$CLI_CAST_SKILL_DIR/scripts/rabby-slow-gas.sh")
RABBY_SLOW_MAX_FEE_WEI=$(printf '%s\n' "$RABBY_SLOW_QUOTE" | jq -er '.max_fee_per_gas_wei')
RABBY_SLOW_PRIORITY_FEE_WEI=$(printf '%s\n' "$RABBY_SLOW_QUOTE" | jq -er '.max_priority_fee_per_gas_wei')
RABBY_SLOW_ESTIMATED_SECONDS=$(printf '%s\n' "$RABBY_SLOW_QUOTE" | jq -er '.estimated_seconds')
RABBY_SLOW_QUOTED_AT=$(printf '%s\n' "$RABBY_SLOW_QUOTE" | jq -er '.quoted_at')
```

Set `CLI_CAST_SKILL_DIR` to the absolute directory containing this `SKILL.md`. The helper calls
`https://api.rabby.io/v2/wallet/gas_market`, selects exactly one `slow` entry, and rejects malformed, non-integer,
incoherent, or incorrectly ordered tiers. Do not reuse a quote for another transaction or a restarted review.

Ask `$evm-atlas` for one read packet containing the resolved Ethereum chain ID, latest block number and hash, and that
block's base fee. Require chain ID `1`, then bind the returned values locally:

```sh
test "$EVM_ATLAS_CHAIN_ID" = '1'
RABBY_SLOW_BLOCK="$EVM_ATLAS_BLOCK_NUMBER"
RABBY_SLOW_BASE_FEE_WEI="$EVM_ATLAS_BASE_FEE_WEI"
test "$RABBY_SLOW_MAX_FEE_WEI" -ge "$RABBY_SLOW_BASE_FEE_WEI"
```

If validation fails, fetch once more. Stop if the second result fails; do not fall back to `cast gas-price`,
`eth_gasPrice`, Normal, or Fast.

## Bind the Fees

When this policy is selected, pass both values to simulation where supported and to every transaction-building or
`cast send` command:

```sh
cast send "$CONTRACT" 'transfer(address,uint256)' "$TO" "$AMOUNT" \
  --rpc-url "$RPC_URL" \
  --gas-price "$RABBY_SLOW_MAX_FEE_WEI" \
  --priority-gas-price "$RABBY_SLOW_PRIORITY_FEE_WEI" \
  SIGNER_FLAGS
```

For EIP-1559 transactions, Cast interprets `--gas-price` as the max fee per gas and `--priority-gas-price` as the max
priority fee per gas. Start browser (`--browser`), encrypted-keystore, hardware-wallet, and environment-backed
private-key commands with the same fee pair. Use one reviewed signer suffix such as `--browser`,
`--keystore "$KEYSTORE_FILE"`, `--ledger`, or `--private-key "$ETH_PRIVATE_KEY"`; the signer preference and approval
rules in `SKILL.md` still apply. For browser signing, these flags are starting values: the user may deliberately edit
the gas limit or fee caps in the wallet confirmation UI, and the approved final wallet values govern the transaction. Do
not use `--legacy` for this policy.

For `cast publish`, inspect the signed transaction first and verify it already contains the approved fee pair; fees
cannot be changed after signing. The Rabby quote covers execution gas only, so a blob transaction still needs an
independently reviewed blob-gas price.

Immediately before broadcast, have `$evm-atlas` fetch the latest block and base fee again. If it exceeds the reviewed
max fee, the transaction is not currently includable: obtain a new Slow quote, simulate again, and present a revised
review. For replacements or cancellations, stop when Slow does not satisfy the required fee bump rather than silently
increasing the tier.

1.8.3

#!/bin/bash
set -euo pipefail

command -v curl >/dev/null 2>&1 || {
  echo 'rabby-slow-gas: curl is required' >&2
  exit 1
}
command -v jq >/dev/null 2>&1 || {
  echo 'rabby-slow-gas: jq is required' >&2
  exit 1
}

endpoint='https://api.rabby.io/v2/wallet/gas_market'
response=$(
  curl --fail --silent --show-error \
    --connect-timeout 5 \
    --max-time 10 \
    --retry 2 \
    --retry-delay 1 \
    --request POST \
    --header 'content-type: application/json' \
    --data '{"chain_id":"eth"}' \
    "$endpoint"
)
quoted_at_unix=$(date +%s)
quoted_at=$(date -u '+%Y-%m-%dT%H:%M:%SZ')

printf '%s\n' "$response" | jq -ce \
  --arg endpoint "$endpoint" \
  --arg quoted_at "$quoted_at" \
  --argjson quoted_at_unix "$quoted_at_unix" '
  def one_tier($name):
    [.[] | select(.level == $name)] as $matches
    | if ($matches | length) == 1 then $matches[0]
      else error("expected exactly one \($name) tier")
      end;
  def valid_tier:
    (.price | type) == "number"
    and (.price | floor) == .price
    and .price > 0
    and (.priority_price | type) == "number"
    and (.priority_price | floor) == .priority_price
    and .priority_price >= 0
    and .priority_price <= .price
    and (.estimated_seconds | type) == "number"
    and (.estimated_seconds | floor) == .estimated_seconds
    and .estimated_seconds >= 0;

  if type != "array" then error("expected a tier array") else . end
  | . as $tiers
  | ($tiers | one_tier("slow")) as $slow
  | ($tiers | one_tier("normal")) as $normal
  | ($tiers | one_tier("fast")) as $fast
  | if (($slow | valid_tier) and ($normal | valid_tier) and ($fast | valid_tier))
      and $slow.price <= $normal.price
      and $normal.price <= $fast.price
      and $slow.priority_price <= $normal.priority_price
      and $normal.priority_price <= $fast.priority_price
    then {
      endpoint: $endpoint,
      chain_id: 1,
      chain_server_id: "eth",
      tier: "slow",
      max_fee_per_gas_wei: ($slow.price | tostring),
      max_priority_fee_per_gas_wei: ($slow.priority_price | tostring),
      estimated_seconds: $slow.estimated_seconds,
      quoted_at_unix: $quoted_at_unix,
      quoted_at: $quoted_at
    }
    else error("invalid or incorrectly ordered gas tiers")
    end
  '