TIP-7518: DyCIST – Dynamic Compliant Interoperable Security Token for TRON

[lopeed]

tip: 7518
title: DyCIST – Dynamic Compliant Interoperable Security Token for TRON
author: lopeed
status: Draft
type: Standards Track
category: TRC
created: 2026-03-30
requires: 1155 (TRC-1155)

---

Simple Summary

This TIP defines a token standard (TRC-7518) for issuing and managing regulated real-world assets (RWAs) on the TRON blockchain using a partitioned, semi-fungible architecture. Built on TRC-1155, each tokenId represents a distinct partition (e.g., share class, investor tranche, lockup period) with its own compliance rules, transfer restrictions, and payout logic. The standard enables dynamic compliance, cross-chain interoperability, and granular asset control, making it ideal for complex asset tokenization such as real estate, private equity, funds, and structured products.

---

Abstract

TRC-7518 introduces a modular framework where each token partition operates as an independent compliance silo. Key components include:

· Partitioned Token Model: Each tokenId (partition) represents a distinct asset class, investor group, or regulatory tranche, with its own metadata, lockup schedules, and transfer rules.
· Dynamic Compliance: On-chain and off-chain compliance checks via canTransfer hooks and cryptographically signed vouchers (EIP-712), enabling real‑time rule updates without contract redeployment.
· Granular Controls: Per-partition transfer restrictions, address freezing, time‑based token locking, and forced transfers for legal recovery.
· Efficient Operations: Batch payouts, batch transfers, and gas‑optimized multi‑asset management within a single contract.
· Cross‑Chain Interoperability: Optional wrapping/unwrapping functions to move tokens across EVM and non‑EVM chains while preserving compliance metadata.

The standard aligns with global regulatory frameworks (MiCA, MiFID II, SEC guidance) and leverages TRON’s existing security infrastructure, including T3 Financial Crime Unit and Blockaid.

---

Motivation

TRC‑20 is the dominant token standard on TRON, but it lacks native support for semi-fungible assets and granular compliance partitioning. Issuers of complex RWAs face challenges:

· Multiple share classes (e.g., Class A, Class B, preferred vs. common) require separate token contracts, fragmenting liquidity and increasing deployment costs.
· Regulatory lockups and vesting schedules must be enforced per investor group, often requiring custom logic.
· Cross‑chain mobility demands that compliance rules survive bridging.

Existing standards like TRC-3643 (T-REX) excel at fungible, identity‑based compliance but are not optimized for multi‑class, semi‑fungible scenarios. TRC-7518 fills this gap by providing a single‑contract solution for managing complex asset structures, reducing overhead by up to 70% in enterprise use cases .

---

Specification

The standard defines the following core components. A token is considered TRC-7518 compliant if it implements the described interfaces and behaves according to the partition model.

1. Partition Model

Each partition is represented by a tokenId (uint256). Partitions are semi‑fungible: tokens within the same tokenId are fungible, but each tokenId can have distinct compliance rules, lockup periods, and metadata.

struct TokenPartition {
    string name;                 // e.g., "Class A Preferred"
    bytes32 complianceRulesHash; // hash of off-chain compliance rules (e.g., jurisdiction, investor caps)
    uint256 lockPeriod;          // minimum holding period in seconds
    bool transferRestricted;     // if true, transfers are blocked until restriction removed
    mapping(address => uint256) lockedBalances; // per-account locked amounts
}

2. Core Interface (IERC7518)

The token contract MUST implement the following interface, which extends TRC‑1155 and TRC‑165:

interface IERC7518 is IERC1155, IERC165 {
    // Events
    event TokensLocked(address indexed account, uint indexed id, uint256 amount, uint256 releaseTime);
    event TokenUnlocked(address indexed account, uint indexed id);
    event TokensForceTransferred(address indexed from, address indexed to, uint indexed id, uint256 amount);
    event AddressFrozen(address indexed account, bytes data);
    event AddressUnfrozen(address indexed account, bytes data);
    event TransferRestricted(uint indexed id);
    event TransferRestrictionRemoved(uint indexed id);
    event PayoutDelivered(address indexed from, address indexed to, uint256 amount);
    event BatchPayoutDelivered(address[] to, uint256[] amounts);

    // View Functions
    function transferableBalance(address account, uint id) external view returns (uint);
    function lockedBalanceOf(address account, uint256 id) external view returns (uint256);
    function canTransfer(address from, address to, uint id, uint amount, bytes calldata data) external view returns (bool);

    // Transfer Functions (override TRC-1155)
    function safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes calldata data) external returns (bool);

    // Compliance & Control
    function restrictTransfer(uint id) external returns (bool);
    function removeRestriction(uint id) external returns (bool);
    function lockTokens(address account, uint id, uint256 amount, uint256 releaseTime) external returns (bool);
    function unlockToken(address account, uint256 id) external;
    function forceTransfer(address from, address to, uint256 id, uint256 amount, bytes memory data) external returns (bool);
    function freezeAddress(address account, bytes calldata data) external returns (bool);
    function unFreeze(address account, bytes memory data) external returns (bool);

    // Payouts
    function payout(address to, uint256 amount) external returns (bool);
    function batchPayout(address[] calldata to, uint256[] calldata amount) external returns (bool);
}

3. Compliance Enforcement

The canTransfer function MUST be called before every transfer. It checks:

· Whether the sender or receiver address is frozen.
· Whether the partition (id) is transfer‑restricted.
· Whether the sender has sufficient transferable balance (balanceOf - lockedBalanceOf).
· Whether off‑chain compliance vouchers (if provided in data) are valid (issuer signature, expiration, etc.).
· Any additional rules defined by the issuer (e.g., jurisdictional limits, investor caps).

If canTransfer returns false, safeTransferFrom MUST revert.

4. Optional: Wrapper Interface (IERC1155Wrapper)

For cross‑chain interoperability, the contract MAY implement an optional wrapper interface:

interface IERC1155Wrapper {
    function setWrappedToken(address token) external;
    function wrapToken(address from, uint256 amount, bytes memory data) external returns (bool);
    function unwrapToken(address to, uint256 amount, bytes memory data) external returns (bool);
}

This enables compliant bridging: when wrapping, the original token is locked (or burned) and a wrapped version is minted on the destination chain with identical compliance metadata .

---

Rationale

Why Partitions?

Partitions allow multiple asset classes or investor groups to coexist in a single contract, reducing deployment costs, simplifying management, and maintaining liquidity across related assets . This is essential for:

· Real estate: Each floor or unit as a partition; fractional shares within each partition are fungible.
· Private equity: Different share classes (common, preferred, restricted) as separate partitions.
· Funds: Separate tranches (e.g., senior, mezzanine) with different risk/return profiles.

Why Dynamic Compliance?

Regulatory requirements evolve. ERC-7518's voucher‑based compliance allows issuers to update rules without redeploying contracts, significantly reducing operational overhead . Vouchers are signed off‑chain by trusted issuers (e.g., KYC providers) and validated on‑chain, ensuring real‑time adaptability.

Why Built on TRC-1155?

TRC-1155 (the TRON adaptation of ERC-1155) is the most gas‑efficient standard for managing multiple token types within a single contract. It supports batch operations, reducing costs for large‑scale distributions (e.g., dividend payouts to thousands of holders) .

---

Implementation

Reference Implementations

Component Repository
ERC-7518 Reference https://github.com/zoniqx/erc7518_reference
Zoniqx DyCIST Documentation https://www.zoniqx.com/resources/zprotocol-a-framework-for-compliant-institutional-tokenization

Adapting to TRON

To deploy a TRC-7518 token on TRON:

1. Replace ERC-1155 imports with TRC-1155-compatible contracts (e.g., using OpenZeppelin’s TRC-1155 implementation).
2. Ensure all function signatures remain compatible with TRON’s TVM (EVM-equivalent).
3. Integrate with TRON’s identity and compliance infrastructure:
   · Use ONCHAINID or similar for identity verification.
   · Leverage T3 Financial Crime Unit for address screening.
   · Use Blockaid for pre‑transaction fraud detection.

MetaMask and Wallet Adapters

TRC-7518 tokens are fully compatible with MetaMask’s native TRON support (announced January 2026) via adapters like @metamask/connect-tron and @tronweb3/tronwallet-adapter-metamask-tron. The standard’s TRC-1155 base ensures compatibility with existing wallets and explorers.

---

Security Considerations

· Voucher validation: Implementers must verify issuer signatures, nonce uniqueness, and expiration to prevent replay attacks.
· Agent privileges: Functions like forceTransfer, freezeAddress, and lockTokens should be protected by role‑based access control (RBAC), ideally with multi‑signature or DAO governance.
· Partition isolation: Ensure that compliance rules for one partition do not inadvertently affect others.
· Cross‑chain bridges: When implementing wrapping/unwrapping, validate that compliance metadata is preserved and that bridges are audited for security.

---

Integration with TRON Ecosystem Partners

TRC-7518 tokens can leverage TRON’s existing security and compliance infrastructure:

Integration with TRON Ecosystem Partners

TRC-7518 tokens are designed to leverage TRON’s existing security, identity, and compliance infrastructure. The following partners provide critical capabilities that can be integrated with the standard:

Partner	Role	Key Functionality	Application in TRC-7518
🔒 T3 Financial Crime Unit (TRM Labs)	Anti‑fraud & compliance	Real‑time address screening, fund freezing	Pre‑transfer screening of addresses; freezeAddress can be triggered by T3 alerts to comply with regulatory orders.
🛡️ Blockaid	On‑chain security	Pre‑transaction simulation, fraud detection	Simulates canTransfer to prevent malicious transactions; detects wallet drainers and fake token approvals.
🏦 Anchorage Digital	Institutional custody	Regulated custody of digital assets	Custody of private keys for issuers, agents, and large token holders; enables institutional-grade safekeeping of tokenized assets.
🆔 Nabox	Decentralized identity (DID)	Multi‑chain identity management	Integration with identity registries for KYC/AML verification; provides the IIdentity interface required for claim validation.
🌉 Plume Network (Skylink)	Cross‑chain RWA infrastructure	Compliant bridging via LayerZero	Enables wrapping/unwrapping of TRC-7518 tokens to/from other chains while preserving compliance metadata.
🔮 WINkLink	Oracle network	Off‑chain data feeds	Provides price feeds, proof-of-reserve, and other external data needed for compliance modules (e.g., NAV calculations for funds).
🧠 TRON DAO AI Fund	Ecosystem funding	Grants and investment	TRC-7518 projects may qualify for support from the $1B fund focused on RWA tokenization, AI identity, and developer tools.

All integrations are optional but recommended to achieve full regulatory alignment and operational robustness.

Regulatory Alignment

TRC-7518 is designed to align with major global frameworks:

· MiCA (EU): Supports issuer disclosure, recordkeeping, and transfer restrictions.
· SEC (U.S.): Enables embedded transfer restrictions for Rule 144, Regulation D, and Regulation S compliance; provides immutable audit logs for reporting .
· VARA (Dubai): Governance and AML/KYC controls align with VARA’s virtual assets regime.

---

Copyright

This TIP is licensed under the MIT License.

---

This proposal is based on ERC-7518 (DyCIST) developed by Zoniqx and the Ethereum community, adapted for the TRON ecosystem. Special thanks to the teams at Zoniqx, TRON DAO, and the broader RWA community for their foundational work.

---

[simbadMarino]

Hello @lopeed , thanks for pushing to bring this as a TIP, RWAs are critical for the blockchain industry. I agree on further exploring this collectively.

Would be great to bring the Zoniqx team into the discussion as well!
Linking their TBL submission here for reference