SYMMIO May (2024) — Developer Updates
Highlights: Version 0.83: Audit begins, Instant Trading Public Testnet & $SYMM TGE preparations have started.
Version 0.83 is ready to enter the auditing phase, slightly delayed due to the addition of features requested by our solvers. Solver requests are our top priority to ensure an optimal user experience.
These new features, carefully designed with your needs in mind, enhance solver interaction and functionality. The auditing and staging process is expected to take 2–3 months, though delays may occur. We appreciate your patience as we maintain our commitment to quality and security, and we’re excited for you to experience the enhanced user experience these features will bring.
Instant Trading: Internal Tests Completed, Alpha Testing Imminent
The internal tests for our most significant feature, Instant Trading (Full Access), have been successfully concluded. We are preparing to move this upgrade to alpha testing with selected frontends and their beta testers.
This feature will be available on public testnet via cloverfield, (Update on 31st May Instant Closing is already on public testnet via cloverfield and is currentlybeing tested by a handful of selected Symmians, the time for frontends to implement it on their end is currently still TBD). Key improvements include reducing trade execution and price lock times to under 1000ms, with on-chain settlement taking 5–30 seconds, depending on the chain. Prices are locked in after 600–800ms, enabling scalp trading on SYMMIO for the first time. Previously, price lock-in took 20–60 seconds. This enhancement represents a 50–100x improvement in price lock-in time.
This also greatly improves the feedback loop for traders. Instead of waiting 20–60 seconds or even minutes for a solver response, users will now receive confirmation in less than 1 second. This upgrade also drastically improves the user experience, positioning SYMMIO as the first truly decentralized derivatives trading infrastructure with the responsiveness of a centralized exchange.
$SYMM technical implementation preparations have begun
Subsequently to all the infrastructure upgrades, the SYMMIO core team has started to scope and design the token implementations, an additional blog post is currently being prepared where the features and timelines for the $SYMM token will be outlined.
Version 0.83: Features recap
Some of the v0.83 features could be repetitive with the last developer updates, but for completenes of contents we have outlined them again in detail, this is the full list of final upgrades which are being prepared to go into audit in the coming weeks:
1. Internal Transfers
Version 0.83 introduces internal transfers without the previous 12-hour cooldown period. Users can now transfer funds within SYMMIO’s “L3” to other users or subaccounts instantly, enhancing liquidity and operational efficiency.
2. Internal Bridge Transfers
A new transfer type has been developed for third-party bridges. IntentX is already working on a solution to allow users to withdraw from SYMMIO without waiting for the 12-hour window. This bridge transfer includes a unique transaction ID, enabling bridge providers to manage and suspend users involved in suspicious activities, such as force close abuse or double spending.
3. FrontendAddress in sendQuote
To simplify the fee distribution pattern, the frontendAddress parameter has been added to the sendQuote function. As SYMMIO expands beyond its initial design with meta frontends and serviced frontends, this change reduces management overhead and streamlines fee distribution.
4. Resolved Liquidation Frontrunning Issue
A significant issue allowing users to escape liquidation by topping up their margin, even when already liquidated offchain, has been resolved. The new liquidation system ensures that if a user adds margin during offchain liquidation, the liquidation can proceed, and the newly added margin will be returned to the user. This fix prevents interruptions in solver services, maintaining the integrity and reliability of the system.
5. Removal of User-Initiated Nonce Incrementation
In Version 0.83, users can no longer increment their nonces without solver confirmation (except for force close operations). This change significantly enhances operational stability, allowing solvers to be 99% certain that user nonces remain unchanged. This stability is crucial for the instant-trading update.
6. Improved Force Close Mechanism
The force close mechanism has been significantly improved to address previous limitations. The existing system was susceptible to being gamed by users, as it relied on certain price movements after setting a limit order, potentially leading to denial of service (DOS) for solvers. The new force close system now uses the average of the 1-minute candle around the closing request, ensuring the most favorable price for the user within that timeframe without making the system exploitable.
Function Documentation: Force Close Mechanism
Overview
The force close mechanism is designed to enable users to close their positions if certain market conditions are met, based on a range of parameters. This mechanism comes into play when a hedger does not fill a close order at the specified price. It allows users to force close their position under specific conditions, applying penalties and ensuring fairness for both parties involved.
Force Close Parameters
startTime: Start time of the price range.
endTime: End time of the price range.
highest: Highest price within the range.
lowest: Lowest price within the range.
averagePrice: Volume-weighted mean price in the range.
forceCloseFirstCooldown: Time allowed for Party B to respond to a close order event and place their order on the broker.
forceCloseSecondCooldown: Time allowed for Party B to send a fillCloseOrder() transaction on-chain.
forceCloseGapRatio: The price gap allowed for Party B to charge on top of the oracle (Binance) price.
forceClosePricePenalty: Penalty imposed on Party B if the user force closes the position.
forceCloseMinSigPeriod: Minimum range time required if using the average price as the closing price for the position.
Force Close Conditions
startTime must be greater than the time of the user’s limit order plus forceCloseFirstCooldown.
endTime must be less than the current timestamp minus forceCloseSecondCooldown.
For long positions, the highest price should exceed the limit order price plus forceCloseGapRatio. For short positions, the lowest price should be below the limit order price minus forceCloseGapRatio.
Closing Price Determination
The closing price for a position is set to the limit order price plus forceClosePricePenalty for long positions and minus forceClosePricePenalty for short positions.
If the close order price set by the user is lower than the market price, potentially harming the user, the averagePrice in the range is used. This is contingent on the range duration being more than forceCloseMinSigPeriod.
Revert Scenarios
The function reverts if force closing the position at this price would render Party A insolvent.
If force closing the position would render Party B insolvent, Party B is automatically liquidated as part of the force close mechanism.Additional Information
Any party can obtain a signature from Muon to force close a position if all conditions are met.
The function handles different scenarios, ensuring that the force close process is fair and does not unduly disadvantage any party.
This documentation provides a comprehensive overview of the force close function, ensuring clarity in its operation and conditions.Two scenarios where the new force close may still encounter issues include:
1. Muon being down. 2. Binance or other API providers for Muon being down.
TL:DR The new force close has a minimum timeframe of 2 minutes due to the use of 1-minute candles and a required 1-minute cooldown. Future updates aim to reduce this minimum time by implementing alternative methods for retrieving prices over timestamps. Additionally, the updated force close mechanism includes a fix for scenarios where the solver becomes liquidatable, ensuring that force close operations can proceed effectively alongside user liquidation.
7. Upgraded Force Close Gap Mechanism
Version 0.83 introduces an upgrade to the ForceCloseGap mechanism, which now operates on a per-symbol basis. This enhancement allows solvers greater flexibility in setting their fees for different symbols without opening the potential for users to abuse the ForceCloseGap. The ForceCloseGap is essential because it enables solvers to charge a spread, ensuring profitability and preventing potential attacks on solvers by users.
In Version 0.82, the Force Close Spread was global, exposing solvers to risks when charging different spreads across various markets. By making the Force Close Spread specific to each symbol, Version 0.83 mitigates this risk, although it does not yet address the issue of having gaps per solver per symbol. This will be resolved in Version 0.9. In the meantime, an immediate hotfix available to solvers is to use isolated diamonds for each of them, providing a temporary solution to manage spreads more effectively.
8. Emergency Mode per Symbol
Version 0.83 introduces an emergency mode per symbol, enabling solvers to close markets that are being delisted at their brokers or hedging venues. In Version 0.82, only a global emergency mode was available, allowing solvers to close all their trades simultaneously. While the global emergency mode remains in place for complete system failures, the new symbol-specific emergency mode provides a more targeted approach.
This feature is activated by the SYMMIO team when an asset is delisted by brokers. Future updates will handle these emergency markets using an oracle or through Eigenlayer AVS, ensuring a more flexible and responsive system for solvers in managing delistings and other market-specific emergencies.
Additional planned upgrades Outside of v0.83 Contract Changes
In addition to the v0.83 contract features, several small but significant upgrades are planned for the MUON APPs and solver-operated Shield Nodes.
Planned MUON App Upgrades:
- Archive Nodes Integration:
- The MUON APP and RPCs will be upgraded to archive nodes to accurately determine allocated balances by block, supporting the new and improved liquidation processes.
- Timestamp-Based Price Retrieval:
- Upgrades will enable MUON to retrieve prices based on a timestamp range, further enhancing the efficiency and accuracy of liquidations.
