Update ERC-3009: fix erc3009 typo

ERCS/erc-3009.md

@@ -10,7 +10,7 @@
 requires: 20, 712
 ---
 
 ## Simple Summary
 
 A contract interface that enables transferring of fungible assets via a signed authorization.
 
@@ -41,7 +41,7 @@
 
 This can be especially problematic if the gas prices are very high and transactions often get queued up and remain unconfirmed for a long time. Non-sequential nonces allow users to create as many transactions as they want at the same time.
 
 The ERC-20 allowance mechanism is susceptible to the [multiple withdrawal attack](https://blockchain-projects.readthedocs.io/multiple_withdrawal.html)/[SWC-114](https://swcregistry.io/docs/SWC-114), and encourages antipatterns such as the use of the "infinite" allowance. The wide-prevalence of upgradeable contracts have made the conditions favorable for these attacks to happen in the wild.
 
 The deficiencies of the ERC-20 allowance pattern brought about the development of alternative token standards such as the [ERC-777](./eip-777) and [ERC-677](https://github.com/ethereum/EIPs/issues/677). However, they haven't been able to gain much adoption due to compatibility and potential security issues.
 
@@ -197,7 +197,7 @@
 
 ```
 // "‖" denotes concatenation.
-Digest := Keecak256(
+Digest := Keccak256(
   0x1901 ‖ DomainSeparator ‖ Keccak256(ABIEncode(TypeHash, Params...))
 )
 
@@ -310,9 +310,9 @@
 
 ## Backwards Compatibility
 
 New contracts benefit from being able to directly utilize EIP-3009 in order to create atomic transactions, but existing contracts may still rely on the conventional ERC-20 allowance pattern (`approve`/`transferFrom`).
 
 In order to add support for EIP-3009 to existing contracts ("parent contract") that use the ERC-20 allowance pattern, a forwarding contract ("forwarder") can be constructed that takes an authorization and does the following:
 
 1. Extract the user and deposit amount from the authorization
 2. Call `receiveWithAuthorization` to transfer specified funds from the user to the forwarder
@@ -387,11 +387,11 @@
 
 ## Test Cases
 
 See [EIP3009.test.ts](https://github.com/CoinbaseStablecoin/eip-3009/blob/master/test/EIP3009.test.ts).
 
 ## Implementation
 
 **EIP3009.sol**
 ```solidity
 abstract contract EIP3009 is IERC20Transfer, EIP712Domain {
     // keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
@@ -454,7 +454,7 @@
 }
 ```
 
 **IERC20Transfer.sol**
 ```solidity
 abstract contract IERC20Transfer {
     function _transfer(
@@ -465,14 +465,14 @@
 }
 ```
 
 **EIP712Domain.sol**
 ```solidity
 abstract contract EIP712Domain {
     bytes32 public DOMAIN_SEPARATOR;
 }
 ```
 
 **EIP712.sol**
 ```solidity
 library EIP712 {
     // keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)")
@@ -521,7 +521,7 @@
 }
 ```
 
 A fully working implementation of EIP-3009 can be found in [this repository](https://github.com/CoinbaseStablecoin/eip-3009/blob/master/contracts/lib/EIP3009.sol). The repository also includes [an implementation of EIP-2612](https://github.com/CoinbaseStablecoin/eip-3009/blob/master/contracts/lib/EI32612.sol) that uses the EIP-712 library code presented above.
 
 ## Security Considerations