> For the complete documentation index, see [llms.txt](https://zodax.gitbook.io/zodax-goldpaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zodax.gitbook.io/zodax-goldpaper/system-architecture/smart-contract-structure.md).

# Smart Contract Structure

The platform is built on a robust framework of modular and interoperable smart contracts, each designed for specific functionalities. These contracts work seamlessly to deliver a secure, compliant, and scalable ecosystem for Real World Asset (RWA) tokenization. Below is a comprehensive overview of each contract, its capabilities, and interactions:

***

#### 1. **Identity Registry (IdentityRegistryV1)**

**Purpose**: Manages decentralized user identities, ensuring verified profiles with compliance and jurisdiction-specific attributes.

**Core Features**:

* **Identity Registration**:
  * Assigns unique profiles to users, including jurisdiction codes, tax domicile, risk scores, and entity categories (e.g., individual, accredited, institutional).
  * Only authorized verifiers can create or update identities.
* **Dynamic Risk Scoring**:
  * Risk scores are dynamically adjusted based on jurisdiction and user activity.
  * Compliance officers can update scores to reflect changes in behavior or status.
* **Jurisdiction Management**:
  * Enables addition of jurisdictions with predefined risk levels.
  * Ensures operations comply with regional regulations.
* **Identity Restriction**:
  * Administrators can restrict or blacklist accounts for non-compliance or suspicious activities.

**Processes**:

1. **Registration**: Authorized verifiers register users with jurisdiction-specific data.
2. **Validation**: Compliance modules ensure users are active and compliant.
3. **Updates**: Risk levels or credentials are dynamically updated based on activity.

***

#### 2. **Claim Registry (ClaimRegistryV1)**

**Purpose**: Manages the issuance, validation, and lifecycle of compliance claims like KYC and AML certifications.

**Core Features**:

* **Claim Issuance**:
  * Claims are issued by entities with the `CLAIM_ISSUER_ROLE`.
  * Attributes include type, issuer, cryptographic proof hash, and expiration date.
* **Claim Validation**:
  * Ensures claims are valid, authorized, and within their validity period.
* **Claim Revocation & Renewal**:
  * Claims can be revoked or renewed to reflect updated compliance statuses.
* **Standardized Claim Types**:
  * Predefined claim types (e.g., KYC, AML) ensure compatibility across modules.

**Processes**:

1. **Creation**: Authorized issuers generate claims linked to user identities.
2. **Verification**: Compliance modules validate user claims.
3. **Revocation or Renewal**: Claims are updated based on user compliance.

***

#### 3. **Compliance Module (ComplianceV1)**

**Purpose**: Enforces regulatory requirements for all participants and transactions.

**Core Features**:

* **Compliance Rules Management**:
  * Administrators define compliance requirements for participation.
  * Rules are dynamically updated to reflect evolving regulations.
* **Validation Framework**:
  * Aggregates data from Identity and Claim Registries to assess compliance.
  * Blocks non-compliant users from participating in transactions.
* **Dynamic Enforcement**:
  * Validates user compliance during operations like transfers or withdrawals.

**Processes**:

1. **Rule Definition**: Compliance rules specify mandatory claims for jurisdictions.
2. **Validation**: Ensures transactions meet compliance criteria.

***

#### 4. **Cryptography Engine**

**Purpose**: Provides advanced cryptographic security and privacy for sensitive operations.

**Core Features**:

* **Homomorphic Encryption**:
  * Enables operations on encrypted balances without revealing sensitive data.
* **Signature Validation**:
  * Verifies ECDSA-based signatures for secure transaction authorization.
* **Encryption Utilities**:
  * Facilitates secure data encoding and decoding.

**Processes**:

1. **Encryption**: Sensitive data, such as balances, is encrypted before storage.
2. **Validation**: Cryptographic signatures are verified for authenticity.
3. **Decryption**: Encrypted data is securely decoded when necessary.

***

#### 5. **Security Token (RWAToken)**

**Purpose**: Represents a compliant security token for RWA tokenization, incorporating encrypted balances, compliance checks, and secure operations.

**Core Features**:

* **Encrypted Balances & Transfers**:
  * Balances and transfers are protected using homomorphic encryption.
* **Compliance Enforcement**:
  * Integrated with the ComplianceV1 module for jurisdiction-specific regulations.
* **Access Control & Roles**:
  * `Admin`: Manages compliance and contract configurations.
  * `Minter`: Authorized to mint new tokens.
  * `Burner`: Authorized to burn tokens.
* **Account Freezing**:
  * Non-compliant accounts can be frozen.
* **Pausable & Upgradeable**:
  * Implements emergency halts and supports upgrades.

**Processes**:

1. **Minting**: Tokens are minted post-compliance validation.
2. **Transfer Validation**: Ensures sender and recipient compliance.
3. **Burning & Freezing**: Tokens can be burned or accounts frozen as needed.

***

#### 6. **MERC3643 Treasury (MERC3643Treasury)**

**Purpose**: Facilitates token purchases and liquidity management for RWA tokenization.

**Core Features**:

* **Token Whitelisting**:
  * Maintains a list of approved tokens for transactions.
* **Purchases with ERC20 Tokens**:
  * Supports secure purchases using USDT, with compliance validations.

**Processes**:

1. **Purchase**: Users send USDT, triggering compliance checks before token issuance.
2. **Withdrawal**: Administrators manage liquidity by withdrawing USDT.
3. **Signature Validation**: Ensures transaction authorization.

***

This architecture ensures a secure, compliant, and scalable environment for tokenizing real-world assets.

### Summary <a href="#summary" id="summary"></a>

<table data-view="cards"><thead><tr><th>Contract</th><th>Purpose</th><th>Key Features</th></tr></thead><tbody><tr><td><strong>RWA Token</strong></td><td>Tokenize RWAs securely</td><td>Encrypted balances, compliance enforcement, minting/burning, operator delegation</td></tr><tr><td><strong>Compliance Module</strong></td><td>Enforce regulatory compliance</td><td>Dynamic rules, user validation, interoperability</td></tr><tr><td><strong>Cryptography Engine</strong></td><td>Provide cryptographic utilities</td><td>Homomorphic encryption, signature validation, secure data handling</td></tr><tr><td><strong>Identity Registry</strong></td><td>Maintain user identities</td><td>Jurisdictional attributes, dynamic risk scoring, restrictions</td></tr><tr><td><strong>Claim Registry</strong></td><td>Manage compliance claims</td><td>Claim issuance/revocation, validation, lifecycle management</td></tr><tr><td><strong>RWAToken Treasury</strong></td><td>Manage USDT-based purchases</td><td>USDT handling, token whitelisting, compliance validation</td></tr></tbody></table>

### ZODAX Protocol Components <a href="#zodor-protocol-components" id="zodor-protocol-components"></a>

<figure><img src="https://982441963-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0Jzk2xrrW5T1WCsjiLGO%2Fuploads%2FRYcgNlfjLx9yhh8KD953%2FTIaB79xMqs.png?alt=media&amp;token=998209f9-107b-44c2-afb6-7403e8e8ccd8" alt=""><figcaption></figcaption></figure>