Skip to content

Z0 ARCHIVED: DAO Factory & Registry

Jump to bottom
Trevor Clarke edited this page Apr 5, 2022 · 1 revision

Registry

  • Releases Data:
    • code_hash
    • semver, as Vec<u8>: [1,0,0]
    • contract code bytes (the deployed source code)
    • owner (Should this also check if owner is part of council?)
    • metadata:
      • code_hash
      • version (change to Semver so contracts could programmatically check backward compat, as Vec<u8>: [1,0,0])
      • commit_id
      • changelog_url
      • types - export an "ABI" that can both serve as methods list + arguments, that contracts could interpret as well as clients could bootstrap within their apps. See: https://github.com/DA0-DA0/dao-contracts/tree/main/types 
pub struct DaoContractMetadata {
    // version of the DAO contract code
    // Example: [3,0,0]
    pub version: [u8; 3],
    // commit id of https://github.com/near-daos/sputnik-dao-contract
    // representing a snapshot of the code that generated the wasm
    // Example: "c2cf1553b070d04eed8f659571440b27d398c588"
    pub commit_id: String,
    // if available, url to the changelog to see the changes introduced in this version
    // Example: https://github.com/near-daos/sputnik-dao-contract/releases/tag/2.0.0
    pub changelog_url: Option<String>,
}

New Upgrade Proposal: (Possible flow)

  1. Pulls list from registry, allows an owner or designated acceptable council group to query the list of compatible versions to upgrade and migrate to.
  2. Need to calculate how much upgrades would cost. (Helpful for migrations, if no migration only need diff in storage cost for core code)
  3. Need to inform (list of changelogs) to the users what is changing.
  4. New proposal is submitted with the version the DAO would like to move to (code_hash or similar single value).
  5. Lock the contract/DAO until DAO upgrade + migration is done.
  6. Complete any/all migrate steps (can be triggered by owner, or approved signer -- IE: Croncat).
  7. Migration completion includes unlocking DAO and allowing continuation of all other functions.

Factory Upgrade Proposal: (Possible flow)

This would be used for DAOs that configure their preference of being automatically upgraded. (If that is even feasible :P)

  1. New release is approved by Factory DAO council
  2. Factory would iterate over DAO preferences (only DAOs that have opted in) and submit upgrade proposals
  3. Upgrade flow happens when DAO approves the upgrade.

Backward compatibility Questions:

  • Old contracts, how do they opt-in for upgrades? (Registry could keep track of ALL DAOs because Each dao could lie about its version unless code_hash was exposed)
  • How can registry check if contracts are compatible?

Registry ownership Questions:

  • DAO based? Who is on the council?
  • when can 100% Keyless be possible?
  • Who/How does registry upgrade/update? Need a way to propose official versions/releases. I would expect council members to be trusted to submit releases, approved by > 5 council members
  • Malicious possible attacks? Do not want code upgrading a DAO that affects governance policies negatively, or was not presented before upgrade. I would expect all governance policy scenarios would be tested with upgrade flows.

Known Code Hash:

Clone this wiki locally