Account Abstracted Instant Actions Frontend Builders

This section explains how and why we the ERC-4337 “account abstraction” style login is used for Instant Actions. It will cover:

• What ERC-4337 and EIP-1271 bring to the table • The end-to-end flow for Instant Login (fetching a nonce, building a SIWE message, hashing/signing, local EIP-1271 validation, HTTP call) • A complete TypeScript code snippet showing how to call /login and obtain an access token

Why ERC-4337 / Account Abstraction?

Traditional EOAs (Externally Owned Accounts) sign every transaction with their private key. Smart-contract wallets (Gnosis Safe, Argent, etc.) cannot expose a raw private key. ERC-4337 let’s a smart-contract wallet “personal_sign” arbitrary data off-chain, then verify that signature on-chain via the standard EIP-1271 isValidSignature(bytes32, bytes) call.

Benefits for Instant Actions: • Users grant a single “session” signature once. • Solvers can verify authorization on-chain or locally. • No need for the user to re-sign every open/close quote.

High-Level Login Flow

  1. Fetch a nonce from /nonce/{subAccount}

  2. Construct a SIWE message (domain, wallet address, statement, nonce, issuedAt, expiration)

  3. Apply EIP-191 prefix + keccak256 → “ERC-4337 hash”

  4. Ask the Safe to personal_sign the raw SIWE string (SigningMethod.ETH_SIGN)

  5. (Optional) Locally verify the signature via protocolKit.isValidSignature(erc4337Hash, sig)

  6. POST to /login with • account_addressissued_atexpiration_timenoncesignature (packed Safe signatures) • sign_type: “ERC4337”

The sign_type field is essential to obtain an access token with Rasa but not necessarily required for other solvers.

Server validates on-chain via EIP-1271 and returns an access token

Use that token as Authorization: Bearer <access_token> for all subsequent instant open/close calls.

Detailed Code Example (TypeScript)


When the server receives your POST body, the solver backend will:

• Reconstruct the same SIWE message (using your domain, URI, nonce, subaccount, etc.) • Re-compute the ERC-4337 hash (EIP-191 prefix + keccak256) • Call userSmartWallet.isValidSignature(hash, signature) on-chain – If it returns 0x1626ba7e, the signature is valid • If valid, mint you a JWT access_token with an expiry and your sub-account embedded

Using Your Access Token


Once you have access_token, attach it to every instant-action request:

Authorization: Bearer <access_token>

The solver will trust that token (no further on-chain checks) until it expires.

You can see how to attach this token to requests in the Building an Application with SYMMIO section.

Last updated