Merge pull request #435 from crazehang/master

rfcs: fix some comments
nervosnetwork · Apr 3, 2024 · 966a848 · 966a848
2 parents dff5235 + 245522e
commit 966a848
Show file tree

Hide file tree

Showing 3 changed files with 3 additions and 3 deletions.
diff --git a/rfcs/0003-ckb-vm/0003-ckb-vm.md b/rfcs/0003-ckb-vm/0003-ckb-vm.md
@@ -214,7 +214,7 @@ It ensures generated data is legit by validating that contents in output cell ma
 
 In the above example, function implementation for validating cell is directly compiled into input contract script. It's also possible to reference and call code from external cell for validation.
 
-First, the following implementation can be provided for transfering UDT tokens:
+First, the following implementation can be provided for transferring UDT tokens:
 
 ```c
 int udt_transfer(data_t *data, const char from[ADDRESS_LENGTH], const char to[ADDRESS_LENGTH], int64_t tokens)

diff --git a/rfcs/0011-transaction-filter-protocol/0011-transaction-filter-protocol.md b/rfcs/0011-transaction-filter-protocol/0011-transaction-filter-protocol.md
@@ -44,7 +44,7 @@ table SetFilter {
 
 ### AddFilter
 
-Upon receiving a `AddFilter` message, the given bit data will be added to the exsiting filter via bitwise OR operator. A filter must have been previously provided using `SetFilter`. This messsage is useful if a new filter is added to a peer whilst it has connections to the network open, alsp avoids the need to re-calculate and send an entirely new filter to every peer.
+Upon receiving a `AddFilter` message, the given bit data will be added to the existing filter via bitwise OR operator. A filter must have been previously provided using `SetFilter`. This messsage is useful if a new filter is added to a peer whilst it has connections to the network open, alsp avoids the need to re-calculate and send an entirely new filter to every peer.
 
 ```
 table AddFilter {

diff --git a/rfcs/0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md b/rfcs/0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md
@@ -70,7 +70,7 @@ A phase 2 transaction MUST satisfy the following conditions:
 
 - One or more `withdrawing cell`s MUST be included in the transaction as inputs.
 - For each `withdrawing cell`, the transaction MUST also include the reference to its associated including block in `header_deps`, which will be used by Nervos DAO type script as the endpoint of deposit.
-- For a `withdrawing cell` at input index `i`, the transaction builder should locate the deposit block header, meaning the the header of the original `deposit cell`'s inclusion block. With the deposit block header:
+- For a `withdrawing cell` at input index `i`, the transaction builder should locate the deposit block header, meaning the header of the original `deposit cell`'s inclusion block. With the deposit block header:
     - The deposit block header hash MUST be included in `header_deps`.
     - The index of the deposit block header hash in `header_deps` MUST be put in the type-script-part of the corresponding witness at index `i`, using 64-bit unsigned little-endian integer format. The example below explains data placement in transaction witnesses.
 - For a `withdrawing cell`, the `since` field in the cell input MUST conform to the Nervos DAO's locking period requirement, which is 180 epochs. For example, if one deposits into Nervos DAO at epoch 5, he/she can only expect to withdraw Nervos DAO at epoch 185, 365, 545, etc.