Skip to content

feat: add validation gas overhead for Shhh wallets and SNIP-163 session accounts#69

Open
haycarlitos wants to merge 1 commit into
avnu-labs:mainfrom
haycarlitos:feat/shhh-snip163-overhead
Open

feat: add validation gas overhead for Shhh wallets and SNIP-163 session accounts#69
haycarlitos wants to merge 1 commit into
avnu-labs:mainfrom
haycarlitos:feat/shhh-snip163-overhead

Conversation

@haycarlitos

Copy link
Copy Markdown

Problem

starknet_estimateFee uses SKIP_VALIDATE, so accounts with expensive validation logic get underestimated gas limits. This is the same issue solved for Braavos MFA accounts in the existing braavos() overhead.

Three new account types need overhead support:

  1. Shhh Ed25519 wallet — uses Garaga v1.0.1 for on-chain Ed25519 signature verification (~33M L2 gas), enabling Solana (Phantom) users to operate Starknet smart accounts with their existing wallet.

  2. Shhh EVM wallet — uses native verify_eth_signature syscall for secp256k1 verification, enabling MetaMask/EVM users to operate Starknet smart accounts.

  3. SNIP-163 session accounts (Chipi Pay reference implementation) — session key validation involves dual-hash SNIP-12 computation, session data storage reads, entrypoint whitelist iteration, and call consumption writes. These add significant L2 gas beyond a standard OZ account.

Why this matters

Cross-chain wallet access: Shhh wallets let users from Solana and EVM ecosystems use Starknet without managing Starknet-native keys. All operations go through execute_from_outside_v2 (SNIP-9 V2), making paymaster gas estimation accuracy critical. Correct overhead values allow these wallets to work seamlessly with any dApp using the AVNU paymaster.

Agentic smart wallets: SNIP-163 (merged into starknet-io/SNIPs, PR #163) defines the session key standard for Starknet. Session keys enable scoped, time-bounded, call-limited delegation — the primitive for AI agents, automated yield strategies, and gaming bots operating on-chain. As session-based accounts grow, accurate gas estimation ensures reliable paymaster-sponsored execution.

Supporting these account types in the paymaster helps attract liquidity to Starknet by lowering the barrier for users already holding assets on Solana or EVM chains.

Detection

Following the existing Braavos pattern (entrypoint-based detection, cached per user address):

Account Type Detection Method Response
Shhh Ed25519 get_owner() Exactly 2 felts (u256 halves)
Shhh EVM get_eth_address() Exactly 1 felt (EthAddress)
SNIP-163 Sessions supports_interface(0x037ab…55d) 1 (true)
Braavos MFA get_signers() >4 felts (existing)

Detection order: Shhh Ed25519 → Shhh EVM → SNIP-163 → Braavos → none.

Gas overhead values

Account L2 Gas Overhead Source
Shhh Ed25519 ~80M (0x04c4b400) Garaga MSM+EdDSA ~33M + bytes_to_hex_ascii ~5M + OE encoding ~3M + Serde deserialization ~5M + byte comparison loop ~2M + storage ~2M
Shhh EVM ~20M (0x01312D00) keccak256 syscall ~5M + ecrecover ~8M + OE encoding ~3M + ByteArray loops ~2M + storage ~2M
SNIP-163 Sessions ~20M (0x01312D00) Dual SNIP-12 hash + 2x ECDSA + session reads + whitelist iteration + spending policy
Braavos MFA ~46.8M (0x02c7ab80) Existing

Values measured on mainnet. Only affects gas limits, not actual gas consumed or sponsored amount.

References

…on accounts

Add per-account-type gas overhead for three new account types that
have expensive validation logic not captured by SKIP_VALIDATE:

- Shhh Ed25519 wallet (~80M L2 gas): Garaga v1.0.1 on-chain EdDSA
  verification for Solana/Phantom users
- Shhh EVM wallet (~20M L2 gas): native secp256k1 verify_eth_signature
  for MetaMask/EVM users
- SNIP-163 session accounts (~20M L2 gas): dual-hash SNIP-12 + session
  key validation (Chipi Pay reference implementation)

Detection follows the existing Braavos pattern (entrypoint-based,
cached per user address). Only affects gas limits, not actual gas
consumed or sponsored amount.
@vercel

vercel Bot commented Apr 2, 2026

Copy link
Copy Markdown

@haycarlitos is attempting to deploy a commit to the 419labs Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant