Starknet
Starknet account abstraction gives smart accounts programmable call authorization
Updated -Starknet account abstraction places call authorization inside each account contract. For an account-originated INVOKE transaction, the sequencer runs __validate__ before __execute__. The account checks the supplied authorization against its implemented rules, then executes the requested calls if validation succeeds. Those rules can require a signature, multiple signers, or a restricted session, depending on the deployed account's code and configuration.
A wallet's approval screen presents a request; the account contract enforces the permissions onchain. That separation explains how approvals cover calls and how account policies affect execution. Recovery and fee sponsorship need their own supporting mechanisms.
Account validation controls access to execution
The sequencer passes an INVOKE transaction's calldata to the account's validation entry point. Successful validation allows execution to proceed with the same arguments. The account's Cairo execution code then dispatches the requested contract calls. Keeping these functions separate gives authorization an identifiable boundary before application logic runs.
A signer supplies evidence that the account can evaluate. The transaction's signature field carries that evidence in the format that the account expects. A basic implementation verifies a cryptographic signature against its configured public key. Other implementations can evaluate several signers or delegated permissions. Private keys remain part of many designs; programmability changes how their signatures establish authority.
Account developers must protect execution entry points against callers that could bypass validation. Any supported alternative entry point needs its own authorization checks. The native account model supplies the framework, while the deployed code determines whether those checks work correctly.
What information does the account check before execution?
The account checks the authorization data required by its code, using transaction information and its configured permissions. Understanding the call representation, signed transaction hash, and nonce explains which parts of a request the account can bind to an approval.
Call data identifies the requested action
The SNIP-6 account interface represents a call with a target contract address, function selector, and calldata. The selector identifies the function; calldata carries its encoded arguments. An account can inspect that call information when enforcing restrictions. The wallet must encode the request in the format that the account understands.
The transaction hash connects approval to context
Account and network identity
The standard INVOKE transaction hash includes the sender account, chain ID, calldata, and fee-related fields. An implementation that verifies signatures over this hash binds authorization to that transaction context. Changing a signed field changes the hash, so an existing signature no longer authorizes the altered transaction.
The nonce prevents transaction replay
A nonce identifies the transaction's place in the account's sequence. Starknet enforces sequential account nonces at the protocol level. Binding a signature to the transaction hash also binds it to that nonce, preventing reuse of an earlier transaction authorization once the account advances beyond it.
Validation has resource limits and cannot call functions in external contracts. These restrictions bound the sequencer's preliminary work and prevent an external storage change from invalidating requests across many accounts. Custom verification logic must fit those restrictions, even when the account supports a more elaborate approval policy.
Multisignature thresholds distribute approval authority
A multisignature account requires authorization from the signer group defined by its implementation. Its threshold specifies the required level of agreement. The account verifies the supplied signatures against its signer policy before allowing the requested calls. Different implementations can impose different signature formats, ordering rules, and counting requirements.
The threshold is an account setting, so Starknet account abstraction does not prescribe a universal approval count. Secure administration must also govern changes to signers, thresholds, and account code. Otherwise, permission to weaken the policy could defeat its protection. Coordination becomes harder as the account requires broader agreement, and unavailable signers can prevent the account from meeting its configured requirement.
Can one authorization cover multiple contract calls?
A compatible account can execute a list of contract calls within a single INVOKE transaction. Its validation logic evaluates the authorization for that request, and its execution logic processes the call list. A signature over the full transaction hash covers the encoded list. Batching combines approval and execution work, while the account's restrictions still govern the permitted calls. In a multicall implementation that propagates a failed inner call, that failure reverts the transaction's execution changes. Account-specific rules may also restrict which calls can share a batch.
A different threshold changes the same approval set
Consider a hypothetical multisignature account that requires exactly its stored threshold of distinct authorized signatures. The signer list, signatures, and transaction data stay fixed across alternative configurations; only the hypothetical threshold changes.
Let S denote the supplied signature count and T the required threshold. Assume every signature correctly authorizes the unchanged transaction and comes from a different permitted signer. With S equal to T, the signature set satisfies this account's threshold check. The code supplies the comparison rule; storage supplies the required count.
Compare that configuration with a valid threshold above S, within the unchanged signer group's size. The same signature set now fails validation, and the account does not execute its target calls. More signers must agree under the higher threshold. That increases coordination effort while reducing the authority of a smaller group.
Authorization failure differs from an execution revert
When an account-originated INVOKE fails
__validate__, execution does not begin, and the protocol does not charge a transaction fee. Execution can also fail after authorization succeeds because a target contract rejects the requested operation. That failure belongs to execution, even though the account correctly approved the request.
Starknet can include such an INVOKE transaction in a block with a reverted execution status and charge for work performed. Execution changes roll back, while protocol accounting still applies. A reverted INVOKE transaction still advances its sender account's nonce. A returned transaction hash identifies the request; its receipt supplies execution and finality information.
Sessions, recovery, and sponsorship require distinct permissions
Session-enabled accounts can delegate restricted signing authority, allowing applications to submit permitted requests without a fresh wallet prompt each time. The session implementation determines its scope. Restrictions can identify allowed contracts and functions, with expiry or other limits where the account supports them.
Delegation needs limits on administrative authority
A permission that covers an application function does not automatically authorize signer changes or account upgrades. The account must distinguish ordinary interactions from administrative operations. Session support also needs compatible wallet and application software. A sign-in method alone does not establish which calls the account permits or whether it supports delegation.
Recovery changes who can authorize future calls
Recovery-capable implementations can provide a separate authorized path for replacing lost signing credentials. Their code defines the recovery participants, conditions, and any waiting period. An account without a usable recovery path can remain inaccessible after its required credentials disappear. Key rotation and recovery therefore depend on implemented account functions and their existing permissions.
Outside execution separates signing from submission
SNIP-9 outside execution lets a compatible account execute signed instructions submitted through another account's transaction. Its authorization includes an optional caller restriction, an execution window, and separate replay protection. This mechanism can support fee sponsorship because the submitting account pays the network transaction fee. Paymaster services may sponsor eligible calls or accept supported payment tokens. Their availability and terms remain service-specific, and paying the fee does not grant control over the signed account. Invalid outside-execution authorization can make the submitter's transaction revert, incurring fees despite rejection of the signed instructions.
Starknet account abstraction: questions and answers
Do Starknet accounts need an ERC-4337 bundler to authorize transactions?
Native Starknet account transactions do not require an ERC-4337 bundler. The protocol invokes the account's validation and execution entry points as part of its transaction handling. ERC-4337 defines a separate smart-account mechanism with user operations and bundlers. An application may add submission services, but that integration does not turn a bundler into a prerequisite for native Starknet account authorization.
Why does an application ask for a signature without submitting a transaction?
An application can request a signed message to establish authorization without changing blockchain state. SNIP-6 includes is_valid_signature for checking a signature against a supplied message hash. The meaning of that approval comes from the message and the application that consumes it. A signed instruction can also authorize later execution, so signing without immediate submission does not make every request harmless.
Which entry point checks permission to declare a contract class?
The account's __validate_declare__ entry point checks authorization for a DECLARE transaction. Its input includes the class hash that identifies the declared code. An account needs this entry point to originate declarations, even if it already supports ordinary INVOKE transactions. Account deployment through DEPLOY_ACCOUNT uses a different validation entry point, __validate_deploy__, with its own transaction inputs.
Does a successful fee estimate prove that every required signature is present?
A successful fee estimate does not always establish complete account authorization. Fee estimation can use SKIP_VALIDATE, which omits the account's validation stage. Some account implementations also support estimation before they collect the complete multisignature approval set. The estimate describes resource costs under its simulation conditions; actual submission must satisfy the account's authorization requirements.
Will passkey authentication automatically enable account recovery?
Passkey authentication does not automatically install an account recovery mechanism. An implementation can support WebAuthn signatures for authentication while defining recovery separately. Access after losing a credential depends on the remaining usable credentials and any recovery path that the account implements. The sign-in screen alone does not establish who can replace a signer or which recovery conditions apply.
Are transaction signatures and call data confidential?
Account abstraction alone does not make transaction signatures or call data confidential. Starknet transaction interfaces expose those fields, so submitted requests can reveal the contracts and operations involved. A signature is authorization evidence, not the private signing key. Applications should keep secret credentials out of calldata and distinguish signature validation from mechanisms that actually provide confidentiality.
Can a signer change without changing the Starknet account address?
An account that supports key rotation can replace an authorized signer while keeping its contract address. The contract stores or otherwise defines its signer policy separately from the address of the deployed instance. The replacement must follow that implementation's authorization rules. Changing a wallet's local key alone does not update the permissions that the account contract enforces onchain.