# Membership: Tiered Credentials and Domain Trust Anchors

#### **6.3.1 The Role of Tiered Membership in NSF DAOs**

Not all DAO participants should have equal access, authority, or influence.\
NSF DAOs operate across critical risk domains—health, climate, finance, and disaster governance—where:

* Decision latency must be minimized
* Credential quality must be provable
* Risk of credential inflation or capture must be managed
* Multilateral compliance must be ensured

To address this, NSF introduces **tiered membership**, where every agent’s DAO role is governed by:

* **Credential provenance**
* **Tier classification**
* **Domain-specific scope**
* **Revocability and delegation paths**

Each tier is enforced via cryptographically verifiable credentials and integrated into clause execution, simulation validation, and vote weighting.

***

#### **6.3.2 Credential Tiers: Overview**

| Tier       | Description                                       | Typical Roles                                                   |
| ---------- | ------------------------------------------------- | --------------------------------------------------------------- |
| **Tier 0** | Root governance; clause authorship or treaty body | Treaty Delegate, DAO Architect, Jurisdictional Signatory        |
| **Tier 1** | Governance and institutional operators            | Credential Issuer, Simulation Verifier, DAO Auditor             |
| **Tier 2** | Operational agents in-field or agency-linked      | Simulation Analyst, Disaster Coordinator, Public Health Officer |
| **Tier 3** | Public-facing observers and contributors          | Citizen Witness, Public Research Partner, NGO Liaison           |

Tier definitions are DAO-specific, and may be inherited from higher-order treaties or clause families.

***

#### **6.3.3 Domain Trust Anchors**

A **Domain Trust Anchor** is an entity (e.g., DAO, multilateral body, or sovereign registry) recognized by the NSF protocol to:

* Authorize Tier 1 and Tier 2 credential issuance
* Validate subordinate VC claims
* Establish delegation, appeal, and revocation policies
* Participate in clause-level execution bindings

Example:

```json
"trust_anchor": {
  "id": "UNDRR-DAO",
  "domains": ["DisasterResponse", "EarlyWarning"],
  "recognized_by": ["UN Treaty System"],
  "valid_until": "2030-12-31"
}
```

Each trust anchor must maintain:

* Credential issuance logs
* Revocation registries
* Public audit oracles

***

#### **6.3.4 Membership Verification at Execution**

Execution environments (TEEs, CACs, simulation oracles) validate:

* That a VC corresponds to a registered tier
* That its issuer is a recognized trust anchor
* That it has not been revoked
* That its role matches the action being requested

Clause logic may require:

```scl
if signer.hasVC("SimulationAuditorVC")  
and signer.tier >= 1  
and VC.issuer in trust_anchors("Simulation")  
then execute
```

***

#### **6.3.5 Tiered Privileges and Boundaries**

Each tier grants:

| Capability                 | Tier 0 | Tier 1                | Tier 2               | Tier 3 |
| -------------------------- | ------ | --------------------- | -------------------- | ------ |
| Propose new clauses        | ✅      | 🔶 (with endorsement) | ❌                    | ❌      |
| Vote in governance         | ✅      | ✅                     | 🔶 (in domain scope) | ❌      |
| Issue credentials          | ✅      | ✅                     | ❌                    | ❌      |
| Execute policy clauses     | 🔶     | ✅                     | ✅                    | ❌      |
| Submit simulation outputs  | 🔶     | ✅                     | ✅                    | ❌      |
| Trigger emergency override | ✅      | 🔶                    | ❌                    | ❌      |

🔶 = Scoped / conditional

***

#### **6.3.6 Upgrading and Downgrading Tiers**

Tier movement is governed by DAO policy and enforced via:

* Time-based progression rules
* Peer verification (e.g., 3 Tier 1s must endorse Tier 2 upgrade)
* Simulation or clause-bound outcomes (e.g., a successful forecast leads to promotion)
* Revocation or demotion upon misuse, inactivity, or appeals resolution

Credential oracles track tier lineage, issuer authority, and lifecycle events.

***

#### **6.3.7 Credential Bundling Across Tiers**

Credential bundles may include mixed tiers:

```json
"bundle": [
  "ForecastModelVC#Tier1",
  "DisasterOperatorVC#Tier2",
  "CitizenWitnessVC#Tier3"
]
```

Each clause must validate **which tier levels are required for which logic paths**.\
For instance, a simulation trigger may require at least one Tier 1 certifying credential and two Tier 2 confirmations.

***

#### **6.3.8 DAO Membership Oracles**

Oracles for DAO access validate:

* Tier credential (valid, signed, unrevoked)
* Role match to clause, simulation, or proposal
* Geographic or domain jurisdiction
* Delegation or delegation expiry status

They return:

```json
{
  "tier": 2,
  "authorized_for": ["FloodReliefDispatch@2.1", "SimulationTrigger@1.3"],
  "issuer": "UNDRR-DAO",
  "scope": "EGY"
}
```

***

#### **6.3.9 Tier Mapping Across Federated DAOs**

In multilateral configurations:

* DAOs define **tier equivalence mappings**
* These mappings are logged, signed, and enforced during execution or vote validation

Example:

```json
{
  "from_dao": "AFRICAN-Union-DAO",
  "to_dao": "WHO-GovDAO",
  "tier_equivalents": {
    "Tier 2": "Tier 1",
    "Tier 3": "Tier 2"
  }
}
```

***

#### **6.3.10 Tiered Membership as a Pillar of Machine-Led Governance**

NSF's tiered credential system provides:

* Granular access control
* Verifiable authority boundaries
* Traceable trust escalation
* Jurisdictional accountability
* Governance resilience

It turns credentials from **flat permission flags** into **domain-aware institutional identities**, embedded directly in the clause and execution architecture of risk governance.


---

# 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.therisk.global/organization/standardization/nexus-sovereignty/vi.-governance-engine/membership-tiered-credentials-and-domain-trust-anchors.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.