# Identity and Access Control

Identity and access control determine **who may hold, transfer, or interact with a tokenised asset**. In decentralized RWA tokenisation, this must be enforced **without turning the protocol into an identity registry or custodial gatekeeper**.

The model used here focuses on **eligibility, roles, and permissions**, not personal identity.

***

#### Identity vs Eligibility

A key distinction is separating *who someone is* from *what they are allowed to do*.

| Concept     | Meaning                              | On-Chain Representation |
| ----------- | ------------------------------------ | ----------------------- |
| Identity    | A real-world person or entity        | Not required            |
| Eligibility | Permission to interact with an asset | Required                |
| Role        | Scope of allowed actions             | Explicit                |
| Access      | Enforcement of rules                 | Deterministic           |

The protocol enforces **eligibility**, not identity.

***

#### Credential-Based Access Model

Access control is based on **credentials**, not accounts.

Credentials may represent:

* investor class (e.g. accredited, institutional)
* jurisdictional eligibility
* role (issuer, custodian, investor)
* compliance status

Credentials are:

* issued off-chain
* verified on-chain
* scoped to specific assets

They can be revoked or updated without rewriting token logic.

***

#### Access Control Flow

At a high level, access control is evaluated at the moment of interaction.

```
User / Wallet
     │
     ▼
Presents Credential Proof
     │
     ▼
Eligibility Check (On-Chain)
     │
     ├─ Pass → Action Allowed
     └─ Fail → Action Rejected
```

No background permissions exist. Every action is checked explicitly.

***

#### Roles and Permissions

The protocol distinguishes between roles to avoid authority overlap.

| Role       | Typical Permissions       |
| ---------- | ------------------------- |
| Investor   | Hold, transfer, redeem    |
| Issuer     | Initiate issuance events  |
| Custodian  | Provide attestations      |
| Operator   | Trigger lifecycle updates |
| Governance | Modify rule sets          |

Roles are **asset-specific**, not global. Holding a role for one asset does not imply authority over another.

***

#### Transfer Eligibility Enforcement

Transfers are gated by eligibility checks on both sides.

Formally:

Transfer Allowed=Esender∧Erecipient∧Rasset\text{Transfer Allowed} = E\_{sender} \land E\_{recipient} \land R\_{asset}Transfer Allowed=Esender​∧Erecipient​∧Rasset​

Where:

* EEE = eligibility status
* RRR = asset-level rules

If any condition fails, the transfer does not execute.

***

#### Privacy-Preserving Verification

In many cases, it is sufficient to prove *eligibility* without revealing identity.

The system supports:

* boolean eligibility proofs
* credential hashes
* zero-knowledge proofs (where applicable)

This allows statements like:

> “This wallet is eligible to hold this asset”

without disclosing:

* name
* jurisdiction
* financial details

***

#### Credential Scope and Lifetime

Credentials are not permanent.

They may be:

* time-bound
* usage-bound
* asset-specific

| Property   | Purpose                   |
| ---------- | ------------------------- |
| Expiry     | Prevent stale eligibility |
| Scope      | Limit cross-asset reuse   |
| Revocation | Respond to changes        |

Expired or revoked credentials immediately invalidate access.

***

#### Handling Eligibility Changes

Eligibility can change due to:

* regulatory updates
* investor status changes
* compliance events

When eligibility changes:

* new transfers may be blocked
* existing holdings remain recorded
* escalation or redemption paths apply

The protocol avoids forced erasure or silent reclassification.

***

#### No Central Identity Registry

The protocol does **not**:

* store personal data
* maintain user profiles
* link wallets to identities

Identity providers, credential issuers, and legal verification remain external and replaceable.

This reduces:

* privacy risk
* regulatory surface area
* systemic lock-in

***

#### Auditability and Transparency

While identity is not stored, **access decisions are auditable**.

Observers can verify:

* which rules applied
* whether a transfer passed or failed
* when rule sets changed

This enables regulatory review without exposing user data.

***

#### Why This Model Matters

Traditional RWA platforms often:

* centralize identity management
* require accounts and approvals
* mix custody with access control

This model avoids those pitfalls by:

* enforcing rules, not identities
* keeping access explicit and scoped
* preserving privacy while remaining enforceable

Access control becomes **deterministic infrastructure**, not discretionary policy.

***

#### Identity and Access Control Summary

| Property          | Outcome                 |
| ----------------- | ----------------------- |
| Identity storage  | None                    |
| Eligibility       | Credential-based        |
| Enforcement       | On-chain, deterministic |
| Privacy           | Preserved               |
| Authority overlap | Prevented               |