Skip to content

Sputnik Factory V2 Upgrade Action Plan

Jump to bottom
Trevor Clarke edited this page Feb 6, 2022 · 4 revisions

Action Plan Intro

The Sputnik DAO codebase is ready to start rolling out upgrades & new features to allow DAOs to continue innovating. This is a step in the direction of continuous deployment of new features the community needs. This is the first phase of upgrades that will be rolled out over the coming months.

Does this apply to Sputnik v1

No. At current time of writing, this upgrade only applies to Sputnik v2 factory & governance contracts.

Who is affected?

The following groups will need to self-identify & read pertinent information, action items & next steps:

  • Factory Owners:
    • You are a factory owner if you hold keys to any of the following accounts: ['sputnik-dao.near','sputnikdao.near','sputnikv2.testnet','sputnik-2.testnet']
    • You are a factory owner if you have ever deployed the file sputnikdao_factory2.wasm to testnet or mainnet.
  • Client Owners:
    • You are a client owner if you are a core team members in Astro, Sputnik or have a web UI deployed that utilizes sputnik contracts.
  • DAO Owners:
    • You are a DAO owner if you have a governing vote within a deployed sputnik-dao contract instance. You will know by checking the DAO address is a sub-account of sputnik-dao.near, example some_dao.sputnik-dao.near.
  • Near Community
    • Anyone that believes in DAOs and is a NEAR hodler :)

Factory Owners

You will be responsible for:

  1. Deploying new factory code to factory contracts
  2. Testing deployed factory code with sample scripts
  3. Follow guidance & testing process for each network: testnet, mainnet

Client Owners (Astro)

You will be responsible for:

  1. Preparing web interfaces for upcoming upgrade support
  2. Assisting DAO owners understand when they can upgrade
  3. Creating a web experience helping DAO owners propose upgrades
  4. Creating a web experience for displaying versioning information based on new factory standards

DAO Owners

You will be responsible for:

  1. Waiting patiently until DAO upgrades are available
  2. Doing research & understanding each upcoming upgrades requirements & data migrations
  3. Proposing that your DAO does an upgrade (including potential data migrations in the future)
  4. Confirming all DAO functionality works post-upgrade

NOTE: This first upgrade for your DAO will not require a data migration. This is just a reference to help you understand that future upgrades may require some data migrations before your DAO can continue using new upgrades & features.

Near Community

As a community member you will help assist in a positive influence in helping others come along-side to support the upgrade process. You will help answer any questions & concerns other community members have while this upgrade process happens.

Process Overview

The upgrade process will require a very rigid procedure order:

  1. Codebase Updates [Sputnik Dev Team]
  2. Security Audit [External Audit Team]
  3. Client Preparedness [Client Owners]
  4. Factory Deployment [Factory Owners]
  5. Factory Testing & QA [Factory Owners], [Sputnik Dev Team]
  6. Factory Cooloff [Factory Owners], [Sputnik Dev Team]
  7. Governance Contract Deployment (AKA DAO V3) [Factory Owners]
  8. Governance Contract Testing & QA [Sputnik Dev Team]
  9. DAO Upgrade Proposals Testing [Sputnik Dev Team]
  10. DAO Upgrade Proposal Client Integration Rollout [Client Owners]
  11. DAO Upgrade Proposal Approval & Deployment [Client Owners], [DAO Owners]

NOTE: Each owner has been tagged for quick reference of responsibilities in order.

Upgrade Process Action Items

0. [Complete] Upgrade Factory Development

A. Develop Code for Factory Contract

Update the factory contract code to support version based code stored in blobs. Each stored instance of code should apply the approved standards for upgrading contracts. The factory will be used as a registry of versioned DAO code.

B. Documentation

Create documentation on the deployment + testing flow for new factory changes.

1. Audit

A. Reference Documentation

View all documentation available for currently deployed code, core codebase, local/testnet deployment practices & the new upgrade flow documentation.

Audit docs list

B. Results Submission

Upon audit completion, results should be submitted directly to the core development team to review. All audit results should be considered confidencial until any/all mitigation steps have been completed. In the interest of transparency, all audit items will be posted upon mitigation in the "Audit Guidance" section below.

2. Client Preparedness

Version Interface Support

Upon standards acceptance of the new Factory versioning data, all clients should be ready to integrate a way for DAO users to know which version their DAO contract code is.

There will only be 2 versions available to begin once the factory is upgrades. The following code snippet shows the data sample:

[
  [
    "FBSVNx98eQMFaNfu686bVqpaBCCw7iPRL9Pn3EbYrLPk",
    { "version": "v3", "commit_id": "no data", "changelog_url": null }
  ],
  [
    "ZGdM2TFdQpcXrxPxvq25514EViyi9xBSboetDiB3Uiq",
    {
      "version": "v2",
      "commit_id": "c2cf1553b070d04eed8f659571440b27d398c588",
      "changelog_url": null
    }
  ]
]

This can be retrieved using the following command (once the factory has been deployed)

NEAR_ENV=mainnet near view sputnik-dao.near get_contracts_metadata

NOTE: This could change, please connect with development team prior to implementation! NOTE: The response payload will also contain different data depending on the current step in the upgrade process.

3. Factory Testnet Deployment

A. Deployment checklist

  • Create 1 or 2 demo DAOs that can be upgraded upon factory upgrade
  • Compile Latest Factory
  • Deploy Factory to: sputnikv2.testnet
  • Check that factory basic methods are fine
  • Get a current DAO source code & store as .wasm file
  • Submit source code as a new stored version in factory
  • Submit metadata recording the version, code_hash & commit_id
B. Tests & Confirmation checklist

  • Confirm 2 versions exist in factory
  • Confirm list of DAOs
  • Confirm factory can create a new DAO
  • Check basics factory methods

4. Factory Mainnet Deployment

A. Deployment checklist

  • Create 1 or 2 demo DAOs that can be upgraded upon factory upgrade
  • Compile Latest Factory
  • Deploy Factory to: sputnik-dao.near
  • Check that factory basic methods are fine
  • Get a current DAO source code & store as .wasm file
  • Submit source code as a new stored version in factory
  • Submit metadata recording the version, code_hash & commit_id
B. Tests & Confirmation checklist

  • Confirm 2 versions exist in factory
  • Confirm list of DAOs
  • Confirm factory can create a new DAO
  • Check basics factory methods

5. Factory Cooloff (2 weeks)

2 Week Period of Mainnet Testing

Using a cooloff window for testing in mainnet without rolling out upgrades to DAO contracts will help mitigate any exploits or data corruption pre-maturely. It will help ensure all stakeholders are in lock-step approving next phase of upgrades safely.

The 2 week clock will begin once the V3 Factory has been deployed to mainnet.

6. Governance Contract Deployment (AKA DAO V3)

Testnet Checklist

  • Compile Latest Sputnik2
  • Deploy Sputnik2 .wasm file to Factory: sputnikv2.near
  • Submit metadata recording the version, code_hash & commit_id
  • Confirm the new version exists in factory, v3 with commit id 596f27a649c5df3310e945a37a41a957492c0322 and hash GUMFKZP6kdLgy3NjKy1EAkn77AfZFLKkj96VAgjmHXeS
  • Confirm factory can create a new DAO
  • Check basics DAO methods, add member, payout proposal, etc.
Mainnet Checklist

  • Compile Latest Sputnik2
  • Deploy Sputnik2 .wasm file to Factory: sputnik-dao.near
  • Submit metadata recording the version, code_hash & commit_id
  • Confirm the new version exists in factory, v3 with commit id 596f27a649c5df3310e945a37a41a957492c0322 and hash GUMFKZP6kdLgy3NjKy1EAkn77AfZFLKkj96VAgjmHXeS
  • Confirm factory can create a new v3 DAO

7. Governance Contract Testing & QA

Mainnet Test V3 Checklist

NOTE: This is the list of all features for happy path. These tests will confirm all functionality of a DAO are in working order. This does not test upgrade, as that will happen in next step.

  • Check basic DAO view methods
  • Add member
  • Payout proposal, etc.

8. DAO Upgrade Proposals Testing

A. Mainnet Demo DAO Upgrade Flow Test

  • Using a Demo DAO, create an "UpgradeSelf" proposal that uses v3 code hash
  • Majority of council will need to approve the upgrade proposal
  • Once the proposal is approved, check that there wasn't a failed transaction
B. Mainnet Demo DAO Tests & QA (Post-Upgrade)

NOTE: List of all features needed to test successful upgrade from v2 to v3. Does not cover **all** cases, but focusses on backward compatibility checks.

  • Create DAO with default policy
  • Add Member to council
  • Remove Member to council
  • Approve Proposal
  • Reject Proposal
  • Remove Proposal
  • Update Policy - ChangePolicy
  • Submit Payout (Transfer NEAR) proposal
  • Submit Payout (Transfer Fungible Token) proposal
  • Submit FunctionCall proposal
  • Submit SetStakingContract proposal
  • Submit AddBounty proposal
  • Submit BountyDone proposal

9. DAO Upgrade Proposal Client Integration Rollout (Astro, etc)

Client DAO Owner Upgrade UI/UX

All clients (Astro, Sputnik v2) UI needs a helpful upgrade flow with messaging to help DAO council to create an upgrade proposal. This should consist of 3 pieces:

  1. A notice to the DAO if there is an available upgrade, with a link to creating an upgrade proposal
  2. A UI for creating the upgrade proposal
  3. A success message if the upgrade proposal was sent, or had an error of some kind
Client Messaging Samples

Here are some sample messages that can be used in client UI:

For recent version releases:

Title: "An Upgrade Is Available For Your DAO"
Description: "Click the Propose Upgrade button to start the upgrade process. Once your DAO has approved the proposal, your DAO will get immediately upgraded."

For DAOs that do not upgrade for a while:

Title: "Your DAO is out of date, please upgrade!"
Description: "Your DAO can be upgraded to the latest version, please click Propose Upgrade to get started. Upon approval, your DAO will have the latest version and support all new features."

10. Community Announcements

Gov Forum & Blog Post

Gov.near.org Forum Post

Sputnik core team will create a post announcing this upgrade process, and how each DAO will be able to upgrade to the latest DAO code. This post will give a little background about what the changes will be, the action steps a DAO council will need to take and a roadmap for future upgrade process.

Blog Post

Sputnik core team & Near Foundation will collaborate on a blog post announcing the DAO upgrades, to help the greater community awareness on this innovative step. This post will help address issues & concerns pertaining to the greater community. It will also list how general public can help get involved and start a new V3 DAO.

11. Guide: How to upgrade your DAO

For DAO Council Members

If you are a DAO member with the ability to submit new proposals, specifically "UpgradeSelf" proposals, this guide is for you. Note, these steps may change, however it will give you an idea of how to proceed.

  1. Go to Astro and go to your DAO.
  2. Find the settings page of your DAO, and look for info about the DAO version.
  3. If your DAO shows the version "v2", you need an upgrade!
  4. Find a button for "Upgrade DAO", OR submit an "UpgradeSelf" proposal.
For DAO Community

If you are a DAO community member that doesn't have the ability to submit proposals but notice that your DAO needs an upgrade, here's a few ways you can help get the DAO upgraded:

  1. Send a message to your DAO council members, alerting them the upgrade is available.
  2. Submit a poll to your DAO to check if the community agrees the upgrade should happen.
  3. Confirm that your DAO is capable of upgrading (Make sure it is v2, not v1). You will know it cannot be upgraded if your DAO has an account with .sputnikdao.near.

Open Questions

TBD (If you have a question/concern, submit a comment)

Audit Guidance

TBD upon audit completion

Reference Data

Known Code Hashes:

History of Sputnik - Searching through the archives:

Sputnik V1 smart contracts

Factory:

  • the factory code can be found inside sputnikdao-factory/src
  • the factory code is deployed on mainnet on sputnikdao.near account
  • the factory code was deployed on mainnet for the first time on January 11, 2021 at 2:29:30pm and the second time on January 20, 2021 at 1:31:05pm
  • the factory code is deployed on testnet on sputnik-v1.testnet account

DAOs:

  • the DAOs code can be found inside sputnikdao/src
  • the DAO code is deployed to several accounts that have the following format: <dao_name>.sputnikdao.near for mainnet and <dao_name>.sputnik-v1.testnet for testnet
  • see all the DAOs that live on mainnet by calling near view sputnikdao.near get_dao_list
  • see all the DAOs that live on testnet by calling near view sputnik-v1.testnet get_dao_list

Sputnik v2 smart contracts

Factory:

  • the factory code can be found inside sputnikdao-factory2/src
  • the factory code is deployed on mainnet on sputnik-dao.near account
  • the factory code was deployed only once on mainnet on June 01, 2021 at 6:17:46pm
  • the factory code is deployed on testnet on sputnikv2.testnet account

DAOs:

  • the DAOs code can be found inside sputnikdao2/src
  • the DAO code is deployed to several accounts that have the following format: <dao_name>.sputnik-dao.near for mainnet and <dao_name>.sputnikv2.testnet for testnet
  • see all the DAOs that live on mainnet by calling near view sputnik-dao.near get_dao_list
  • see all the DAOs that live on testnet by calling near view sputnik-v1.testnet get_dao_list

UI DApps built on top of the Sputnik smart contracts (from oldest to newest)

Clone this wiki locally