You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: CHANGELOG.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -427,7 +427,7 @@ Instead, contracts now revert with custom errors. Systems that interact with sma
427
427
428
428
##### Relying on storage locations for retrieving data
429
429
430
-
After 5.0, the storage location of some variables were changed. This is the case for `Initializable` and all the upgradeable contracts since they now use namespaced storaged locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.
430
+
After 5.0, the storage location of some variables was changed. This is the case for `Initializable` and all the upgradeable contracts since they now use namespaced storage locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.
Copy file name to clipboardexpand all lines: GUIDELINES.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ Code must be thoroughly tested with quality unit tests.
6
6
7
7
We defer to the [Moloch Testing Guide](https://github.com/MolochVentures/moloch/tree/master/test#readme) for specific recommendations, though not all of it is relevant here. Note the introduction:
8
8
9
-
> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests are just as important (if not more so) than the code itself, and should be written with the highest standards of clarity and elegance.
9
+
> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests is just as important (if not more so) than the code itself, and should be written to the highest standards of clarity and elegance.
10
10
11
11
Every addition or change to the code must come with relevant and comprehensive tests.
Copy file name to clipboardexpand all lines: RELEASING.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Releasing
2
2
3
-
OpenZeppelin Contracts uses a fully automated release process that takes care of compiling, packaging, and publishing the library, all of which is carried out in a clean CI environment (GitHub Actions), implemented in the ([`release-cycle`](.github/workflows/release-cycle.yml)) workflow. This helps to reduce the potential for human error and inconsistencies, and ensures that the release process is ongoing and reliable.
3
+
OpenZeppelin Contracts uses a fully automated release process that takes care of compiling, packaging, and publishing the library, all of which is carried out in a clean CI environment (GitHub Actions), implemented in the [`release-cycle`](.github/workflows/release-cycle.yml) workflow. This helps to reduce the potential for human error and inconsistencies, and ensures that the release process is consistent and reliable.
Copy file name to clipboardexpand all lines: audits/2017-03.md
+5-5
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ The git commit hash we evaluated is:
20
20
21
21
# Disclaimer
22
22
23
-
The audit makes no statements or warrantees about utility of the code, safety of the code, suitability of the business model, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bug free status. The audit documentation is for discussion purposes only.
23
+
The audit makes no statements or warranties about utility of the code, safety of the code, suitability of the business model, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bug free status. The audit documentation is for discussion purposes only.
24
24
25
25
# Executive Summary
26
26
@@ -90,7 +90,7 @@ We are still working through the confirmation protocol in `Shareable.sol`, but w
90
90
This bug has a number of causes that need to be addressed:
91
91
92
92
1.`resetSpentToday` and `confirm` together do not limit the days on which the function can be called or (it appears) the number of times it can be called.
93
-
1. Once a call has been confirmed and `execute`d it appears that it can be re-executed. This is not good.
93
+
1. Once a call has been confirmed and executed it appears that it can be re-executed. This is not good.
94
94
3.`confirmandCheck` doesn't seem to have logic about whether or not the function in question has been called.
95
95
4. Even if it did, `revoke` would need updates and logic to deal with revocation requests after a function call had been completed.
96
96
@@ -109,7 +109,7 @@ It would be nice to see how many payments are pending. This would imply a bit of
109
109
110
110
## Shareable Contract
111
111
112
-
We do not believe the `Shareable.sol` contract is ready for primetime. It is missing functions, and as written may be vulnerable to a reordering attack -- an attack in which a miner or other party "racing" with a smart contract participant inserts their own information into a list or mapping.
112
+
We do not believe the `Shareable.sol` contract is ready for prime time. It is missing functions, and as written may be vulnerable to a reordering attack -- an attack in which a miner or other party "racing" with a smart contract participant inserts their own information into a list or mapping.
113
113
114
114
The confirmation and revocation code needs to be looked over with a very careful eye imagining extraordinarily bad behavior by shared owners before this contract can be called safe.
115
115
@@ -159,7 +159,7 @@ Allows owner to set a public string of contract information. No issues.
159
159
160
160
This needs some work. Doesn't check if `_required <= len(_owners)` for instance, that would be a bummer. What if _required were like `MAX - 1`?
161
161
162
-
I have a general concern about the difference between `owners`, `_owners`, and `owner` in `Ownable.sol`. I recommend "Owners" be renamed. In general we do not recomment single character differences in variable names, although a preceding underscore is not uncommon in Solidity code.
162
+
I have a general concern about the difference between `owners`, `_owners`, and `owner` in `Ownable.sol`. I recommend "Owners" be renamed. In general we do not recommend single character differences in variable names, although a preceding underscore is not uncommon in Solidity code.
163
163
164
164
Line 34: "this contract only has six types of events"...actually only two.
165
165
@@ -224,7 +224,7 @@ Transfer() and transferFrom() use SafeMath functions, which will cause them to t
224
224
225
225
### SimpleToken
226
226
227
-
Sample instantiation of StandardToken. Note that in this sample, decimals is 18 and supply only 10,000, so the supply is a small fraction of a single nominal token.
227
+
Sample instantiation of StandardToken. Note that in this sample, decimals is 18 and supply is only 10,000, so the supply is a small fraction of a single nominal token.
Copy file name to clipboardexpand all lines: contracts/utils/README.adoc
+2-2
Original file line number
Diff line number
Diff line change
@@ -18,12 +18,12 @@ Miscellaneous contracts and libraries containing utility functions you can use t
18
18
* {ReentrancyGuardTransient}: Variant of {ReentrancyGuard} that uses transient storage (https://eips.ethereum.org/EIPS/eip-1153[EIP-1153]).
19
19
* {Pausable}: A common emergency response mechanism that can pause functionality while a remediation is pending.
20
20
* {Nonces}: Utility for tracking and verifying address nonces that only increment.
21
-
* {NoncesKeyed}: Alternative to {Nonces}, that support key-ed nonces following https://eips.ethereum.org/EIPS/eip-4337#semi-abstracted-nonce-support[ERC-4337 speciciations].
21
+
* {NoncesKeyed}: Alternative to {Nonces}, that support keyed nonces following https://eips.ethereum.org/EIPS/eip-4337#semi-abstracted-nonce-support[ERC-4337 specifications].
22
22
* {ERC165}, {ERC165Checker}: Utilities for inspecting interfaces supported by contracts.
23
23
* {BitMaps}: A simple library to manage boolean value mapped to a numerical index in an efficient way.
24
24
* {EnumerableMap}: A type like Solidity's https://solidity.readthedocs.io/en/latest/types.html#mapping-types[`mapping`], but with key-value _enumeration_: this will let you know how many entries a mapping has, and iterate over them (which is not possible with `mapping`).
25
25
* {EnumerableSet}: Like {EnumerableMap}, but for https://en.wikipedia.org/wiki/Set_(abstract_data_type)[sets]. Can be used to store privileged accounts, issued IDs, etc.
26
-
* {DoubleEndedQueue}: An implementation of a https://en.wikipedia.org/wiki/Double-ended_queue[double ended queue] whose values can be removed added or remove from both sides. Useful for FIFO and LIFO structures.
26
+
* {DoubleEndedQueue}: An implementation of a https://en.wikipedia.org/wiki/Double-ended_queue[double ended queue] whose values can be added or removed from both sides. Useful for FIFO and LIFO structures.
27
27
* {CircularBuffer}: A data structure to store the last N values pushed to it.
28
28
* {Checkpoints}: A data structure to store values mapped to a strictly increasing key. Can be used for storing and accessing values over time.
29
29
* {Heap}: A library that implements a https://en.wikipedia.org/wiki/Binary_heap[binary heap] in storage.
0 commit comments