MultiTokenPaymaster EPv07#98
Conversation
- Changes `bytes calldata signature` to `bytes memory signature` in return. - Updated bytes data slicing as seems to be `encodePacked` rather than `encode` so accounted for packing. - Added simple Foundry test to check with previously failing bytes data being passed into function. Looks like the correct data is now being decoded and returned. Command to run test at top of file as hitting Yul stack error when trying without `--optimize`.
WalkthroughThis pull request updates build artifact details and compiler configurations by replacing outdated buildInfo references and bytecode strings. It adds new multi-token paymaster functionality through several smart contracts (BasePaymaster, IOracleAggregator, MultiTokenPaymaster, TokenPaymasterErrors) and an accompanying deployment script. Additionally, it refines the etherspot‑wallet contracts by modifying constructors to accept explicit owners, includes a new SafeTransferLib library for safe token transfers, adds a Foundry test for the MultiTokenPaymaster, and updates numerous TypeScript factory and interface files with improved formatting (switching to double quotes) and expanded constructor types—all without altering public APIs. Changes
Sequence Diagram(s)sequenceDiagram
participant D as Deployer
participant MTP as MultiTokenPaymaster
participant EP as EntryPoint
D->>MTP: Deploy contract (with owner, entry point, verifying signer)
MTP-->>D: Return contract address
D->>MTP: Call addStake and deposit functions
MTP->>EP: Update stake/deposit balance
EP-->>MTP: Confirm update
sequenceDiagram
participant U as User
participant MTP as MultiTokenPaymaster
participant OA as OracleAggregator
participant EP as EntryPoint
U->>MTP: Submit user operation
MTP->>OA: Retrieve token exchange rate
MTP->>EP: Validate operation & calculate required pre-fund
EP-->>MTP: Return validation result
MTP-->>U: Operation approved or rejected
Poem
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (18)
config/compilers.ts (1)
28-28: Added IR-based compilation for newer Solidity versionsThe addition of
"viaIR": trueto the compiler settings for Solidity versions 0.8.21 and 0.8.23 enables the newer intermediate representation compilation pipeline, which can generate more optimized bytecode and reduce gas costs.This change aligns well with the EPv07 support objective, as the IR-based pipeline can produce more efficient code. Note that while this optimization is beneficial for gas costs, it's appropriately applied only to newer Solidity versions where the IR pipeline is more stable.
Also applies to: 39-39
typings/factories/src/modular-etherspot-wallet/interfaces/IERC20SessionKeyValidator__factory.ts (1)
5-7: Standardized string literal formattingThe change from single quotes to double quotes for string literals throughout the file is a consistent style improvement that aligns with modern TypeScript coding conventions.
This is an auto-generated file, so these formatting changes likely came from updating the generator configuration rather than manual edits. The consistent use of double quotes improves readability and follows common TypeScript style guides.
Also applies to: 10-10, 16-19, 21-22, 27-30, 32-33, 39-41, 43-44, 51-54, 56-57, 64-67, 69-70, 77-80, 84-86, 96-99, 102-105, 107-108, 115-118, 121-124, 126-127, 134-137, 140-143, 145-146, 151-154, 156-157, 158-160, 164-167, 169-170, 171-173, 177-182, 184-186, 195-196, 199-202, 205-213, 215-233, 235-237, 239-252, 254-256, 258-271, 273-275, 278-290, 292-294, 298-311, 313-314, 316-319, 321-323, 327-330, 332-333, 334-336, 340-343, 345-346, 347-349, 353-356, 358-361, 363-364, 365-367, 371-374, 376-377, 378-380, 384-387, 391-394, 396-399, 401-404, 406-409, 411-414, 416-419, 421-424, 426-429, 431-434, 436-437, 438-439, 441-442, 444-447, 449-451, 457-460, 462-465, 467-470, 472-475, 477-480, 482-485, 487-490, 492-495, 497-500, 502-503, 504-505, 507-510, 512-513, 515-518, 520-522
typings/src/etherspot-wallet-v1/helpers/SafeTransferLib.ts (2)
15-17: Auto-Generated Empty Object Types in Interface DeclarationsThe interface properties (e.g.
functions: {}on line 15 andevents: {}on line 17) are defined using an empty object type ({}). Although this triggers static analysis warnings, note that this file is autogenerated. If you later decide to improve type-safety, please update the code generator to emit an explicit empty object shape (e.g. using explicit interfaces or record types) instead of{}.🧰 Tools
🪛 Biome (1.9.4)
[error] 15-15: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 17-17: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
46-54: Empty Object Types in Contract MethodsSimilar empty object types are used for contract methods (e.g. on lines 46, 48, 50, 52, 54). Since the file is autogenerated — and these members act as placeholders until actual implementations (if any) are provided — these patterns are acceptable for now. However, if you plan to manually adjust this in the future, consider defining precise types.
🧰 Tools
🪛 Biome (1.9.4)
[error] 46-46: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 48-48: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 50-50: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 52-52: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 54-54: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
typings/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors.ts (2)
15-18: Auto-Generated Empty Object Types in Error InterfaceThe
TokenPaymasterErrorsInterfacedeclares itsfunctionsandeventsas empty object types (lines 15 and 17). As with the previous file, while this triggers static analysis warnings, it is caused by the autogenerated template. If a more explicit type is needed in the future, consider updating the generator.🧰 Tools
🪛 Biome (1.9.4)
[error] 15-15: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 17-17: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
46-54: Empty Object Types for Contract Interaction MethodsEmpty object types are also used for
functions,callStatic,filters,estimateGas, andpopulateTransaction(lines 46, 48, 50, 52, 54). Given that this file is generated code designed as a stub, these patterns are acceptable. If future functionality is added here, adding explicit types would improve clarity.🧰 Tools
🪛 Biome (1.9.4)
[error] 46-46: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 48-48: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 50-50: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 52-52: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 54-54: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
typings/factories/src/etherspot-wallet-v1/paymaster/IOracleAggregator__factory.ts (1)
1-45: LGTM! This factory class correctly implements the IOracleAggregator interface.The factory provides the essential methods to interact with the IOracleAggregator contract, which is responsible for retrieving token exchange rates relative to native tokens. This is a critical component for the EPv07 MultiTokenPaymaster implementation.
The static analysis tool suggests avoiding classes with only static members. While this is an auto-generated file, if you have control over the generator, consider implementing a functional approach instead:
-export class IOracleAggregator__factory { - static readonly abi = _abi; - static createInterface(): IOracleAggregatorInterface { - return new utils.Interface(_abi) as IOracleAggregatorInterface; - } - static connect( - address: string, - signerOrProvider: Signer | Provider - ): IOracleAggregator { - return new Contract(address, _abi, signerOrProvider) as IOracleAggregator; - } -} +export const IOracleAggregator = { + abi: _abi, + createInterface(): IOracleAggregatorInterface { + return new utils.Interface(_abi) as IOracleAggregatorInterface; + }, + connect( + address: string, + signerOrProvider: Signer | Provider + ): IOracleAggregator { + return new Contract(address, _abi, signerOrProvider) as IOracleAggregator; + } +};🧰 Tools
🪛 Biome (1.9.4)
[error] 34-45: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
deploy/015_deploy_multi_token_paymaster.ts (1)
1-96: Verify deployment parameters and improve error handling.• The stake (0.001 ETH) and deposit (0.01 ETH) values are hardcoded. Confirm that these amounts are sufficient and appropriate for your production or test environment.
• Consider adding checks or try/catch equivalents to detect and handle potential failures (e.g., insufficient balance) when callingexecute(...)foraddStakeanddeposit.src/etherspot-wallet-v1/helpers/SafeTransferLib.sol (1)
29-37: Unused gas stipend constants.
_GAS_STIPEND_NO_STORAGE_WRITESand_GAS_STIPEND_NO_GRIEFare declared but never used. If they are not intended for future usage, consider removing them to reduce clutter.- uint256 internal constant _GAS_STIPEND_NO_STORAGE_WRITES = 2300; - uint256 internal constant _GAS_STIPEND_NO_GRIEF = 100000;src/MultiTokenPaymaster/BasePaymaster.sol (1)
95-113: Consider enabling deposit functionality or removing commented-out code.
The deposit and withdrawal methods are commented out. Decide if these will be implemented later or remove them to reduce clutter.src/MultiTokenPaymaster/TokenPaymasterErrors.sol (2)
16-16: Correct spelling in documentation comment.
“verifiying” is misspelled. Change to “verifying” for clarity.- * @notice Throws when the verifiying signer address provided is address(0) + * @notice Throws when the verifying signer address provided is address(0)
42-42: Minor spelling error in commented documentation.
Typo “length oif the” should be “length of the.” While it is commented out, consider fixing for potential future use.- * @param sigLength length oif the signature provided + * @param sigLength length of the signature providedtypings/factories/src/etherspot-wallet-v1/helpers/SafeTransferLib__factory.ts (1)
1-3: Remove or replace TSLint directive if using ESLint.
The/* tslint:disable */directive is outdated if the project relies on ESLint. Consider removing or replacing it with the relevant ESLint directive.typings/src/etherspot-wallet-v1/paymaster/IOracleAggregator.ts (2)
42-42: Replace '{}' with a more explicit type.Using
{}as a type can inadvertently allow any non-nullable value. Prefer an explicit shape, such asRecord<string, never>, to satisfy the lint rule and enhance clarity.- events: {}; + events: Record<string, never>;🧰 Tools
🪛 Biome (1.9.4)
[error] 42-42: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
90-90: Replace '{}' with a more explicit type.Similar to the
eventsfield, using{}forfilterscan be confusing. Opt forRecord<string, never>or another explicit type to avoid type-safety issues.- filters: {}; + filters: Record<string, never>;🧰 Tools
🪛 Biome (1.9.4)
[error] 90-90: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
src/MultiTokenPaymaster/MultiTokenPaymaster.sol (3)
8-8: Remove duplicate ECDSA import.Line 4 and line 8 both import
ECDSAfrom@openzeppelin/contracts/utils/cryptography/ECDSA.sol. Retaining one import should suffice and reduce potential inconsistencies.-import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
64-65: Remove or clarify commented code.Commented-out definitions for
PAYMASTER_VALIDATION_GAS_OFFSETandPAYMASTER_DATA_OFFSETcan cause confusion. Either remove or annotate them to clarify their intended future use.
119-122: Initialize feeReceiver with a meaningful default.Currently,
feeReceiveris explicitly set toaddress(), which is the zero address. Calls tosetFeeReceivercan correct this later, but starting with a valid default (e.g.,_owner) avoids potential misuse or accidental omission.- sstore(feeReceiver.slot, address()) + sstore(feeReceiver.slot, _owner)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (95)
artifacts/@openzeppelin/contracts/access/Ownable.sol/Ownable.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/interfaces/draft-IERC1822.sol/IERC1822Proxiable.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/proxy/beacon/IBeacon.sol/IBeacon.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/proxy/utils/Initializable.sol/Initializable.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol/UUPSUpgradeable.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/Address.sol/Address.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/Address.sol/Address.json(1 hunks)artifacts/@openzeppelin/contracts/utils/Context.sol/Context.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/StorageSlot.sol/StorageSlot.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/StorageSlot.sol/StorageSlot.json(1 hunks)artifacts/@openzeppelin/contracts/utils/Strings.sol/Strings.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/Strings.sol/Strings.json(1 hunks)artifacts/@openzeppelin/contracts/utils/cryptography/ECDSA.sol/ECDSA.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/cryptography/ECDSA.sol/ECDSA.json(1 hunks)artifacts/@openzeppelin/contracts/utils/math/Math.sol/Math.dbg.json(1 hunks)artifacts/@openzeppelin/contracts/utils/math/Math.sol/Math.json(1 hunks)config/compilers.ts(2 hunks)deploy/015_deploy_multi_token_paymaster.ts(1 hunks)src/MultiTokenPaymaster/BasePaymaster.sol(1 hunks)src/MultiTokenPaymaster/IOracleAggregator.sol(1 hunks)src/MultiTokenPaymaster/MultiTokenPaymaster.sol(1 hunks)src/MultiTokenPaymaster/TokenPaymasterErrors.sol(1 hunks)src/etherspot-wallet-v1/helpers/SafeTransferLib.sol(1 hunks)src/etherspot-wallet-v1/paymaster/BasePaymaster.sol(1 hunks)src/etherspot-wallet-v1/paymaster/EtherspotPaymaster.sol(1 hunks)test/foundry/paymaster/MultiTokenPaymaster.t.sol(1 hunks)typings/@openzeppelin/contracts/interfaces/index.ts(1 hunks)typings/factories/@openzeppelin/contracts/interfaces/index.ts(1 hunks)typings/factories/@openzeppelin/contracts/proxy/ERC1967/ERC1967Utils__factory.ts(1 hunks)typings/factories/@openzeppelin/contracts/utils/Address__factory.ts(1 hunks)typings/factories/@openzeppelin/contracts/utils/Strings__factory.ts(1 hunks)typings/factories/@openzeppelin/contracts/utils/cryptography/ECDSA__factory.ts(1 hunks)typings/factories/@openzeppelin/contracts/utils/math/Math__factory.ts(1 hunks)typings/factories/account-abstraction/contracts/core/EntryPointSimulations__factory.ts(1 hunks)typings/factories/account-abstraction/contracts/core/EntryPoint__factory.ts(1 hunks)typings/factories/account-abstraction/contracts/core/SenderCreator__factory.ts(1 hunks)typings/factories/account-abstraction/contracts/core/UserOperationLib__factory.ts(1 hunks)typings/factories/ds-test/test.sol/DSTest__factory.ts(1 hunks)typings/factories/forge-std/StdError.sol/StdError__factory.ts(1 hunks)typings/factories/forge-std/StdStorage.sol/StdStorageSafe__factory.ts(1 hunks)typings/factories/solady/src/utils/ECDSA__factory.ts(1 hunks)typings/factories/solady/src/utils/LibClone__factory.ts(1 hunks)typings/factories/src/access/index.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/helpers/SafeTransferLib__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/helpers/UniversalSignatureValidator.sol/UniversalSigValidator__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/helpers/UniversalSignatureValidator.sol/ValidateSigOffchain__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/helpers/index.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/EtherspotPaymaster__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/IOracleAggregator__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/VerifyingPaymaster__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/Whitelist__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/paymaster/index.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/wallet/EtherspotWalletFactory__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/wallet/EtherspotWallet__factory.ts(1 hunks)typings/factories/src/etherspot-wallet-v1/wallet/Proxy__factory.ts(1 hunks)typings/factories/src/helpers/UniversalSignatureValidator.sol/index.ts(1 hunks)typings/factories/src/helpers/index.ts(1 hunks)typings/factories/src/interfaces/index.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/access/AccessController__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/core/AccountBase__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/core/ExecutionHelper__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/libs/SentinelList.sol/SentinelListLib__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/Bootstrap.t.sol/BootstrapUtil__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockDelegateTarget__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockExecutor__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockFallbackHandler.sol/MockFallback__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockTarget__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockValidator__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/utils/Bootstrap__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/interfaces/IERC20SessionKeyValidator__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/libraries/ErrorsLib__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/modules/hooks/ModuleIsolationHook__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/modules/validators/ERC20SessionKeyValidator__factory.ts(3 hunks)typings/factories/src/modular-etherspot-wallet/modules/validators/MultipleOwnerECDSAValidator__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/test/TestERC20__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/test/TestUSDC__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/wallet/FactoryStaker__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/wallet/ModularEtherspotWalletFactory__factory.ts(1 hunks)typings/factories/src/modular-etherspot-wallet/wallet/ModularEtherspotWallet__factory.ts(1 hunks)typings/factories/src/paymaster/index.ts(1 hunks)typings/factories/src/wallet/index.ts(1 hunks)typings/hardhat.d.ts(1 hunks)typings/index.ts(1 hunks)typings/src/access/index.ts(1 hunks)typings/src/etherspot-wallet-v1/helpers/SafeTransferLib.ts(1 hunks)typings/src/etherspot-wallet-v1/helpers/index.ts(1 hunks)typings/src/etherspot-wallet-v1/paymaster/IOracleAggregator.ts(1 hunks)typings/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster.ts(1 hunks)typings/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors.ts(1 hunks)typings/src/etherspot-wallet-v1/paymaster/index.ts(1 hunks)typings/src/helpers/UniversalSignatureValidator.sol/index.ts(1 hunks)typings/src/helpers/index.ts(1 hunks)typings/src/interfaces/index.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (9)
typings/src/etherspot-wallet-v1/helpers/SafeTransferLib.ts (1)
typings/common.ts (4)
TypedEvent(7-12)TypedEventFilter(14-15)TypedListener(17-19)OnEvent(23-29)
typings/factories/src/etherspot-wallet-v1/paymaster/IOracleAggregator__factory.ts (1)
typings/src/etherspot-wallet-v1/paymaster/IOracleAggregator.ts (1)
IOracleAggregatorInterface(23-43)
deploy/015_deploy_multi_token_paymaster.ts (1)
typings/factories/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster__factory.ts (1)
deploy(922-934)
typings/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster.ts (1)
typings/common.ts (5)
PromiseOrValue(46-46)TypedEvent(7-12)TypedEventFilter(14-15)TypedListener(17-19)OnEvent(23-29)
typings/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors.ts (1)
typings/common.ts (4)
TypedEvent(7-12)TypedEventFilter(14-15)TypedListener(17-19)OnEvent(23-29)
typings/factories/src/etherspot-wallet-v1/helpers/SafeTransferLib__factory.ts (2)
typings/common.ts (1)
PromiseOrValue(46-46)typings/src/etherspot-wallet-v1/helpers/SafeTransferLib.ts (1)
SafeTransferLibInterface(14-18)
typings/src/etherspot-wallet-v1/paymaster/IOracleAggregator.ts (1)
typings/common.ts (5)
PromiseOrValue(46-46)TypedEvent(7-12)TypedEventFilter(14-15)TypedListener(17-19)OnEvent(23-29)
typings/factories/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster__factory.ts (2)
typings/common.ts (1)
PromiseOrValue(46-46)typings/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster.ts (1)
MultiTokenPaymasterInterface(65-338)
typings/factories/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors__factory.ts (2)
typings/common.ts (1)
PromiseOrValue(46-46)typings/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors.ts (1)
TokenPaymasterErrorsInterface(14-18)
🪛 Biome (1.9.4)
typings/src/etherspot-wallet-v1/helpers/SafeTransferLib.ts
[error] 15-15: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 17-17: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 46-46: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 48-48: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 50-50: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 52-52: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 54-54: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
typings/factories/src/etherspot-wallet-v1/paymaster/IOracleAggregator__factory.ts
[error] 34-45: Avoid classes that contain only static members.
Prefer using simple functions instead of classes with only static members.
(lint/complexity/noStaticOnlyClass)
typings/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors.ts
[error] 15-15: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 17-17: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 46-46: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 48-48: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 50-50: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 52-52: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 54-54: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
typings/src/etherspot-wallet-v1/paymaster/IOracleAggregator.ts
[error] 42-42: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
[error] 90-90: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
🔇 Additional comments (118)
typings/factories/src/helpers/index.ts (1)
1-4: Autogenerated File VerificationThis autogenerated file is straightforward. It correctly disables both TSLint and ESLint, and the export statement on line 4 properly re-exports the contents from
./UniversalSignatureValidator.solunder the namespaceuniversalSignatureValidatorSol.typings/src/helpers/UniversalSignatureValidator.sol/index.ts (1)
1-5: UniversalSignatureValidator Types ExportThis autogenerated file is correctly set up to export the types
UniversalSigValidator(line 4) andValidateSigOffchain(line 5). The disable directives for TSLint and ESLint ensure that any formatting or lint issues in autogenerated code are safely ignored.typings/src/helpers/index.ts (1)
1-5: Aggregated Helpers ExportThis file serves as an aggregator for helper types. The import on line 4 and the subsequent export on line 5 correctly expose the
universalSignatureValidatorSolnamespace, allowing for better modular usage in the codebase. As with the other files, the linter disable directives are appropriately added.typings/factories/src/modular-etherspot-wallet/wallet/FactoryStaker__factory.ts (6)
4-10: Consistent Import Quotation Updates
The import statements have been updated to use double quotes consistently (including for type imports). This improves code consistency across the file without affecting functionality.
15-23: ABI Constructor Definition Formatting
In the first ABI object (the constructor), the fields for "internalType", "name", and "type" are now using double quotes. Additionally, the "stateMutability" and "type" values have been updated. These changes standardize the string literals and ensure consistency in the ABI.
24-48: Standardizing ABI Error Definitions
The error objects (e.g. "AlreadyInitialized", "FactoryStaker_InvalidEPAddress", "NewOwnerIsZeroAddress", "NoHandoverRequest", and "Unauthorized") have been updated so that all string literals (for properties such as "name" and "type") now use double quotes. This update is purely stylistic and enhances consistency across error definitions without altering any behavior.
49-93: ABI Event Definitions Consistency
For the events ("OwnershipHandoverCanceled", "OwnershipHandoverRequested", and "OwnershipTransferred"), all updated lines—including internal type annotations, event names, and type fields—are now using double quotes. This consistent formatting improves readability and maintains a uniform style within the ABI section.
94-221: Uniform Formatting for ABI Function Descriptions
All ABI function entries—from "addStake" through "withdrawStake"—have been updated to use double quotes in their properties (such as "internalType", "name", "type", and "stateMutability"). This ensures that the ABI for all functions is formatted uniformly. There are no changes in functionality; the updates are solely for consistency and clarity.
224-226: Bytecode String Literal Standardization
The bytecode constant has been reformatted to use double quotes. This change aligns with the rest of the file’s style guidelines regarding string literals and does not affect the underlying bytecode.typings/@openzeppelin/contracts/interfaces/index.ts (1)
8-8: Verified new interface export for IERC1271This change exports the ERC1271 interface - which is the standard for contract signature validation (EIP-1271). This is a necessary addition for EPv07 support since signature validation is a core component of account abstraction paymasters.
typings/src/etherspot-wallet-v1/helpers/index.ts (1)
6-6: Appropriate export addition for SafeTransferLibAdding SafeTransferLib export makes this utility available throughout the codebase. This is a good addition as it provides safe methods for token transfers, which are essential for the MultiTokenPaymaster's ERC20 handling capabilities.
typings/factories/solady/src/utils/ECDSA__factory.ts (1)
17-18: Verified bytecode update for Solady ECDSAThe bytecode update for the ECDSA library aligns with EPv07 support. The bytecode change reflects either compiler version updates or changes in the underlying implementation. This update is necessary for maintaining compatibility with the EPv07 standard.
typings/factories/src/modular-etherspot-wallet/libraries/ErrorsLib__factory.ts (1)
85-86: Verified bytecode update for ErrorsLibThe bytecode update for ErrorsLib appears to be part of the broader update to support EPv07. This is consistent with the pattern of bytecode updates across multiple factory files in this pull request.
typings/factories/src/etherspot-wallet-v1/helpers/UniversalSignatureValidator.sol/ValidateSigOffchain__factory.ts (1)
43-44: Updated contract bytecode for EPv07 compatibilityThe bytecode for the
ValidateSigOffchaincontract has been updated, likely as a result of recompilation with the new compiler settings or to accommodate changes for EPv07 support.This is an auto-generated file, and the bytecode update is consistent with the compiler configuration changes seen elsewhere in this PR. The updated bytecode likely contains optimizations or necessary changes to support the EPv07 functionality.
typings/index.ts (2)
4-17: Standardized import string formattingThe change from single quotes to double quotes for import statements improves consistency with modern TypeScript conventions.
This formatting standardization enhances code readability and maintains consistent style throughout the codebase.
18-219: Standardized export paths and added ERC1271 supportThe PR standardizes string literal formatting across all export statements and adds support for the ERC1271 interface, which is essential for smart contract signature validation.
The addition of ERC1271 is particularly relevant for EPv07 support, as it enables smart contract wallets to implement custom signature validation logic. This interface is critical for wallet implementations that need to validate signatures according to their own rules rather than using standard ECDSA verification.
typings/src/interfaces/index.ts (1)
1-10: LGTM! Well-structured auto-generated exports fileThis new file properly exports type definitions for various interfaces with a clear organization pattern, which makes them easily accessible throughout the application. The autogenerated nature of the file is appropriately indicated.
typings/factories/forge-std/StdStorage.sol/StdStorageSafe__factory.ts (1)
65-66: Bytecode update looks appropriateThe bytecode has been updated, which is expected when contracts are recompiled with a different compiler version, optimization settings, or when the source contract has been modified. Since this is an auto-generated file and only the bytecode has changed (not the ABI), this appears to be a standard compiler output update.
typings/factories/src/modular-etherspot-wallet/modules/validators/MultipleOwnerECDSAValidator__factory.ts (2)
4-222: Standardized string literals - good practiceThe changes in this file are purely stylistic, converting all string literals from single quotes to double quotes. This style standardization improves consistency across the codebase and aligns with JSON formatting standards.
222-223: Updated bytecode reflects recompilationThe bytecode has been updated, which is expected when a contract is recompiled. This update ensures the contract implementation matches the latest source code and compiler settings.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/utils/Bootstrap__factory.ts (2)
4-410: Consistent formatting with double quotesThe changes in this file follow the same pattern of standardizing string literals to use double quotes consistently. This maintains a uniform style convention throughout the codebase.
410-411: Bytecode updated appropriatelyThe bytecode has been updated to reflect the latest compilation output. This is standard practice when upgrading compiler versions or modifying contract source code.
typings/factories/src/etherspot-wallet-v1/paymaster/Whitelist__factory.ts (2)
167-168: Bytecode updated to new versionThe bytecode for the Whitelist contract has been updated, which indicates a recompilation of the contract. This is consistent with the PR's objective to add support for EPv07.
170-172: Constructor parameters enhanced for more flexibilityThe
WhitelistConstructorParamstype has been expanded to includeConstructorParameters<typeof ContractFactory>, which provides greater flexibility when instantiating the contract factory.typings/factories/ds-test/test.sol/DSTest__factory.ts (2)
306-307: Bytecode updated to new versionThe bytecode for the DSTest contract has been updated to a new version, likely reflecting recompilation with newer compiler settings or changes to the underlying contract.
309-311: Constructor parameters enhanced for more flexibilityThe
DSTestConstructorParamstype has been expanded to includeConstructorParameters<typeof ContractFactory>, which provides greater flexibility when instantiating the contract factory.typings/factories/src/modular-etherspot-wallet/modules/validators/ERC20SessionKeyValidator__factory.ts (2)
44-65: Improved error handling with more specific error typesThe PR replaces the likely previous single error
ERC20SKV_InvalidDurationwith two more specific errors:
ERC20SKV_InvalidValidAfterfor when a session key has an invalid start timeERC20SKV_InvalidValidUntilfor when a session key has an invalid end timeAdditionally, the input type has been optimized from
uint256touint48, which is more than sufficient for timestamp values while being more gas-efficient.
708-708: Bytecode updated to new versionThe bytecode for the ERC20SessionKeyValidator contract has been updated to reflect the changes in the contract implementation, particularly the new error handling and function state mutability modifications.
typings/factories/@openzeppelin/contracts/interfaces/index.ts (1)
6-6: Added export for IERC1271 interface factoryThe addition of the IERC1271__factory export is a good enhancement that provides access to the EIP-1271 signature validation interface. This interface is crucial for contracts that need to validate signatures, which is likely related to the paymaster functionality being implemented in this PR.
This change suggests integration with contracts that implement EIP-1271 for signature validation, which is important for account abstraction and smart contract wallet interactions.
typings/src/access/index.ts (1)
1-4: Auto-Generated File Check:
The file is correctly auto-generated and includes directives to disable both tslint and eslint as intended. The export statement forAccessControlleris precise.artifacts/@openzeppelin/contracts/utils/Address.sol/Address.dbg.json (1)
1-5: Build Info Update Verification:
The updated"buildInfo"key, now referencing"../../../../build-info/e2fd7f5465972619d4e3fc035ba9cf15.json", is in line with coordinated changes across similar artifacts. Please confirm that the new build info file exists and is correctly integrated into the build process.artifacts/@openzeppelin/contracts/utils/math/Math.sol/Math.dbg.json (1)
1-5: Consistent Build Info Update:
The update to the"buildInfo"field (now pointing to"../../../../../build-info/e2fd7f5465972619d4e3fc035ba9cf15.json") is consistent with similar modifications in the repository. Ensure that the new build information is valid and available.artifacts/@openzeppelin/contracts/access/Ownable.sol/Ownable.dbg.json (1)
1-5: Build Info Consistency Check:
The"buildInfo"update (referencing"../../../../build-info/e2fd7f5465972619d4e3fc035ba9cf15.json") aligns with the changes made in other artifact files. It is recommended to verify that the referenced build info file is accessible and correctly generated.typings/factories/@openzeppelin/contracts/utils/math/Math__factory.ts (1)
20-22: Bytecode Update Verification:
The_bytecodeconstant has been updated as part of the coordinated build changes. Please ensure that this new bytecode correctly reflects the deployed contract's bytecode. Additionally, verify that any dependent toolchains or factory usage still behave as expected.typings/factories/@openzeppelin/contracts/utils/Strings__factory.ts (1)
31-32: Bytecode updated to match current compiler outputThe bytecode has been updated, which is expected when recompiling contracts with new compiler versions or configurations. This change should not affect the contract's functionality.
artifacts/@openzeppelin/contracts/utils/StorageSlot.sol/StorageSlot.dbg.json (1)
2-3: Build reference correctly updatedThe buildInfo reference has been updated to point to a new build artifact. This is consistent with similar changes across multiple debug files in this PR and is a normal part of the rebuild process.
typings/factories/src/access/index.ts (1)
1-4: Appropriate factory export for AccessControllerThis new index file properly exports the AccessController factory, following the project's pattern for TypeScript factory organization.
typings/factories/src/etherspot-wallet-v1/helpers/index.ts (1)
5-5: SafeTransferLib factory correctly exposedAdding the export for SafeTransferLib__factory is appropriate as it makes the new factory class available to the rest of the codebase.
artifacts/@openzeppelin/contracts/proxy/utils/Initializable.sol/Initializable.dbg.json (1)
3-3: Build artifact update for Initializable contractThe buildInfo reference has been updated to point to a new build information file. This is a normal part of the rebuild process and doesn't affect functionality.
typings/factories/solady/src/utils/LibClone__factory.ts (1)
31-31: Updated bytecode for LibClone contractThe bytecode has been updated as part of the EPv07 support changes. The bytecode is correctly formatted with the Solidity 0.8.17 marker at the end. This change is consistent with the other build artifact updates in this PR.
artifacts/@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol/UUPSUpgradeable.dbg.json (1)
3-3: Build artifact update for UUPSUpgradeable contractThe buildInfo reference has been updated to point to a new build information file. This change is consistent with other debug JSON files in this PR and represents a standard rebuild artifact update.
artifacts/@openzeppelin/contracts/utils/cryptography/ECDSA.sol/ECDSA.dbg.json (1)
3-3: Build artifact update for ECDSA contractThe buildInfo reference has been updated to point to a new build information file. This is part of the consistent update pattern across all OpenZeppelin contract debug files in this PR.
artifacts/@openzeppelin/contracts/utils/Context.sol/Context.dbg.json (1)
3-3: Build artifact reference updated.The buildInfo path has been updated to point to a new build information file. This is an expected change during recompilation and doesn't impact functionality.
artifacts/@openzeppelin/contracts/interfaces/draft-IERC1822.sol/IERC1822Proxiable.dbg.json (1)
3-3: Build artifact reference updated.The buildInfo path has been updated to point to a new build information file. This is consistent with the other artifact updates in this PR.
artifacts/@openzeppelin/contracts/utils/Strings.sol/Strings.dbg.json (1)
3-3: Build artifact reference updated.The buildInfo path has been updated to point to a new build information file. This is consistent with the other artifact updates and is expected when the project is recompiled.
typings/src/etherspot-wallet-v1/paymaster/index.ts (1)
6-8: Added new contract type exports for EPv07 support.These new type exports align with the PR objective of adding EPv07 support to the MultiTokenPaymaster component. The additions include interface types for the Oracle Aggregator, MultiToken Paymaster, and Token Paymaster Errors, which will ensure proper type checking when working with these components.
typings/factories/@openzeppelin/contracts/proxy/ERC1967/ERC1967Utils__factory.ts (1)
99-99: Bytecode change appears consistent with compiler update or contract modificationsThe bytecode update is likely related to the EPv07 support mentioned in the PR objectives. Since this is an autogenerated file, this change is expected after recompilation.
artifacts/@openzeppelin/contracts/proxy/beacon/IBeacon.sol/IBeacon.dbg.json (1)
3-3: Build reference update is expectedThe change to the build information path is consistent with a recompilation of the contracts, which is expected when updating to support EPv07.
typings/factories/account-abstraction/contracts/core/UserOperationLib__factory.ts (1)
55-55: Account abstraction bytecode update for EPv07 supportThe bytecode change for UserOperationLib is expected as part of the EPv07 support implementation in the MultiTokenPaymaster, as mentioned in the PR objectives.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/libs/SentinelList.sol/SentinelListLib__factory.ts (1)
48-48: SentinelListLib bytecode update looks goodThe bytecode update is consistent with other changes in this PR, reflecting updated compiler settings or contract implementation changes to support EPv07.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockExecutor__factory.ts (1)
200-201: Bytecode update appears consistent with EPv07 supportThe bytecode for the MockExecutor contract has been updated, which aligns with the PR's objective of adding EPv07 support. This auto-generated file reflects changes in the underlying contract implementation.
artifacts/@openzeppelin/contracts/utils/math/Math.sol/Math.json (1)
12-13: Bytecode updates appear valid for dependency contractThe bytecode and deployedBytecode have been updated for this OpenZeppelin contract. This change is consistent with the PR's objective of updating build artifacts for EPv07 support. The Solidity compiler version (0.8.17) remains unchanged.
typings/factories/forge-std/StdError.sol/StdError__factory.ts (1)
132-133: Testing dependency bytecode update looks consistentThe bytecode for the StdError testing dependency has been updated. This is in line with the other bytecode updates in this PR and maintains consistency across the testing framework for EPv07 support.
artifacts/@openzeppelin/contracts/utils/Strings.sol/Strings.json (1)
23-24: Standard library bytecode updates are in syncThe bytecode and deployedBytecode updates for the Strings utility contract from OpenZeppelin are consistent with the other dependencies updated in this PR. These changes help ensure compatibility with the EPv07 implementation.
artifacts/@openzeppelin/contracts/utils/cryptography/ECDSA.sol/ECDSA.json (1)
34-35: Bytecode update reflects recompilationThe bytecode and deployedBytecode have been updated, which is expected when upgrading dependencies or recompiling with new settings. The bytecode signature indicates compilation with Solidity 0.8.23 (indicated by the
64736f6c63430008170033suffix).typings/factories/@openzeppelin/contracts/utils/cryptography/ECDSA__factory.ts (1)
43-43: Bytecode update in factory fileThis change updates the bytecode string to match the new compiled version in the artifact file. This is an expected modification in autogenerated files when contracts are recompiled.
typings/factories/src/etherspot-wallet-v1/wallet/EtherspotWalletFactory__factory.ts (1)
210-210: Bytecode update for EtherspotWalletFactoryThe bytecode update in this autogenerated factory file reflects recompilation of the EtherspotWalletFactory contract, likely with updated dependencies or compiler settings for EPv07 support.
src/MultiTokenPaymaster/IOracleAggregator.sol (1)
1-8: New interface for token exchange rate oracleThis interface is well-defined and follows best practices:
- Clear naming that indicates its purpose as an oracle aggregator
- Single responsibility pattern with just one function
- External visibility is appropriate for an interface
- Return parameter is named for better code readability
This interface will be essential for the MultiTokenPaymaster to determine token-to-native currency exchange rates.
typings/factories/src/helpers/UniversalSignatureValidator.sol/index.ts (1)
1-6: Exports look correctThis file properly exports the factory classes for universal signature validator contracts.
typings/factories/account-abstraction/contracts/core/EntryPoint__factory.ts (2)
1009-1010: Bytecode updated for EntryPoint contractThe bytecode for the EntryPoint contract has been updated, likely reflecting changes to support EPv07 as mentioned in the PR description.
1012-1014: Constructor params properly definedThe EntryPointConstructorParams type correctly includes a union with ConstructorParameters to allow for flexibility in constructor arguments.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockDelegateTarget__factory.ts (1)
33-34: Bytecode updated for MockDelegateTarget contractThe bytecode has been updated, likely as part of a broader update related to adding EPv07 support.
typings/factories/src/modular-etherspot-wallet/access/AccessController__factory.ts (1)
469-470: Bytecode updated for AccessController contractThe bytecode has been updated, likely as part of a broader update related to adding EPv07 support.
artifacts/@openzeppelin/contracts/utils/Address.sol/Address.json (1)
34-35: Bytecode update for Address contract appears consistentThe bytecode and deployedBytecode fields have been updated, likely due to recompilation with a different compiler version or settings. This is expected as part of supporting the new EPv07 feature mentioned in the PR objectives.
typings/factories/@openzeppelin/contracts/utils/Address__factory.ts (1)
42-43: Bytecode constant updated correctly to match artifactThe
_bytecodeconstant has been updated to match the corresponding bytecode in the Address.json artifact file, ensuring consistency between the TypeScript factory and the compiled contract.typings/factories/src/etherspot-wallet-v1/wallet/EtherspotWallet__factory.ts (1)
980-981: Bytecode update for EtherspotWallet contractThe
_bytecodeconstant has been updated as part of the broader changes to support EPv07. This is consistent with the bytecode updates seen in other files and is necessary for the proper functioning of the updated contracts.typings/factories/account-abstraction/contracts/core/EntryPointSimulations__factory.ts (1)
1326-1326: Bytecode updated for EntryPointSimulations contractThe bytecode for the EntryPointSimulations contract has been updated, likely to support EPv07 (EntryPoint version 0.7) as mentioned in the PR objectives. This update ensures that any new deployments of this contract will use the latest implementation.
typings/factories/src/etherspot-wallet-v1/wallet/Proxy__factory.ts (1)
31-31: Bytecode updated for Proxy contractThe bytecode for the Proxy contract has been updated, which is part of the broader update to support EPv07. The interface remains unchanged, maintaining backward compatibility while implementing the necessary internal changes.
typings/factories/src/etherspot-wallet-v1/helpers/UniversalSignatureValidator.sol/UniversalSigValidator__factory.ts (1)
130-130: Bytecode updated for UniversalSigValidator contractThe bytecode for the UniversalSigValidator contract has been updated, likely optimized or modified to work with the new EPv07 standard. The signature validation functionality remains unchanged based on the preserved ABI.
typings/factories/src/wallet/index.ts (1)
1-6: New index file added for wallet factoriesThis new index file exports the wallet-related factory classes, improving the module's organization and making imports more straightforward for consumers of this library. This is a good practice that simplifies the import statements needed to access these factories.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/core/ExecutionHelper__factory.ts (1)
39-40: Bytecode update for ExecutionHelper contractThe bytecode for the ExecutionHelper contract has been updated, likely reflecting changes in the contract implementation to support EntryPoint v0.7 (EPv07) as mentioned in the PR.
typings/factories/src/etherspot-wallet-v1/paymaster/index.ts (1)
6-8: New MultiTokenPaymaster related factories exportedThe new exports add support for the MultiTokenPaymaster functionality mentioned in the PR. The three new factories provide access to:
IOracleAggregator: Likely for handling token price conversionsMultiTokenPaymaster: Main implementation for the multi-token paymasterTokenPaymasterErrors: Custom error definitions for the paymasterThese exports properly make the new factory classes available throughout the codebase.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/core/AccountBase__factory.ts (1)
33-34: Bytecode update for AccountBase contractThe bytecode for the AccountBase contract has been updated, likely reflecting changes in the implementation to support EntryPoint v0.7 (EPv07) as mentioned in the PR.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockTarget__factory.ts (1)
47-48: Bytecode update for MockTarget test contractThe bytecode for the MockTarget contract has been updated to maintain compatibility with the other contract changes for EPv07 support. Good practice to ensure test mocks are updated alongside implementation contracts.
src/etherspot-wallet-v1/paymaster/EtherspotPaymaster.sol (1)
35-35:Details
❓ Verification inconclusive
Verify constructor compatibility across all concrete implementations
The constructor change in BasePaymaster has been correctly propagated to EtherspotPaymaster. However, ensure all other concrete paymaster implementations that extend BasePaymaster are updated with the new constructor signature.
🏁 Script executed:
#!/bin/bash # Find all contracts that extend BasePaymaster to verify they've been updated echo "Checking for all paymasters extending BasePaymaster:" rg -A 3 "contract \w+ is BasePaymaster" --type solLength of output: 195
Review Update: Verify Constructor Compatibility Across All Paymaster Implementations
The constructor change inBasePaymasterappears correctly propagated inEtherspotPaymaster.sol. However, please ensure that every concrete paymaster contract (i.e. any Solidity file declaring a contract that extendsBasePaymaster) uses the updated constructor signature. The above script is intended to help gather this information across the codebase. Once you’ve run this script, manually verify that no outdated implementations remain.
🏁 Script executed:
#!/bin/bash # Re-run the search command with an explicit Solidity file filter to verify # that all paymaster contracts extending BasePaymaster have the updated constructor signature. echo "Searching for contracts extending BasePaymaster in Solidity files:" rg -g "*.sol" -A 3 "contract \w+ is BasePaymaster"Length of output: 1511
Action: Verify Constructor Consistency Across All Paymasters
The constructor in
EtherspotPaymaster.solhas been updated as expected:constructor(IEntryPoint _entryPoint) BasePaymaster(msg.sender, _entryPoint) {}However, our search revealed that there are additional contracts extending
BasePaymaster:
- src/etherspot-wallet-v1/paymaster/VerifyingPaymaster.sol
- src/MultiTokenPaymaster/MultiTokenPaymaster.sol
Please ensure that the constructors in these contracts are updated to match the new signature in
BasePaymaster. Manual verification is required to confirm that they correctly propagate the constructor change.typings/factories/src/interfaces/index.ts (1)
1-9: LGTM! New TypeScript factory exports for interfacesThis auto-generated file correctly exports all the necessary factory interfaces for contract interactions.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockValidator__factory.ts (1)
212-217: Bytecode update and constructor type enhancementThe bytecode update reflects changes to the contract implementation, and the constructor type enhancement provides more flexibility for factory initialization. These changes align with the broader pattern of factory standardization in the codebase.
typings/factories/src/modular-etherspot-wallet/test/TestUSDC__factory.ts (1)
346-348: Updated Bytecode for TestUSDC FactoryThe
_bytecodeconstant (line 346) has been updated with a new bytecode string. Please confirm that this new bytecode correctly reflects the latest compiled version of the TestUSDC contract. If your continuous integration already tests against the Sepolia deployment, ensure that this update remains compatible with existing deployments.typings/factories/src/modular-etherspot-wallet/wallet/ModularEtherspotWallet__factory.ts (3)
4-11: Consistent String Literal FormattingThe changes (e.g. in lines 4 and 10) standardize string literals to use double quotes rather than single quotes. This improves consistency with the rest of the codebase. No functional changes are introduced.
12-43: ABI Definition FormattingThe ABI entries (lines 12–43) now have names and internal types formatted with double quotes. This formatting update does not affect functionality but improves readability and consistency.
44-55: Factory Class Structure UnchangedThe remaining factory class code (lines 44–55) shows no functional changes aside from formatting; the conversion to double quotes is stylistic. The class continues to correctly expose deploy, transaction, attach, and connect methods.
typings/factories/src/modular-etherspot-wallet/wallet/ModularEtherspotWalletFactory__factory.ts (4)
4-11: Standardized Imports with Double QuotesThe import statements (e.g. lines 4–6) now use double quotes. This change enhances consistency and complies with the project’s string formatting conventions.
12-33: ABI Definitions Use Double QuotesThe ABI definitions (lines 12–33) now represent types and names using double quotes. There is no change in functionality, only a stylistic improvement that increases consistency with the rest of the project.
334-340: Updated Bytecode in Wallet FactoryThe
_bytecodeconstant (line 334) has been refreshed. Please verify that this bytecode update is intended and that it corresponds to the latest build for the ModularEtherspotWalletFactory contract.
344-394: Factory Class Implementation ConsistencyThe
ModularEtherspotWalletFactory__factoryclass implementation (lines 344–394) remains structurally the same as before, with changes only to formatting and string literals. All override methods (deploy, getDeployTransaction, attach, and connect) continue to work as expected.typings/factories/src/modular-etherspot-wallet/test/TestERC20__factory.ts (2)
346-347: Bytecode updated with new implementation.The bytecode has been updated, likely due to changes in the contract implementation or compiler optimizations.
349-351: Enhanced constructor parameter type.The constructor parameter type has been updated to include
ConstructorParameters<typeof ContractFactory>, which improves the flexibility of the factory by allowing more constructor parameter options.typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/Bootstrap.t.sol/BootstrapUtil__factory.ts (3)
4-10: String literal formatting standardized to double quotes.Import statements and type references now consistently use double quotes for string literals.
12-126: ABI definition updated to use double quotes consistently.All string literals in the ABI definition now use double quotes instead of single quotes, improving consistency throughout the codebase.
128-129: Bytecode string uses double quotes for consistency.The bytecode string now uses double quotes, maintaining the same standardized string formatting applied throughout the file.
typings/factories/src/modular-etherspot-wallet/erc7579-ref-impl/test/mocks/MockFallbackHandler.sol/MockFallback__factory.ts (2)
198-199: Bytecode updated with new implementation.The bytecode has been updated, likely reflecting changes in the contract implementation or compiler optimizations for the MockFallback contract.
201-203: Enhanced constructor parameter type.The constructor parameter type has been updated to include
ConstructorParameters<typeof ContractFactory>, which improves the flexibility of the factory by allowing more constructor parameter options.artifacts/@openzeppelin/contracts/utils/StorageSlot.sol/StorageSlot.json (1)
6-7: Confirm updated bytecode correctness.The new
bytecodeanddeployedBytecodeindicate a build or compiler update. Please ensure that these artifact changes are intended and fully tested, especially if dependency versions or compiler settings changed.typings/factories/src/modular-etherspot-wallet/modules/hooks/ModuleIsolationHook__factory.ts (1)
4-206: Validate bytecode alignment and confirm style consistency.Most changes are quote style updates from single to double quotes; the updated
_bytecodealso suggests a compiler or build update. This file looks good overall, but ensure the newly generated bytecode has been tested against the deployed contract to avoid mismatches.typings/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster.ts (1)
1-1195: Interface definitions appear valid.This newly introduced TypeChain interface for the
MultiTokenPaymastercontract looks consistent with the contract’s methods and events. No issues found.typings/factories/account-abstraction/contracts/core/SenderCreator__factory.ts (1)
35-35:Details
❓ Verification inconclusive
Confirm the updated bytecode correctness.
The new
_bytecodemay reflect recent contract changes. Please verify that it precisely matches the contract’s compiled artifact from your current build process.Below is a quick script to confirm the generated bytecode matches your latest compile output:
🏁 Script executed:
#!/bin/bash # Compile the SenderCreator contract and compare the generated bytecode # with the one in this factory file. # 1. Compile the contract (assumes Hardhat or Foundry is available). # If you use Hardhat, run: # npx hardhat compile # If you use Foundry, run: # forge build # 2. Locate the compiled artifact and display its bytecode. # This snippet shows an example Hardhat location; adjust as needed: fd "SenderCreator.json" | xargs cat | jq '.bytecode' # 3. Compare with line 35 of SenderCreator__factory.ts # Confirm they match in hex content.Length of output: 50
Manual Verification Required: Confirm Bytecode Consistency
The updated bytecode intypings/factories/account-abstraction/contracts/core/SenderCreator__factory.ts(line 35) should precisely match the compiled output of theSenderCreatorcontract (e.g., from Hardhat or Foundry). The verification script executed earlier did not produce any output, so please perform a manual check by:
- Locating the
SenderCreator.jsonartifact from your build.- Retrieving the
.bytecodevalue using a tool likejqor another JSON parser.- Comparing this value against the hex string at line 35 in the factory file.
If any discrepancies are observed, verify that your compilation process is up to date and that the correct contract version is being built.
test/foundry/paymaster/MultiTokenPaymaster.t.sol (4)
1-8: Licensing, pragma, and imports look good.No issues spotted. These lines are consistent with common Foundry patterns.
10-13: Definition of the test contract and state variables.Declaring
mtpandentrypointat the contract level is standard for Foundry. This design is straightforward and readable.
14-20: Test constants and initial test data.The chosen addresses and sample
paymasterAndDataseem appropriate for demonstration. Ensure any reference addresses and keys are purely for testing (no private keys in use).
22-28: Test setup logic.Deployment in
setUp()is aligned with Foundry’s best practices. Logging the length ofpaymasterAndDatais useful for debugging.src/etherspot-wallet-v1/helpers/SafeTransferLib.sol (7)
8-24: Custom errors for ERC20/ETH operations.These custom errors provide clear failure outcomes for transfers. They help keep transaction revert reasons direct and give better debugging feedback.
42-81:safeTransferFrom: Low-level call usage.Inline assembly logic is optimized for gas but adds complexity. Ensure tokens strictly adhere to ERC-20 standards or at least do not revert for non-standard return values. The revert condition looks robust, properly reverting on non-
1return or no return data.
83-137:safeTransferAllFrom: Single-call retrieval and transfer.This function fetches the full balance, then transfers in one go. Make sure
fromand the contract are authorized for that entire balance. Otherwise, it will revert.
139-166:safeTransfer: Transfer from the contract to a specified address.The revert checks handle both the "1" return and zero-length returns. This is consistent with the fallback approach for tokens that do not return a boolean. Good coverage.
168-214:safeTransferAll: Transfer the entire token balance.Similar to
safeTransferAllFrom, it retrieves the contract’s balance viabalanceOfand attempts a single transfer. The logic follows the same robust revert checks.
216-243:safeApprove: Setting token allowances.As with the other operations, the function uses assembly to minimize gas. The revert condition is consistent, ensuring a "1" or zero return data is recognized as success.
245-266:balanceOf: Querying the token balance.This inline assembly approach is straightforward. It gracefully returns zero in case of tokens that do not implement a standard return or revert on calls. This design choice can help when dealing with non-compliant tokens.
src/MultiTokenPaymaster/BasePaymaster.sol (2)
1-3: Add brief rationale for GPL-3.0 usage and specify compiler version consistency.
The license and pragma statements are correct for an open-source contract. However, consider providing a short explanation in your repository documentation (e.g., README) for choosing GPL-3.0 over more permissive licenses.
24-28: Ensure that double ownership assignment is intended.
By callingOwnable(_owner)in the constructor and then invoking_transferOwnership(_owner), the contract sets the owner twice. Confirm this is desired, or remove one of the assignments if redundant.typings/factories/src/etherspot-wallet-v1/helpers/SafeTransferLib__factory.ts (2)
42-44: Validate constructor parameter utility.
isSuperArgscleanly differentiates constructor arguments. This is a good approach forContractFactoryextension; no issues spotted.
35-36: Confirm correctness of bytecode for SafeTransferLib.
Ensure the provided bytecode is the correct compiled output from the associated Solidity code. If so, this looks fine.typings/src/etherspot-wallet-v1/paymaster/IOracleAggregator.ts (1)
23-41: Interface structure appears coherent.The definition of the
IOracleAggregatorInterfacewith typed functions and events aligns well with best practices, providing clarity and maintainability.typings/factories/src/etherspot-wallet-v1/paymaster/MultiTokenPaymaster__factory.ts (1)
1-67: Factory code looks good and consistent.The auto-generated contract factory includes correct deployment parameters and typed interfaces, ensuring easy instantiation of the contract. No issues found.
typings/factories/src/etherspot-wallet-v1/paymaster/TokenPaymasterErrors__factory.ts (1)
1-123: Error factory is well-structured.Auto-generated factory with a concise ABI for common error types. Definitions are properly mapped, and the deployment flow appears correct.
src/MultiTokenPaymaster/MultiTokenPaymaster.sol (1)
168-176:Details
✅ Verification successful
Re-examine maximum gas threshold limit.
The hard cap of
200000gas for_newThresholdCostmight be too restrictive on certain L2 networks or complex operations. Verify whether this upper bound is appropriate for all targeted environments.
🏁 Script executed:
#!/bin/bash # Check if any environment or test configuration references a higher required overhead than 200000 gas # The command scans for references to setUnaccountedEPGasThreshold usage or doc references that exceed 200000. rg "setUnaccountedEPGasThreshold|_newThresholdCost|UNACCOUNTED_COST"Length of output: 115101
Clarify the rationale for the 200,000 gas cap.
Our scan of the codebase and test references shows that the threshold is consistently capped at 200,000 gas and that no configuration or usage requires a higher value. Given UNACCOUNTED_COST is initialized to 45,000 and the hard cap is meant to prevent unrealistic values (with an explicit note regarding potential issues on Arbitrum), the current limit appears to be intentional and appropriate. That said, please double-check in your L2 testing that the gas overhead during post-operations remains sufficient. If future use cases indicate a need for a higher threshold, consider making this parameter configurable or updating the cap accordingly.typings/factories/src/etherspot-wallet-v1/paymaster/EtherspotPaymaster__factory.ts (1)
616-616: Bytecode updated for EPv07 support.The bytecode has been updated to align with the new EPv07 implementation, which is consistent with the PR objective of adding EPv07 support to the MultiTokenPaymaster system.
typings/factories/src/etherspot-wallet-v1/paymaster/VerifyingPaymaster__factory.ts (1)
470-470: Bytecode updated for EPv07 support.The bytecode has been updated to align with the new EPv07 implementation, which is consistent with the PR objective of adding EPv07 support to the MultiTokenPaymaster system.
typings/hardhat.d.ts (1)
36-38: New PayMaster and Oracle contracts added with consistent formatting.The TypeScript declarations have been updated to include new contract interfaces required for the MultiTokenPaymaster EPv07 functionality:
- IERC1271: Interface for ERC1271 standard to verify signatures
- SafeTransferLib: Utility library for safe token transfers
- IOracleAggregator: Interface for retrieving token values
- MultiTokenPaymaster: Main contract for the multi-token paymaster functionality
- TokenPaymasterErrors: Error definitions for the token paymaster
Additionally, string formatting has been consistently updated from single to double quotes throughout the file.
Also applies to: 232-234, 276-286, 470-473, 715-718, 770-783
| }, | ||
| ], | ||
| stateMutability: "nonpayable", | ||
| stateMutability: "view", |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Optimized function state mutability
The validateSessionKeyParams function has been changed from nonpayable to view, which is an important optimization. This change indicates that the function no longer modifies the blockchain state, which allows for cheaper gas costs and the ability to call the function without creating a transaction.
This change is positive as it reduces gas costs. Ensure all callers of this function are aware that it's now a view function, as this might affect how they interact with it.
| /* Autogenerated file. Do not edit manually. */ | ||
| /* tslint:disable */ | ||
| /* eslint-disable */ | ||
| export { BasePaymaster__factory } from "./BasePaymaster__factory"; | ||
| export { EtherspotPaymaster__factory } from "./EtherspotPaymaster__factory"; | ||
| export { VerifyingPaymaster__factory } from "./VerifyingPaymaster__factory"; | ||
| export { Whitelist__factory } from "./Whitelist__factory"; |
There was a problem hiding this comment.
Missing exports for new paymaster components
This index file currently only exports existing paymaster factories. According to the AI summary, it should also export the new components needed for EPv07 support: IOracleAggregator__factory, MultiTokenPaymaster__factory, and TokenPaymasterErrors__factory.
Add the missing exports to complete the implementation:
/* Autogenerated file. Do not edit manually. */
/* tslint:disable */
/* eslint-disable */
export { BasePaymaster__factory } from "./BasePaymaster__factory";
export { EtherspotPaymaster__factory } from "./EtherspotPaymaster__factory";
export { VerifyingPaymaster__factory } from "./VerifyingPaymaster__factory";
export { Whitelist__factory } from "./Whitelist__factory";
+export { IOracleAggregator__factory } from "./IOracleAggregator__factory";
+export { MultiTokenPaymaster__factory } from "./MultiTokenPaymaster__factory";
+export { TokenPaymasterErrors__factory } from "./TokenPaymasterErrors__factory";📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /* Autogenerated file. Do not edit manually. */ | |
| /* tslint:disable */ | |
| /* eslint-disable */ | |
| export { BasePaymaster__factory } from "./BasePaymaster__factory"; | |
| export { EtherspotPaymaster__factory } from "./EtherspotPaymaster__factory"; | |
| export { VerifyingPaymaster__factory } from "./VerifyingPaymaster__factory"; | |
| export { Whitelist__factory } from "./Whitelist__factory"; | |
| /* Autogenerated file. Do not edit manually. */ | |
| /* tslint:disable */ | |
| /* eslint-disable */ | |
| export { BasePaymaster__factory } from "./BasePaymaster__factory"; | |
| export { EtherspotPaymaster__factory } from "./EtherspotPaymaster__factory"; | |
| export { VerifyingPaymaster__factory } from "./VerifyingPaymaster__factory"; | |
| export { Whitelist__factory } from "./Whitelist__factory"; | |
| export { IOracleAggregator__factory } from "./IOracleAggregator__factory"; | |
| export { MultiTokenPaymaster__factory } from "./MultiTokenPaymaster__factory"; | |
| export { TokenPaymasterErrors__factory } from "./TokenPaymasterErrors__factory"; |
| constructor(address _owner, IEntryPoint _entryPoint) Ownable(_owner) { | ||
| _validateEntryPointInterface(_entryPoint); | ||
| entryPoint = _entryPoint; | ||
| _transferOwnership(_owner); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Constructor contains redundant ownership transfer
The constructor now has two ways of setting ownership:
- Through the
Ownable(_owner)constructor parameter - By explicitly calling
_transferOwnership(_owner)
This redundancy is unnecessary and wastes gas since the Ownable constructor already sets the owner.
constructor(address _owner, IEntryPoint _entryPoint) Ownable(_owner) {
_validateEntryPointInterface(_entryPoint);
entryPoint = _entryPoint;
- _transferOwnership(_owner);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| constructor(address _owner, IEntryPoint _entryPoint) Ownable(_owner) { | |
| _validateEntryPointInterface(_entryPoint); | |
| entryPoint = _entryPoint; | |
| _transferOwnership(_owner); | |
| } | |
| constructor(address _owner, IEntryPoint _entryPoint) Ownable(_owner) { | |
| _validateEntryPointInterface(_entryPoint); | |
| entryPoint = _entryPoint; | |
| } |
| function testParsePaymasterAndData() public { | ||
| ( | ||
| MultiTokenPaymaster.ExchangeRateSource priceSource, | ||
| uint48 validUntil, | ||
| uint48 validAfter, | ||
| address feeToken, | ||
| address oracleAggregator, | ||
| uint256 exchangeRate, | ||
| uint32 priceMarkup, | ||
| bytes memory signature | ||
| ) = mtp.parsePaymasterAndData(paymasterAndData); | ||
| console2.log("priceSource:", uint8(uint256(priceSource))); | ||
| console2.log("validUntil:", validUntil); | ||
| console2.log("validAfter:", validAfter); | ||
| console2.log("feeToken:", feeToken); | ||
| console2.log("oracleAggregator:", oracleAggregator); | ||
| console2.log("exchangeRate:", exchangeRate); | ||
| console2.log("priceMarkup:", priceMarkup); | ||
| console2.logBytes(signature); | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance the test with assertions.
Currently, the test only logs the parsed values without verifying them. Consider adding checks (e.g., assertEq, assertTrue) to confirm correctness of each parsed field.
function testParsePaymasterAndData() public {
(
MultiTokenPaymaster.ExchangeRateSource priceSource,
uint48 validUntil,
uint48 validAfter,
address feeToken,
address oracleAggregator,
uint256 exchangeRate,
uint32 priceMarkup,
bytes memory signature
) = mtp.parsePaymasterAndData(paymasterAndData);
// Existing logs
console2.log("priceSource:", uint8(uint256(priceSource)));
console2.log("validUntil:", validUntil);
console2.log("validAfter:", validAfter);
console2.log("feeToken:", feeToken);
console2.log("oracleAggregator:", oracleAggregator);
console2.log("exchangeRate:", exchangeRate);
console2.log("priceMarkup:", priceMarkup);
console2.logBytes(signature);
+ // Suggested additions
+ // Example: Check expected values if known
+ // assertEq(uint8(uint256(priceSource)), /* expectedValue */, "Unexpected price source");
+ // ...
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| function testParsePaymasterAndData() public { | |
| ( | |
| MultiTokenPaymaster.ExchangeRateSource priceSource, | |
| uint48 validUntil, | |
| uint48 validAfter, | |
| address feeToken, | |
| address oracleAggregator, | |
| uint256 exchangeRate, | |
| uint32 priceMarkup, | |
| bytes memory signature | |
| ) = mtp.parsePaymasterAndData(paymasterAndData); | |
| console2.log("priceSource:", uint8(uint256(priceSource))); | |
| console2.log("validUntil:", validUntil); | |
| console2.log("validAfter:", validAfter); | |
| console2.log("feeToken:", feeToken); | |
| console2.log("oracleAggregator:", oracleAggregator); | |
| console2.log("exchangeRate:", exchangeRate); | |
| console2.log("priceMarkup:", priceMarkup); | |
| console2.logBytes(signature); | |
| } | |
| } | |
| function testParsePaymasterAndData() public { | |
| ( | |
| MultiTokenPaymaster.ExchangeRateSource priceSource, | |
| uint48 validUntil, | |
| uint48 validAfter, | |
| address feeToken, | |
| address oracleAggregator, | |
| uint256 exchangeRate, | |
| uint32 priceMarkup, | |
| bytes memory signature | |
| ) = mtp.parsePaymasterAndData(paymasterAndData); | |
| console2.log("priceSource:", uint8(uint256(priceSource))); | |
| console2.log("validUntil:", validUntil); | |
| console2.log("validAfter:", validAfter); | |
| console2.log("feeToken:", feeToken); | |
| console2.log("oracleAggregator:", oracleAggregator); | |
| console2.log("exchangeRate:", exchangeRate); | |
| console2.log("priceMarkup:", priceMarkup); | |
| console2.logBytes(signature); | |
| // Suggested additions | |
| // Example: Check expected values if known | |
| // assertEq(uint8(uint256(priceSource)), /* expectedValue */, "Unexpected price source"); | |
| // ... | |
| } | |
| } |
| function _validateEntryPointInterface(IEntryPoint _entryPoint) internal virtual returns(bool) { | ||
| require(IERC165(address(_entryPoint)).supportsInterface(type(IEntryPoint).interfaceId), "IEntryPoint interface mismatch"); | ||
| } |
There was a problem hiding this comment.
Fix missing return in _validateEntryPointInterface.
This function is declared returns(bool) but does not return a value. This discrepancy might cause compilation warnings or errors.
function _validateEntryPointInterface(IEntryPoint _entryPoint) internal virtual returns(bool) {
require(IERC165(address(_entryPoint)).supportsInterface(type(IEntryPoint).interfaceId), "IEntryPoint interface mismatch");
-}
+ return true;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| function _validateEntryPointInterface(IEntryPoint _entryPoint) internal virtual returns(bool) { | |
| require(IERC165(address(_entryPoint)).supportsInterface(type(IEntryPoint).interfaceId), "IEntryPoint interface mismatch"); | |
| } | |
| function _validateEntryPointInterface(IEntryPoint _entryPoint) internal virtual returns(bool) { | |
| require(IERC165(address(_entryPoint)).supportsInterface(type(IEntryPoint).interfaceId), "IEntryPoint interface mismatch"); | |
| return true; | |
| } |
2 participants
Description
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Summary by CodeRabbit
New Features
Refactor / Chore