ometere123/the-skills-bible/account-abstraction-engineer

Account Abstraction Engineer

Purpose

Design programmable accounts with validation, sponsorship, batching, session keys, delegation, modules, and recovery.

Use this skill when

• The work directly concerns account authority, operation format, or validation rules.
• Assets, protocol authority, chain state, keys, proofs, or distributed participants create material risk.
• A design, implementation, review, migration, or production decision needs reproducible evidence.
• Existing behaviour is under-specified, chain-specific, operationally fragile, or difficult to audit.

Do not use this skill as the primary workflow when

• A conventional trusted system fully satisfies the requirement with lower risk.
• The request seeks unauthorised exploitation, key theft, evasion, or disruption.
• The required protocol, chain, contract, or authority cannot be identified.
• A narrower implementation, security, testing, or operations skill is the actual task.

Required inputs

• Target networks, chain identifiers, protocol and software versions.
• Contracts, addresses, source, bytecode, schemas, storage, events, and transaction formats where applicable.
• Participants, signers, validators, administrators, relayers, users, and governance authority.
• Assets, balances, state transitions, finality, replay, and failure requirements.
• Keys, signatures, proofs, external dependencies, and trust assumptions.
• Fees, incentives, collateral, liquidity, rewards, penalties, and attack economics where applicable.
• Deployment, upgrade, migration, observability, incident, and recovery constraints.

Classify missing information as blocking, important, or optional. Inspect the real protocol specification, deployment, chain state, traces, governance records, and operational evidence before asking for information that can be verified directly.

Core operating principles

• State the trust, fault, and adversary model before making implementation claims.
• Keep canonical chain state distinct from mempool observations, indexes, caches, and off-chain records.
• Use deterministic state transitions, canonical encodings, domain separation, and replay protection.
• Treat privileged keys, upgrades, pauses, minting, validator changes, and treasury actions as explicit governance surfaces.
• Design for reorganisation, duplicate delivery, delayed finality, network partition, and uncertain transaction outcome.
• Model incentives, fees, liquidity, penalties, and attack economics alongside code correctness.
• Bound computation, storage growth, message size, retries, fan-out, and external dependencies.
• Make chain, contract, transaction, proof, signer, and governance versions observable.
• Preserve user exit, reconciliation, incident containment, and migration paths where feasible.
• Validate with adversarial tests, simulations, forks, formal reasoning where suitable, and independent review.

Workflow

1. Account Authority

• Define the exact scope, actors, authoritative data, assumptions, and invariants for account authority.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

2. Operation Format

• Define the exact scope, actors, authoritative data, assumptions, and invariants for operation format.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

3. Validation Rules

• Define the exact scope, actors, authoritative data, assumptions, and invariants for validation rules.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

4. Execution Semantics

• Define the exact scope, actors, authoritative data, assumptions, and invariants for execution semantics.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

5. Gas Sponsorship

• Define the exact scope, actors, authoritative data, assumptions, and invariants for gas sponsorship.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

6. Session Keys

• Define the exact scope, actors, authoritative data, assumptions, and invariants for session keys.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

7. Delegation

• Define the exact scope, actors, authoritative data, assumptions, and invariants for delegation.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

8. Recovery

• Define the exact scope, actors, authoritative data, assumptions, and invariants for recovery.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

9. Module Governance

• Define the exact scope, actors, authoritative data, assumptions, and invariants for module governance.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

10. Bundler And Relayer Assumptions

• Define the exact scope, actors, authoritative data, assumptions, and invariants for bundler and relayer assumptions.
• Inspect current implementation and evidence before proposing change.
• Specify normal, boundary, adversarial, degraded, and recovery behaviour.
• Record decisions in a form that can be independently tested and reproduced.

Decision rules

Required outputs

• Account Authority specification and evidence.
• Operation Format specification and evidence.
• Validation Rules specification and evidence.
• Execution Semantics specification and evidence.
• Gas Sponsorship specification and evidence.
• Session Keys specification and evidence.
• Delegation specification and evidence.
• Recovery specification and evidence.
• Module Governance specification and evidence.
• Bundler And Relayer Assumptions specification and evidence.

Blockchain and distributed-systems quality gates

• Trust gate: Trusted parties, cryptographic assumptions, consensus assumptions, and external dependencies are explicit.
• State gate: Authoritative state, transition rules, ordering, finality, and reorganisation behaviour are defined.
• Key gate: Key generation, custody, signing, rotation, recovery, revocation, and compromise response are controlled.
• Economic gate: Fees, rewards, penalties, collateral, liquidity, and attack costs are modelled.
• Contract gate: Interfaces, events, storage, permissions, and upgrade assumptions are versioned and tested.
• Interoperability gate: Chain identifiers, proof formats, message uniqueness, domains, and replay boundaries are enforced.
• Security gate: Privilege abuse, reentrancy, oracle manipulation, bridge compromise, denial of service, and governance capture are tested.
• Finality gate: Inclusion, confirmations, protocol finality, and economic settlement are distinguished.
• Operations gate: Nodes, validators, relayers, indexers, signers, alerts, incident response, and recovery are ready.
• Governance gate: Upgrade, pause, treasury, parameter, and emergency authority are transparent and bounded.

Evidence standard

Identify the exact network, chain ID, block hash, transaction hash, contract address, bytecode or source version, state root, proof, signer, validator set, governance proposal, and observation time relevant to the conclusion. Distinguish mempool observation, inclusion, confirmation, protocol finality, economic finality, and off-chain settlement.

Failure handling and escalation

Pause or escalate when chain identity or authority is uncertain; a transaction or cross-chain message may have executed but cannot be reconciled; keys or privileged roles may be compromised; consensus, oracle, bridge, accounting, or governance integrity is doubtful; or testing could move real assets or disrupt a public network. Preserve evidence before changing keys, contracts, routes, or node state.

Common anti-patterns

• Treating account authority as implicit or universally understood.
• Calling a system trustless while relying on undisclosed operators, signers, providers, or governance.
• Using an explorer, indexer, or event stream as the sole source of canonical state.
• Assuming transaction submission, inclusion, confirmation, and finality are the same outcome.
• Granting broad upgrade or emergency authority without delay, transparency, and recovery controls.
• Testing only honest participants and normal network conditions.
• Ignoring token, callback, fee, decimal, chain-ID, or signature edge cases.
• Changing protocol behaviour without versioned compatibility and migration evidence.

Completion checklist

• [ ] Trust and authority assumptions are explicit.
• [ ] Canonical state and derived state are separated.
• [ ] Critical invariants and failure behaviour are testable.
• [ ] Keys, permissions, replay boundaries, and chain identity are controlled.
• [ ] Economic and operational risks are documented.
• [ ] Upgrade, incident, recovery, and retirement paths exist.
• [ ] Representative adversarial validation has passed.
• [ ] Residual risk has an accountable owner.

Protocol implementation record

# Protocol Implementation Record
 
## Outcome
[Protocol, contract, wallet, bridge, market, or governance outcome]
 
## Trust and authority
[Validators, signers, administrators, relayers, users, and assumptions]
 
## State and finality
[State, transitions, ordering, confirmations, finality, reorgs, and recovery]
 
## Cryptography and keys
[Algorithms, domains, custody, signing, rotation, and proofs]
 
## Economics
[Fees, rewards, penalties, collateral, liquidity, and attack costs]
 
## Interfaces
[Transactions, calls, events, messages, proofs, versions, and compatibility]
 
## Validation
[Tests, simulations, forks, formal properties, audits, and residual gaps]
 
## Operations
[Nodes, validators, relayers, indexers, monitoring, incidents, and migration]

Related skills

• wallet-key-management-engineer
• transaction-lifecycle-engineer
• smart-contract-security-engineer

Maintenance rules