# Governance and Control

Governance defines how decisions are made when **predefined rules are insufficient**. In the context of RWA tokenisation, governance is not about day-to-day operation — it is about handling **exceptions, upgrades, and disputes** in a way that preserves legal integrity, investor protection, and protocol neutrality.

This model treats governance as a **fallback mechanism**, not a control plane.

***

#### Scope of Governance Authority

Governance authority is intentionally narrow.

Governance may:

* approve or reject rule updates
* authorize emergency actions defined at onboarding
* resolve disputes that cannot be handled automatically
* manage role changes (issuer, custodian, attestor)

Governance may not:

* override ownership arbitrarily
* bypass compliance rules
* retroactively alter valid transfers
* interfere with normal settlement flows

This prevents governance from becoming a centralized administrator.

***

#### Asset-Level vs Protocol-Level Governance

Governance operates at two distinct layers.

| Layer          | Responsibility                               |
| -------------- | -------------------------------------------- |
| Asset-level    | Rules, lifecycle events, exceptional actions |
| Protocol-level | Framework upgrades, security fixes           |

Asset-level governance affects **only the specific asset**.\
Protocol-level governance affects **infrastructure**, not asset economics.

This separation prevents cross-asset contagion.

***

#### Governance Triggers

Governance is activated only under defined conditions, such as:

* conflicting or missing attestations
* regulatory or legal disputes
* asset impairment or default
* required upgrades to compliance logic

Normal operations do not require governance involvement.

***

#### Emergency Controls

Some situations require immediate containment.

Emergency controls may include:

* temporary transfer freezes
* issuance suspension
* escalation to dispute resolution

Emergency actions are:

* predefined at onboarding
* time-bound
* auditable

They cannot be exercised indefinitely or silently.

***

#### Rule Updates and Change Management

Asset rules may evolve over time.

Rule updates require:

* explicit proposals
* defined approval thresholds
* on-chain recording of changes

Rule changes:

* apply prospectively, not retroactively
* preserve historical correctness
* are visible to all participants

This avoids silent changes to investor rights.

***

#### Tokenholder Rights and Governance Participation

Tokenholders may have governance rights depending on asset design.

Examples include:

* voting on specific lifecycle events
* approving restructurings
* selecting replacement service providers

These rights are:

* explicitly defined
* encoded where possible
* limited in scope

Ownership does not imply blanket control.

***

#### Dispute Resolution

Disputes arise when:

* attestations conflict
* obligations are unmet
* asset state becomes ambiguous

Dispute resolution follows a structured path:

```
Automated Rules
     ↓
Escalation Trigger
     ↓
Governance Review
     ↓
Bounded Resolution
```

Governance resolves disputes **within predefined authority**, not ad hoc judgment.

***

#### Transparency and Accountability

All governance actions are:

* recorded on-chain
* attributable to decision-making bodies
* reviewable historically

There is no off-chain or informal governance channel that affects on-chain state.

***

#### What Governance Does *Not* Replace

Governance does not replace:

* courts or legal enforcement
* custodial obligations
* regulatory authority

It coordinates protocol behavior in response to those systems — it does not supersede them.

***

#### Governance Failure Modes

The design assumes governance may fail or be slow.

As a result:

* emergency actions are time-limited
* unresolved issues lead to restriction, not continuation
* asset state can be frozen safely

The protocol prioritizes **capital protection over activity**.

***

#### Governance and Control Summary

| Aspect             | Approach                     |
| ------------------ | ---------------------------- |
| Governance role    | Exceptional, not operational |
| Authority          | Narrow and explicit          |
| Transparency       | Full on-chain visibility     |
| Emergency actions  | Bounded and predefined       |
| Cross-asset impact | Isolated                     |

***

#### Why This Model Matters

Many RWA platforms collapse governance and control into:

* issuer discretion
* upgrade keys
* opaque committees

This model avoids those risks by:

* constraining authority
* making actions auditable
* separating governance from ownership

Governance exists to **protect integrity**, not to manage assets.