solidity-account
Generate an ERC-4337 compliant account contract with customizable signature validation, token support, and upgradeability options. Returns source code in a Markdown code block.
Instructions
Make an account contract that follows the ERC-4337 standard.
Returns the source code of the generated contract, formatted in a Markdown code block. Does not write to disk.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the account contract | |
| signatureValidation | No | Whether to implement the ERC-1271 standard for validating signatures. This is useful for the account to verify signatures. | |
| ERC721Holder | No | Whether to implement the `onERC721Received` function to allow the account to receive ERC721 tokens. | |
| ERC1155Holder | No | Whether to implement the `onERC1155Received` function to allow the account to receive ERC1155 tokens. | |
| signer | No | Defines the signature verification algorithm used by the account to verify user operations. Options: - ECDSA: Standard Ethereum signature validation using secp256k1, validates signatures against a specified owner address - EIP7702: Special ECDSA validation using account's own address as signer, enables EOAs to delegate execution rights - Multisig: ERC-7913 multisignature requiring minimum number of signatures from authorized signers - MultisigWeighted: ERC-7913 weighted multisignature where signers have different voting weights - P256: NIST P-256 curve (secp256r1) validation for integration with Passkeys and HSMs - RSA: RSA PKCS#1 v1.5 signature validation (RFC8017) for PKI systems and HSMs - WebAuthn: Web Authentication (WebAuthn) assertion validation for integration with Passkeys and HSMs on top of P256 | |
| batchedExecution | No | Whether to implement a minimal batching interface for the account to allow multiple operations to be executed in a single transaction following the ERC-7821 standard. | |
| ERC7579Modules | No | Whether to implement the ERC-7579 compatibility to enable functionality on the account with modules. | |
| info | No | Metadata about the contract and author | |
| upgradeable | No | Whether the smart contract is upgradeable. Transparent uses more complex proxy with higher overhead, requires less changes in your contract. Can also be used with beacons. UUPS uses simpler proxy with less overhead, requires including extra code in your contract. Allows flexibility for authorizing upgrades. |