29

src/frontend/src/pages/Chapters/Camel/ChapterFA20Operator/course.md

@@ -10,7 +10,7 @@ In this chapter we will focus on _Operators_ and _Permissions_.
 
 ## Entry points
 
-Token contract implementing the FA2 standard MUST have the following entry points.
+A Token contract implementing the FA2 standard MUST have the following entry points.
 
 ```
 type fa2_entry_points =
@@ -28,18 +28,18 @@ type fa2_entry_points =
 
 #### Definition
 
-_Operator_ can be seen as delegate role.
+An _Operator_ can be seen as a delegate role.
 
-_Operator_ is a Tezos address that initiates token transfer operation on behalf of the owner.
-_Owner_ is a Tezos address which can hold tokens.
+An _Operator_ is a Tezos address that initiates token transfer operation on behalf of the owner.
+An _Owner_ is a Tezos address which can hold tokens.
 An operator, other than the owner, MUST be approved to manage particular token types held by the owner to make a transfer from the owner account.
-Operator relation is not transitive. If C is an operator of B , and if B is an operator of A, C cannot transfer tokens that are owned by A, on behalf of B.
+_Operator_ relation is not transitive. If C is an operator of B , and if B is an operator of A, C cannot transfer tokens that are owned by A, on behalf of B.
 
-an _operator_ is defined as a relationship between two address (owner address and operator address) and can be understood as an operator address who can operate tokens held by a owner.
+An _Operator_ is defined as a relationship between two address (owner address and operator address) and can be understood as an operator address which can operate tokens held by an owner.
 
 #### FA2 interface operator
 
-FA2 interface specifies two entry points to update and inspect operators. Once permitted for the specific token owner, an operator can transfer any tokens belonging to the owner.
+The FA2 interface specifies two entry points to update and inspect operators. Once permitted for the specific token owner, an operator can transfer any tokens belonging to the owner.
 
 ```
 | Update_operators of update_operator_michelson list
@@ -64,15 +64,15 @@ type is_operator_param = {
 }
 ```
 
-<!-- prettier-ignore -->Notice the *update\_operator* can only Add or Remove an _operator_ (an allowance between an operator address and a token owner address).
+<!-- prettier-ignore -->Notice that the *update\_operator* can only Add or Remove an _operator_ (an allowance between an operator address and a token owner address).
 
-<!-- prettier-ignore -->Notice the parameter _is\_operator\_param_ given to *Is\_operator* entry point contains a *callback* property used to send back a response to the calling contract.
+<!-- prettier-ignore -->Notice that the parameter _is\_operator\_param_ given to *Is\_operator* entry point contains a *callback* property used to send back a response to the calling contract.
 
-<!-- prettier-ignore -->Notice entry point *Update\_operators* expectes a list of *update\_operator\_michelson*. The fa2 convertor helper provide the *operator\_param\_to\_michelson* function to convert *operator\_param* format into *update\_operator\_michelson* format.
+<!-- prettier-ignore -->Notice that the entry point *Update\_operators* expects a list of *update\_operator\_michelson*. The FA2 standard provides the *operator\_param\_to\_michelson* function to convert *operator\_param* format into *update\_operator\_michelson* format.
 
 #### FA2 standard operator library
 
-Some helpers functions has been implemented in the FA2 library which help manipulating _operator_. This library contains following functions and type alias :
+Some helper functions has been implemented in the FA2 library which help manipulating _operator_ relationship. This library contains following functions and type alias :
 
 an _operator_ is a relationship between two address (owner address and operator address)
 
@@ -89,16 +89,16 @@ an _operator_ is a relationship between two address (owner address and operator
 Most token standards specify logic that validates a transfer transaction and can either approve or reject a transfer.
 Such logic (called _Permission Policy_) could validate who initiates a transfer, the transfer amount, and who can receive tokens.
 
-This FA2 standard defines a framework to compose and configure such permission policies from the standard behaviors and configuration APIs.
+This FA2 standard defines a framework to compose and configure such permission policies.
 
-FA2 defines :
+The FA2 standard defines :
 
 - the default core transfer behavior, that MUST always be implemented
 - a set of predefined permission policies that are optional
 
 #### Permissions descriptor
 
-<!-- prettier-ignore -->FA2 specifies an interface permissions_descriptor allowing external contracts to discover an FA2 contract's permission policy and to configure it. *permissions\_descriptor* serves as a modular approach to define consistent and non-self-contradictory policies.
+<!-- prettier-ignore -->The FA2 standard specifies an interface permissions_descriptor allowing external contracts to discover an FA2 contract's permission policy and to configure it. *permissions\_descriptor* serves as a modular approach to define consistent and non-self-contradictory policies.
 
 The _permission descriptor_ indicates which standard permission policies are implemented by the FA2 contract and can be used by off-chain and on-chain tools to discover the properties of the particular FA2 contract implementation.
 
@@ -139,7 +139,7 @@ type owner_hook_policy =
 
 #### Custom permission policy
 
-<!-- prettier-ignore -->It is possible to extend permission policy with a custom behavior, which does not overlap with already existing standard policies. This standard does not specify exact types for custom config entry points. FA2 token contract clients that support custom config entry points must know their types a priori and/or use a tag hint of *custom\_permission\_policy*.
+<!-- prettier-ignore -->It is possible to extend a permission policy with a custom behavior, which does not overlap with already existing standard policies. This standard does not specify exact types for custom config entry points. FA2 token contract clients that support custom config entry points must know their types a priori and/or use a tag hint of *custom\_permission\_policy*.
 
 ```
 type custom_permission_policy = {
@@ -176,8 +176,10 @@ Our NFT "token" is almost ready but to allow a new rule. We need Bob to transfer
 
 - Vera account is owner of the token 1
 
-<!-- prettier-ignore -->2- Complete the _ligo dry-run_ command for authorizing Bob to transfer token taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *operator\_update\_to\_michelson* function to convert your parameters into the format expected by *Update\_operators* entry point.
+<!-- prettier-ignore -->2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *operator\_update\_to\_michelson* function to convert your parameters into the format expected by *Update\_operators* entry point.
 
-<!-- prettier-ignore -->3- Complete the _ligo dry-run_ command for simulating the transfer of 1 token from Vera'account to Alice's account, transaction emitted by Bob. The transfered token id is number 1  (token\_id and and amount must be 1). You can use the *transfer\_to\_michelson* function to convert your parameters into the format expected by *Transfer* entry point.
+<!-- prettier-ignore -->3- Complete the _ligo dry-run_ command for simulating the transfer of 1 token from Vera'account to Alice's account, transaction emitted by Bob. The transfered token id is number 1 (token\_id and and amount must be 1). You can use the *transfer\_to\_michelson* function to convert your parameters into the format expected by *Transfer* entry point.
 
-You will have to modify the storage to in the state where "Vera account is owner of the token 1" (step 1) and Bob is authorized to transfer token taken from Vera account (step 2).
+You will have to modify the storage accordingly:
+- "Vera account is owner of the token 1" (step 1)
+- "Bob is authorized to transfer tokens taken from Vera account" (step 2).

src/frontend/src/pages/Chapters/Pascal/ChapterFA20Operator/course.md

@@ -26,18 +26,18 @@ type fa2_entry_points is
 
 #### Definition
 
-_Operator_ can be seen as delegate role.
+An _Operator_ can be seen as a delegate role.
 
-_Operator_ is a Tezos address that initiates token transfer operation on behalf of the owner.
-_Owner_ is a Tezos address which can hold tokens.
+An _Operator_ is a Tezos address that initiates token transfer operation on behalf of the owner.
+An _Owner_ is a Tezos address which can hold tokens.
 An operator, other than the owner, MUST be approved to manage particular token types held by the owner to make a transfer from the owner account.
-Operator relation is not transitive. If C is an operator of B , and if B is an operator of A, C cannot transfer tokens that are owned by A, on behalf of B.
+The Operator relation is not transitive. If C is an operator of B , and if B is an operator of A, C cannot transfer tokens that are owned by A, on behalf of B.
 
-an _operator_ is defined as a relationship between two address (owner address and operator address) and can be understood as an operator address who can operate tokens held by a owner.
+An _operator_ is defined as a relationship between two address (owner address and operator address) and can be understood as an operator address which can operate tokens held by a owner.
 
 #### FA2 interface operator
 
-FA2 interface specifies two entry points to update and inspect operators. Once permitted for the specific token owner, an operator can transfer any tokens belonging to the owner.
+The FA2 interface specifies two entry points to update and inspect operators. Once permitted for the specific token owner, an operator can transfer any tokens belonging to the owner.
 
 ```
 | Update_operators  of update_operator_params
@@ -75,15 +75,15 @@ end
 type is_operator_params is michelson_pair_right_comb(is_operator_params_)
 ```
 
-<!-- prettier-ignore -->Notice the *update\_operator* can only Add or Remove an _operator_ (an allowance between an operator address and a token owner address).
+<!-- prettier-ignore -->Notice that the *update\_operator* can only Add or Remove an _operator_ (an allowance between an operator address and a token owner address).
 
-<!-- prettier-ignore -->Notice the parameter _is\_operator\_params_ given to *Is\_operator* entry point contains a *callback* property used to send back a response to the calling contract.
+<!-- prettier-ignore -->Notice that the parameter _is\_operator\_params_ given to *Is\_operator* entry point contains a *callback* property used to send back a response to the calling contract.
 
-<!-- prettier-ignore -->Notice entry point *Update\_operators* expectes a list of *update\_operator\_param*.
+<!-- prettier-ignore -->Notice that the entry point *Update\_operators* expects a list of *update\_operator\_param*.
 
 #### FA2 standard operator library
 
-Some helpers functions has been implemented in the FA2 library which help manipulating _operator_. This library contains following functions and type alias :
+Some helper functions has been implemented in the FA2 library which help manipulating _operator_ relationship. This library contains following functions and type alias :
 
 an _operator_ is a relationship between two address (owner address and operator address)
 
@@ -96,16 +96,16 @@ an _operator_ is a relationship between two address (owner address and operator
 Most token standards specify logic that validates a transfer transaction and can either approve or reject a transfer.
 Such logic (called _Permission Policy_) could validate who initiates a transfer, the transfer amount, and who can receive tokens.
 
-This FA2 standard defines a framework to compose and configure such permission policies from the standard behaviors and configuration APIs.
+This FA2 standard defines a framework to compose and configure such permission policies.
 
-FA2 defines :
+The FA2 standard defines :
 
 - the default core transfer behavior, that MUST always be implemented
 - a set of predefined permission policies that are optional
 
 #### Permissions descriptor
 
-<!-- prettier-ignore -->FA2 specifies an interface permissions_descriptor allowing external contracts to discover an FA2 contract's permission policy and to configure it. *permissions\_descriptor* serves as a modular approach to define consistent and non-self-contradictory policies.
+<!-- prettier-ignore -->The FA2 standard specifies an interface permissions_descriptor allowing external contracts to discover an FA2 contract's permission policy and to configure it. *permissions\_descriptor* serves as a modular approach to define consistent and non-self-contradictory policies.
 
 The _permission descriptor_ indicates which standard permission policies are implemented by the FA2 contract and can be used by off-chain and on-chain tools to discover the properties of the particular FA2 contract implementation.
 
@@ -163,7 +163,7 @@ type owner_hook_policy =
 
 #### Custom permission policy
 
-<!-- prettier-ignore -->It is possible to extend permission policy with a custom behavior, which does not overlap with already existing standard policies. This standard does not specify exact types for custom config entry points. FA2 token contract clients that support custom config entry points must know their types a priori and/or use a tag hint of *custom\_permission\_policy*.
+<!-- prettier-ignore -->It is possible to extend a permission policy with a custom behavior, which does not overlap with already existing standard policies. This standard does not specify exact types for custom config entry points. FA2 token contract clients that support custom config entry points must know their types a priori and/or use a tag hint of *custom\_permission\_policy*.
 
 ```
 type custom_permission_policy = {
@@ -200,8 +200,10 @@ Our NFT "token" is almost ready but to allow a new rule. We need Bob to transfer
 
 - Vera account is owner of the token 1
 
-<!-- prettier-ignore -->2- Complete the _ligo dry-run_ command for authorizing Bob to transfer token taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Update\_operators* entry point.
+<!-- prettier-ignore -->2- Complete the _ligo dry-run_ command for authorizing Bob to transfer tokens taken from Vera account, transaction emitted by Vera. (reuse the storage you made on step 1). You can use *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Update\_operators* entry point.
 
 <!-- prettier-ignore -->3- Complete the _ligo dry-run_ command for simulating the transfer of 1 token from Vera'account to Alice's account, transaction emitted by Bob. The transfered token id is number 1 (token\_id and and amount must be 1). You can use the *Layout.convert\_to\_right\_comb* function to convert your parameters into the format expected by *Transfer* entry point.
 
-You will have to modify the storage to in the state where "Vera account is owner of the token 1" (step 1) and Bob is authorized to transfer token taken from Vera account (step 2).
+You will have to modify the storage accordingly:
+- "Vera account is owner of the token 1" (step 1)
+- "Bob is authorized to transfer tokens taken from Vera account" (step 2).