Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/operator restrictions #4

Open
wants to merge 47 commits into
base: feat/generic-sanity-checks
Choose a base branch
from

Conversation

0xhammadghazi
Copy link
Contributor

Stubs implemented:

  1. Only operator restriction.
  2. Order-specific sanity checks.
  3. Verify signatures.
  4. Call pre-interaction hook.
  5. Transfer funds from the maker to the vault.
  6. Call facilitator interaction.
  7. Ensure the facilitator is respecting the maker's limit price.
  8. Transfer funds from the vault to the recipient.
  9. Call post-interaction hook.
  10. Log events.

Hammad Ghazi added 30 commits October 11, 2023 17:34
Removed 'signature' member from 'Order' struct as it's essentially a message that users will sign. Having signature in the message makes the contract susceptible to signature malleability attacks.
implemented vault contract to facilitate asset transfers between the maker and the vault.
integrated vault contract for asset transfers from the maker's address to the vault contract in AdvancedOrderEngine contract. Imported vault contract and invoked its _receiveAsset function for funds transfer
Added a validation check to ensure that maker receives an amount equal to or more than requested
removed the 'facilitatorInteractionTargetContract' var from the 'fillOrders' fn param. Facilitator is now expected to provide the target contract address within the 'facilitatorInteractionCallData' param. Also removed the facilitator target contract address check
@0xhammadghazi 0xhammadghazi requested review from gul-hameed, 0xabdullah0 and imxm and removed request for gul-hameed and 0xabdullah0 October 16, 2023 20:59
bytes32 public constant ORDER_TYPE_HASH =
keccak256(
"Order("
"uint256 nonce,"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use smaller datatype for nonce ?
@0xhammadghazi

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm considering this. Actually, we can consider using smaller types for the following variables: nonce, validTill, sellTokenAmount, buyTokenAmount, and feeAmounts

@gul-hameed gul-hameed requested review from gul-hameed and removed request for imxm October 17, 2023 10:31
@@ -33,6 +31,13 @@ contract AdvancedOrderEngine is Vault, EIP712 {
string memory version
) EIP712(name, version) {}

modifier onlyOperator() {
if (!isOperator[msg.sender]) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xhammadghazi Refactor a modifier to call a local function instead of directly having the code in the modifier, saving bytecode size and thereby deployment cost Ref

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Acknowledged. The bytecode of the function modifier is duplicated/copied to each method, but we are currently using onlyOperator in only one function. Therefore, it won't make any difference at the moment, but yes, it's a good point to consider during the gas optimization phase.

@BlockApex BlockApex deleted a comment from gul-hameed Oct 17, 2023
@BlockApex BlockApex deleted a comment from gul-hameed Oct 17, 2023
@BlockApex BlockApex deleted a comment from gul-hameed Oct 17, 2023
// STUB: PARTIAL FILL FEATURE //

// TBD: debatable, can take signing scheme in order schema or can verify like 1inch
if (order.isContract()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make seperate function for processing orders from contract or account like 1inch is doing , better for readibility..
https://github.com/1inch/limit-order-protocol/blob/master/contracts/OrderMixin.sol#L222C15-L222C15

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I will take it into consideration.

}

// STUB: VERIFY PREDICATES //

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xhammadghazi Will there be any more checks related to predicates ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure yet, I will work on the predicates section tomorrow, so only then can I tell.

isOperator[_address] = _access;

emit OperatorAccessModified(_address, _access);
}

/**
* @notice Fills multiple orders by processing the specified orders and clearing prices.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xhammadghazi
The natspec for signatures seems missing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

acknowledged

@@ -34,30 +88,137 @@ contract AdvancedOrderEngine {
}

// Revert if the length of the orders array does not match the clearing prices array.
if (orders.length != clearingPrices.length) {
revert ArraysLengthMismatch(orders.length, clearingPrices.length);
if (orders.length != offeredAmounts.length) {
Copy link
Contributor

@gul-hameed gul-hameed Oct 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xhammadghazi
do you think that we also check that signatures.length matches orders.length?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes indeed

@gul-hameed
Copy link
Contributor

@HareemSaad

According to this PR I've gone through the Slither report and here's what stands out:
slither.md

  • Calls-Loop in fillOrders: We've got external calls inside a loop which can hike up gas costs and might open doors for reentrancy bugs. How about we try simulating the orders before going all in? This could give us a better handle on what's executable.

  • Cyclomatic-Complexity: Our fillOrders function is a bit complex, which could make it tricky to manage and test. Maybe breaking it down could help? Like pulling out the signature verification into its own thing could simplify stuff a lot.

Once we tackle these and any other points you spot in the PR, we should be good to merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants