# Account Abstraction Security Model

Source: https://docs.settlemint.com/docs/compliance-security/security/account-abstraction-security
How DALP bounds the authority of the account abstraction execution layer:
sponsorship ticket constraints, signer key controls, account-management
safety rails, and the separation between execution and identity.




Account abstraction is an execution route, not a trust boundary. It changes how gas is paid and how transaction authority is represented, but it does not grant compliance status, alter asset policy, affect custody approval, or change who owns an identity. The authority of the AA layer is bounded at three specific surfaces: what a sponsorship signature covers, how signing keys are managed, and what account-management operations the smart account will accept.

Related pages:

* [Account Abstraction Design](/docs/architects/components/infrastructure/account-abstraction/account-abstraction-design)
* [Paymasters and Gas Sponsorship](/docs/architects/components/infrastructure/account-abstraction/paymasters-and-gas-sponsorship)
* [Why Account Abstraction](/docs/architects/concepts/account-abstraction)

## Sponsorship abuse and the ticket bound [#sponsorship-abuse-and-the-ticket-bound]

The most obvious risk in a paymaster is broad or replayable sponsorship: a single credential that authorises gas payment for any transaction on behalf of any party. DALP answers this with a SponsorshipTicket validated on-chain by the paymaster via an EIP-712 signature.

The ticket is not a per-UserOp blank check. It binds:

* the sender address,
* a hash of the call data,
* the organization identifier,
* a deadline, and
* a maximum gas cost.

A sponsorship signature is therefore valid only for a specific sender submitting a specific payload within a specific time window, at a capped cost. Replaying it against a different payload or sender fails on-chain validation. The scope is limited to one organization, so a ticket from one organization cannot be used to sponsor operations in another.

The paymaster signer key can be rotated through an operator API. Rotation is an explicit remediation control when a key is suspected to have been compromised.

<Mermaid
  chart="`flowchart TD
  UserOp[UserOperation submitted] --> PM[Paymaster validates ticket]
  PM --> SigCheck{EIP-712 sig valid?}
  SigCheck -->|no| Reject[Rejected on-chain]
  SigCheck -->|yes| FieldCheck{sender + callDataHash + orgId + deadline + maxGasCost match?}
  FieldCheck -->|no| Reject
  FieldCheck -->|yes| Execute[Execute with gas sponsorship]
`"
/>

## Key compromise and the multisig validator [#key-compromise-and-the-multisig-validator]

A single compromised signing key is the primary key-management threat in any AA account. DALP addresses this for multi-approver accounts through a weighted multisig validator, which is an ERC-7579 validator module.

The validator requires multiple signers to accumulate enough weight to meet a threshold before an operation proceeds. No single key below that threshold can authorize execution unilaterally.

A subtler risk is a signer using account-management functions to change the validator configuration and bypass the multisig entirely. The weighted multisig validator blocks this: it grants no account-management authority. A signer who can meet the threshold for ordinary operations still cannot use that authority to reconfigure the account's validator modules. Account management and transaction execution stay separate.

## Account-management safety rails [#account-management-safety-rails]

ERC-7579 modular accounts can hold multiple validator modules. DALP's smart account supports up to 16 validators. The account refuses to remove its last validator.

This prevents a class of account-lockout attack where an actor iteratively removes validators until no authorization path remains and the account becomes permanently inaccessible. The invariant is enforced by the account itself, not by an off-chain policy.

| Threat                                                   | Control                                                                           |
| -------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Replay a sponsorship signature for a different payload   | Ticket binds callDataHash; on-chain check fails                                   |
| Use a sponsorship signature after expiry                 | Ticket binds deadline; on-chain check fails                                       |
| Sponsor operations beyond a cost cap                     | Ticket binds maxGasCost                                                           |
| Compromise paymaster signer key                          | Key rotation via operator API                                                     |
| Single-signer takeover of multi-approver account         | Weighted multisig threshold; the validator grants no account-management authority |
| Remove all validators to lock out an account             | Account refuses last-validator removal                                            |
| Bypass executor gate with a direct contract write        | All writes route through the central transaction queue                            |
| Assume a sponsored transaction carries compliance status | AA is execution only; identity, eligibility, and asset policy are independent     |

## Separation of signing and execution [#separation-of-signing-and-execution]

For claims issuance, the issuer EOA signs the off-chain payload. The on-chain `addClaim` write then routes through the AA-aware transaction queue and may execute from the smart wallet.

This means the signing authority (the EOA that produced the credential) and the execution authority (the account that submits the transaction) are distinct. A compromise of the execution path does not give an attacker the ability to produce valid off-chain claim signatures. The two surfaces have separate key material and separate compromise scenarios.

More broadly, account abstraction is not a separate execution path. Every on-chain write routes through the one transaction queue, which resolves whether the executing account is an EOA or a smart wallet in a single place. A route handler cannot silently override that selection or submit a contract write that bypasses the queue.

## The setup boundary [#the-setup-boundary]

Account abstraction is activated only once an organization is fully provisioned. Organization setup, including smart wallet creation, bundler and paymaster configuration, role assignment, and identity metadata initialization, runs on the EOA path. The account abstraction setting is switched on as the final step.

This ordering prevents a scenario where the AA substrate is used to authorize the operations that create it, which would create a circular dependency and an undefined authorization state. The setup sequence is not reversible mid-flight through the AA path.

Invitations into an already AA-enabled organization route through AA from that point forward. Smart wallet creation for a new member is piggybacked with initialization data on the first UserOp-capable transaction, ordinarily identity creation.

This page covers the controls as they are implemented. Incident-response runbooks for paymaster key compromise, formal verification status of the validator module, and audit coverage are not covered here (unverified).