{"componentChunkName":"component---src-pages-sips-sip-markdown-remark-frontmatter-sip-tsx","path":"/sips/sip-306/","result":{"data":{"markdownRemark":{"fileAbsolutePath":"/vercel/path0/content/sips/sip-306.md","frontmatter":{"sip":306,"sccp":null,"title":"V3 Migration","network":"Ethereum & Optimism","author":"Afif Bandak (@aband1), Kain Warwick (@kaiynne), Noah Litvin (@noahlitvin)","type":"Governance","proposal":"https://snapshot.org/#/snxgov.eth/proposal/0xfe74586d997170f3b7bea8347e04b5f169aac1b85d5fc39d5b3c2898936db93e","implementor":"Daniel Beal (@dbeal-eth), Leonardo Massazza (@leomassazza), Alejandro Santander (@ajsantander)","release":null,"created":"2022-07-04T00:00:00.000Z","updated":null,"status":"Implemented"},"html":"<!--You can leave these HTML comments in your merged SIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-draft_title_abbrev.md`. The title should be 44 characters or less.-->\n<h2 id=\"simple-summary\" style=\"position:relative;\"><a href=\"#simple-summary\" aria-label=\"simple summary permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Simple Summary</h2>\n<!--\"If you can't explain it simply, you don't understand it well enough.\" Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->\n<p>This SIP proposes a migration plan for Version 3 of the Synthetix protocol. Collateral will be migrated to V3 and account tokens will be minted to existing stakers’ addresses. These stakers will continue to back all debt issued by V2X.</p>\n<h2 id=\"abstract\" style=\"position:relative;\"><a href=\"#abstract\" aria-label=\"abstract permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Abstract</h2>\n<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, \"we propose to deploy a new contract that will do x\".-->\n<p>The migration will allow stakers on V2X to move their collateral to V3 and receive an account token with a staking position that backs a special <em>Legacy Market</em>. The Legacy Market will appear to the V2X system as a staker. It will also be able to convert stablecoins issued from V2X (sUSD) into stablecoins issued by V3 (snxUSD). Migrated escrowed SNX will be locked with an equivalent schedule in the V3 system.</p>\n<h2 id=\"motivation\" style=\"position:relative;\"><a href=\"#motivation\" aria-label=\"motivation permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Motivation</h2>\n<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is innaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->\n<p>The primary goal of this plan is to minimize friction for stakers and to avoid disrupting the current usage of synths while allowing the system to benefit from the upgrade to V3. This is also a relatively simple migration path, which reduces risk and expedites deployment.</p>\n<p>This plan also allows us to migrate to V2X and V3 while being agnostic to cross-chain considerations. Because we can deploy V3 with a Legacy Market on both L1 and L2 and the <a href=\"https://sips.synthetix.io/sips/sip-165/\">debt pool synthesis</a> can continue to be utilized, the V2X debt on both networks can be backed by collateral the V3 system on either or both networks. Cross-chain migration of collateral (staking positions) and debt (snxUSD) for V3 will be proposed in forthcoming SIPs.</p>\n<p>This plan is also agnostic to rewards and escrow/locking. If <a href=\"https://sips.synthetix.io/sips/sip-276/\">SIP-276</a> is implemented and locking/escrow is not necessary in <a href=\"https://sips.synthetix.io/sips/sip-305/\">SIP-305</a>, stakers should be able to retrieve escrowed SNX from the existing contracts. Otherwise, a proposal for the migration of escrowed SNX into a new escrow system for V3 may be proposed.</p>\n<p>Further, the migrate function specified in the Legacy Market can initially only be invoked by the relevant staker. In the future, we could add an incentive for users to migrate and eventually the function could be made public in the future. This would allow a script to forcibly migrate all V2X staking positions to completely end use of the contracts in the V2X being replaced by V3.</p>\n<h2 id=\"specification\" style=\"position:relative;\"><a href=\"#specification\" aria-label=\"specification permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Specification</h2>\n<!--The specification should describe the syntax and semantics of any new feature, there are five sections\n1. Overview\n2. Rationale\n3. Technical Specification\n4. Test Cases\n5. Configurable Values\n-->\n<h3 id=\"overview\" style=\"position:relative;\"><a href=\"#overview\" aria-label=\"overview permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Overview</h3>\n<!--This is a high level overview of *how* the SIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->\n<p>The plan proposed here involves the creation of a <em>Legacy Market</em> contract. See <a href=\"https://sips.synthetix.io/sips/sip-299/\">SIP-299</a> for prerequisite updates to the V2X protocol.</p>\n<p><img src=\"/static/diagram-8f99dd89fdaf17fadab107250b268ba8.jpg\" alt=\"Synthetix V3 Migration Plan Overview\"></p>\n<h3 id=\"rationale\" style=\"position:relative;\"><a href=\"#rationale\" aria-label=\"rationale permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Rationale</h3>\n<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->\n<p>We’ve considered multiple other migration plans in relation to the one proposed here. The main alternative would involve a “clean break” from V2X, where all stakers and synth holders would need to voluntarily exit the existing system and opt into V3. There any many downsides to this approach: all users and ecosystem partners would be required to actively migrate; there would be an indefinite maintenance period for V2X; we would have multiple versions of the protocol’s tokens in circulation at once; there would be a risk of the synths issued by V2X losing their backing; there could become a higher risk of liquidation for stakers on V2X; and, there would be a higher risk of lost TVL and revenue.</p>\n<p>Another plan we considered would entail rebuilding all aspects of the protocol for V3, updating all of the existing tokens—including synths—such that V3 can mint and burn them, and then running a migration script to generate V3 accounts and staking positions. While this would be non-disruptive to users, it would require us to determine how the market contracts and all of the auxiliary features of V2X (wrappers, loans, cross-chain synthesis, etc.) will be handled by V3 prior to initiating the migration.</p>\n<p>Instead, the plan proposed here is similar to the second option above, but allows us to execute it in multiple steps. The “legacy” market contract will allow V3 to back the existing synths and support the auxilary features of the system. This way, we can start by providing the benefits of V3 to stakers (improved systems for collateral management, liquidations, staking incentives, etc.) prior to upgrading how synths are implemented and auxiliary features.</p>\n<h3 id=\"technical-specification\" style=\"position:relative;\"><a href=\"#technical-specification\" aria-label=\"technical specification permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Technical Specification</h3>\n<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.-->\n<p>This migration will involve making some upgrades to V2X and deploying a Legacy Market Contract on V3.</p>\n<p>All of the smart contracts pertaining to synths, perps, wrappers, loans, and shorts can be left as-is. They can be deprecated and/or migrated in the future.</p>\n<p><strong>“Legacy” Market Contract</strong></p>\n<p>The following pseudo-code outlines the necessary functions in the Legacy Market contract:</p>\n<pre><code class=\"language-solidity\">contract LegacyMarket is IMarket {\n\n  function balance() external returns (uint) {\n    return synthetixV2.totalIssuedSynths()\n  }\n\n  function migrate(address staker) external {\n    require(msg.sender == staker);\n    uint accountId = synthetixV3.createAccount();\n    synthetixDebtShares.transferFrom(staker, address(this), synthetixDebtShares.balanceOf(staker));\n    snxToken.transferFrom(address(synthetixV2), address(synthetixV3), snxToken.balanceOf( staker));\n    synthetixV3.delegateCollatera(/* preferred fund, leverage 1, etc. */)\n    _applyApproximateCurveFromEscrowEntry(accountId, staker); // Note that this contract temporarily needs elevated permissions to execute this function.\n    snxAccount.transfer(accountId, staker);\n  }\n\n  function convertUsd(uint amount) external {\n    synthetixV2.burn(msg.sender, amount);\n    synthetixV3.mint(msg.sender, amount);\n  }\n\n}\n</code></pre>\n<p>In the future, it would be possible to execute a script to force migrate users from V2X to V3. At this, all staking positions would be migrated to V3, and all positions will providing liquidity to the legacy markets by default. (This means existing integrations of Synths, such as Curve, will not be disrupted.) Once this migration has occurred it will be possible to deprecate individual synths and features over time as specific migration plans are developed.</p>\n<h3 id=\"test-cases\" style=\"position:relative;\"><a href=\"#test-cases\" aria-label=\"test cases permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Test Cases</h3>\n<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->\n<p>Relevant tests will be developed during implementation.</p>\n<h3 id=\"configurable-values-via-sccp\" style=\"position:relative;\"><a href=\"#configurable-values-via-sccp\" aria-label=\"configurable values via sccp permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Configurable Values (Via SCCP)</h3>\n<p>N/A</p>\n<h2 id=\"copyright\" style=\"position:relative;\"><a href=\"#copyright\" aria-label=\"copyright permalink\" class=\"anchor before\"><svg aria-hidden=\"true\" focusable=\"false\" height=\"16\" version=\"1.1\" viewBox=\"0 0 16 16\" width=\"16\"><path fill-rule=\"evenodd\" d=\"M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z\"></path></svg></a>Copyright</h2>\n<p>Copyright and related rights waived via <a href=\"https://creativecommons.org/publicdomain/zero/1.0/\">CC0</a>.</p>"}},"pageContext":{"id":"c6d8331e-e945-5e55-a84e-f4b451e05b2f","frontmatter__sip":306,"__params":{"frontmatter__sip":"306"}}},"staticQueryHashes":[]}