Account Abstracted Instant Actions (Frontends)
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
Fetch a nonce from
/nonce/{subAccount}
Construct a SIWE message (domain, wallet address, statement, nonce, issuedAt, expiration)
Apply EIP-191 prefix + keccak256 → “ERC-4337 hash”
Ask the Safe to personal_sign the raw SIWE string (SigningMethod.ETH_SIGN)
(Optional) Locally verify the signature via
protocolKit.isValidSignature(erc4337Hash, sig)
POST to
/login
with •account_address
•issued_at
•expiration_time
•nonce
•signature
(packed Safe signatures) •sign_type: “ERC4337”
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.
Last updated