Bug Report: AA10 sender already constructed - Cannot reuse existing wallets with Account Abstraction

[julianosaless]

Description

When attempting to use an existing EOA (Externally Owned Account) that has previously interacted with the ACP protocol, the SDK throws an AA10 sender already constructed error during the AcpContractClient.build() process. This prevents legitimate users from reusing their wallets to create new jobs.

Environment

• Package: @virtuals-protocol/acp-node
• Version: Latest (as of November 2024)
• Network: Base Mainnet (Chain ID: 8453)
• Contract: 0x6a1FE26D54ab0d3E1e3168f2e0c0cDa5cC0A0A4A
• Node.js: v18+
• TypeScript: 5.x

Steps to Reproduce

1. Use a wallet that has previously created ACP jobs or interacted with ACP contracts
2. Attempt to build a new AcpContractClient with the same wallet:

import AcpClient, {
AcpContractClient,
baseAcpConfig
} from '@virtuals-protocol/acp-node';

const BUYER_PRIVATE_KEY = '0x...' as 0x${string};
const BUYER_WALLET = '0x...' as 0x${string};

const acpContractClient = await AcpContractClient.build(
BUYER_PRIVATE_KEY,
1, // Session key ID
BUYER_WALLET,
baseAcpConfig
);

const acpClient = new AcpClient({ acpContractClient });
await acpClient.init();

// Attempt to initiate a job
const jobId = await acpClient.initiateJob(
PROVIDER_ADDRESS,
JSON.stringify(requirement),
payment
);
3. The error occurs during the Account Abstraction user operation construction

Error Output

Status: 400
URL: https://alchemy-proxy-prod.virtuals.io/api/proxy/rpc

Details: {
"code": -32500,
"message": "validation reverted: [reason]: AA10 sender already constructed",
"data": {
"reason": "AA10 sender already constructed"
}
}

RequestError: HTTP request failed.
Status: 400
URL: https://alchemy-proxy-prod.virtuals.io/api/proxy/rpc
Request body: {
"method": "alchemy_requestGasAndPaymasterAndData",
"params": [{
"policyId": "186aaa4a-5f57-4156-83fb-e456365a8820",
"entryPoint": "0x0000000071727De22E5E9d8BAf0edAc6f37da032",
"userOperation": {
"factory": "0x00000000000017c61b5bEe81050EC8eFc9c6fecd",
"factoryData": "0x8b4e464e00000000000000000000000024254eb11549796403e22e23e3e13f44bbb9b28b0000000000000000000000000000000000000000000000000000000000000000",
"sender": "0x24254eb11549796403e22e23e3e13f44bbb9b28b",
"nonce": "0x1010000000000000000",
...
}
}]
}

Details: {
"code": -32500,
"message": "validation reverted: [reason]: AA10 sender already constructed",
"data": {
"reason": "AA10 sender already constructed"
}
} // Check if smart wallet exists
const code = await publicClient.getCode({ address: sender });
const isDeployed = code && code !== '0x';

const userOp = {
    sender,
    nonce: await getNonce(sender),
    callData,
    // Only include factory data if NOT deployed
    ...(isDeployed ? {} : {
        factory: FACTORY_ADDRESS,
        factoryData: encodeFactoryData(originalEOA)
    })
};

return userOp;

}

Workaround

Currently, the only workaround is to use a completely fresh wallet (one that has never interacted with ACP or deployed a smart wallet) for each test or interaction session. This is not sustainable for production use.

Impact

• Severity: HIGH
• Affected Users: Anyone attempting to create multiple jobs from the same wallet
• Production Impact: Prevents normal usage of the SDK for ongoing operations
• User Experience: Forces users to manage multiple wallets unnecessarily

Additional Context

This issue was discovered while building an ACP agent service that needs to repeatedly create jobs from a stable buyer wallet. The agent provider side works correctly, but the buyer/client side cannot reuse wallets after the first successful job creation.

Related Specifications

• ERC-4337: Account Abstraction
• AA10 Error Code: "sender already constructed"

Reproduction Repository

Available upon request - can provide a minimal reproduction case if needed.

---

Thank you for your attention to this issue! This is blocking production deployment of ACP-based services. Please let me know if you need any additional information or logs.

Expected Behavior
Users should be able to reuse their existing wallets to create multiple ACP jobs over time
The SDK should detect if a smart wallet already exists and skip deployment
Existing smart wallet addresses should be reused for subsequent transactions
Actual Behavior
The SDK attempts to deploy a new smart wallet factory even when one already exists
The transaction fails with AA10 sender already constructed
Users are forced to create brand new wallets for each interaction (or after the first interaction)
Root Cause Analysis
The error AA10 sender already constructed is an ERC-4337 EntryPoint validation error that occurs when:
The user operation includes factory and factoryData fields
BUT the smart wallet has already been deployed for this EOA
The SDK appears to always include factory deployment data in user operations, without checking if the smart wallet already exists on-chain.