# Governance

THORChain aims to have as little governance baked into the system as possible. This prevents nodes from coordinating or learning who one another are, which improves security by making collusion difficult.

THORChain governance decides:

* which assets are listed or delisted
* which chains are listed or delisted
* when the protocol is upgraded

## Asset Listing

![New Assets](/files/-MBJxU0tJFr2uXMrrlla)

Users signal which assets they want on the network by staking into a new pool. THORChain will recognise it as a new asset and create a pool in *bootstrap mode* (swapping disabled). Every few days the network checks all bootstrap pools and lists the one with the most value.

### Asset Delisting

Assets are delisted automatically when their liquidity falls too low:

1. New bootstrap pools are compared to the smallest active pools.
2. If a bootstrap pool is deeper, the smallest active pool is returned to bootstrap mode and replaced.
3. Assets can later be re-listed if liquidity returns.

## Chain Listing and Delisting

To add a new chain:

1. Community developers write a new Bifröst module and propose it via a [THORChain Improvement Proposal (TIP)](https://dev.thorchain.org/architecture/).
2. The developer community reviews and decides whether to accept it.
3. If accepted, code is tested and added to THORNode.
4. Nodes upgrade as they churn in and out.
5. When 67% of nodes run the new software, the chain connects.

To delist a chain, nodes stop watching it. Once 67% of nodes are no longer watching, the chain is removed and assets are returned to users.

## Mimir

THORChain operates with a set of constants that define fees, limits and security thresholds. These values can be overridden through Mimir.

Live values:

* [Network Constants](https://gateway.liquify.com/chain/thorchain_api/thorchain/constants)
* [Mimir Settings](https://gateway.liquify.com/chain/thorchain_api/thorchain/mimir)

See [Constants and Mimir](https://dev.thorchain.org/mimir.html) within the developer documentation for a description of each one.

## Change Management

Protocol-level changes use **Architecture Decision Records (ADRs)**. An ADR should describe:

* context and goals
* the proposed change
* pros and cons
* references
* changelog

Process and status can be found here:

* [ADR Process](https://dev.thorchain.org/architecture/PROCESS.html)
* [Current ADRs](https://dev.thorchain.org/architecture/index.html)

## Emergency Changes

Nodes cannot directly coordinate, which makes emergency changes difficult. In critical cases the **Ragnarök protocol** is used:

1. Nodes begin to leave the system.
2. When fewer than 4 nodes remain, Ragnarök triggers.
3. All funds are automatically returned to users.
4. The network shuts down safely and can be restarted later.

## Governance Philosophy

THORChain’s governance is minimal by design:

* avoids coordination between nodes
* reduces attack and capture risk
* lets market forces drive asset and chain selection
* reduces human overhead and governance fatigue
* keeps the system self-regulating and secure


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.thorchain.org/technical-documentation/technical-deep-dive/governance.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.