Smart Contract Structure
The platform is built on a set of modular and interoperable smart contracts, each serving distinct purposes but seamlessly interacting to provide a secure, compliant, and scalable ecosystem for Real World Asset (RWA) tokenization. Below is a detailed breakdown of each contract, its features, processes, and interactions.
1. Identity Registry (IdentityRegistryV1)
Purpose: Manages decentralized user identities, ensuring each participant has a verified profile with compliance and jurisdiction-specific attributes.
Core Features:
Identity Registration:
Users are assigned a unique profile containing attributes such as jurisdiction code, tax domicile, risk score, and entity category (e.g., individual, accredited, institutional).
Only authorized verifiers can register or modify identities.
Dynamic Risk Scoring:
Risk scores are dynamically calculated based on jurisdiction and user activity.
Risk levels are updated by compliance officers to reflect changes in a user's status or behavior.
Jurisdiction Management:
Supports adding jurisdictions with predefined risk levels.
Ensures operations comply with regional regulations.
Identity Restriction:
Allows administrators to restrict or blacklist accounts for non-compliance or suspicious activity.
Process:
Registration: Verifiers register a user with jurisdiction-specific data.
Validation: Compliance modules query the registry to ensure the user is active and compliant.
Updates: Risk levels or credentials are updated dynamically based on activity or external factors.
2. Claim Registry (ClaimRegistryV1)
Purpose: Handles the issuance, validation, and lifecycle management of claims like KYC and AML certifications.
Core Features:
Claim Issuance:
Claims are issued by entities with the
CLAIM_ISSUER_ROLE
.Each claim includes attributes such as claim type, issuer, cryptographic proof hash, and expiration time.
Claim Validation:
Ensures claims are valid, issued by authorized entities, and within their validity period.
Claim Revocation and Renewal:
Issuers or administrators can revoke claims if a user fails to maintain compliance.
Claims can be renewed before expiration, extending their validity.
Standardized Claim Types:
Predefined claim types (e.g., KYC, AML) ensure uniformity and compatibility across modules.
Process:
Claim Creation: Authorized issuers generate a claim tied to a user’s identity.
Verification: The compliance module queries claims to validate user credentials.
Revocation or Renewal: Claims are updated or revoked based on compliance status.
3. Compliance Module (ComplianceV1)
Purpose: Acts as the enforcement layer, ensuring all participants and transactions adhere to regulatory requirements.
Core Features:
Compliance Rules Management:
Compliance administrators define the required claims and attributes for user participation.
Rules can be updated dynamically to adapt to new regulations.
Validation Framework:
Aggregates data from the Identity and Claim Registries to determine if users meet compliance requirements.
Prevents non-compliant users from participating in transactions.
Dynamic Enforcement:
Validates user compliance during operations such as token transfers, purchases, or withdrawals.
Process:
Rule Definition: Compliance rules specify mandatory claims (e.g., KYC) for different jurisdictions.
Validation: Before a transaction, the compliance module checks user identity and claims for adherence to the defined rules.
4. Cryptography Engine (CryptographyEngine)
Purpose: Ensures the security and privacy of sensitive operations through advanced cryptographic methods.
Core Features:
Homomorphic Encryption:
Allows operations on encrypted balances without exposing sensitive data.
Supports addition and subtraction directly on encrypted values.
Signature Validation:
Verifies ECDSA-based signatures for transaction authorization.
Used in token transfers, minting, and purchase processes.
Encryption Utilities:
Provides methods for securely encoding and decoding data used in transactions.
Process:
Encryption: Token balances and transaction amounts are encrypted before storage or transmission.
Validation: All signatures are cryptographically validated to ensure authenticity.
Decryption: Encrypted data is decoded when necessary for internal operations.
5. Security Token (RWAToken)
Purpose: The RWAToken contract represents a fully compliant security token designed for RWA tokenization. It integrates features like encrypted balances, compliance checks, and secure token operations.
Core Features:
Encrypted Balances and Transfers:
Token balances and transfer amounts are encrypted using homomorphic encryption for privacy and confidentiality.
Mathematical operations on encrypted values allow transfers without exposing sensitive data.
Compliance Enforcement:
Integrated with the ComplianceV1 contract, all transfers are subject to KYC/AML and jurisdiction-specific regulations.
Validates compliance for both sender and recipient accounts before executing transfers.
Access Control and Roles:
Admin Role: Manages compliance, freezing accounts, and contract configurations.
Minter Role: Authorized to mint new tokens.
Burner Role: Authorized to burn tokens.
Account Freezing:
Enables administrators to freeze accounts suspected of malicious activity or non-compliance.
Verification Mechanism:
Verification is managed through cryptographic signatures.
Pausable and Upgradeable:
Implements OpenZeppelin's pausability for emergency halts.
Process:
Token Minting: Tokens are minted only after verifying compliance.
Transfer Validation: Each transfer is validated against compliance rules before execution.
Burning and Freezing: Non-compliant accounts can be frozen or tokens burned as required.
6. RWA Token Treasury (RWATokenTreasury)
Purpose: Manages token purchases and liquidity for RWA tokenization.
Core Features:
Token Whitelisting:
Maintains a list of approved tokens for transactions.
Ensures only compliant tokens are used.
Purchases with ERC20 tokens:
Users can purchase security tokens using USDT tokens with cryptographic and compliance validations.
Validates purchase signatures and ensures secure processing.
Process:
Token Purchase: Users send USDT to the Treasury, which verifies compliance and issues tokens.
Withdrawal: Administrators withdraw USDT to manage liquidity.
Signature Validation: Ensures that purchase and transfer requests are authorized.
Summary
Tokenize RWAs securely
Encrypted balances, compliance enforcement, minting/burning, operator delegation
Enforce regulatory compliance
Dynamic rules, user validation, interoperability
Provide cryptographic utilities
Homomorphic encryption, signature validation, secure data handling
Maintain user identities
Jurisdictional attributes, dynamic risk scoring, restrictions
Manage compliance claims
Claim issuance/revocation, validation, lifecycle management
Manage USDT-based purchases
USDT handling, token whitelisting, compliance validation
ZODOR Protocol Components
Last updated