fix typo in DOC

Author: SpaceStation09

docs/API.md

@@ -27,16 +27,15 @@ Generally, users can specify a list of ERC721 token ID to create an ERC721 red p
 
 1. Users need to call `setApprovalForAll()` in advance to approve of our red packet operating users' asset.
 
-2. Users call `create_red_packet()` in our red packet contract. At this step, users need to specify a list of the NFT tokenID to put in red packet. During creation, the specified NFTs are **NOT** transferred to our red packet since it requires plenty of gas if we transfer these NFTs one by one. At this stage, red packet contract only has the grant to operate the NFTs rather than **own** these NFTs. Thus, we need to design a mechanism to handle the situation where an NFT has already been transferred to another address when a user tries to claim it.
+2. Users call `create_red_packet()` in our red packet contract. At this step, users need to specify a list of the NFT tokenID to be put in red packet. During creation, the specified NFTs are **NOT** transferred to our red packet since it requires plenty of gas if we transfer these NFTs one by one. At this stage, red packet contract only has the grant to operate the NFTs rather than **own** these NFTs. Thus, we need to design a mechanism to handle the situation where an NFT has already been transferred to another address when a user tries to claim it.
 
-3. Users can call `claim()` to claim an NFT from the red packet contract. 
+3. Users can call `claim()` function to claim an NFT from the red packet. 
     - At the beginning, the NFT will be picked randomly. 
     - If the picked NFT is still in red packet creators's account, then the user can claim the NFT directly.
     - If the user meets the situation where an NFT has already been transferred to another address, then red packet contract needs to reselect an available NFT:
-        -We use a `uint256` variable `bit_status` to record the status of each NFT in red packet. (Therefore, we currently only allow 256 NFTs to be put in red packet at most.)
-        - Firstly, we check if the NFT still belongs to the red packet creator. If no, that means the NFT has already been transferred to another address.
-        - Secondly, we start to scan `bit_status` from the first bit. If the bit is 1, we skip it; If the bit is 0, we check if the NFT still belongs to the red packet creator.
-        - If yes, we pick this NFT.
+        - We use a `uint256` variable `bit_status` to record the status of each NFT in red packet. (Therefore, we currently only allow 256 NFTs to be put in red packet at most.)
+        - Firstly, we start to scan `bit_status` from the first bit. If the bit is 1, we skip it; If the bit is 0, we check if the NFT still belongs to the red packet creator.
+        - If yes, we pick this NFT and stop the NFT selection period.
         - If no, we update the corresponding bit in `bit_status` to 1 and continue to scan `bit_status`. 
         - Then we repeat the above steps until we find an available NFT or there is no NFT remain(Will be revert with error).
 
@@ -261,15 +260,15 @@ Get the current availability status of all tokens in a red packet.
 Generally, users can specify a list of ERC721 token ID to create an ERC721 red packet with RedPacket_ERC721. Then, users are able to randomly claim one NFT from the red packet.
 
 ### Workflow in Red Packet
-1. Users need to call `approve()` to approve of our red packet contract operating enough amount of users' token.
+1. Users need to call `approve()` to approve of our red packet contract operating enough amount of users' tokens.
 
-2. Users call `create_red_packet()` in our red packet contract. At this step, creators are able to choose the claim method: avarage or random. **Notice**: Different from the design in RedPacket_ERC721, tokens to be put in red packet will be transferred to red packet contract during creation period in fungible token red packet.
+2. Users call `create_red_packet()` in our red packet contract. At this step, creators are able to choose the claim method: average or random. **Notice**: Different from the design in RedPacket_ERC721, tokens to be put in red packet will be transferred to red packet contract during red packet creation period.
 
-3. Users can call `claim()` to claim tokens from the red packet contract.
-    1. If the claimer is claiming the last packet, the claimer will get all of the remaining token directly.
+3. Users can call `claim()` to claim tokens from the red packet.
+    1. If the claimer is claiming the last packet, the claimer will get all of the remaining tokens directly.
     2. Otherwise, if the red packet is set as random, the claimer will get random amount of tokens. If the red packet is set as average, the claimer will get average amount of tokens.
 
-4. After the red packet expired, if there are remain tokens in this red packet, the red packet creator is able to withdraw the remain tokens.
+4. After the red packet expired, if there are remaining tokens in this red packet, the red packet creator is able to withdraw the remaining tokens.
 
 
 ### create red packet 
@@ -405,7 +404,7 @@ Check red packet info.
   - N/A
 
 ### refund
-After the redpacket expired, the red packet creator is able to withdraw the remaining token.
+After the red packet expired, the red packet creator is able to withdraw the remaining token.
 
 ```solidity
   function refund(bytes32 id) public {}
@@ -432,16 +431,16 @@ After the redpacket expired, the red packet creator is able to withdraw the rema
   ```
 
 ## Verification Design
-Both red packet smart contracts contains a verification mechanism which is used to ensure the claimer is claiming red packet through our Mask externsion.
+Both red packet smart contracts contain a verification mechanism which is used to ensure the claimer is claiming red packet through our Mask extension.
 
 Verification mechanism:
-1. Front-end randomly generates an Ethereum account A (the account address is the public key) with its private key. While creating the red packet, we need to pass the public key to redpacket smart contract as a parameter.
+1. Front-end randomly generates an Ethereum account A (the account address is the public key) with its private key. While creating the red packet, we need to pass the public key to red packet smart contract as a parameter.
 2. Smart contract will store the public key and front-end will keep the private key.
 3. When a user tries to claim the red packet, front-end will sign a message with the private key of account A. The content of this message is the address of account B who calls the `claim()` function (i.e. `msg.sender`).
 4. The signature will be passed to smart contract as a parameter while calling `claim()`. 
-5. With the signature and the hash of `msg.sender`, redpacket smart contract is able to calculate the address of account who signs the message.
+5. With the signature and the hash of `msg.sender`, red packet smart contract is able to calculate the address of account who signs the message.
 6. By comparing the public key stored during red packet creation period with the account address we calculated, we are able to distinguish if the function caller carries the signature signed with the right private key kept in front-end.
 
 With this mechanism:
 - Users who don't have the private key, they cannot generate a right signature. So they will be rejected while calling `claim()`.
-- If they listen to Ethereum network, and catch the transaction payload which claimed successfully. They will try to claim with the same payload. They'll still get rejected since our contract will calculate the hash of message with `msg.sender` which cannot be the same with the successful claim case.
+- If they listen to Ethereum network, and catch the transaction payload which claimed successfully. They will try to claim with the same payload. They'll still get rejected since our contract will calculate the hash of message using `msg.sender` which cannot be the same with the successful claim case.