update doc and readme #326
Conversation
alex0207s
commented
Aug 5, 2024
alex0207s
commented
- Add Tokenlon Architecture image
- Update Tokenlon documents
- Update README
doc/RFQ.md
Outdated
| - Partial fill : Whether the Offer can be filled partially or not (but once). | ||
| - Contract call : Whether the Offer can be filled by a contract or not. | ||
| - `FLG_ALLOW_CONTRACT_SENDER` : Determines whether the RFQ offer can be filled by a contract. | ||
| - `FLG_ALLOW_PARTIAL_FILL` : Whether a RFQ offer can be filled partially or not (but once). |
There was a problem hiding this comment.
What does (but once) mean here?
There was a problem hiding this comment.
it indicates an RFQ order can be partial filled, but can only be filled once, regardless of any remaining quantity.
There was a problem hiding this comment.
Revised version: Determines whether an RFQ offer can be partially filled. However, each RFQ order can only be filled once, regardless of whether it's fully or partially filled.
doc/RFQ.md
Outdated
| - Contract call : Whether the Offer can be filled by a contract or not. | ||
| - `FLG_ALLOW_CONTRACT_SENDER` : Determines whether the RFQ offer can be filled by a contract. | ||
| - `FLG_ALLOW_PARTIAL_FILL` : Whether a RFQ offer can be filled partially or not (but once). | ||
| - `FLG_MAKER_RECEIVES_WETH` : Specifies whether a market maker is willing to receive WETH from a RFQ offer. |
There was a problem hiding this comment.
| - `FLG_MAKER_RECEIVES_WETH` : Specifies whether a market maker is willing to receive WETH from a RFQ offer. | |
| - `FLG_MAKER_RECEIVES_WETH` : Specifies whether a market maker wants the RFQ contract to wrap the ETH he received into WETH for him. |
doc/TokenCollector.md
Outdated
| @@ -1,6 +1,8 @@ | |||
| # TokenCollector | |||
|
|
|||
| In Tokenlon V6, multiple schemes of token approval is supported. TokenCollector is an abstract contract that handles different ways of token transfering. When interacting with Tokenlon, user can choose one of supported approving scheme and prepare the corresponded Tokenlon permit parameter (in bytes). The first byte of the permit indicate the type and the rest are encoded data with type specific structure. | |||
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |||
There was a problem hiding this comment.
... allowing flexibility in interacting with Tokenlon and other token standards
What does this mean?
There was a problem hiding this comment.
This means:
-
Tokenlon uses TokenCollector to collect user's tokens.
-
It supports multiple schemes to interact with various token types.
This flexibility allows TokenCollector to handle different token standards and transfer methods efficiently.
There was a problem hiding this comment.
The flexibility is used to describe "TokenCollector" however "users" are the ones "interacting with" Tokenlon so it's better to differentiate them in your sentence. For example:
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, giving users flexibility when interacting with Tokenlon and other token standards. |
Or
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer across different token standards. Users have great flexibility in token authorization when interacting with Tokenlon. |
There was a problem hiding this comment.
Also it seems TokenCollector should be a base contract instead of an abstract contract as it does not have any virtual functions.
There was a problem hiding this comment.
It simply describes that we actually define TokenCollector as an abstract contract.
doc/TokenCollector.md
Outdated
| @@ -1,6 +1,8 @@ | |||
| # TokenCollector | |||
|
|
|||
| In Tokenlon V6, multiple schemes of token approval is supported. TokenCollector is an abstract contract that handles different ways of token transfering. When interacting with Tokenlon, user can choose one of supported approving scheme and prepare the corresponded Tokenlon permit parameter (in bytes). The first byte of the permit indicate the type and the rest are encoded data with type specific structure. | |||
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |||
There was a problem hiding this comment.
The flexibility is used to describe "TokenCollector" however "users" are the ones "interacting with" Tokenlon so it's better to differentiate them in your sentence. For example:
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, giving users flexibility when interacting with Tokenlon and other token standards. |
Or
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer across different token standards. Users have great flexibility in token authorization when interacting with Tokenlon. |
doc/TokenCollector.md
Outdated
| @@ -1,6 +1,8 @@ | |||
| # TokenCollector | |||
|
|
|||
| In Tokenlon V6, multiple schemes of token approval is supported. TokenCollector is an abstract contract that handles different ways of token transfering. When interacting with Tokenlon, user can choose one of supported approving scheme and prepare the corresponded Tokenlon permit parameter (in bytes). The first byte of the permit indicate the type and the rest are encoded data with type specific structure. | |||
| `TokenCollector` is an abstract contract designed to handle various token collection mechanisms. It supports different methods of token transfer, allowing flexibility in interacting with Tokenlon and other token standards. | |||
There was a problem hiding this comment.
Also it seems TokenCollector should be a base contract instead of an abstract contract as it does not have any virtual functions.
