feat: add time range module #180
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adamegyed
force-pushed
the
adam/time-range-rule
branch
from
ac6503a
to
ed7a64a
Compare
fangting-alchemy
approved these changes
Sep 19, 2024
adamegyed
force-pushed
the
adam/add-allowlist
branch
from
5da015e
to
4d83375
Compare
adamegyed
force-pushed
the
adam/time-range-rule
branch
from
ed7a64a
to
d7b5b7f
Compare
jaypaik
reviewed
Sep 23, 2024
|
|
||
| import {BaseModule} from "../../modules/BaseModule.sol"; | ||
|
|
||
| contract TimeRangeModule is IValidationHookModule, BaseModule { |
There was a problem hiding this comment.
Mind adding NatSpec documentation to our contracts?
There was a problem hiding this comment.
Added here: 5aeff4d
Lmk if anything's missing!
jaypaik
reviewed
Sep 23, 2024
|
|
||
| error TimeRangeNotValid(); | ||
|
|
||
| function onInstall(bytes calldata data) external override { |
There was a problem hiding this comment.
Also @dev comments in functions like these to describe how data should be encoded.
There was a problem hiding this comment.
Added!
Though I wonder if it would be preferable to put this info in an @param instead?
adamegyed
force-pushed
the
adam/add-allowlist
branch
from
4d83375
to
6273dfe
Compare
adamegyed
force-pushed
the
adam/time-range-rule
branch
2 times, most recently
from
c278831
to
4265d1f
Compare
adamegyed
force-pushed
the
adam/add-allowlist
branch
2 times, most recently
from
e54e9a1
to
4afc628
Compare
adamegyed
force-pushed
the
adam/time-range-rule
branch
from
4265d1f
to
108d147
Compare
adamegyed
force-pushed
the
adam/time-range-rule
branch
from
108d147
to
51d7377
Compare
Summary by OctaneNew Contracts
Updated ContractsNo contracts were updated in this PR. 🔗 Commit Hash: 51d7377 |
OverviewOctane AI analysis has finished. No vulnerabilities were found. Cheers! 🎉🎉🎉 🔗 Commit Hash: 51d7377 |
|
Contract sizes: | Contract | Size (B) | Margin (B) |
|------------------------------|----------|------------|
| AccountFactory | 4,169 | 20,407 |
| AllowlistModule | 5,817 | 18,759 |
| ERC20TokenLimitModule | 4,138 | 20,438 |
| ModularAccount | 25,983 | -1,407 |
| SemiModularAccount | 26,487 | -1,911 |
| SingleSignerValidationModule | 3,444 | 21,132 |
+| TimeRangeModule | 1,870 | 22,706 |
| TokenReceiverModule | 2,189 | 22,387 |Code coverage:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
We want the ability to limit validations by time range, for use in session keys and other modules.
Solution
Add a time range enforcing module. When used as a user op validation, this returns the time range in the 4337 validationData value. When used as a runtime validation, this checks
block.timestampand enforces that the validation is only used within this context.Also adds additional commands to
package.jsonfor viewing coverage and generating anlcovreport.Note: this currently doesn't enforce anything for signature validation. It is not clear to me whether or not it is safe to use
block.timestampin the signature checking logic, because if may be used within another account's 4337 validation phase. However, that entire workflow is not common due to the likely violation for associated storage.To discuss: should this hook check
block.timestampin the pre signature validation hook? Or should we just recommend users to disable signature validation from validation functions with this hook using the flag?