Skip to content

Fix: typos #103

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -203,7 +203,7 @@ changes. Once scheduled, batch configs cannot be removed and their order cannot
Scheduling a config is a two step process: First, the config object is drafted using the various
`setNext...` functions and, second, it is finalized using `schedule`.

Only the contract owner is allowed to schedule configs. This role is inteded to be played by a DAO.
Only the contract owner is allowed to schedule configs. This role is intended to be played by a DAO.

The batch config objects divide time into a sequence of batches and each config is applicable to a
range of them. The following fields specify this:
Expand All @@ -222,7 +222,7 @@ The batch span can be zero denoting that the system is disabled. It can be enabl
scheduling a new config with a batch span greater than zero.

The key generation parameters are set by the `keypers` and `threshold` fields. Note that `keypers`
must not contain duplicates and that the threshold must less than or equal to the number of
must not contain duplicates and that the threshold must be less than or equal to the number of
keypers, but greater than half of it.

The transactions that are allowed to enter a batch are constrained by the following fields:
Expand All @@ -235,12 +235,12 @@ For transaction execution after decryption, the following fields are relevant:

- `transactionGasLimit`: the maximum amount of gas a transaction is allowed to consume during
execution once it is decrypted
- `targetAddress`: the address of the contract to which the derypted transactions will be passed
- `targetAddress`: the address of the contract to which the decrypted transactions will be passed
to
- `targetFunctionSelector`: the 4 byte function selector that specifies the function in the target
contract that will be called with each decrypted transaction
- `executionTimeout`: the number of blocks to pass between the end of a batch and the time at which
it is assumed that decryption has failed and can be skipped (e.g., because too many keyper were
it is assumed that decryption has failed and can be skipped (e.g., because too many keypers were
offline)

### Batcher Contract
Expand Down