SYMMIO v0.83 Update Contest
The novel derivatives Peer2Peer clearing infra, enabling LPs to provide synthetic leveraged exposure to any asset.
Details
Scope
Contest Results
On what chains are the smart contracts going to be deployed?
All EVM compatible chains
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
Only whitelisted tokens can work with the codebase, and these include large market cap stablecoins such as USDC, USDT, and USDE.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
No
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
For permissioned functions, please list all checks and requirements that will be made before calling the function.
There is a multisig behind those functions and a couple of team members will review that call before executing it.
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
The Diamond Standard (EIP-2535)
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
There is a Muon oracle that provides data such as the uPnL of parties' positions.
Are there any hardcoded values that you intend to change before (some) deployments?
No
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
Currently, we have not implemented specific measures for handling sequencer issues in our L2 deployment. We recognize the importance of this and will prioritize developing a robust contingency plan, including fallback mechanisms and monitoring systems, to ensure protocol reliability and user security.
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
Yes, report potential issues, including broken assumptions about function behavior, if they pose future integration risks. Key properties that should hold include correctness (accurate returns), security (resistant to manipulation), consistency (uniform behavior on-chain and off-chain), and reliability (functioning correctly under all conditions).
Correctness:
The function should return accurate and expected results based on its inputs and documented behavior. For example, if a read function is expected to return the current balance of an account, it should not return a cached or stale value.
Security:
The function should be resistant to manipulation and unauthorized access. It should not expose any vulnerabilities that could be exploited to return false or misleading information.
Consistency:
The function should behave uniformly across different environments (Different chains for example).
Reliability:
The function should function correctly under all conditions, including edge cases and unexpected inputs. For example, a function that reads from a data structure should handle cases where the requested data does not exist and return a predefined error or null value.
Low severity issues falling in these categories would not be valid and issues falling in these categories would be valid only for future integrations of other protocols with Symm.
Please discuss any design choices you made.
In the liquidation system, we allow liquidators to liquidate a user if they were insolvent before. The nonce should not be changed from that time (essentially, the user's positions should remain unchanged during this period). If the user adds funds to become solvent, the liquidator can still liquidate the user and return the extra funds.
Please list any known issues and explicitly state the acceptable risks for each known issue.
Any risk is acceptable
We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
The liquidation functionality should not be inaccessible for more than 2 hours.
Please provide links to previous audits (if any).
We had three audits before, two of which were with Sherlock and one with "Smart State." You can find the details at the following link:
https://docs.symm.io/legal-and-brand-and-security/security-audits-bugbounty/audits
Please list any relevant protocol resources.
You can find all the docs we have at the following link:
https://docs.symm.io
Additional audit information.
In this document, you can see the changes from the previous version that was audited by Sherlock.
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
17,000 USDC
9,000 USDC
700 USDC
800 USDC
Status
Scope
Start Time
End Time
Judging Rules
