-
Notifications
You must be signed in to change notification settings - Fork 24
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
9 changed files
with
40 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
# AllowanceTarget | ||
|
||
The AllowanceTarget contract manages token allowances and authorizes specific spenders to transfer tokens on behalf of users. | ||
|
||
## Security Considerations | ||
|
||
AllowanceTarget provides a pause mechanism to prevent unexpected situations. Only the contract owner can pause or unpause the contract. In most cases, the contract will not be paused. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,3 @@ | ||
# CoordinatedTaker | ||
|
||
CoordinatedTaker is a conditional taker contract of LimitOrderSwap. It adds a fill permission design on the top of it. A permission of fill is issued by a coordinator with signature. If a user wants to fill an order, he needs to apply for the fill permission and submit the fill with it. The coordinator will manage the avaliable amount of each orders and only issue fill permission when the pending avaliable amount is enough. It helps avoiding fill collision and makes off-chain order canceling possible. | ||
CoordinatedTaker is a conditional taker contract of LimitOrderSwap. It adds a fill permission design on the top of it. A permission of fill is issued by a coordinator with signature. If a user wants to fill an order, he needs to apply for the fill permission and submit the fill with it. The coordinator will manage the available amount of each orders and only issue fill permission when the pending available amount is enough. It helps avoiding fill collision and makes off-chain order canceling possible. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,11 @@ | ||
# GenericSwap | ||
|
||
GenericSwap is a general token swapping contract that integrate with different strategy executors. The GS contract is responsible for ensuring the result of a swap is match the order. However, the actual swap is executed by a strategy executor. This design allows fulfilling an order with any combination of swapping protocols. Also, by adjusting payload in off-chain system, it may support new protocol without upgrading contracts. | ||
GenericSwap is a general token swapping contract designed to integrate with various strategy executors (e.g. the `SmartOrderSwap` contract). The GenericSwap contract is responsible for ensuring a result of a swap is match the order. However, the actual swap is executed by a strategy executor. This design allows fulfilling an order with any combination of swapping protocols. Also, by adjusting payload in our off-chain system, it may support new protocol without upgrading contracts. | ||
|
||
## Gas Saving Technical | ||
|
||
GenericSwap retains 1 wei of the maker token at the end of each swap transaction. This practice avoids repeatedly clearing the token balance to zero, as the EVM charges different gas fees for various storage states. By preventing frequent resets to zero, this approach effectively reduces gas consumption. | ||
|
||
## Relayer | ||
|
||
GS supports submitting a swap by a relayer with user signature. The hash of relayed swap should be recoreded to prevent replay attack. | ||
The GenericSwap contract allows for trade submissions by a relayer with user's signatures. To prevent replay attacks, the hash of the relayed trade is recorded. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,18 +1,26 @@ | ||
# RFQ | ||
|
||
RFQ (Request For Quote) is a contract that settles a trade between two parties. Normally it requires an off-chain quoting system which provides quotes and signatures from certain makers. A user may request for a quote of a specific trading pair and size. Upon receiving the request, any maker willing to trade can respond with a quote to the user. If the user accepts it, then both parties will sign the trading order and submit the order with signatures to the RFQ contract. After verifying signatures, the RFQ contract will transfer tokens between user and maker accordingly. | ||
The RFQ (Request For Quote) contract facilitates the settlement of trades between two parties: a market maker and an user. We provide an off-chain quoting system that handles the quoting process. Users can request quotes for specific trading pairs and sizes. Upon receiving a request, any interested maker can provide a quote to the user. If the user accepts the quote, both parties will sign the trading order and submit it ot the RFQ contract along with their signatures. The RFQ contract verifies the signatures and executes the token transfers between the user and the market maker. | ||
|
||
## Order option flags | ||
|
||
There are two options that the maker of a RFQ offer can set. The option flags is a uint256 field in the offer. | ||
The maker of an RFQ offer can specify certain options using a `uint256` field in the offer, referred to as option flags: | ||
|
||
- 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). | ||
- `FLG_MAKER_RECEIVES_WETH` : Specifies whether a market maker is willing to receive WETH from a RFQ offer. | ||
|
||
## Relayer | ||
|
||
RFQ supports submitting a trade by a relayer with user signature. The hash of relayed trade should be recoreded to prevent replay attack. | ||
The RFQ contract allows for trade submissions by a relayer with user's signatures. To prevent replay attacks, the hash of the relayed trade is recorded. | ||
|
||
## Fee | ||
|
||
Some portion of maker asset of an order will be deducted as protocol fee. The fee will be transfered to `feeCollector` during the settlement. Each order may have different fee factor, it depends on the characteristic of an order. | ||
A portion of the maker's asset in the order will be deducted as a protocol fee. This fee is transferred to the feeCollector during settlement. | ||
|
||
The fee factor is composed of two parts: | ||
|
||
1. Protocol Fee | ||
2. Gas Fee | ||
|
||
If a relayer submits the trade on-chain, the gas fee will be adjusted according to the on-chain conditions at the time of the transaction. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,7 @@ | ||
# SmartOrderStrategy | ||
|
||
SmartOrderStrategy is a strategy executor of a generic swap. It should be called by GenericSwap contract and preform any swaps according to provided payload. This contract should not has any balance or token approval since it could perform any arbitary calls. Also the `executeStrategy` function is only allowed to be called by GenericSwap contract. | ||
SmartOrderStrategy is a strategy executor of a generic swap. It is designed to be called by the `GenericSwap contract` and performs swaps according to the provided payload. This contract should not hold any significant token balance or require token approvals, as it can execute arbitrary calls. Additionally, the `executeStrategy` function is restricted to being called only by the GenericSwap contract. | ||
|
||
## Gas Saving Technical | ||
|
||
SmartOrderStrategy retains 1 wei of the maker token at the end of each swap transaction. This practice avoids repeatedly clearing the token balance to zero, as the EVM charges different gas fees for various storage states. By preventing frequent resets to zero, this approach effectively reduces gas consumption. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters