sherlock-audit / 2023-08-symmetrical

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Symmetrical Update contest details

Q&A

Q: On what chains are the smart contracts going to be deployed?

Arbitrum One, Arbitrum Nova, Fantom, Optimism, BNB chain, Polygon, Avalanche, Base


Q: Which ERC20 tokens do you expect will interact with the smart contracts?

USDT and USDC


Q: Which ERC721 tokens do you expect will interact with the smart contracts?

none


Q: Which ERC777 tokens do you expect will interact with the smart contracts?

none


Q: Are there any FEE-ON-TRANSFER tokens interacting with the smart contracts?

none


Q: Are there any REBASING tokens interacting with the smart contracts?

none


Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?

TRUSTED


Q: Is the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?

TRUSTED


Q: Are there any additional protocol roles? If yes, please explain in detail:

MUON_SETTER_ROLE: Can change settings of the Muon Oracle. SYMBOL_MANAGER_ROLE: Can add, edit, and remove markets, as well as change market settings like fees and minimum acceptable position size. PAUSER_ROLE: Can pause all system operations. UNPAUSER_ROLE: Can unpause all system operations. PARTY_B_MANAGER_ROLE: Can add new partyBs to the system. LIQUIDATOR_ROLE: Can liquidate users. SETTER_ROLE: Can change main system settings. Note: All roles are trusted except for LIQUIDATOR_ROLE.


Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?

ERC-2535: Diamonds, Multi-Facet Proxy
Create modular smart contract systems that can be extended after deployment.


Q: Please list any known issues/acceptable risks that should not result in a valid finding.

There are some already found issues here in the previous contest

https://github.com/sherlock-audit/2023-06-symmetrical-judging


Q: Please provide links to previous audits (if any).

https://github.com/sherlock-audit/2023-06-symmetrical-judging


Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, input validation expectations, etc)?

Liquidator Bots, Force close Bots, Force cancel Bots, Anomaly detector Bots


Q: In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

1- Collateral tokens, which are stablecoins, we accept the risks.

2- The potential for the Muon app to be down or give inaccurate data is also considered acceptable.


Q: Do you expect to use any of the following tokens with non-standard behaviour with the smart contracts?

Yes... USDC and USDT can be used as collateral


Q: Add links to relevant protocol resources

https://docs.symm.io/protocol-overview/general-information

https://docs.symm.io/building-on-symm-io/technical-documentation


Additional context into the update contest:

In the ever-evolving landscape of software development, continuous improvement is key. Our team has recently completed the first part of the Sherlock Audit contest for our project, and several important changes have been made to enhance functionality, improve security, and fix bugs. Below is a comprehensive list of commits, each accompanied by a brief explanation to provide context for the updates.

Commit List and Explanations

  1. Allowing PartyBs to Deregister

    • This update allows partyBs to deregister from the system, offering greater flexibility in user participation. GitHub Commit
  2. Check for Zero Address in PartyB Registering

    • This change adds a validation check to prevent registration of a zero address as partyB. GitHub Commit
  3. Fix the Pending Locked Balance of PartyB When Position is Opened Partially

    • This update corrects the pending locked balance of partyB when a position is opened partially. Specifically, all pending locked amounts of the quote should have been released. GitHub Commit
  4. Fix the Bug that the PartyA Nonce Was Incremented Before Setting the PartyB Field on Quote

    • This change addresses a bug where the nonce for partyA was incremented before setting the partyB field on the quote. GitHub Commit
  5. Check Symbol's Validness Before Opening the Position

    • This update adds a check to validate the trading symbol before opening a position. GitHub Commit
  6. Bug in Liquidation Process Allowing Reuse of Old Signatures

    • This change fixes a bug in the liquidation process that allowed users to use old signatures, possibly from previous liquidations, more than once. GitHub Commit
  7. Change in Trading Fee Process

    • This update modifies the process of collecting trading fees. Specifically, it prevents the fee collector from withdrawing collected fees when the respective positions are not yet opened. The trading fee is now subtracted from the allocated balance of the user and handed over to the fee collector when the position opens. GitHub Commit
  8. Fix the Bug that Expired Signatures Can Be Used in Liquidating PartyB

    • This change corrects a bug that allowed expired signatures to be used in the liquidation process for partyB. GitHub Commit
  9. Trading Fee Could Have Changed While the Quote is Pending

    • This update addresses an issue where the trading fee could change while a quote is pending but not yet opened. This could result in a loss or profit for the user. Now, the trading fee that the quote is sent with is stored in the quote structure itself. Additionally, trading fees of pending quotes are returned to the user when the quote gets liquidated. GitHub Commit
  10. Bug with Decimals in depositAndAllocateForPartyB Method

    • This change resolves a bug related to decimal handling in the depositAndAllocateForPartyB method. It also removes the redundant depositForPartyB method. GitHub Commit
  11. PartyB Should Not Deallocate or Transfer During Unfinished Liquidation

    • This update prevents partyB from deallocating or transferring its allocated collateral when the user is liquidated but their liquidation process is not yet complete. This is because partyB may still owe money to the user. GitHub Commit
  12. Muon Signatures Share the Same Set of Fields

    • To address the issue of muon signatures sharing the same set of fields, this change adds the name itself to the hash to make each signature unique. GitHub Commit
  13. Problem with PartyB Postponing Force Close

    • This update fixes a problem where partyB could delay a force close by closing a small part of the request and updating the modifyTimestamp field. The field name is now changed to statusModifyTimestamp and, as the name suggests, it only changes when the quote status changes. GitHub Commit
  14. Post-Solvency Check Issue in Open Position Function

    • This commit addresses an issue with the post-solvency check in the openPosition function. The problem was that after the check we were updating its corresponding locked values so the checking wasn't valid (The provided solution in this commit has some problems that the locked values of quote were considered twice... It got fixed in another commit later: 33rd item) GitHub Commit
  15. Upnl Signature Reusability in Liquidation

    • This update fixes a problem where the Upnl signature of liquidation could be reused in other functions. To prevent this, the partyA nonce, which is a part of the signature in liquidation, is incremented. GitHub Commit
  16. Review of Nonce Increases in Code

    • This change involves a comprehensive review of all places in the code where nonces are increased. Unnecessary nonce increments were removed, and missing ones were added. GitHub Commit
  17. Emergency Close Functionality for ClosePending Positions

    • This update fixes an issue where ClosePending positions were not allowed in the emergencyClose function. The absence of this feature could be abused by partyA to prevent their positions from being emergency closed by partyB. GitHub Commit
  18. Mistake in ForceClose Method

    • This commit corrects a mistake in the ForceClose method where the quote was being closed by its requestedClosePrice instead of the actual price that comes from the signature. GitHub Commit
  19. Check for Token Decimals in SetCollateral Method

    • This update adds a check to ensure that token decimals in the SetCollateral method are not greater than 18, as the rest of the code expects them to be that way. GitHub Commit
  20. Update Locked Values for Market Orders When Position Opens

    • This commit ensures that locked values for market orders are also updated when a position is opened, maintaining the integrity of the trading system. GitHub Commit
  21. Remove Solvency Check During Position Close Request

    • This update removes the solvency check for users when they request to close their positions. The rationale is that the user's solvency state may change by the time partyB wants to fill the close request. GitHub Commit
  22. Revision of PartyA Liquidation Process

    • This change addresses several issues in the liquidation process for partyA. One problem was that if a user becomes solvent after the first liquidation step, there would be leftover money that didn't belong to anyone. To fix this, the process now requires the same signatures in both the first and second steps. Another issue was that pending positions were changed to 'LIQUIDATED' status during liquidation, which was unclear for third-party services. This has been changed to 'CANCELLED' status for better clarity. GitHub Commit
  23. Introduction of Funding Rate Feature

  24. Prevent Suspended PartyAs from Opening Positions

    • This update prevents partyAs that are suspended from opening new positions. GitHub Commit
  25. Handling Insufficient Funds for PartyB

    • This commit addresses a scenario where partyB may not have enough money to fully pay partyA. This could happen when partyB is also liquidatable but has not yet been liquidated by the liquidator. In such cases, partyA might not receive their full profits. GitHub Commit
  26. Additional Checks for Small Calculation Errors in Closing Quote

    • This update adds some extra checks to account for possible but very small calculation errors that could occur when closing a quote. GitHub Commit
  27. Ensure No Old Collateral Is Left When Changing Collateral Token

    • This change adds an additional check to ensure that no old collateral is left on the contract when changing the collateral token. GitHub Commit
  28. Check for Minimum Quote Value in OpenPosition Method

    • This update adds checks in the openPosition method to ensure that the quote value doesn't fall below the minimum acceptable amount due to price changes. GitHub Commit
  29. Setting Max Leverage for Symbols on the Contract

    • This commit allows for the setting of maximum leverage for trading symbols directly on the contract. GitHub Commit
  30. Restrictions on PartyB in Emergency Mode

    • This update prevents a partyB that is in emergency mode from opening a new position. This is because they could abuse this state to close positions at will and take profits. As the name suggests, emergency mode is extremely rare and only intended for genuine emergencies. GitHub Commit
  31. Multi-Account and Proxy Contract Features

    • This commit adds a multi-account feature, allowing users to have multiple accounts linked to the same wallet. This enables users to simulate isolated trading modes. Additionally, partyB can now use multiple wallets but still appear in the system under a single address, thanks to a proxy contract known as the SymmioPartyB contract. GitHub Commit 1 GitHub Commit 2
  32. Check for Expired Signatures in LiquidatePartyA Method

    • This update adds a check to prevent the use of expired signatures in the LiquidatePartyA method. GitHub Commit
  33. Issue with Double-Counting Locked Values in Post-Solvency Check

    • This commit resolves an issue in the post-solvency check performed when opening a position. Specifically, the locked values of the opening position were being double-counted in the calculations. GitHub Commit
  34. Optimization of PartyB Contract Size for Deployment

    • This change addresses a problem where the PartyB contract was too large for deployment. One of its methods has been extracted to another library to resolve this issue. GitHub Commit

Audit scope

symmio-core @ 0dec905617d3c6355ce4393de3e77274b90e2eb4

About


Languages

Language:TypeScript 46.8%Language:Solidity 45.1%Language:JavaScript 7.2%Language:Shell 0.5%Language:Dockerfile 0.2%Language:Python 0.2%