Governance code of conduct

docs/use/governance/astar-townhall.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 4
 sidebar_label: Off-chain Governance
 title: Astar Townhall - Off-chain Governance
 ---

docs/use/governance/code-of-conduct.md

@@ -0,0 +1,24 @@
+---
+sidebar_position: 1
+sidebar_label: Code of Conduct
+title: Governance Code of Conduct
+---
+
+These is the _Code of Conduct_ for the Astar on-chain governance system. It is a set of rules and guidelines that all participants in the governance process should follow. It aims to ensure that the governance process is fair, transparent, and efficient. However, nothing is written in stone, and can be changed in the future.
+
+| #  | Guidelines                                                                                                                                                                                                 |
+|----|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| 1  | Users should familiarize themselves with how governance works before making any proposals. This can be done by, for example, reading the official [documentation](https://docs.astar.network/docs/learn/governance/) or the [blog](https://astar.network/blog/astar-onchain-governance-153). |
+| 2  | Before making any on-chain proposal, it is strongly advised to discuss it first on the Astar forum to gather feedback and conduct a temperature check. The discussion section on Astar Subsquare can also be used for this purpose and to conduct polls. |
+| 3  | If a user makes a malicious proposal, it may be canceled, and deposits from the user and backers may be slashed.                                                                                           |
+| 4  | A malicious proposal is one that aims to execute an on-chain call with harmful consequences, such as stealing funds, minting new tokens, introducing technical bugs, bypassing security checks, or similar actions. |
+| 5  | The Main Council may cancel an ongoing referendum if it considers it to be against the network's best interest. Since this is an _unorthodox_ action, it must be properly explained and justified, either within the proposal itself or on the Astar forum. |
+| 6  | The Technical Committee may cancel a public proposal if it considers it technically malicious (e.g., a faulty runtime upgrade). As this is an _unorthodox_ action, it must be properly explained and justified, either within the proposal itself or on the Astar forum. |
+| 7  | The Main Council and Community Council must provide justification for accepting or rejecting a treasury spending proposal.                                                                                |
+| 8  | For major treasury expenditures, it is preferable for the proposer to create a public referendum.                                                                                                          |
+| 9  | Before registering or unregistering a dApp from the dApp staking protocol, the Community Council should discuss the proposal with token holders on the Astar forum.                                        |
+| 10 | The Community Council should evaluate staking and treasury spending requests with a clear understanding of expected returns and manageable expenditures. They are responsible for ensuring the community treasury remains sustainable and functional. |
+| 11 | The Main Council has the authority to remove members of the Main Council, Community Council, and Technical Committee if they are inactive, act against the network's interests, or request removal themselves. Any changes to council membership must be publicly discussed and justified. |
+| 12 | The Main Council can appoint new members to the Main Council, Community Council, and Technical Committee. Such actions must be publicly discussed beforehand.                                              |
+| 13 | Any council member can delegate their responsibilities to another account. This option should be used if the council member expects to be absent and unavailable for a period of time.                    |
+| 14 | Fast-track can be used to expedite runtime upgrade proposals, without them being urgent. However, voting & enactment period duration should still be respected.                                            |

docs/use/governance/subsquare_guide.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 1
+sidebar_position: 2
 sidebar_label: On-chain Governance
 title: Astar Subsquare - On-chain Governance
 ---

docs/use/governance/unstoppable-community-grant-program.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 2
+sidebar_position: 3
 sidebar_label: UCG Program
 title: Astar Unstoppable Community Grant Program
 ---