# Advanced accounts security

Source: https://docs.settlemint.com/docs/compliance-security/security/advanced-accounts-security
How DALP bounds the authority of the advanced accounts 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 the platform represents transaction signing authority, but it does not grant compliance status, alter asset policy, affect custody approval, or change who owns an identity. Three surfaces bound what the AA layer can do: what a sponsorship signature covers, how signing keys are managed, and what account-management operations the smart account accepts. If you are evaluating security boundaries, start with these three controls. Related pages: [Advanced accounts design](/docs/architects/components/infrastructure/advanced-accounts/advanced-accounts-design), [Paymasters and Gas Sponsorship](/docs/architects/components/infrastructure/advanced-accounts/paymasters-and-gas-sponsorship), and [Advanced accounts concept](/docs/architecture/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 the paymaster validates on-chain 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 valid only for a specific sender submitting a given payload within a fixed time window, at a capped cost. Replaying it against a different payload or sender fails the on-chain check. Each ticket covers one organization, so a ticket from one organization cannot sponsor operations in another.

You rotate the paymaster signer key through the operator API. Use key rotation as the remediation step when a key may be 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 threat in any AA account. If you use multi-approver accounts, DALP addresses this through a weighted multisig validator, an ERC-7579 validator module.

Multiple signers must accumulate enough weight to meet a threshold before any operation proceeds. No single key below that threshold can authorize execution on its own.

A subtler risk is a signer using account-management functions to change the validator setup and bypass the multisig entirely. The weighted multisig validator blocks this: it carries no account-management authority. A signer who can meet the threshold for ordinary operations still cannot use that position to reconfigure the account's validator modules. Account configuration 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 and refuses to remove its last one.

This blocks a lockout attack where an actor strips validators one by one until no valid signing path remains and the account becomes permanently inaccessible. The account itself enforces this invariant, not 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]

When issuing claims, 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.

The EOA that produced the credential and the account that submits the transaction are distinct. Compromising the execution path does not let an attacker produce valid off-chain claim signatures. The two surfaces carry separate key material and face separate compromise scenarios.

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

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

The platform enables account abstraction only after an organization is fully provisioned. Setup runs on the EOA path and covers smart wallet creation, bundler and paymaster configuration, role assignment, and identity metadata initialization. Only after all of that does the platform switch on the advanced accounts setting.

This ordering prevents a circular dependency: the AA substrate cannot authorize the operations that create it. If you attempt to reverse the setup sequence mid-flight through the AA path, the platform blocks the request with an undefined authorization state.

Invitations into an already AA-enabled organization route through AA from that point forward. The platform bundles smart wallet creation for a new member with initialization data on the first UserOp-capable transaction. That transaction is ordinarily identity creation. The bundling ensures no intermediate state where a member has a session but no wallet or identity, which would leave authorization checks in an indeterminate state.

This page covers the controls as currently implemented. If you are reviewing incident response, formal verification of the validator module, or audit coverage, those topics are outside this page's scope.