Govtool in bootstrapping phase

[Ryun1]

What?

• We will need to consider how GovTool will run in the bootstrapping phase vs full governance.

  • in bootstrapping
    • DReps can only vote on Info actions
    • only parameter changes, hardforks and info governance actions are supported

• We need to consider how GovTool can run on a network that is yet to have any governance data on it

Why?

• Under bootstrapping phase some governance features are not possible

  • some user actions will fail at transaction submission time
  • do we want to prevent the user from trying to create erroneous transactions?

• Ensuring GovTool can run on networks without governance data allows us to prepare GovTool environments on networks which are yet to hardfork into governance

Question

• What do should we do to address these points?

[spannercode]

Backend being connected to cardano node and DBSync knows which network and protocol version it is currently running. This information needs to be passed to the frontend (via API). Then the frontend can make decisions on which features to enable or disable to make sure the frontend works well on that protocol version. This information is also needed for the automated testing so that the test expectations can be set depending on the protocol version and the network.

Here is how I see this transition:

• For any selected network, the backend is prepared to work, resolving any issues with dbsync or node.
• Backend exposes the network and protocol version via an API
• Frontend on startup fetches the backend network and protocol version and configures the relevant feature flags.
• Frontend on wallet connection checks whether the backend network and the wallet network matches. In case of failure, a clear message is shown to the user. Here it is not just mainnet or testnet but also different testnet differentiation checks happen here.
• For govtool features like governance action submission, and DRep voting, the frontend checks the previously configured flags or the protocol version and then enable/disable certain user actions.
• When the bootstrapping phase ends (v9.0 -> v10.0), the ideal change would be just updating the backend (Node, DBSync, API) so that it reflects the updated protocol version and no changes needed on the frontend.

some user actions will fail at transaction submission time
do we want to prevent the user from trying to create erroneous transactions?

I'd say yes. When we know certain transactions are going to fail, in my opinion, it is better to show them on disabled state so the user is aware of that and prevents any wasted effort on the user's part.