fix: typo inside readme

README.md

@@ -735,4 +735,4 @@ Candidate features for Version 1 to consider when reviewing or integrating with
  - Modifying witness typestring mechanics — in Version 0, a witness typestring fragment is supplied that includes both the argument for the witness as well any additional types for the struct, if any, used by the witness. This gives some added flexibility, but also leads to additional data that needs to be supplied by the arbiter when calling The Compact and opens arbiters up to selecting structs with names that do not adhere to the requirement that all EIP-712 struct definitions are alphanumerically ordered in the typestring. By way of example, if a given witness uses a struct of `Witness(uint256 witnessArgument)`, the supplied typestring would be `Witness witness)Witness(uint256 witnessArgument)`. One option for Version 1 would be to define a fixed witness struct fragment internally and only allow for providing the internal arguments; given the provided example, the arbiter would simply provide `uint256 witnessArgument` for the witness typestring argument.
  - Enabling allocated transfers or withdrawals via an approved operator — in Version 0, transfers or withdrawals from an operator account utilize an `attest(address operator, address from, address to, uint256 id, uint256 amount)` callback on the allocator to support standard ERC6909 transfers. However, an additional method using something like `allocatedTransferFrom` could enable cases where a signature still needs to be supplied from the allocator or where additional context is required beyond what's available as part of a standard transfer. Note that the existing claim processing methodology can be adapted to many of these use-cases, but this approach does not involve approvals and instead requires that the sponsor provide permit-style signatures; sponsors that prefer an approval-based mechanic currently need to use an allocator that implements `attest`.
  - Reworking metadata — Version 0 implements relatively rudimentary metadata rendering. Version 1 should improve on this metadata, particularly as it relates to images and other rich metadata, without compromising on the core autonomy and reproducibility present in Version 0.
- - General optimization: Version 0 already contains a significant amount of low-level code in order to succintly represent the necessary logic. Version 1 could improve on overall efficiency by implementing further optimizations and by bringing the codesize down further to allow for dialing up compiler optimization.
+ - General optimization: Version 0 already contains a significant amount of low-level code in order to succinctly represent the necessary logic. Version 1 could improve on overall efficiency by implementing further optimizations and by bringing the codesize down further to allow for dialing up compiler optimization.