4. Product

Table of Content

1. Roadmap Development Process
2. Decentralized Deployment
3. Asset Listing Process
4. Synth Swap
5. Socket Plugin
6. Smart Margin v2.0.0
7. Risk Protection Fund
8. Referral Program
9. Kwenta deployment on new chains

Roadmap Development Process

Any time a new council is voted in, it will be the responsibility of the Kwenta Council, in collaboration with Management Contributors, Core Contributors, and adminDAO to establish a refreshed roadmap. The roadmap will need to pass a feasibility check by all Core Contributors (CCs) where consensus is reached amongst CCs that they are comfortable with the scope of work and direction. If the roadmap does not receive majority support within the Kwenta Council or amongst CCs, the roadmap will need to be adjusted until it passes both checks.

Once the roadmap is approved, the Core Contributors will work to establish a delivery schedule reflective of the roadmap. As new KIPs are introduced, the CCs will be tasked with updating the delivery schedule to accommodate for the newly passed KIPs.

Milestones on the roadmap will include budgets of KWENTA bonuses for the adminDAO to distribute according to the involvement of relevant Contributors if the milestones are completed. The milestone bonuses are not bound by the dates they are scheduled for as there will inevitably be delays; additionally incentivizing early completion will drive timely development. The treasuryDAO will send the KWENTA to the adminDAO upon confirmed completion of a given milestone. It will be the responsibility of the Kwenta Council to confirm once a milestone has been reached. It will be the responsibility of the Management Contributors to define what qualifies as a completed milestone. It will be the responsibility of the treasuryDAO to determine a given epoch roadmap's milestone rewards budget.

Decentralized Deployment

The Kwenta frontend source code and Kwenta State Log (KSL) are hosted both on GitHub and distributed through a decentralized code collaboration network called Radicle. The elected Kwenta Council votes on the repositories it officially endorses. The Kwenta Council and Core Contributors manage a multisig which requires 2/6 votes, 5 of which are held by Kwenta Council members and 1 of which is held by the Core Contributors (any Core Contributor).

Frontend

Transaction-based execution directs which version of the code the official Kwenta ENS is pointing to on IPFS. This official version of Kwenta can be reached at: https://kwenta.eth.limo or ipns://kwenta.eth.

Code Repository

The endorsed decentralized code project for Kwenta is:

rad:git:hnrkdc9jh3a1ud7k3spy9pper1ptbkh55yy5y

And can be found at: https://kwenta-gov.on.fleek.co/seeds/maple.radicle.garden/rad:git:hnrkdc9jh3a1ud7k3spy9pper1ptbkh55yy5y/tree or on Github at: https://github.com/Kwenta/kwenta

Kwenta State Log Repository

The endorsed decentralized code project for the KSL is:

rad:git:hnrkq1oex148yz4zi9tm7spfnjaryyuc93yay

And can be found at: https://kwenta-gov.on.fleek.co/seeds/maple.radicle.garden/rad:git:hnrkq1oex148yz4zi9tm7spfnjaryyuc93yay/tree/master or on GitHub at: https://github.com/Kwenta/kwenta-state-log

Radicle Note

Due to Radicles current limitations while under active development, active development of the frontend code repository and code collaboration of the Kwenta State Log are taking place on GitHub.

In case of disagreements, abandonment or forks of the endorsed Kwenta source code project, community members can put forward requests to the Kwenta Council in order to vote on alternative project ids being supported and officially endorsed.

Asset Listing Process

In the event the Synthetix protocol supports a new synth, the Kwenta protocol will automatically list the asset and make it available for use in the product. Kwenta shall not take custodial control over users' assets and shall continue to act as a decentralized trading protocol.

Synth Swap

Leveraging 1inch (smart contracts and API) and Synthetix, Kwenta will enable the exchange of any ERC20 tokens for any synths (and vice versa) directly on its platform. The first iteration will support most ERC20 tokens that can be swapped on 1inch but will withhold the ability to add custom tokens for swaps.

Specification

User Flows: As a spot trader, I want:

• Spot exposure with synthetic assets:
  • By swapping my ERC20 tokens or ETH for synths
• To leave the ecosystem:
  • By swapping my synths for ERC20 tokens or ETH

As a futures trader, I want:

• To open positions:
  • By swapping my ERC20 tokens or ETH for sUSD margin

SynthSwap smart contracts utilize both 1inch and Synthetix to execute ERC20 token swaps. SynthSwap provides swap functionality for ETH and 1inch supported ERC20 tokens to synths and vice-versa. Swap aggregation data is generated off-chain via 1inch's API and used on-chain to efficiently execute token exchange through 1inch smart contracts. The Synthetix exchange fills in the last leg of the swap if needed (if swapping Synth <-> Synth). This allows for users to go from ETH to sETH in one transaction vs previously having to go from ETH to sUSD and then a separate transaction for sUSD to sETH.

• SynthSwap NPM Package: npmjs.com/package/@kwenta/synthswap
• Kwenta aggregator contracts: github.com/Kwenta/synthswap

Socket Plugin

The Socket Plugin offers a user-friendly, multichain experience with minimal resource allocation for integration and developer overhead. It currently supports multichain swaps between Optimism, Ethereum, Binance Smart Chain, Gnosis Chain, Polygon, Fantom, Arbitrum, Avalanche, and Aurora in a single transaction. This integration will improve onboarding for users across the DeFi ecosystem.

Specification

The Socket Plugin contracts interact with the Socket Liquidity Layer, which aggregates various bridge and DEX aggregators. The swap functionality will offer synthetic assets from Synthetix, where available, on their native chains.

This allows users to start from any token on any of the supported chains and exchange it into a new token on the chain of their choice. For example, a user could hold ETH on Arbitrum, bridge and exchange it into sUSD on Optimism, and deposit it directly into their trading account.

Fur further information, see Socket Plugin Documentation

Smart-Margin v2.0.0

The core Smart-Margin v2.0.0 improvement includes support for Synthetix Perps V2, which provides users with a better trading experience with decreased fees and other improvements.

Secondary improvements include an architecture rework to support account upgradability and versioning, traditional cross-margin optionality, and new order types/strategies. Among those types and strategies are reduce-only orders, batched orders, and conditional orders (replacing advanced orders).

Specification

Synthetix Perps V2

As defined by SIP-281, orders may now be delayed to improve trading; thus, our current atomic trading system must be updated. Instead of simply executing an order immediately, orders are submitted in one transaction and executed after a delay in another transaction. Execution is not limited to the order-submitting account but can be executed by any caller. We will replace all instances of the function modifyPositionWithTracking with submitOffchainDelayedOrderWithTracking and leave order execution up to either the user or another external party (such as a keeper).

SIP-281 will also have significant implications concerning conditional orders. Conditional orders must be carefully built to balance risk and usability. Thus, strategies to prevent bad actors will be in place and discussed later in the conditional orders section.

System Upgradeability

Cross-Margin v1 (CMv1) does not support contract upgradeability, and the protocol logic is only compatible with Synthetix Perps V1. Due to this, all protocol contracts must be redeployed to support Perps V2 interaction.

Future upgrades to the protocol will require the same steps unless upgradability is introduced. Currently, margin accounts are created per user and are minimal proxies as defined by EIP-1167. The implementation address typically could not be changed; however, deploying a proxy that forwards all calls from each minimal proxy to another logic contract enables the protocol to upgrade margin account logic without the need to redeploy another account. A proof of concept of this system design has been implemented and tested here: https://github.com/JaredBorders/upgradable-minimal-proxy.

Furthermore, adding account versioning and a permanent contract store that tracks deployed accounts and the respective deployer will simplify frontend interaction and account tracking. Reducing subgraph reliance will decrease frontend load and improve performance. The store will also track verified factory addresses, ensuring that only trusted sources can update tracked accounts.

Order Execution

CMv1 relies on position-defining objects to dictate logic execution regarding placing/modifying/closing positions. As strategies and the underlying protocol grows in complexity, upgradability will become increasingly difficult. Furthermore, CMv1 bundles multiple calls to Synthetix in an order-specific fashion that cannot be decoupled resulting in decreased flexibility.

CMv2 will break down order state by specifying individual commands to execute, relying solely on the caller to determine what action(s) they wish to perform. Upgrading functionality that maps one-to-one with Perps V2 and beyond will become as trivial as adding a new function and command key. The latter will be represented as an enum and passed to an "execute" function in the CMv2 contracts alongside necessary input parameters.

Traditional Cross-Margin

Traditional cross-margin shares account margin across all positions. However, due to the isolated nature of Synthetix's implementation of perps markets, directly sharing margin is not possible.

CMv2 will introduce optional account access to user-approved addresses that will allow approved addresses to deposit/withdraw margin on behalf of users. These approved addresses can belong to Kwenta-designed keepers that can execute account margin rebalancing during certain account conditions (such as approaching liquidation). They can also belong to the third-party designed trading bots that offer a similar service. This design will increase account flexibility and incentivize others to improve the trading experience for Kwenta users.

New Order Types/Strategies

Conditional Orders (previously Advanced Orders)

Conditional orders (ex: limit/stop-loss) must be reimagined for Perps V2’s delayed orders. Submitting an order once certain market conditions are met does not guarantee that post delay, the execution price will still be valid. Furthermore, price feeds previously were atomic and on-chain, allowing a keeper (Gelato) to poll Synthetix markets to determine if an order is ready to be executed.

This changes with Perps V2. To ensure keepers submit valid orders, we will implement our version of price feed verification very similar to what Synthetix uses for executing delayed off-chain orders, which requires a price feed that is then verified on-chain. We will also redefine our advanced orders as conditional orders to highlight the conditional aspect of our new orders and the divergence from traditional advanced market order syntax.

Reduce-Only Orders

In existing markets, reduce only orders allow traders to place orders that only reduce the current position. This ensures, when there exists an active order and active position and the position is either modified or closed out, the remaining order doesn’t re-open or extend the current position. CMv2 will include a new option to restrict orders to reduce only.

Batched Orders

CMv2 will implement new functions that allow complex order composition that combines market and conditional orders in a single transaction. This addition will require a minor update of the new order-defining data structure. Providing a means for users to open a position and define conditional orders that prevent loss or realize gains in a single transaction will significantly improve the trader experience.

Smart Margin v2.0.1

Version 2.0.1 improves risk management and resolves several small non-logic audit findings.

The smart margin engine system will add a new contract, Settings.sol, which will be owned and can set a parameter accountExecutionEnabled that will directly affect the execution of commands in the Account.sol contract. The execution lock will allow the system to suspend all command execution for all accounts in the system, and the lock will be used in the event of a system-wide upgrade or emergency. Furthermore, conditional order execution will also be disabled during system suspengit sion.

Audit findings addressed in this upgrade include missing indexed attributes for conditional order events and documentation improvements. Additionally, conditional order IDs are now indexed, and the task ID generated by Gelato is now included in related events.

Smart Margin v2.0.2

Version 2.0.2 upgrades the Smart Margin (SM) account conditional order related logic based on price feeds provided by Pyth's Oracle Network. The integration of Pyth's on-chain price feed service is a necessary step to improve the precision of conditional orders within SM accounts. To access the price feeds, SM accounts utilize a contract deployed by Synthetix that enables direct querying of base asset prices (refer to IPerpsV2ExchangeRate).

Smart Margin v2.0.3

Version v2.0.3 involves upgrading Smart Margin (SM) accounts to incorporate commands that facilitate Uniswap v3 token swaps. Moreover, the integration of Uniswap's Permit2 functionality is suggested to enhance both user experience and security concerning token approvals.

The modifications necessitate the introduction of a new command specific to Uniswap that facilitates token swaps. The execution of supported token swaps will be managed by Uniswap's SwapRouter (refer to https://github.com/Uniswap/v3-periphery/blob/main/contracts/SwapRouter.sol). Detailed information pertaining to the contract-level implementation can be found in the following comprehensive resource: https://docs.uniswap.org/contracts/v3/guides/swaps/single-swaps.

The integration of Permit2 will enable SM accounts to engage in signature-based, expiring approvals and transfers for any ERC20 token. This integration does not require the inclusion of additional commands; however, it mandates SM accounts to store the designated Permit2 address and rely on the respective contract to handle all token transfers. For a thorough understanding of the contract-level implementation with regard to signature-based transfers, please refer to the following comprehensive guide: https://docs.uniswap.org/contracts/permit2/reference/signature-transfer.

Smart Margin v2.1.0

Public Conditional Order Execution

Extends Smart Margin (SM) account conditional order execution to the public. Limiting conditional order execution to a single service provider results in centralization and increases the risk of inadequate handling of conditional order execution, leading to a single point of failure. This approach also undermines the competitiveness and trustworthiness of our margin engine. While it may not be feasible to completely eliminate risks associated with on-chain smart contract automation, designing the system to incentivize non-gated conditional order execution can foster competition. This competition has the potential to significantly reduce latency and, in the worst-case scenario, result in a system that is similar to the existing one.

A proven approach, demonstrated in Synthetix's perps v2 system through off-chain delayed order execution², involves accepting and verifying a signed Pyth-provided price update as a parameter. By triggering conditional order execution with a verified price update, any keeper monitoring off-chain prices can promptly execute eligible conditional orders upon observing a satisfactory price corresponding to the given conditional order.

See KIP-087 for full details on specifications.

Risk Protection Fund

The creation of the Risk Protection Fund formalized the process for rewarding users that identify and report bugs and errors in the Protocol’s codebase.

Funding

As initial funding for the Risk Protection Fund, 100,000 $sUSD equivalent was immediately allocated from existing SNX received through SIP-2002 (Revised Volume Source Fee Program) incentives, with the adminDAO authorized to manage the fund as deemed fit. Thereafter, up to 10% of the monthly incentives from this program will be diverted to the Risk Protection Fund as long as the balance in the Risk Protection Fund remains under 100,000 $sUSD. Topping up the Risk Protection Fund under these guidelines does not require a KTR.

The funds Gnosis Safe address is: oeth:0x450f3250c61C7b492EB75f76fa836ddbfAF5C4A2

Use Cases

The following guidelines are established as an internal framework for use of the Risk Protection Fund. AdminDAO will maintain a document describing this framework. Adjustments to this framework are within the discretion of adminDAO.

The Risk Protection Fund may be used in the following situations:

• When a loss is sustained or a considerable risk of loss is identified as a direct result of a bug in the Kwenta codebase.
• To reward users or community members that report potential bugs in the codebase and subsequently cooperate with contributors during the investigation of said incident or vulnerability.
• The Risk Protection Fund may not be used in the following situations:
• When a loss or risk of loss is identified but is related to 3rd party infrastructure, user equipment or a situation outside of the codebase of the Protocol.
• When a user sustains a loss that could have been mitigated by user action is due to the inherent risks of market exposure, or is a result of user negligence.
• When a user requests compensation for a realized loss but is not able to demonstrate that the loss was due to the Kwenta platform itself or does not reasonably cooperate with the KwentaDAO’s investigation.
• When a user requests compensation for identifying a potential bug but is not able to demonstrate that the risk is due to the Kwenta platform itself, or that loss is likely and imminent.

The disbursement of rewards will be at the discretion of adminDAO, but will follow these general guidelines:

• Tokens that are distributed as awards should be valued at the market rate against sUSD on liquid exchanges for the purposes of these guidelines.
• Individual rewards to a user should be based only on excess losses which are a direct result of an error or bug in the KwentaDAO codebase.
• Awards are always within the discretion of the adminDAO.
• Awards for a single event or tightly clustered series of events cannot exceed the total holdings of the Risk Protection Fund.
• $KWENTA tokens that are distributed from the Risk Protection Fund should follow the same vesting schedule as rewards from staking.

Prevention Measures

To mitigate the risk of losses in the future and ensure users are informed about the state of the Kwenta platform, a review of the KwentaDAO product offerings and platform should be completed with the following goals:

• The terms of service should include an open and obvious warning that the use of Kwenta may result in a total loss of funds.
• Specific and visible warnings should be placed on all new features or recent significant changes to the Kwenta platform.
• Each major product update should include a review process.

Referral Program

Referral programs are a common marketing strategy for both centralized and decentralized exchanges, offering advantages such as permissionless onboarding, low overhead, and performance-based incentives. By introducing a referral program tied to the rewards_score variable described in KIP-3 and the $KWENTA staking mechanism, Kwenta can leverage a clearly defined source of funding for user acquisition while providing additional value to $KWENTA stakers and traders.

The referral program aims to utilize the existing $KWENTA trading rewards mechanism to reward participants. Additionally, by storing Issuer and Recipient data on-chain, Kwenta can target Issuer wallets with future rewards sources from Kwenta or partner protocols, creating incentives for immediate referral participation.

Specification

Definition of Terms

• Issuer: The user wallet that initiates the referral of a new user.
• Recipient: The user wallet that mints the soulbound Boost NFT.
• Boost NFT: A soulbound NFT held by a recipient, referencing an issuer.
• referral_score: The value assigned to issuer wallets, determining the type and impact of the Boost NFT.
• Bonus: The bonus awarded to the issuer, calculated as the recipient's rewards_score multiplied by the bonusRate.

Boost NFT Tiers

Rewards Calculations

• rewards_score calculation: rewards_score = fees_paid^a * (staked_KWENTA+0.1)^1-a
• final_score calculation for a trader: final_score = rewards_score + (rewards_score * boost) + Σbonus
• referral_score calculation for an issuer: referral_score = staked_KWENTA + nftScore

a is a configurable value currently set to 0.7 under KIP-3, the Cobb-Douglas function defining the weighting between fees_paid and staked_KWENTA.

Technical Specifications

• Deploy a contract allowing the MarketingDAO or AdminDAO to mint and distribute Affiliate NFTs with an nftScore value.
• Deploy a contract allowing a Recipient to mint a single soulbound Boost NFT and define an Issuer address.

Special Cases

The MarketingDAO launched an optional Gold tier referral code called kwenta from Gnosis Safe as the issuer, then transfered ownership of the Gnosis Safe to the vanity burn address 0xfaded420faded420faded420faded420faded420, effectively burning affiliate rewards associated with this code. This code has been shared with existing active community members through the Kwenta Discord.

Kwenta deployment on new chains

Kwenta can automatically launch on any network supported by the Synthetix protocol.

Specification

This KIP entails that Kwenta can deploy its products on any chain supported by Synthetix protocol. New chains should adhere to the following specifications:

• New deployed networks should be EVM compatible chains
• New networks should be supported by the infrastructure Kwenta uses > Core Contributors are responsible for feasibility and have the right to reject the addition of new chains if the feasibility analysis fails.