# Security Model

The security model for RWA tokenisation is designed around a single principle: **no single failure should compromise asset integrity, ownership records, or settlement logic**. Because RWAs span on-chain and off-chain domains, security must address smart contracts, keys, roles, and exceptional conditions — not just code correctness.

This section explains how the system is protected, how authority is constrained, and how emergencies are handled.

***

#### Layered Security Architecture

Security is implemented in layers, each with a specific responsibility.

```
Legal & Operational Layer
        │
        ▼
Role & Permission Layer
        │
        ▼
Smart Contract Logic
        │
        ▼
Blockchain Execution & Finality
```

A failure at any layer should be **contained locally** and not propagate silently across the system.

***

#### Smart Contract Security

Smart contracts enforce the most critical guarantees:

* supply caps
* ownership and transfer rules
* compliance enforcement
* lifecycle transitions

Key design choices include:

* minimal and auditable contract surfaces
* explicit state machines
* conservative default behavior (fail closed)

Contracts are designed to reject ambiguous actions rather than attempt recovery automatically.

***

#### Contract Audits and Verification

Smart contracts are subject to:

* independent third-party audits
* internal review and testing
* formal verification where feasible

Audit scope includes:

* issuance and burn logic
* transfer enforcement
* rule evaluation paths
* upgrade and emergency mechanisms

Audit reports are intended to be public to support external scrutiny.

***

#### Key Management and Authority Separation

Keys represent authority and are therefore a primary attack surface.

The protocol enforces **strict separation of keys** across roles.

| Key Type       | Authority                         |
| -------------- | --------------------------------- |
| Issuer key     | Initiate issuance events          |
| Custodian key  | Submit attestations               |
| Operator key   | Trigger defined lifecycle actions |
| Governance key | Approve rule changes              |
| Emergency key  | Activate bounded safeguards       |

No single key can:

* mint tokens
* modify rules
* bypass compliance
* override ownership

This separation limits the impact of key compromise.

***

#### Least-Privilege Principle

Every role operates under the principle of least privilege.

Formally:

Effective Authority=min⁡(Role Permissions,Context Rules)\text{Effective Authority} = \min(\text{Role Permissions}, \text{Context Rules})Effective Authority=min(Role Permissions,Context Rules)

Even authorized roles can only act:

* within predefined scopes
* during allowed lifecycle states
* under specific conditions

Excess authority is intentionally unavailable.

***

#### Upgrade and Configuration Security

Upgrades are one of the highest-risk operations.

Upgrade controls include:

* explicit upgrade proposals
* time delays before activation
* on-chain recording of changes
* rollback paths where possible

There are no silent upgrades or mutable logic without governance visibility.

***

#### Emergency Controls

Some failures require immediate containment.

Emergency controls may include:

* pausing transfers
* halting issuance
* restricting redemptions

Emergency actions are:

* predefined at onboarding
* time-bound
* logged immutably

They are designed to **buy time**, not permanently resolve issues.

***

#### Protection Against Insider Risk

Because RWAs involve real-world actors, insider risk is explicitly considered.

Mitigations include:

* multi-role separation
* auditable attestations
* transparent governance actions
* immutable historical records

No insider can alter history or conceal actions once recorded.

***

#### Security Monitoring and Alerts

Security-relevant events include:

* failed rule checks
* unexpected attestation patterns
* emergency activations
* governance interventions

These events are observable on-chain and can be monitored by:

* issuers
* investors
* regulators
* third-party analytics

Transparency is treated as a security primitive.

***

#### Security Failure Handling

When security assumptions break:

* activity is restricted
* escalation paths are triggered
* resolution proceeds conservatively

The system defaults to **capital preservation**, not continuity.

***

#### What the Security Model Does *Not* Guarantee

To avoid false assumptions, the security model does not guarantee:

* protection against all smart contract bugs
* immunity from legal enforcement failures
* safety against all insider collusion
* prevention of asset value loss

It guarantees **detectability, containment, and accountability**.

***

#### Security Model Summary

| Aspect            | Approach              |
| ----------------- | --------------------- |
| Contract design   | Minimal, explicit     |
| Authority         | Role-separated        |
| Upgrades          | Governed, transparent |
| Emergency actions | Bounded               |
| Monitoring        | Public and auditable  |

***

#### Why This Model Matters

RWA systems often fail by:

* over-centralizing control
* hiding upgrade authority
* assuming trusted operators

This security model avoids those failures by:

* constraining authority at every layer
* making actions visible
* failing safely under uncertainty

Security here is not about perfection — it is about **resilience under stress**.