# T-REX.network The Ultimate RWA Ecosystem
ERC-3643/pages/3mBFa46plBUOge1OW2ht
AppStore/pages/CFK6RKfc1SPjjVnSmtvA
AppChain/pages/PVxUwd4l75tnqebegrBR
Utility Token/pages/h1ML7Q1THeEfjc1cIZpY
Community/pages/f8k1pXmVvMCnENVVIBpQ
Developer tools/pages/qF7U0VxJV0NDCnZOur3N
# T-REX The interoperability infrastructure for compliant RWAs ## What T-REX is T-REX is a neutral, industry-led settlement and compliance layer governed by regulated financial institutions. It is not a competing L2 or a commercial venture, the objective is to provide the underlying infrastructure that allows transfer agents, custodians, CSDs, market infrastructures, and DeFi protocols to transact with full lifecycle control and regulatory oversight. ## Why it is needed FIs have built isolated private chains and stablecoin environments that don’t interoperate which will ultimately constrain adoption and fragment liquidity. Without a shared compliance and identity-based settlement layer, scaling digital markets globally becomes impossible. ## Core principles * Golden-source ledger framework bridging TradFi and DeFi * Governance via an institutional DAO to ensure neutrality * Anchored to a public L1 environment (EVM-based) for global interoperability * Confidentiality via advanced cryptography (e.g., FHE) * Built on ERC-3643, the institutional compliance standard used by 140+ members # Overview A new Era for On-chain Finance ERC-3643 RWA tokens, with legal guarantees and DeFi interoperability. *** ## Powering Mass Tokenization. After years of technological development, new regulations, and education worldwide, it is finally time to massively tokenize assets on the blockchain. The **Great Transition**, where assets get massively tokenized on the blockchain, will occur over the next ten years. The [T-REX ERC-3643 protocol](/t-rex-network/t-rex-protocol) is the enabler of this fundamental change for finance. **T-REX**, the utility token driving the [**ERC-3643**](https://erc3643.org/) **protocol**, addresses these needs with a practical and innovative approach to tokenizing financial assets where compliance is enforced on-chain enabling a strong interoperable ecosystem to thrive. Currently, most RWA tokens lack compliance, provide poor investor guarantees, or are confined within central custodian wallets, limiting their use in DeFi applications. T-REX fixes these issues by enabling the **legal tracking of digital asset ownership**. ## T-REX Protocol The ERC-3643 protocol, known as "T-REX," is an advanced set of audited smart contracts designed to simplify the tokenization of financial assets. It allows for the seamless representation of assets and their underlying data, such as documents, prices, ratings, and certifications, as well as the legal identification of stakeholders on the blockchain. T-REX also enables the tracking of all investment activities, including transactions, investments, and redemptions. It is currently the only standard for tokenized securities recognized by the Ethereum community. The protocol enhances the ERC-20 standard by integrating decentralized identity solutions and control functions. This extends the tokenization process by embedding critical compliance and control mechanisms directly into the cross-chain protocol. It provides a practical solution for linking real-world assets and financial securities to their blockchain representations. #### Key Features: * **On-Chain Compliance**: Ensures that all transactions meet regulatory standards, providing a secure environment for asset management. * **Direct Asset Linkage**: Establishes a clear and transparent connection between real-world assets and their digital counterparts. * **Stakeholder Representation**: Supports various stakeholders, including issuers, investors, and distributors, within a unified framework. * **Chains and DeFi Compatibility**: Seamlessly integrates with any EVM chains and decentralized finance (DeFi) applications, opening new avenues for growth and innovation. Learn more about the protocol: {% embed url="" %} ## T-REX Ecosystem
The T-REX protocol offers a standardized framework for tokenizing Real World Assets and securities, addressing the complexities inherent in both finance and blockchain technology. By **providing clear guidelines and best practices**, it enables all stakeholders to efficiently execute their roles, building on the experiences of previous projects. This **standardization enhances interoperability** and compatibility, allowing service providers to integrate seamlessly with all tokens through a single integration, thereby reducing technical burdens and promoting consistent interactions across the value chain. Adopting the ERC3643 protocol significantly **reduces technical complexity** by utilizing an audited and market-proven standard, eliminating the need for extensive due diligence. This results in **substantial time and cost savings**, as issuers and investors can rely on the protocol's established credibility. Furthermore, the protocol democratizes access to technology, enabling even small asset owners to leverage the benefits of tokenization, driving innovation and growth. Investors gain confidence, knowing their rights are protected without the need to analyze smart contracts, thereby enhancing trust and adoption. ## T-REX token The **T-REX Token** is central to this ecosystem. T-REX holders contribute to the ecosystem's growth and benefit from staking rewards and revenue-sharing models, fostering a collaborative and sustainable environment. # Vision When standardization enables mass adoption. *** ## The Need for an Interoperable Ecosystem Tokenizing financial assets is a complex process due to the intricacies of both finance and blockchain technology. The financial industry involves numerous actors with distinct roles, and the complexity varies based on the type of securities, jurisdictions, and investor types. Additionally, blockchain technology, including smart contracts, is often misunderstood, leading to further complications. {% content-ref url="/pages/uPxWaoDaXqk4kcQEDt2K" %} [RWA Market Needs](/introduction/vision/rwa-market-needs) {% endcontent-ref %} {% content-ref url="/pages/D7YpNxyZuGYBI0xNRXIf" %} [A Unified RWA Framework](/introduction/vision/a-unified-rwa-framework) {% endcontent-ref %} {% content-ref url="/pages/XiGtmeBWFFxqZZuS40kG" %} [Ecosystem Players](/introduction/vision/ecosystem-players) {% endcontent-ref %} ### **Creating a Coherent Ecosystem** By standardizing with T-REX, we create a more efficient, interoperable, and trustworthy environment for financial asset tokenization, benefiting all stakeholders. A coherent and interoperable ecosystem is essential for successful asset tokenization at scale. The T-REX protocol aims to provide this standardized framework, leveraging the ERC-3643 suite of smart contracts and the guidelines provided by the ERC3643 Association. By ensuring seamless interaction among all stakeholders, it reduces legal and technical hurdles and enhances the reliability of tokenized assets. # Market opportunities The problem with the other tokenization protocols and blockchains *** ## RWAs were limited by tech, not regulation The digital transformation of finance has introduced tokenization as a means to represent real-world assets on the blockchain. However, current tokenization protocols, particularly permissionless tokens like ERC-20, face significant limitations that hinder their effectiveness and adoption. Most RWA chains and protocols overlook that tokenizing an asset doesn't alter the nature of the underlying assets. > Globally, wherever securities regulations exist, asset tokenization is possible. However, this requires the ability to enforce these securities regulations within a blockchain infrastructure. **Existing Limitations:** * **Lack of Compliance Integration**: Most existing tokenization protocols do not integrate compliance mechanisms directly on-chain. This oversight leads to regulatory challenges, lack of transparency, and limits the participation of institutional investors who require strict adherence to financial regulations. * **Fragmented Ecosystem**: The financial industry is highly fragmented, with various silos operating independently. So far, this fragmentation has been replicated on chain. This is exacerbated by the use of private recording systems and blockchains, which, despite their declining popularity, still contribute to a disjointed landscape. As a result, there is no unified ecosystem where all stakeholders can seamlessly and securely interact. * **Distributor-Level Tokenization**: Tokenization often occurs at the distributor level (centralized exchange, bank or broker) rather than at the issuer level. This approach creates multiple ledgers, one for each distributor, leading to inefficiencies and the need for off-chain reconciliation. Without a single, aggregated ledger, the system remains complex and prone to errors. **Market Gaps:** * **Compliance and Control**: There is a pressing need for tokens that enforce compliance rules directly on-chain. Permissioned tokens, which can only be transferred to eligible investors based on compliance criteria, would provide issuers with the necessary assurances to authorize any application on the blockchain. These tokens also offer guarantees to investors, ensuring that they are the legal holders of the underlying assets, even in cases of wallet hacking or theft. * **Real-World Asset Integration**: Current protocols struggle to effectively link real-world assets with their digital representations. This gap limits the potential of blockchain technology in asset management and hampers the adoption of tokenization in traditional finance. * **Unified Registry**: The absence of a single registry that aggregates all transfers and investments from various platforms and distributors is a significant drawback. A unified registry would streamline operations, reduce reconciliation efforts, and enhance transparency. **Issues with simple ERC-20 Tokens:** * **Transfer capable, but not legal**: ERC-20 tokens are technically easy to transfer, but they often represent financial assets that are not freely transferable due to regulatory constraints. This discrepancy creates legal and compliance issues, as the ease of transfer does not align with the regulatory requirements of the underlying assets. These discrepancies undermine investor guarantees. Investors who purchased tokens on the secondary market think they own an asset. However, they do not appear in the legal registry. * **Bearer Instruments**: Most countries have regulations against bearer instruments due to anti-money laundering (AML) and taxation rules. Simple ERC-20 tokens, which can be transferred without compliance checks, often fall into this category, making them non-compliant with regulations. Sanctions vary based on the asset's issuing country and the token holder's country, ranging from fines to imprisonment. **The Need for a New Approach:** To address these challenges, **the industry requires a new approach that integrates compliance, unifies the ecosystem, and effectively links real-world assets with their blockchain representations.** This approach should focus on creating permissioned tokens that ensure great investor experience and compliance, enabling issuers to confidently authorize blockchain applications. By doing so, the industry can move towards a more cohesive and efficient system that benefits all stakeholders, providing them with the assurance of legal ownership and compliance. # RWA Market Needs From a Fragmented Market to a unified Framework *** ## The Need for an Interoperable Ecosystem. Tokenizing financial assets is a complex process due to the intricacies of both finance and blockchain technology. The financial industry involves numerous actors with distinct roles, and the complexity varies based on the type of securities, jurisdictions, and investor types. Additionally, blockchain technology, including smart contracts, is often misunderstood, leading to further complications. ### **Challenges in the Current Landscape:** * **Complexity in Finance and Blockchain**: The intricate nature of finance and the technical complexities of blockchain make tokenization projects difficult to execute. This dual complexity results in lengthy legal and technical challenges. * **Educational Gaps**: There is a significant need for education to bridge the knowledge gap between traditional finance and blockchain technology. * **Incompatibility of Traditional Systems**: Most traditional financial systems are not equipped or compatible with blockchain technology. This incompatibility hinders seamless interaction and integration, further complicating the tokenization process. Due to these challenges, current tokenization projects often lead to poor quality outcomes. These projects provide limited guarantees to investors and lack interoperability within the value chain, hindering seamless interactions between issuers, distributors, and on-chain applications. # A Unified RWA Framework Standardization enables Mass Adoption *** ### **The Urgent Need for Standardization:** To overcome these challenges, market standardization is crucial. A standardized approach to tokenization would streamline the entire process, from issuance and lifecycle management to distribution. This would pave the way for the Great Transition, where most assets are digitized on the blockchain, leading to better management and enhanced liquidity. #### **Benefits of Standardizing the Ecosystem** Adopting a common framework like the T-REX ERC3643 protocol brings numerous advantages to the tokenization of financial assets, streamlining processes and enhancing efficiency. #### **Clear Roles and Execution:** * **Guidelines and Best Practices**: All actors can efficiently execute their roles using established guidelines and best practices, building on the experiences of previous projects and following the official guidelines and solutions provided by the DAO. #### **Interoperability and Compatibility:** * **Single Integration**: Service providers, including law firms, fund administrators, exchanges, and distributors, need only one integration to be compatible with all tokens, reducing technical burdens. * **Seamless Interaction**: Standardized smart contracts enhance interoperability across the value chain, promoting consistent and compatible interactions. #### **Reduced Complexity:** * **Audited Smart contracts**: Using an audited and market-proven standard removes technical complexity, eliminating the need for extensive tech due diligence. * **Time and Cost Efficiency**: Significant savings in time and cost, as issuers, service providers, and investors can rely on the protocol's credibility and widespread use. #### **Accessibility and Trust:** * **Technology Access**: T-REX democratizes access to technology, enabling even small asset owners to leverage tokenization benefits, driving innovation and growth. * **Investor Confidence**: Investors gain assurance that their rights are protected without needing to analyze smart contracts, enhancing trust and adoption. # Ecosystem Players Merging TradFi with DeFi *** ## The T-REX DAO T-REX operates as a Decentralized Autonomous Organization (DAO), an innovative structure that eliminates traditional shareholders. Instead, token holders become the beneficiaries of the T-REX ecosystem, placing power in the hands of the community. T-REX Network manages a strategic treasury, allocating budgets to key initiatives such as the ERC3643 Association and various service providers. It also implements grant programs to stimulate the ecosystem, creating a dynamic environment where innovation and collaboration thrive. ## ERC3643 Association The ERC3643 Association is a non-profit organisation consisting of around 140 select members. {% embed url="" %} 140+ Selected Members. Large FIs, Web3 players and global law firms {% endembed %} These **core contributors** collaborate to develop open-source tools and solutions for the T-REX ecosystem, establish guidelines, and ensure the open-source protocol continually evolves. The association's members are actively engaged in various projects, currently focusing on privacy, cross-chain compatibility, decentralized identity, data management, and innovative tools for token management and distribution. All outputs from these working groups and projects are published publicly and made available to the T-REX Ecosystem. ERC3643 Association receives an annual budget in T-REX tokens from the T-REX DAO. These tokens serve to motivate members to actively contribute to protocol development. ## Builders T-REX Builders specialise in creating and operating products and services compatible with ERC-3643 tokens. They commit to: * Hold T-REX tokens to demonstrate commitment and alignment with official ERC-3643 tools. * Exclusively recognize ERC-3643 tokens issued via the official Token Factory. * Be interoperable and collaborate to create a cohesive and compatible ecosystem. Discover the vetted Builders of the T-REX Ecosystem: {% embed url="" %} ## Community of Investors The T-REX ecosystem stands out by offering the most extensive selection of standardized tokenized assets, providing investors with unparalleled opportunities. By ensuring that assets are tokenized in full compliance and that smart contracts are robustly secure, T-REX instills confidence in investors. Moreover, the ecosystem processes data related to underlying assets in a standardized and certified manner on the blockchain, adding an extra layer of trust and transparency. Investors within the T-REX ecosystem enjoy the convenience of reusing their on-chain identity across various assets, enhancing their investment experience. This cohesive and compatible environment creates compelling incentives for investors to join a thriving community focused on tokenized assets, driving growth and innovation in the space. # Compliant by design T-REX Ledger is the first institutional-grade settlement infrastructure where compliance is not a feature, it is the substrate. T-REX provides a "compliance brain" that operates across every layer. *** ### 1. Token-Level Enforcement (ERC-3643) Unlike general-purpose blockchains that rely on simple wallet whitelisting, T-REX enforces compliance directly within the smart contract logic of the asset thanks to the T-REX Protocol (ERC-3643). * Embedded KYC/AML: Every transfer triggers a real-time check against the OnchainID identity registry. * Modular Rule Engine: Issuers can program specific restrictions based on jurisdiction, investor type (e.g., Accredited vs. Qualified), holding periods, etc. * The "Golden Record": The T-REX Ledger maintains the definitive book of record for ownership, ensuring that even when assets move cross-chain, the compliance rules remain intact and non-bypassable. *** ### 2. Infrastructure & Sequencer Security The T-REX Ledger is powered by a production-grade OP Stack deployment, managed via a professional team to ensure institutional-grade reliability and security. * **Institutional PoA Consortium**: The network is operated by a consortium of regulated financial institutions and Tier-1 Web3 corporates who serve as Proof-of-Authority (PoA) validators, co-signing key network events. * **Sequencer-Level Screening**: Compliance starts at the gateway. The sequencer will include OFAC-configurable ingress screening and AI-powered detection to identify and block suspicious behaviors or known bad actors before they reach the execution layer. * **Guardian Role**: To mitigate critical security incidents, T-REX authorized engineers hold a "Guardian" role, providing the ability to pause L1 withdrawals in the event of a vulnerability or hack. *** ### 3. Curated AppStore Excellence Compliance extends to the tools and services interacting with the ledger. The T-REX AppStore is a gated ecosystem. * **Vetted Providers**: Only "Institutional Grade" providers who pass the T-REX Committee's five-dimensional vetting process (Utility, Business Model, Security, Compliance, and Reliability) are listed. * **Verified Badge**: Approved applications receive the "T-REX Certified" badge, ensuring they meet global securities regulations and technical standards. * **Non-Circumvention**: Providers are legally bound to maintain high SLAs and strict data protection standards (GDPR/PIPA). *** ### 4. Regulatory & Legal Framework T-REX is structured to provide legal certainty for the world's largest asset managers. * **Bermuda DABA License (pending approval)**: The network operator (Digital Asset Operational Services ISAC Ltd.) is seeking a Digital Asset Business Act (DABA) license from the Bermuda Monetary Authority (BMA), covering issuance, custody, and exchange operations. * **MiCA Compliance**: We are filing a MiCA whitepaper in the EU to ensure the upcoming utility token is compliant for admission to trading across the European Union. * **Clear classification**: The utility token will be strictly a utility token for gas, governance, and service credits, separate from the security tokens it settles. * **Permissioned Settlements**: We are currently evaluating the integration of permissioned stablecoins and native cash legs like USD1 to ensure the entire transaction lifecycle, from gas to settlement, remains within a regulated perimeter. *** ### 5. Privacy without Anonymity Through our partnership with Zama, T-REX will offer optional Fully Homomorphic Encryption (FHE). * **Confidential Transfers**: Institutions can keep balances and transaction details encrypted while still allowing smart contracts to perform compliance checks. * **Programmable Decryption**: Regulators can be granted "view keys" for specific data, enabling oversight without exposing sensitive commercial information to the public. # Roadmap Clear and Ongoing Roadmap *** ## 2017-2025 * Create and battle-test the token protocol with 140+ token issuers * Develop core building blocks: Smart contracts suite, APIs, web interfaces, add-ons * Validation with 20+ regulators in key financial jurisdictions * Create the largest RWA non-profit association: ERC3643.org *** ## 2026 * T-REX Ledger: Test net of the RWA Reference chain * Key partnerships with technology providers and asset servicers * Grant programs for Builders and RWA issuers * Builders solutions onboarding * Release of the T-REX Factory dApp * Release of the OnchainID dApp * Release of the AssetID dApp * Release of the DINO Primary dApp * Release of the DINO Secondary dApp * Partnerships with Exchanges * T-REX Token launch * T-REX Ledger: Main net of the RWA Reference chain *** ## 2026-2035 * Tokenization of 10T USD of assets * Reach 1M holders exposed to tokenized RWAs # T-REX Protocol The market standard for compliant tokenization and on-chain distribution. *** The ERC-3643 protocol - code name "T-REX" - is a sophisticated suite of audited smart contracts designed to streamline the tokenization of financial assets. It enables the seamless representation of assets, the data of their underlying assets (documents, price, rating, certifications, etc.), and the legal identification of various stakeholders on the blockchain. Additionally, it facilitates the tracking of all investment activities, including transactions, investments, and redemptions. Currently, ERC-3643 is the sole standard for tokenized securities recognized by the Ethereum community: ## Key Features of T-REX ERC-3643 * **Multi-chain Protocol**: The ERC-3643 protocol can be easily deployed and operated on any EVM-compatible blockchain, ensuring flexibility and broad applicability. * **Efficient Token Issuance**: Issuers can deploy tokens in a single transaction while setting compliance and distribution rules. This efficiency simplifies the issuance process and enhances control. * **Data Enrichment**: Tokens can be enriched with detailed data using embedded AssetID smart contracts, providing comprehensive information about the underlying assets on the blockchain. This feature enhances transparency, builds investor confidence, and enables advanced DeFi applications. * **Identity Verification**: Investors' identities are represented anonymously using verifiable credentials on the blockchain. This ensures compliance while maintaining the confidentiality of investor data. The protocol is using an open DID framework compatible with all KYC solutions and agents. * **Compliance Modules**: Additional compliance modules can be linked to the RWA tokens to enforce regulatory requirements directly on-chain. This ensures that all transactions adhere to predefined rules. Most of the time, these compliance modules are used to enforce offering rules, applicable to all investors. * **Centralized Registry**: The protocol establishes a centralized but confidential registry on the blockchain, managed by the issuer or authorized agents (Transfer agent, CSD, etc.). This registry serves as a single, transparent source of truth accessible to all distributors and applications, reducing the need for off-chain reconciliation. * **Automated Operations**: Rules for managing and transferring tokens are applied automatically and in real-time on the blockchain. This automation enhances efficiency and reduces the risk of errors. * **DeFi Compatibility**: Assets tokenized using ERC-3643 are compatible with all decentralized finance (DeFi) applications, opening new opportunities for growth and innovation. Learn more about the T-REX protocol: {% embed url="" %} Learning center {% endembed %} Read the official documentation from the ERC3643 Association: {% embed url="" %} Official ERC-3643 documentation {% endembed %} ## Creating a Token-Centric Economy. ERC-3643 enables the creation of a token-centric economy by providing a robust framework for asset tokenization. Its comprehensive features ensure compliance, enhance transparency, and streamline operations, making it an ideal solution for modern financial asset management. # T-REX Apps Official Solutions and Add-ons to the ERC-3643 smart contracts *** ## On-chain Factories On-chain factories are official and ready-to-use smart contracts provided to the T-REX community. #### Token deployments The T-REX network provides a token factory in accordance with the guidelines set by the ERC-3643 Association. These smart contracts, already available on numerous EVM-compatible blockchains, **enable the deployment of Real-World Asset (RWA) tokens with just a few clicks**, eliminating technical complexities and ensuring that the tokens are secure. The factory utilizes the latest, audited version of the ERC-3643 protocol. All tokens deployed through these official on-chain factories receive a claim in their assetID, verifying their origin and **compliance with the ERC3643 Association's guidelines**. This approach ensures that users can confidently deploy tokens that meet the highest standards of security and compliance, streamlining the tokenization process. #### Self-sovereign identities The network also provides a factory for on-chain identities, known as onchainIDs, which are integral to the ERC-3643 protocol. These identities, represented as smart contracts on the blockchain, **enable the identification of various stakeholders** within the ecosystem (issuers, agents, investors, regulators). The open model of this decentralized identity system ensures compatibility with any identification solutions that support digital signatures. Coded in Solidity, these smart contracts are accessible on the same EVM-compatible blockchains as the token factory, facilitating seamless integration and interoperability across the network. #### Asset identities Tokens issued by the token factory include an assetID by default, which operates on the same principles as self-sovereign identities. These assetIDs represent the underlying assets of the tokens and allow for data enrichment. For example, they can include details such as the issuer's Legal Entity Identifier (LEI), the financial instrument's International Securities Identification Number (ISIN), the token's Digital Token Identifier (DTI), the token's price (Net Asset Value), ratings and even legal documents. This information can be signed and certified, either by the issuer or authorized third parties, such as regulators or auditors, **ensuring the data's authenticity**. These smart contracts, coded in Solidity, are accessible on the same EVM-compatible blockchains as the token factory, facilitating seamless integration and data verification. ## Applications already selected #### T-REX Engine - :white\_check\_mark: LIVE A complete, secure and scalable set of APIs to interact with ERC-3643 tokens and the T-REX ecosystem. #### T-REX Platform - :white\_check\_mark: LIVE A turnkey white-label platform to onboard RWA investors, collect their investments, manage portfolio, and access applications compatible with the T-REX ecosystem. #### AssetID dApp - :construction\_site: Q4 2025 A simple and free decentralized application to verify claims on asset identities. #### OnchainID dApp- :construction\_site: Q4 2025 A simple and free decentralized application to verify claims on stakeholders' identities (Investors, issuers, agents, regulators). #### DINO *Primary* dApp - :construction\_site: Q1 2026 An example of decentralized application connected to the DINO primary market distribution network for compliant security tokens and RWAs. #### DINO *Secondary* dApp - :construction\_site: Q1 2026 An example of decentralized application connected to the DINO secondary liquidity network for compliant security tokens and RWAs. #### T-REX Cash - :construction\_site: Q2 2026 A permissioned cash coin made available to the RWA ecosystem. It relies on the T-REX on-chain identities to track and guarantee ownership. It is pegged by a selection of stablecoins available on the market. ### Call for Builders The Builders applications have been thoroughly assessed for their compatibility and suitability with the ecosystem before being made available. You are interested in providing your solutions to the T-REX ecosystem? Contact us: # DINO Shared Distribution & Liquidity Layer for T-REX *** Dino is the onchain distribution and market infrastructure of the T-REX ecosystem. It provides a shared set of smart contracts that any issuer, distributor, broker-dealer, or dApp builder can plug into to distribute and trade ERC-3643 (T-REX) tokens. Instead of every project deploying its own isolated subscription forms and OTC order books, Dino runs on a **shared infrastructure (the T-REX Ledger)**. This turns fragmented primary and secondary flows into a common liquidity pool, where all participants benefit from the same rails and network effects. ### What Dino Does At a high level, Dino provides three building blocks: * **DinoFactory** – Deploys and wires Dino contracts (Primary & Secondary) for a given ERC-3643 token, with standardized roles, fees, and permissions. * **DinoPrimary** – Handles **onchain subscription and redemption** flows for T-REX tokens in the primary market (investors subscribing to new tokens or redeeming them with the issuer). * **DinoSecondary** – Handles **onchain trading intents** in the secondary market (investors posting offers to buy or sell existing T-REX tokens). Together, they form a **single onchain venue** where compliant primary flows and secondary trading can coexist for any ERC-3643 token connected to the T-REX Ledger. ### Dino Primary: On-Chain Subscriptions & Redemptions **DinoPrimary** is the primary market layer for T-REX tokens: * Issuers (or their distributors) can open **subscription windows** and let qualified investors subscribe onchain using approved payment tokens (e.g. stablecoins). * The same rail can be used for **redemptions**, allowing investors to sell tokens back to the issuer under predefined rules. * All flows are **compliance-aware**, leveraging the ERC-3643 identity and eligibility checks (Identity Registry, ONCHAINID, etc.). For the user, this can look like a simple “Invest” / “Redeem” button in a dApp or platform UI. Under the hood, all issuers use the **same DinoPrimary infrastructure**, which: * Standardizes subscription and redemption logic. * Applies ecosystem fees in a predictable way. * Ensures that investor qualification and token compliance are enforced at the contract level. The result: **repeatable, interoperable primary flows** for any compliant RWA, instead of one-off bespoke implementations per issuer. ### Dino Secondary: Shared Intent-Based Liquidity **DinoSecondary** is the secondary market layer: * Investors can publish **offers (intents) to buy or sell** a given T-REX token against another token (typically a payment token). * Other participants can **take those offers**, fully or partially, enabling peer-to-peer trading. * Offers are managed onchain with expiry, pruning, and compliance checks built in. Because DinoSecondary is shared: * Any broker-dealer, platform, or dApp can plug into the same **pool of offers**. * Liquidity doesn’t get siloed inside a single interface, it’s **aggregated at the contract level**. * The same fee and compliance framework applies to all trades, simplifying integrations. This creates a **common secondary liquidity network** for ERC-3643 tokens, rather than fragmented OTC channels scattered across different systems. ### Running on the T-REX Ledger: Shared Infrastructure by Design Dino contracts are deployed on the **T-REX Ledger**, which acts as the reference chain for compliance and market infrastructure across the ecosystem. Because DinoPrimary and DinoSecondary are **shared contracts on this common ledger**: * Any compliant ERC-3643 token can attach to the same **primary and secondary rails** via the DinoFactory. * Distributors, broker-dealers, custodians, and platforms can integrate once and access **all Dino-enabled tokens**. * New apps (e.g. white-label platforms, bespoke institutional portals, wallets, or aggregators) can reuse the same contracts and liquidity instead of rebuilding their own infrastructure. In other words, Dino is not a single app, it is **the onchain market layer** that all T-REX-compatible apps can build on. ### Who Is Dino For? Dino is designed to be used by: * **Issuers & Fund Managers**\ Use DinoPrimary to run compliant onchain subscriptions and redemptions for their RWA programs. * **Distributors, Broker-Dealers & Market Operators**\ Plug into DinoPrimary and DinoSecondary to distribute products and provide liquidity without reinventing the rails. * **Platforms & dApp Builders**\ Build investor-facing experiences on top of shared infrastructure, benefiting from common standards, fees, and compliance behavior. * **Investors**\ Interact through any connected dApp to subscribe, redeem, and trade T-REX tokens, while always benefiting from the same underlying onchain logic. ### Dino in the T-REX Apps Stack Within the broader T-REX ecosystem: * **T-REX Engine** exposes APIs to interact programmatically with Dino contracts. * **T-REX Platform** and dedicated dApps (DINO Primary dApp, DINO Secondary dApp) provide investor-facing UIs on top of these contracts. * **Dino** itself is the **neutral, shared smart contract layer** that all of these applications use for distribution and trading. The detailed mechanics of primary subscriptions/redemptions and secondary offers/trades are described on the next pages: * **Dino Primary** (primary market flows) * **Dino Secondary** (secondary market flows) * **Dino Factory** (deployment and access control) ### **Commercial Service** DINO applications are provided by [Tokeny](https://tokeny.com/) # DINO Primary Dino Primary is the **primary market rail** of the T-REX ecosystem.\ It is a shared smart contract, deployed on the [**T-REX Ledger**](/t-rex-network/t-rex-ledger), that standardizes how investors: * **Subscribe** to new ERC-3643 (T-REX) tokens, and * **Redeem** those tokens back to the issuer, with **instant onchain settlement**, **compliance checks**, and a **configurable rule set** controlled by the issuer and its delegates. Instead of each issuer building its own bespoke subscription and redemption logic, Dino Primary provides a **common infrastructure layer** that any issuer, distributor, broker-dealer or dApp can reuse. ### Key Features * **Standardized subscription & redemption flows**\ Unified logic across all Dino-enabled ERC-3643 tokens, with instant settlement onchain. * **Multiple payment tokens**\ Issuers can accept several payment tokens (e.g. stablecoins and non-stable tokens) and configure them per asset. * **Price oracle integration**\ Dino Primary plugs into price feeds so the contract can compute how many asset tokens correspond to a given payment amount. * **Per-asset rule configuration**\ Issuers (or their admins) can configure: * Subscription and redemption open/close * Minimum and maximum amounts * Accepted payment tokens * Optional **malus / haircut** on redemptions * Referral fees for distributors * **Built-in compliance**\ Dino Primary is designed for tokens following the **ERC-3643** standard. It relies on the Identity Registry and token compliance modules to ensure that only verified and eligible investors can subscribe or redeem. * **Shared infrastructure on the T-REX Ledger**\ All participants — issuers, distributors, platforms, and investors — share the same contract infrastructure, making integrations repeatable and interoperable. ### Actors & Roles At a conceptual level, Dino Primary involves: * **Issuer / Issuer Safe**\ The party responsible for the asset and the wallet that receives subscription proceeds and pays redemptions. * **Investors**\ Wallets holding ERC-3643 tokens (or subscribing for them) that are verified and compliant. * **Distributors / Platforms / dApps**\ Front-ends integrating with Dino Primary to offer “Invest” and “Redeem” experiences to end-users. * **Dino Primary Contract**\ The onchain logic handling subscriptions and redemptions, enforcing rules, collecting ecosystem fees, and talking to the ERC-3643 token. Under the hood, Dino Primary uses an [**AccessManager**](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) with separate roles (e.g. admin, token manager, rules manager) so issuers can clearly separate: * Who can configure payment tokens, * Who can adjust subscription/redemption rules, * Who can manage overall administration. Details of these roles and functions are covered in the *Dino Primary – Admin & Management* subpage. ### Subscription Flow A **subscription** is when an investor buys ERC-3643 tokens from the issuer, paying with an approved payment token. High-level flow: 1. **Configuration by the issuer** * The issuer (or its delegates) configures: * Subscription open/close status, * Min/max subscription amounts, * Accepted payment tokens and their price feeds. 2. **Investor eligibility** * The investor must: * Be registered in the **Identity Registry** (ONCHAINID linked to their wallet), * Pass the usual ERC-3643 compliance checks (jurisdiction, investor type, etc.). 3. **Investor action** * The investor approves the **payment token** (e.g. stablecoin) for Dino Primary. * The investor calls the `subscribe(amount, paymentToken)` function via a dApp or platform. 4. **On-chain processing** * Dino Primary: * Verifies that subscriptions are open and within configured limits. * Verifies the investor’s eligibility and token compliance. * Transfers the payment token to the issuer’s safe address. * Allocates the ERC-3643 tokens to the investor using one of two approaches: * **Preminted treasury**: tokens are transferred from the issuer’s treasury wallet. * **On-the-fly mint**: tokens are minted directly to the investor (Dino Primary acts as a minter agent of the token). 5. **Settlement & logging** * The transaction settles **atomically** on-chain. * A `Subscribed` event is emitted with the relevant details for off-chain systems. From a front-end perspective, this is typically surfaced as a simple **“Invest”** button with fields for amount and payment token, while all compliance and settlement logic happens within Dino Primary and the ERC-3643 token. ### Redemption Flow A **redemption** is when an investor sells their ERC-3643 tokens back to the issuer under pre-defined rules. High-level flow: 1. **Configuration by the issuer** * The issuer configures: * Whether redemptions are open, * Min/max redemption amounts, * Accepted payment tokens, * Optional **malus** (a penalty or haircut on the redemption price). 2. **Investor eligibility** * As with subscriptions, the investor must remain compliant and verified under ERC-3643 rules. 3. **Investor action** * Optional *–* The investor approves the **asset token** (ERC-3643) for Dino Primary *–* only applicable if **Preminted treasury** where the tokens need to be transferred back to the Issuer. * The investor calls `redeem(amount, paymentToken)` via a dApp. 4. **Onchain processing** * Dino Primary: * Verifies that redemptions are open and limits are respected. * Re-checks investor eligibility and compliance. * Handles the ERC-3643 tokens using one of two approaches: * **Preminted treasury**: tokens are transferred back to the issuer’s treasury. * **Burning**: tokens are burned from the investor (Dino Primary acts as an agent with burn permissions). * Calculates the payment amount, optionally applying a **malus** if configured. * Transfers the payment token from the issuer’s safe address to the investor. 5. **Settlement & logging** * The transaction settles atomically. * A `Redeemed` event is emitted with all key parameters. From the end-user perspective, this is usually exposed as a **“Redeem”** or **“Sell back to issuer”** action with clear display of applicable rules and any malus. ### Payment Tokens & Pricing Dino Primary supports: * **Stable payment tokens**\ Tokens considered stable against the reference asset (e.g. USD), where pricing can be treated as 1:1 or based on simple rules. * **Non-stable payment tokens**\ Tokens whose value fluctuates (e.g. other cryptocurrencies). For these, Dino Primary integrates with a **price oracle** implementing [AggregatorV3Interface](https://docs.chain.link/data-feeds/api-reference#aggregatorv3interface) configured per payment token. This allows issuers to: * Offer subscriptions/redemptions in several currencies or tokens. * Keep the asset priced in one reference unit (e.g. NAV in USD) while accepting payments in different tokens. The configuration and management of payment tokens is described in the *Dino Primary – Admin & Management* subpage. ### Compliance & ERC-3643 Integration Dino Primary is designed to work with **ERC-3643 permissioned tokens**: * Every investor wallet is linked to an **ONCHAINID** in the Identity Registry. * The ERC-3643 token enforces: * KYC/AML status, * Jurisdiction rules, * Investor categorization (retail/professional, etc.), * Any additional custom compliance logic. When a subscription or redemption is attempted, Dino Primary: 1. Calls into the ERC-3643 token / Identity Registry to confirm: * The investor is registered and eligible. * The transfer or burn/mint operation is allowed by compliance rules. 2. Executes the token transfer or burn/mint only if all checks pass. This ensures that **every primary market operation is compliance-aware by design**, not just at the UI layer. ### Integration Patterns for Platforms & dApps Typical integration steps for a platform building on Dino Primary: 1. **Discovery** * Fetch Dino Primary configuration for a given token: * Subscription and redemption status. * Min/max amounts. * Accepted payment tokens and, where useful, their price feeds. 2. **Pre-checks** * Check that: * The investor is onboarded and linked to an ONCHAINID. * The wallet is approved in the relevant Identity Registry. * The transaction respects compliance rules defined at ERC-3643 level (call `canTransfer(address from, address to, uint256 amount)` on the compliance contract). * Any off-chain checks (e.g. investor questionnaire) are completed. 3. **User flows** * For subscriptions: * Guide user to approve the payment token. * Call `subscribe(amount, paymentToken)` and track the emitted event. * For redemptions: * Guide user to approve the asset token (only if **Preminted treasury**). * Call `redeem(amount, paymentToken)` and track the emitted event. 4. **Post-trade processing** * Listen to `Subscribed` / `Redeemed` events to: * Update portfolio views, * Trigger reporting, * Synchronize with off-chain systems (e.g. transfer agent, fund admin, custodians). Because Dino Primary is a **shared contract** on the T-REX Ledger, the same integration can be reused across multiple assets, issuers, and distribution channels. ### Related Documentation For more detailed and technical information, see the subpages: * [**Dino Primary – Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-primary/admin-and-management)\ Roles, rule configuration, payment token management, fee model. * [**Dino Primary – Developer Reference**](/t-rex-network/t-rex-apps/dino/dino-primary/developer-reference)\ Solidity interfaces, function signatures, events, error codes, and integration examples. These pages are where you can expose the content from your existing `DinoPrimary.md` and the actual contract interface, while keeping this page focused on the conceptual behavior and business logic. # Admin & Management This page explains **how to operate and configure** the Dino Primary contract: * How access control works (roles & responsibilities) * Which functions are available to admins, token managers, and rules managers * How payment tokens, subscription windows, redemption windows and malus are configured * How fees and events fit into the operational model For Solidity interfaces, function signatures, and low-level integration details, see the [**Dino Primary – Developer Reference**](/t-rex-network/t-rex-apps/dino/dino-primary/developer-reference) ## Access Control System Dino Primary uses [OpenZeppelin’s **AccessManager**](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) to enforce fine-grained permissions. Instead of hard-coding `onlyOwner` logic, each mutating function is protected by AccessManager, which checks whether the caller has the appropriate **role** before allowing execution. ### Roles Dino Primary defines three logical roles: | Role | Value | Description | Typical Holder(s) | | -------------------- | ----- | --------------------------------------------------------------- | ------------------------------------------ | | `ADMIN_ROLE` | `0` | Global administrative role | Issuer Safe / Issuer Ops / Governance Safe | | `TOKEN_MANAGER_ROLE` | `1` | Manages accepted payment tokens | Issuer Treasury / Ops Team | | `RULES_MANAGER_ROLE` | `2` | Manages subscription & redemption rules (timing, limits, malus) | Issuer Risk / Product / Compliance | {% hint style="info" %} The numeric values (`0`, `1`, `2`, …) are configured in the AccessManager contract. Dino Primary only checks that the caller is **authorized** for a given function via its `restricted` modifier; it is the AccessManager that maps accounts to roles. {% endhint %} ### How Roles Are Granted Roles are not granted directly by Dino Primary itself. Instead: 1. Dino Primary is deployed and **initialized** with the address of an `AccessManager` contract. 2. That AccessManager is responsible for: * Attaching permissions to each Dino Primary function selector * Assigning roles to actual addresses (EOAs, multisigs, other contracts). Typical pattern: * The Token Owner is set as **admin** of the AccessManager. * The Token Owner then assigns: * `ADMIN_ROLE` to the issuer’s main treasury or governance multisig; * `TOKEN_MANAGER_ROLE` to treasury/ops; * `RULES_MANAGER_ROLE` to the team in charge of product / risk / compliance. {% hint style="success" %} In practice, you usually want: * A **multisig** (e.g. Safe) to hold `ADMIN_ROLE`; * One or more dedicated ops / treasury addresses to hold `TOKEN_MANAGER_ROLE`; * A separated address (or multisig) for `RULES_MANAGER_ROLE` to keep configuration changes auditable and controlled. {% endhint %} ### Admin Management Settings (`ADMIN_ROLE`) Holders of `ADMIN_ROLE` can manage **core configuration** of Dino Primary. #### Core Admin Functions | Setting | Function | Role | Description | | ---------------- | ------------------ | ------------ | --------------------------------------------------------------------------- | | Issuer Safe | `updateIssuerSafe` | `ADMIN_ROLE` | Updates the address receiving subscription proceeds and paying redemptions. | | Preminted Status | `updatePreminted` | `ADMIN_ROLE` | Sets whether the asset is **preminted** or not. | #### Issuer Safe The **issuer safe** is the central wallet used for: * **Subscriptions**: subscription proceeds (payment tokens) are sent *to* this address. * **Redemptions**: redemption payments (payment tokens) are paid *from* this address. Changing the issuer safe: * Does **not** affect past transactions, * But all future fund flows will use the new address. {% hint style="warning" %} Make sure the new issuer safe: * Is under appropriate control (e.g. issuer’s treasury multisig), * Holds enough balance of each **payment token** to fulfil redemptions, * Is properly set up so that the `DinoPrimary` contract has an allowance to transfer payment tokens out of the issuer safe address for paying redemptions. * Is properly integrated with your off-chain bookkeeping and reporting. {% endhint %} #### **Preminted vs Non-Preminted Mode** The `preminted` flag indicates **how the ERC-3643 token supply is handled**: * `preminted = true` * The issuer has already **minted** a supply of tokens into a treasury address. * Dino Primary will **transfer** tokens from that treasury to investors on subscription, and back to treasury on redemption. * `preminted = false` * Token supply is minted **on demand**. * Dino Primary acts as an **authorized agent** on the ERC-3643 token and: * **Mints** new tokens directly to the investor on subscription; * **Burns** tokens from the investor on redemption. {% hint style="info" %} The choice between preminted / non-preminted is defined at product design level. Changing it mid-life is a sensitive operation and should be aligned with your token economics and legal documentation. {% endhint %} ### Token Manager Settings (`TOKEN_MANAGER_ROLE`) Holders of `TOKEN_MANAGER_ROLE` configure which **payment tokens** can be used for subscriptions and redemptions, and how they are priced. #### Payment Token Management Dino Primary exposes three management functions: | Setting | Function | Role | Description | | -------------------- | -------------------- | -------------------- | ------------------------------------------------------------------------ | | Add Payment Token | `addPaymentToken` | `TOKEN_MANAGER_ROLE` | Registers a new payment token with its price feed and stability flag. | | Remove Payment Token | `removePaymentToken` | `TOKEN_MANAGER_ROLE` | Deregisters a payment token (no longer accepted for new flows). | | Update Payment Token | `updatePaymentToken` | `TOKEN_MANAGER_ROLE` | Updates price feed and/or stability status of an existing payment token. | Each payment token is associated with: * `token` – ERC-20 address of the payment token; * `priceFeed` – an oracle contract implementing the [AggregatorV3Interface](https://docs.chain.link/data-feeds/api-reference#aggregatorv3interface); * `isStable` – boolean indicating whether the token is considered *stable* vs the pricing currency used for the asset (e.g. NAV in USD). {% hint style="info" %} * For **stable tokens** (e.g. fully backed USD stablecoins), the price feed may be trivial (1:1) or reflect a tight peg. * For **non-stable tokens** (e.g. volatile crypto), Dino Primary uses the price feed to compute how many asset tokens correspond to a given payment amount. {% endhint %} #### Operational Guidelines * Only add payment tokens that: * Have reliable liquidity and oracle feeds; * Are supported by your compliance / risk policies. * Removing a payment token: * Does **not** affect past subscriptions/redemptions, * But prevents **new** operations using that token. * Updating a price feed is **sensitive**: * Always ensure the feed address is correct and from a trusted oracle provider; * Consider multi-sig confirmation or governance procedures for changes. ### Rules Manager Settings (`RULES_MANAGER_ROLE`) Holders of `RULES_MANAGER_ROLE` configure **when** subscriptions/redemptions are allowed and within which **limits**, plus the **malus** applied on redemption. #### Subscription Rules Subscription rules are updated via: | Setting | Function | Role | Description | | ------------------ | ------------------------- | -------------------- | ------------------------------------------- | | Subscription Rules | `updateSubscriptionRules` | `RULES_MANAGER_ROLE` | Sets subscription period and amount limits. | Parameters: * `dateOpened` – timestamp when subscriptions become possible; * `dateClosed` – optional timestamp when subscriptions end (`0` may mean “no end”); * `minAmount` – minimum amount of ERC-3643 tokens that an investor can subscribe in a single transaction; * `maxAmount` – maximum amount of ERC-3643 tokens that an investor can subscribe in a single transaction. Subscriptions are only accepted when: * `dateOpened <= block.timestamp`, and * `dateClosed == 0` *or* `block.timestamp <= dateClosed`, and * `minAmount <= amount <= maxAmount`. {% hint style="success" %} You can use `minAmount` / `maxAmount` to enforce ticket size policies (e.g. minimum investment amount or tranche-specific caps). It can be combined with specific Compliance Modules on the ERC-3643 token to limit volumes on a time basis or holdings per investor for example. {% endhint %} #### Redemption Rules & Malus Redemption rules are updated via: | Setting | Function | Role | Description | | ---------------- | ----------------------- | -------------------- | --------------------------------------------------------------------------- | | Redemption Rules | `updateRedemptionRules` | `RULES_MANAGER_ROLE` | Sets redemption period, amount limits, and **redemption malus** percentage. | Parameters mirror subscription rules, with one extra field: * `redemptionMalus` – a **basis point** value (e.g. 100 = 1%, 500 = 5%) representing a haircut applied to redemption amounts. When investors redeem: 1. Dino Primary computes the gross amount owed based on the asset price and quantity. 2. It applies the **malus**: * Malus amount = `grossAmount * malusBps / 10_000`; * Net paid to investor = `grossAmount - malusAmount`. This allows the issuer to model: * Exit penalties, * Early redemption haircuts, * Liquidity management fees. {% hint style="danger" %} Any change to redemption rules (especially `malus`) should be clearly disclosed to investors and reflected in legal / regulatory documentation. {% endhint %} ### Fee System Dino Primary integrates with the **T-REX Ecosystem Fee Collector** to charge protocol-level fees on top of the asset economics. #### Operation Fees Per design, Dino Primary applies **multipliers** on a base ecosystem fee: | Operation | Fee Multiplier | Description | | --------- | -------------- | -------------------------------------------- | | Subscribe | `3x` base fee | Fee charged on each subscription transaction | | Redeem | `3x` base fee | Fee charged on each redemption transaction | The **base fee**, fee token, and recipient are managed by the **ecosystem fee collector**, not by the Dino Primary contract itself. #### Fee Collection Flow * On each subscription or redemption: * Dino Primary calls `ecosystemFeeCollector.collectFee(msg.sender, FEE_MULTIPLIER_*)`. * The user must have: * **Approved** the fee token for the ecosystem fee collector; * Sufficient fee token balance. {% hint style="info" %} Issuers do *not* configure fee amounts inside Dino Primary. They only need to ensure users are aware of the ecosystem fee and that the fee set at the protocol level is acceptable for their use case. {% endhint %} {% hint style="success" %} A fee abstraction layer can be used to allow users to pay the ecosystem fees with any payment token for more convenience and reduced user friction. {% endhint %} ### Events & Monitoring Dino Primary emits events for all important administrative and economic actions. These can be indexed by back-office systems, analytics, and monitoring tools. #### Admin / Config Events | Event | Description | | -------------------------- | --------------------------------------------------------- | | `IssuerSafeUpdated` | Emitted when the issuer safe address is changed. | | `PremintedUpdated` | Emitted when the `preminted` status is updated. | | `PaymentTokenAdded` | Emitted when a new payment token is added. | | `PaymentTokenRemoved` | Emitted when a payment token is removed. | | `PaymentTokenUpdated` | Emitted when a payment token’s feed/stability is updated. | | `SubscriptionRulesUpdated` | Emitted when subscription rules are changed. | | `RedemptionRulesUpdated` | Emitted when redemption rules / malus are changed. | #### Economic Events | Event | Description | | ------------ | ----------------------------------------- | | `Subscribed` | Emitted on every successful subscription. | | `Redeemed` | Emitted on every successful redemption. | Each `Subscribed` / `Redeemed` event contains the **nonce**, investor, amounts and payment token, allowing: * Portfolio reconstruction, * Regulatory reporting, * Reconciliation with off-chain systems (fund admin, custodian, TA, etc.). #### AccessManaged Events Inherited from the AccessManaged / AccessManager system: | Event | Description | | ------------------ | ------------------------------------------------------------------- | | `AuthorityUpdated` | Emitted when the AccessManager controlling Dino Primary is updated. | {% hint style="success" %} In production, you should index at least: `IssuerSafeUpdated`, `PaymentToken*`, `SubscriptionRulesUpdated`, `RedemptionRulesUpdated`, `Subscribed`, and `Redeemed`. This makes it easy to audit configuration changes and reconstruct investor activity. {% endhint %} ### Typical Operational Lifecycle Putting it all together, a typical lifecycle for a new asset is: 1. **Deployment & Initialization** * Dino Primary is deployed and initialized with: * ERC-3643 token address, * Initial issuer safe, * `preminted` flag, * AccessManager address, * Ecosystem fee collector. 2. **Role Assignment** * AccessManager admin assigns: * `ADMIN_ROLE` to issuer governance / treasury, * `TOKEN_MANAGER_ROLE` to treasury/ops, * `RULES_MANAGER_ROLE` to risk/product/compliance. 3. **Payment Token Setup** * `TOKEN_MANAGER_ROLE` adds one or more payment tokens (USD1, USDC, etc.) with price feeds. 4. **Rule Setup** * `RULES_MANAGER_ROLE` sets initial subscription and redemption rules (dates, min/max, malus). 5. **Operation** * Investors subscribe and redeem via connected dApps/platforms. * Ops teams can adjust rules, add/remove payment tokens, and eventually update issuer safe if needed. 6. **Monitoring** * Back-office systems listen to events to track configuration changes and investor activity. # Developer Reference This page documents the **public interface** of the `DinoPrimary` contract: * Solidity interface (high-level) * Function-by-function behavior (with access control & revert reasons) * Events & custom errors Admin concepts (roles, issuerSafe, preminted, rules, etc.) are described on the [**Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-primary/admin-and-management) page; here we focus on how to **call** the contract. ### Contract & Imports ```solidity import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol"; import { IERC3643 } from "@erc3643org/erc-3643/contracts/ERC-3643/IERC3643.sol"; import { AggregatorV3Interface } from "@chainlink/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol"; import { IDinoPrimary } from "./interfaces/IDinoPrimary.sol"; import { IFeeCollector } from "./interfaces/IFeeCollector.sol"; contract DinoPrimary is IDinoPrimary { /* ... */ } ``` Each asset has **its own instance** of `DinoPrimary`, typically deployed and initialized via **DinoFactory**. ### State Variables (Public Getters) `DinoPrimary` exposes a few public variables: ```solidity IERC3643 public erc3643; address public issuerSafe; bool public preminted; IFeeCollector public ecosystemFeeCollector; uint256 public nonce; mapping(address => PaymentToken) public approvedPaymentTokens; ``` * `erc3643()` – underlying ERC-3643 token for this primary rail. * `issuerSafe()` – address receiving subscription proceeds and paying redemptions. * `preminted()` – `true` if supply is pre-minted in a treasury and transferred; `false` if `DinoPrimary` mints/burns. * `ecosystemFeeCollector()` – protocol fee collector. * `nonce()` – incremented per subscription / redemption; also emitted in events. * `approvedPaymentTokens(token)` – returns price feed and stability info for a payment token. {% hint style="info" %} You won’t write to these directly – use the admin functions and rely on DinoFactory for initialization. {% endhint %} ### Solidity Interface ```solidity interface IDinoPrimary { // --- Lifecycle / Setup --- function initialize( address _erc3643, address _issuerSafe, bool _preminted, address _accessManager, address _ecosystemFeeCollector ) external; // --- Investor functions --- function subscribe( uint256 amount, address paymentToken ) external returns (uint256 nonce); function redeem( uint256 amount, address paymentToken ) external returns (uint256 nonce); // --- Preview helpers (read-only) --- function previewSubscribeWithExactErc3643( uint256 erc3643Amount, address paymentToken ) external view returns (uint256 paymentTokenAmount); function previewSubscribeWithExactToken( uint256 paymentTokenAmount, address paymentToken ) external view returns (uint256 erc3643Amount); function previewRedeemWithExactErc3643( uint256 erc3643Amount, address paymentToken ) external view returns (uint256 paymentTokenAmount); function previewRedeemWithExactToken( uint256 paymentTokenAmount, address paymentToken ) external view returns (uint256 erc3643Amount); // --- Payment token management (TOKEN_MANAGER_ROLE) --- function addPaymentToken( address token, address priceFeed, bool isStable ) external; function removePaymentToken( address token ) external; function updatePaymentToken( address token, address priceFeed, bool isStable ) external; function getPaymentTokens() external view returns (address[] memory); function getPaymentTokenCount() external view returns (uint256); // --- Rules (RULES_MANAGER_ROLE) --- function updateSubscriptionRules( uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount ) external; function updateRedemptionRules( uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount, uint16 redemptionMalus ) external; function subscriptionRules() external view returns ( bool isOpen, uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount ); function redemptionRules() external view returns ( bool isOpen, uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount, uint16 malus ); // --- Admin (ADMIN_ROLE) --- function updateIssuerSafe(address newIssuerSafe) external; function updatePreminted(bool _preminted) external; } ``` Access control (roles) is enforced by `AccessManaged` via an [AccessManager](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) contract; see [**Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-primary/admin-and-management) for role mapping. ### Investor Functions #### `subscribe` ```solidity function subscribe( uint256 amount, address paymentToken ) external nonReentrant returns (uint256 nonce); ``` **Description** Subscribes `amount` of ERC-3643 tokens using `paymentToken` as consideration. * For **preminted** assets: * Transfers `amount` of ERC-3643 from `issuerSafe` to `msg.sender`. * For **non-preminted** assets: * Mints `amount` of ERC-3643 to `msg.sender`. In both cases: * Calculates total cost using a price feed implementing the [AggregatorV3Interface](https://docs.chain.link/data-feeds/api-reference#aggregatorv3interface). * Transfers `paymentToken` from investor to `issuerSafe`. * Collects protocol fee via `ecosystemFeeCollector`. * Emits `Subscribed(nonce, investor, paymentToken, amount, totalCost)`. **Reverts if:** * Subscriptions are closed (`SubscriptionClosed`). * `amount < minAmount` or `amount > maxAmount` (`AmountBelowMinimum` / `AmountAboveMaximum`). * `paymentToken` is not approved (`PaymentTokenNotApproved`). * ERC-3643 transfer / mint is not compliant (`TransferNotCompliant`, `InvestorNotQualified`). * Price feed issues (`InvalidPriceFeed`). * Fee collection fails (e.g. missing approval / balance on fee token). #### `redeem` ```solidity function redeem( uint256 amount, address paymentToken ) external nonReentrant returns (uint256 nonce); ``` **Description** Redeems `amount` of ERC-3643 tokens back to the issuer, and pays the investor in `paymentToken`. * For **preminted** assets: * Transfers ERC-3643 from `msg.sender` back to `issuerSafe`. * For **non-preminted** assets: * Burns ERC-3643 from `msg.sender` (DinoPrimary is an authorized agent). Then: * Computes payment amount based on NAV / price feed. * Applies **redemption malus** (haircut) if configured. * Transfers `paymentToken` from `issuerSafe` to investor. * Collects protocol fee. * Emits `Redeemed(nonce, investor, paymentToken, amount, paymentAmount)`. **Reverts if:** * Redemptions are closed (`RedemptionClosed`). * `amount < minAmount` or `amount > maxAmount` (`AmountBelowMinimum` / `AmountAboveMaximum`). * `paymentToken` not approved. * Investor or transfer not compliant. * Price feed invalid. * `issuerSafe` doesn’t have enough `paymentToken` balance / allowance. * Fee collection fails (e.g. missing approval / balance on fee token). ### Preview Functions (Read-Only Quotes) These functions **do not modify state** and allow UIs or off-chain systems to quote amounts without executing the operation. #### `previewSubscribeWithExactErc3643` ```solidity function previewSubscribeWithExactErc3643( uint256 erc3643Amount, address paymentToken ) external view returns (uint256 paymentTokenAmount); ``` Returns how much `paymentToken` is required to subscribe `erc3643Amount` of the asset. #### `previewSubscribeWithExactToken` ```solidity function previewSubscribeWithExactToken( uint256 paymentTokenAmount, address paymentToken ) external view returns (uint256 erc3643Amount); ``` Returns how many ERC-3643 tokens the investor would receive when paying `paymentTokenAmount`. #### `previewRedeemWithExactErc3643` ```solidity function previewRedeemWithExactErc3643( uint256 erc3643Amount, address paymentToken ) external view returns (uint256 paymentTokenAmount); ``` Returns **net** payment after applying redemption malus for redeeming `erc3643Amount`. #### `previewRedeemWithExactToken` ```solidity function previewRedeemWithExactToken( uint256 paymentTokenAmount, address paymentToken ) external view returns (uint256 erc3643Amount); ``` Returns how many ERC-3643 tokens the investor needs to redeem to receive `paymentTokenAmount` **after** malus. {% hint style="success" %} These helpers are ideal for front-ends: quote first, then call `subscribe` / `redeem` using the same parameters. {% endhint %} ### Payment Token Management {% hint style="warning" %} Requires `TOKEN_MANAGER_ROLE` via AccessManager. {% endhint %} #### `addPaymentToken` ```solidity function addPaymentToken( address token, address priceFeed, bool isStable ) external; ``` Registers a new payment token: * `token` – ERC-20 used for payments. * `priceFeed` – [AggregatorV3Interface](https://docs.chain.link/data-feeds/api-reference#aggregatorv3interface) for `token` vs pricing currency. * `isStable` – `true` if the token is considered stable (e.g. fully backed stablecoin). Reverts if: * `token` is zero address (`ZeroAddress`). * Token already added (`PaymentTokenAlreadyAdded`). #### `removePaymentToken` ```solidity function removePaymentToken(address token) external; ``` Removes a payment token. It will no longer be accepted for new subscriptions or redemptions. Reverts if: * Token is not in the approved set (`PaymentTokenNotApproved`). #### `updatePaymentToken` ```solidity function updatePaymentToken( address token, address priceFeed, bool isStable ) external; ``` Updates price feed and stability flag for an existing payment token. Reverts if token is not approved. #### `getPaymentTokens` / `getPaymentTokenCount` ```solidity function getPaymentTokens() external view returns (address[] memory); function getPaymentTokenCount() external view returns (uint256); ``` Allow enumerating all approved payment tokens, on top of the `approvedPaymentTokens(token)` getter. ### Rules Management {% hint style="warning" %} Requires `RULES_MANAGER_ROLE` via AccessManager. {% endhint %} #### `updateSubscriptionRules` ```solidity function updateSubscriptionRules( uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount ) external; ``` Sets subscription period and per-tx min/max. * `dateOpened` – unix timestamp when subscriptions start. * `dateClosed` – unix timestamp when subscriptions end (0 = no end). * `minAmount` / `maxAmount` – per-call bounds for `amount`. Reverts if `minAmount > maxAmount` (`InvalidAmounts`). #### `updateRedemptionRules` ```solidity function updateRedemptionRules( uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount, uint16 redemptionMalus ) external; ``` Same as subscription rules, plus: * `redemptionMalus` – in basis points (e.g. 100 = 1%, 500 = 5%) applied as haircut on redemptions. #### `subscriptionRules` ```solidity function subscriptionRules() external view returns ( bool isOpen, uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount ); ``` Returns current subscription rule set and whether the window is open at `block.timestamp`. #### `redemptionRules` ```solidity function redemptionRules() external view returns ( bool isOpen, uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount, uint16 malus ); ``` Same for redemptions, including the currently configured malus. ### Admin Functions {% hint style="warning" %} Require `ADMIN_ROLE` via AccessManager. {% endhint %} #### `updateIssuerSafe` ```solidity function updateIssuerSafe(address newIssuerSafe) external; ``` Updates the address that: * Receives subscription proceeds. * Pays redemptions. Reverts if `newIssuerSafe` is zero address. #### `updatePreminted` ```solidity function updatePreminted(bool _preminted) external; ``` Toggles mode: * `true` – transfer from `issuerSafe` (treasury). * `false` – mint/burn via ERC-3643 permissions. Emits `PremintedUpdated`. ### Events * `event IssuerSafeUpdated(address indexed oldIssuerSafe, address indexed newIssuerSafe)` * `event PremintedUpdated(address indexed updatedBy, bool preminted)` * `event PaymentTokenAdded(address indexed token, address priceFeed, bool isStable)` * `event PaymentTokenRemoved(address indexed token)` * `event PaymentTokenUpdated(address indexed token, address priceFeed, bool isStable)` * `event SubscriptionRulesUpdated(uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount, address indexed updatedBy)` * `event RedemptionRulesUpdated(uint256 dateOpened, uint256 dateClosed, uint256 minAmount, uint256 maxAmount, uint16 redemptionMalus, address indexed updatedBy)` * `event Subscribed(uint256 indexed nonce, address indexed investor, address indexed paymentToken, uint256 amount, uint256 totalCost)` * `event Redeemed(uint256 indexed nonce, address indexed investor, address indexed paymentToken, uint256 amount, uint256 paymentAmount)` Plus inherited: * `AuthorityUpdated(address authority)` from `AccessManaged`. ### Custom Errors (from `ErrorsLib`) `DinoPrimary` relies on a shared error library. Relevant errors include: * `ZeroAddress()` – one of the addresses is zero. * `SubscriptionClosed()` – subscription window not open. * `RedemptionClosed()` – redemption window not open. * `AmountBelowMinimum(uint256 amount, uint256 min)` * `AmountAboveMaximum(uint256 amount, uint256 max)` * `PaymentTokenAlreadyAdded(address token)` * `PaymentTokenNotApproved(address token)` * `InvalidAmounts()` – `minAmount > maxAmount` in rules updates. * `InvalidPriceFeed()` – price feed returns non-positive value. * `InvestorNotQualified(address investor)` – identity / eligibility issue. * `TransferNotCompliant()` – ERC-3643 compliance prevents transfer/mint/burn. These are meant to be **developer-friendly** and easily mapped to front-end error messages. # DINO Secondary Dino Secondary is the **shared secondary market rail** of the T-REX ecosystem. It is a smart contract deployed on the **T-REX Ledger** that lets investors, distributors, and broker-dealers: * **Publish on-chain intents (offers)** to buy or sell ERC-3643 (T-REX) tokens * **Partially or fully take** existing offers * **Share liquidity** across multiple platforms and dApps, instead of fragmenting it into isolated OTC channels Every offer is created and settled directly onchain, with: * Built-in compliance integration for ERC-3643 * Freezing of RWA tokens instead of moving them to escrow which helps maintain the integrity of the onchain cap tables at all times * Configurable fee mechanisms for both the ecosystem and the asset issuer/operator Dino Secondary is **not a single UI**. It is the **neutral onchain marketplace layer** that any T-REX-compatible application can plug into. ### Key Features #### Intent-Based Trading * **Offer creation** – Any investor or participant can publish an offer expressing their intent to: * Sell an ERC-3643 token for another token (e.g. stablecoin), or * Buy an ERC-3643 token by offering another token. * **Flexibility** – Offers specify: * The token being offered (`tokenOut`) * The token requested (`tokenIn`) * The respective amounts * An expiration time #### Partial Fills & Offer States * Offers can be **partially filled** multiple times until: * Fully filled * Cancelled by the creator * Pruned after expiry or if conditions are no longer met * The contract tracks: * Total offered amount * Filled amount * Remaining amount * Status (Active, Filled, Cancelled, Expired) #### Two Token Handling Modes Dino Secondary supports two ways to handle the asset vs payment tokens: * **Freeze mode for ERC-3643 tokens**\ When the offer is selling the ERC-3643 token: * The RWA tokens remain in the **seller’s wallet** * They are **frozen** using the ERC-3643 token’s built-in freeze mechanism * When the offer (or part of it) is taken, the relevant amount is unfrozen and transferred * **Escrow mode for standard ERC-20 tokens**\ When the offer is selling a non-ERC-3643 token: * Tokens are **transferred to the Dino Secondary contract** on offer creation * They stay in escrow until the offer is taken, cancelled, or pruned This design ensures: * RWA tokens remain tightly coupled with their identity/compliance logic * Standard ERC-20s are handled with a classic escrow pattern #### Compliance-Aware by Design Dino Secondary is built for **ERC-3643 tokens**: * At least one leg of every trade must involve the configured **ERC-3643 token** for this Dino Secondary instance. * Transfers of that token are subject to the token’s existing compliance rules: * Identity registry checks * Eligibility / jurisdiction rules * Freeze/unfreeze controls * If a transfer would violate compliance, the trade simply cannot be executed. #### Shared Liquidity on the T-REX Ledger All offers for a given ERC-3643 token are stored in the **same contract instance** on the T-REX Ledger. That means: * Any dApp, broker-dealer, or platform integrating Dino Secondary taps into the **same pool of offers**. * Liquidity is aggregated at the **contract level**, not at the UI level. * New interfaces can appear (white-label platforms, wallets, institutional portals, aggregators) and **immediately see and use the existing offer book**. ### Actors & Roles At a conceptual level, Dino Secondary involves: * **Offer Creators (Makers)**\ Investors or institutions who post offers to buy or sell the ERC-3643 token. * **Offer Takers**\ Counterparties who accept offers (fully or partially), triggering settlement. * **Issuers / Operators**\ Entities responsible for the ERC-3643 token and the market around it. They benefit from shared liquidity and may configure fees and operational parameters. * **Platforms & dApps**\ Any interface building on top of Dino Secondary: broker portals, investor dashboards, wallet integrations, etc. * **Dino Secondary Contract**\ The on-chain engine: * Stores & updates offers * Manages freezing / escrow of tokens * Enforces expiry and pruning * Handles fees * Relies on ERC-3643 compliance checks at settlement time At the admin level, the contract uses an [**AccessManager**](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) with roles (such as `ADMIN_ROLE` and `FEE_MANAGER_ROLE`) to control pausing and fee configuration. Those details are described on the [**Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-secondary/admin-and-management) page. ### Trading Model & Offer Lifecycle #### 1. Offer Creation A maker: 1. Chooses: * Which token they are **offering** (`tokenOut`) * Which token they **want in return** (`tokenIn`) * Amounts and expiry 2. Calls `createOffer(...)` via their preferred dApp or platform. Under the hood: * If `tokenOut` is the ERC-3643 token: * Dino Secondary checks that the maker’s **free (unfrozen)** balance is sufficient * Freezes the offered amount in the maker’s wallet * If `tokenOut` is a standard ERC-20: * Transfers the offered amount into escrow (the Dino Secondary contract) * Records the offer in storage and emits an `OfferCreated` event * Charges the relevant **ecosystem fee** for offer creation #### 2. Taking an Offer A taker: 1. Selects an offer and decides how much to take (can be partial). 2. Approves the appropriate token if needed (e.g. payment token). 3. Calls `takeOffer(offerID, amount)`. Dino Secondary: * Validates the offer is still active and not expired * If the offer is no longer valid, it is automatically **pruned** and cannot be taken. * Computes the corresponding counter-amount using the offer’s price ratio. * Executes settlements: * **Unfreezing & transfer** when selling ERC-3643 * **Escrow release** when selling standard ERC-20 * Transfers the requested token from taker to maker * Applies **volume-based fees** and any configured fixed fees. * Updates the offer’s filled amount and marks it: * **Partially filled** (still active with reduced remaining size), or * **Filled** (fully executed and closed) * Emits events (partially filled / filled) and charges **ecosystem fees**. #### 3. Cancelling an Offer Makers can cancel their own active offers: * Call `cancelOffer(offerID)`. * Dino Secondary: * Unfreezes ERC-3643 tokens or releases escrow as needed * Marks the offer as **Cancelled** * Emits `OfferCancelled` and charges the **ecosystem fee** for cancellation #### 4. Pruning Expired or Invalid Offers Any address can trigger pruning via `pruneOffer(offerID)`: * If the offer: * Has expired, or * Is underfunded (e.g. maker moved their frozen tokens away or no longer has enough balance) * Then: * Dino Secondary releases any frozen/escrowed tokens * Marks the offer as **Expired** * Emits `OfferPruned` Pruning prevents stale or unsafe offers from being executed and keeps the active offer set clean. ### Compliance & ERC-3643 Integration Dino Secondary is designed to align with all compliance guarantees of **ERC-3643**: * The ERC-3643 token itself: * Validates transfers against its Identity Registry * Enforces eligibility rules (KYC/AML, jurisdiction, investor type, etc.) * Manages freeze/unfreeze states * Dino Secondary always interacts with the token using its **standard interfaces**, which means: * If a transfer would violate compliance, the token reverts and the trade cannot be settled. * Freeze/unfreeze operations respect existing identity and permission structures. As a result, **secondary market activity remains fully compliant** with the same rules as primary issuance and transfers. ### Fees & Incentives (High-Level) Dino Secondary supports multiple fee layers: * **T-REX Ecosystem Fees**\ Collected via the shared **Ecosystem Fee Collector**, with different multipliers depending on the operation (offer creation, taking, cancellation). * **Asset / Market-Level Fees**\ Configurable by authorized operators (via the `FEE_MANAGER_ROLE`), including: * A **fixed fee** per trade * A **volume-based fee** (percentage) capped to protect users Details on how to configure, calculate, and monitor these fees are covered in the [**Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-secondary/admin-and-management) page. ### Integration Patterns for Platforms & dApps A typical integration with Dino Secondary follows these steps: 1. **Discovery & Display** * Query the list of open offers for a given ERC-3643 token. * Display: * Maker, price, remaining size, expiry, direction (buy/sell). 2. **Offer Creation (Maker UI)** * Provide a form where users choose: * Sell token / buy token * Amounts and expiry * Guide them through: * Approving tokens (if needed) * Calling `createOffer(...)` 3. **Offer Taking (Taker UI)** * Allow users to: * Select any open offer * Choose full or partial amount * Use preview helpers (from the Developer Reference) to show: * Exact amounts they will send/receive * Applicable fees * Call `takeOffer(...)` and display results. 4. **Offer Management** * Expose “My Offers” view: * List of user-created offers * Status, remaining amount, time to expiry * Provide actions to: * Cancel offers * Trigger pruning of expired or invalid offers Because Dino Secondary is **shared infrastructure** on the T-REX Ledger, one integration lets your platform: * Access all offers for that token * Co-exist with other platforms and broker-dealers on the same liquidity pool ### Dino Secondary in the T-REX Apps Stack Within the broader T-REX ecosystem: * **DinoPrimary** handles compliant subscription & redemption (primary market). * **DinoSecondary** handles intent-based secondary trading for the same ERC-3643 tokens. * **DinoFactory** deploys both contracts and configures their access control consistently. * **T-REX Engine** exposes APIs to read offers and interact with Dino Secondary programmatically. * **DINO Secondary dApp** (and any other integrated front-ends) provide user-facing UIs on top of this shared contract. ### Related Documentation For more details: * [**Dino Secondary – Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-secondary/admin-and-management)\ Roles, pausing, fee configuration, and operational best practices. * [**Dino Secondary – Developer Reference**](/t-rex-network/t-rex-apps/dino/dino-secondary/developer-reference)\ Solidity interfaces, function signatures, events, error codes, and concrete integration examples. # Admin & Management This page explains how to **operate and configure** the Dino Secondary contract: * Access control and roles * Pausing / unpausing trading * Fee configuration (fixed fees, volume-based fees, ecosystem fees) * Introspection helpers, multicall, and events * Suggested operational lifecycle For function signatures and technical details, see [**Dino Secondary – Developer Reference**](/t-rex-network/t-rex-apps/dino/dino-secondary/developer-reference). ### Access Control System Dino Secondary uses OpenZeppelin’s [**AccessManager**](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) to enforce fine-grained permissions. Two logical roles are defined: an **admin** role and a **fee manager** role. #### Roles | Role | Value | Description | Typical Holder(s) | | ------------------ | ----- | -------------------------- | -------------------------------------- | | `ADMIN_ROLE` | `0` | Global administrative role | Issuer / Operator multisig, governance | | `FEE_MANAGER_ROLE` | `3` | Fee configuration role | Market operator, platform / treasury | **`ADMIN_ROLE`** can: * Pause / unpause the contract (emergency control) * Generally manage admin-level functions and (via AccessManager) other roles / mappings **`FEE_MANAGER_ROLE`** can: * Configure **fixed fee** parameters * Configure **volume-based fee** parameters DinoSecondary {% hint style="info" %} Dino Factory can either: * Deploy a new AccessManager and wire Dino Primary & Dino Secondary to it; or * Reuse an existing AccessManager shared across multiple assets.\ For a given token, **Dino Primary and Dino Secondary must share the same AccessManager** so roles and UX are consistent. {% endhint %} ### Admin Management Settings (`ADMIN_ROLE`) #### Core Configuration Functions | Setting | Function | Role | Description | | ---------------- | ----------- | ------------ | ------------------------------------------------------------------------------------- | | Pause Contract | `pause()` | `ADMIN_ROLE` | Pauses all trading operations: offers cannot be created, taken, cancelled, or pruned. | | Unpause Contract | `unpause()` | `ADMIN_ROLE` | Resumes normal trading operations. | When paused: * `createOffer`, `takeOffer`, `cancelOffer`, `pruneOffer`, and similar trade functions will revert. * Admin and fee configuration functions remain usable so operators can resolve issues before unpausing. {% hint style="info" %} **Typical usage:** * Incident response (oracle problem, compliance issue, exploit suspicion) * Coordinated protocol upgrade or parameter change that temporarily requires halting trading. {% endhint %} ### Fee Manager Settings (`FEE_MANAGER_ROLE`) Dino Secondary supports **three** fee layers: 1. **Fixed fee** per `takeOffer` operation (contract-level, configured here) 2. **Volume-based fee** proportional to traded volume (contract-level, configured here) 3. **Ecosystem fee** collected by the shared T-REX Ecosystem Fee Collector (configured at ecosystem level) #### Fee Configuration Functions | Setting | Function | Role | Description | | ---------------- | ------------------- | ------------------ | ----------------------------------------------- | | Fixed Fee | `setFixedFee` | `FEE_MANAGER_ROLE` | Sets the fixed fee per `takeOffer` transaction. | | Volume-Based Fee | `setVolumeBasedFee` | `FEE_MANAGER_ROLE` | Sets the percentage-based fee (capped at 1%). | **Fixed Fee** * **Purpose:** Cover operational / platform costs on each trade. * **Charged:** On every `takeOffer` transaction. * **Paid in:** A configurable ERC-20 token (e.g. stablecoin). * **Recipient:** Configurable address (e.g. market operator, platform, or issuer). DinoSecondary The fixed fee configuration typically includes: * `fixedFeeToken` – ERC-20 address; * `fixedFeeAmount` – amount charged per `takeOffer`; * `fixedFeeRecipient` – beneficiary address. **Volume-Based Fee** * **Purpose:** Align incentives with transaction volume (e.g. % fee for the marketplace / issuer). * **Charged on:** The **non-ERC-3643 leg** of the trade (the payment token side). * **Rate:** Expressed in **basis points** (100 = 1%). * **Cap:** Maximum **100 bps** (1%) enforced by the contract. * **Recipient:** Configurable address, usually marketplace or issuer. DinoSecondary Dino Secondary ensures the volume-based fee cannot exceed the 1% cap, protecting users from excessive fee configuration. ### Fee System On top of fixed and volume-based fees, Dino Secondary also participates in the **ecosystem fee model**. #### Ecosystem Operation Fees For each high-level operation, Dino Secondary multiplies a shared **base ecosystem fee** by a specific multiplier: DinoSecondary | Operation | Ecosystem Fee Multiplier | Description | | ------------ | ------------------------ | ---------------------------------------- | | Create Offer | `3x` base fee | Payable for creating a trading offer | | Take Offer | `3x` base fee | Payable for executing a trading offer | | Cancel Offer | `1x` base fee | Payable for cancelling an existing offer | Ecosystem fees are handled by the **T-REX Ecosystem Fee Collector**: * Users must **approve** the ecosystem fee token for the Fee Collector. * Dino Secondary calls the Fee Collector with the relevant multiplier when operations occur. DinoSecondary #### Combined Fee Flow per `takeOffer` When a trade is executed via `takeOffer`: 1. **Ecosystem fee** is collected by the shared Fee Collector (multiplier: `3x`). 2. **Fixed fee** is collected: * In `fixedFeeToken`, from the taker to `fixedFeeRecipient`. 3. **Volume-based fee** is: * Calculated on the **non-ERC-3643 leg** of the trade * Deducted and sent to `volumeFeeRecipient`. From a UX perspective, you should: * **Preview** all three fee layers in your dApp when quoting the trade * Clearly differentiate protocol (ecosystem) fees from market/platform fees ### Fee Introspection Helpers To make integration easier, Dino Secondary exposes several view functions to introspect fee configuration: DinoSecondary | Function | Description | | ---------------------- | ----------------------------------------------------------- | | `fixedFee()` | Returns fixed fee configuration (token, amount, collector). | | `volumeFee()` | Returns volume-based fee rate in basis points. | | `fixedFeeRecipient()` | Returns the fixed fee recipient address. | | `volumeFeeRecipient()` | Returns the volume-based fee recipient address. | These allow frontends and off-chain services to: * Fetch current fee settings * Display them in UI / legal notices * Validate that configuration matches expected policies ### Multicall Support Dino Secondary inherits OpenZeppelin’s [**Multicall**](https://docs.openzeppelin.com/contracts/5.x/utilities#multicall) functionality. This allows batching multiple calls into a **single transaction**, for example: * Multiple `createOffer` calls in a single transaction to create a grid of offers. * Multiple `takeOffer` calls on different offers in a single transaction to process a large transaction that requires fulfilling several Offers at once. * Multiple `cancelOffer` calls on different offers in a single transaction. * Multiple `pruneOffer` calls on different invalid offers to process garbage collection in a single transaction. Benefits: * Gas efficiency (one base transaction cost, many actions) * Better UX (“Confirm once to execute multiple steps”) From the front-end side, you simply encode several calls into a single multicall transaction. ### Events & Monitoring The contract emits detailed events for operational and admin actions. DinoSecondary #### Dino Secondary–Specific Events | Event | Description | | ------------------ | ---------------------------------------------------- | | `OfferCreated` | Emitted when a new offer is created. | | `OfferTaken` | Emitted when an offer is executed (full/partial). | | `OfferCancelled` | Emitted when an offer is cancelled by creator. | | `OfferPruned` | Emitted when an offer is pruned (expired/invalid). | | `FixedFeeUpdated` | Emitted when fixed fee configuration changes. | | `VolumeFeeUpdated` | Emitted when volume-based fee configuration changes. | | `Paused` | Emitted when the contract is paused. | | `Unpaused` | Emitted when the contract is unpaused. | #### Inherited AccessManaged Events | Event | Description | | ------------------ | ------------------------------------------------------ | | `AuthorityUpdated` | Emitted when the controlling AccessManager is updated. | {% hint style="success" %} **Recommendation:** index at least `OfferCreated`, `OfferTaken`, `OfferCancelled`, `OfferPruned`, `FixedFeeUpdated`, `VolumeFeeUpdated`, `Paused`, and `Unpaused` in your backend or analytics pipeline. {% endhint %} ### Typical Operational Lifecycle Putting everything together, a typical lifecycle from an **admin/operator** standpoint looks like this: 1. **Deployment via DinoFactory** * DinoFactory deploys Dino Secondary linked to: * The ERC-3643 token * An AccessManager (new or existing) * The ecosystem Fee Collector 2. **Role Assignment** * AccessManager admin assigns: * `ADMIN_ROLE` to issuer / operator multisig * `FEE_MANAGER_ROLE` to the team managing fees 3. **Fee Configuration** * `FEE_MANAGER_ROLE` calls: * `setFixedFee` to set fixed fee token, amount, and recipient * `setVolumeBasedFee` to set bps rate (≤ 100 bps) and recipient 4. **Production Trading** * Users create, take, cancel, and prune offers through integrated dApps and platforms. * Ecosystem, fixed, and volume-based fees are collected automatically. 5. **Operational Controls** * In case of incidents or planned maintenance, `ADMIN_ROLE` can: * `pause()` trading * Adjust configurations (e.g. fee parameters) * `unpause()` once conditions are safe again 6. **Monitoring & Auditing** * Off-chain systems monitor: * Fee updates * Pauses/unpauses * Offer lifecycle events * Data can be used for: * Market surveillance * Compliance & reporting * Revenue accounting # Developer Reference This page documents the on-chain interface of **DinoSecondary**, the secondary-market module of the DINO stack. Each `DinoSecondary` instance is bound to **one** T-REX (ERC-3643) token and exposes a simple offer book where users can post and take bilateral offers between that T-REX token and any ERC-20 payment token. The contract supports: * Freeze-based handling for the ERC-3643 leg (tokens locked in the investor’s wallet) * Escrow-based handling for the non-ERC-3643 leg (tokens held by the contract) * Fixed and volume-based fees * Ecosystem-level fees (handled by the T-REX fee collector) This page is aimed at **dapp and integration developers**. Admin-only concerns (roles, pausing, fee configuration) are covered in the [*Admin & Management*](/t-rex-network/t-rex-apps/dino/dino-secondary/admin-and-management) page. ### Contract Surface At a high level, the public interface exposed to integrators is: ```solidity interface IDinoSecondary { struct Fee { address feeToken; uint256 feeAmount; address feeCollector; } enum OfferStatus { Active, Filled, Cancelled, Expired } struct Offer { address offerCreator; address tokenOut; uint256 amountOut; uint256 filledAmountOut; address tokenIn; uint256 amountIn; uint256 filledAmountIn; uint256 expiry; OfferStatus status; uint256 createdAt; } function createOffer( address tokenOut, uint256 amountOut, address tokenIn, uint256 amountIn, uint256 expiry ) external returns (uint256 offerID); function takeOffer(uint256 offerID, uint256 amount) external; function cancelOffer(uint256 offerID) external; function pruneOffer(uint256 offerID) external; function setFixedFee(address feeToken, address feeRecipient, uint256 amount) external; function setVolumeBasedFee(address feeRecipient, uint256 basisPoints) external; function TREX() external view returns (address); function fixedFee() external view returns (Fee memory); function volumeFee() external view returns (Fee memory); function getOfferExpiry(uint256 offerID) external view returns (uint256); function getCurrentOfferID() external view returns (uint256); function getOfferDetails(uint256 offerID) external view returns (Offer memory); } ``` {% hint style="info" %} **Note:** The implementation also integrates AccessManager roles, pausing and ecosystem fee collection. Those are configured via the factory and documented in the DinoFactory and Admin pages. {% endhint %} ### Core Data Structures #### Fee Represents a fee configuration used by DinoSecondary: | Field | Type | Description | | -------------- | --------- | ------------------------------------------------------------------------------------------ | | `feeToken` | `address` | Token in which the fee is paid (ERC-20). | | `feeAmount` | `uint256` | Meaning depends on context: fixed amount (for fixed fee) or basis points (for volume fee). | | `feeCollector` | `address` | Address receiving the fee. | * For **fixed fees**, `feeAmount` is the **exact amount** of `feeToken` charged per `takeOffer`. * For **volume-based fees**, `feeAmount` represents the **basis points** (bps) applied on the non-ERC-3643 leg, capped at 100 bps (1%). #### OfferStatus Offer lifecycle states: * `Active` – Offer is live and can be taken. * `Filled` – Offer is fully executed. * `Cancelled` – Cancelled by creator. * `Expired` – Expired based on `expiry` timestamp and/or pruned. #### Offer Represents a single order in the book: | Field | Type | Description | | ----------------- | ------------- | -------------------------------------------------------- | | `offerCreator` | `address` | Maker address. | | `tokenOut` | `address` | Token being sold (outgoing from maker). | | `amountOut` | `uint256` | Total amount offered for sale. | | `filledAmountOut` | `uint256` | Cumulative portion of `amountOut` that has been taken. | | `tokenIn` | `address` | Token expected in exchange. | | `amountIn` | `uint256` | Total amount expected in the counter-token. | | `filledAmountIn` | `uint256` | Cumulative portion of `amountIn` that has been received. | | `expiry` | `uint256` | UNIX timestamp after which offer is no longer tradable. | | `status` | `OfferStatus` | Current status (Active/Filled/Cancelled/Expired). | | `createdAt` | `uint256` | Creation timestamp. | Amounts always keep the **original price ratio**: partial fills are proportional and update the `filledAmount*` fields accordingly. ### Trading Functions #### createOffer ```solidity function createOffer( address tokenOut, uint256 amountOut, address tokenIn, uint256 amountIn, uint256 expiry ) external returns (uint256 offerID); ``` **Purpose** Create a new offer to sell `tokenOut` for `tokenIn` at a fixed ratio `amountIn / amountOut`. **High-level flow** 1. Caller checks prerequisites and approves tokens for DinoSecondary (for the ERC-20 leg). 2. Contract validates: * `amountOut` and `amountIn` are non-zero. * `expiry` is in the future. * At least one leg is the ERC-3643 token bound to this DinoSecondary instance. 3. Token handling: * If the ERC-3643 token is being sold: tokens are **frozen** in the maker’s wallet (not transferred). * If the ERC-20 token is being sold: tokens are moved into **escrow** (held by the contract). 4. Offer struct is stored and a unique `offerID` is assigned (monotonically increasing). 5. Ecosystem fee is charged via the T-REX fee collector. 6. `OfferCreated` event is emitted. **Common errors** * `ZeroAmount()` – if one of the amounts is 0. * `InvalidExpiry(expiry)` – if expiry is in the past or otherwise rejected. * `InvalidToken(token)` – if either token address is not allowed. #### takeOffer ```solidity function takeOffer(uint256 offerID, uint256 amount) external; ``` **Purpose** Accept an existing offer (partially or fully) and execute the trade. **High-level flow** 1. Validates that: * `offerID` refers to an existing offer. * Offer is Active and not expired. * `amount` is > 0. 2. Computes the proportional `amountIn` based on original price ratio. 3. Token transfers: * ERC-3643 leg: * If maker is selling ERC-3643, previously frozen tokens are **unfrozen and transferred** to the taker. * If taker is selling ERC-3643, tokens move via standard `transferFrom` logic to the maker. * ERC-20 leg: tokens move via standard `transferFrom`/escrow logic. 4. Fees: * **Volume-based fee** applied on the non-ERC-3643 leg in basis points (`volumeFee().feeAmount`). * **Fixed fee** charged to the taker in `fixedFee().feeToken` and sent to `fixedFee().feeCollector`. * Ecosystem fee collected via the fee collector. 5. Offer state updated: * `filledAmountOut` / `filledAmountIn` updated. * Status set to `Filled` if fully executed; otherwise remains `Active`. 6. Events: * `OfferPartiallyFilled` if there is remaining liquidity. * `OfferFilled` if fully executed. **Common errors** * `InvalidOfferId(offerID)` – offer does not exist. * `ZeroAmount()` – taker tries to take 0. * `InvalidTokenTransfer(token)` – failure in underlying token transfer. * `VolumeFeeExceedsAmount(volumeFee, amount)` – volume-based fee would be larger than the traded amount. #### cancelOffer ```solidity function cancelOffer(uint256 offerID) external; ``` **Purpose** Allow the **offer creator** to cancel an active offer. **Behavior** * Only the original `offerCreator` can cancel their own offers. * Any frozen ERC-3643 tokens are **released**. * Any ERC-20 tokens held in escrow are returned to the maker. * Status is set to `Cancelled`. * `OfferCancelled` event is emitted. **Common errors** * `InvalidOfferId(offerID)` – no such offer. * `OfferNotCreatedBySender(offerID, sender)` – caller is not the original maker. #### pruneOffer ```solidity function pruneOffer(uint256 offerID) external; ``` **Purpose** Clean up offers that are no longer valid, for example: * Expired offers. * Offers that became non-compliant. * Offers where the ERC-3643 leg is no longer funded (maker removed allowance or an agent moved away the frozen balance reserved for the transfer). Pruning is open to any caller; it updates status to `Expired` and emits `OfferPruned`. If tokens had been locked/frozen, they are freed accordingly. **Common errors** * `InvalidOfferId(offerID)` – no such offer. ### Fee Configuration & Getters #### setFixedFee ```solidity function setFixedFee(address feeToken, address feeRecipient, uint256 amount) external; ``` Admin-only function to configure the **per-transaction fixed fee**: * `feeToken`: ERC-20 token used to pay the fee. * `feeRecipient`: address that receives fixed fees. * `amount`: exact amount of `feeToken` charged on each `takeOffer`. Reverts with: * `VolumeBasedFeeTooHigh` does *not* apply here. * May revert with `ZeroAddress` (common error) if token or recipient is zero. #### setVolumeBasedFee ```solidity function setVolumeBasedFee(address feeRecipient, uint256 basisPoints) external; ``` Admin-only function to configure the **percentage-based fee**: * `basisPoints`: rate in bps (100 = 1%) applied to the **non-ERC-3643 leg** of each trade. * `basisPoints` is capped at 100; higher values revert with `VolumeBasedFeeTooHigh`. #### Fee getters ```solidity function fixedFee() external view returns (Fee memory); function volumeFee() external view returns (Fee memory); ``` * `fixedFee()` * `feeToken`: token used for the fixed fee. * `feeAmount`: fixed fee amount. * `feeCollector`: address receiving fixed fees. * `volumeFee()` * `feeToken`: not used for calculations (bps is applied on the trade amount). * `feeAmount`: basis points value (0–100). * `feeCollector`: address receiving the volume-based fee. The implementation also provides convenience view functions for the raw recipients (`fixedFeeRecipient`, `volumeFeeRecipient`) as documented in the DinoSecondary docs. {% hint style="info" %} For the **ecosystem fee**, see DinoFactory / Global Fees docs – it is collected separately by the T-REX Ecosystem Fee Collector. {% endhint %} ### Read-Only Helpers #### TREX ```solidity function TREX() external view returns (address); ``` Returns the **ERC-3643 token address** this DinoSecondary instance is bound to. Every offer must involve this token in at least one leg. #### getOfferExpiry ```solidity function getOfferExpiry(uint256 offerID) external view returns (uint256); ``` Shortcut to read only the `expiry` field for a given offer. #### getCurrentOfferID ```solidity function getCurrentOfferID() external view returns (uint256); ``` Returns the **next** offer ID that will be assigned on the next `createOffer` call (i.e. a counter, *not* the last valid ID). To iterate over all offers, index from `0` (or `1`, depending on deployment conventions) up to `getCurrentOfferID() - 1`, combined with `getOfferDetails` and event history. #### getOfferDetails ```solidity function getOfferDetails(uint256 offerID) external view returns (Offer memory); ``` Returns the full `Offer` struct for the given `offerID`. Use this for: * Front-end display of the order book. * Reconciling with your indexer state. * Checking status, amounts and timestamps on-chain. ### Events DinoSecondary uses a dedicated events library for consistent logging. #### Trading events
EventWhen it firesKey fields
OfferCreated(uint256 offerID, address offerCreator, address tokenOut, uint256 amountOut, address tokenIn, uint256 amountIn, uint256 creationTime, uint256 expiry)A new offer is createdofferID, maker, tokens and amounts, timestamps
OfferPartiallyFilled(uint256 offerID, uint256 amount, uint256 remainingAmount, address taker)An offer is filled but liquidity remainsamount filled in this trade, remaining, taker
OfferFilled(uint256 offerID, address taker)Offer is fully filledFinal taker
OfferCancelled(uint256 offerID)Maker cancels the offerofferID
OfferPruned(uint256 offerID)Offer is administratively prunedofferID
#### Fee events | Event | Description | | --------------------------------------------------------------------- | --------------------------------- | | `FixedFeeSet(address feeToken, address feeRecipient, uint256 amount)` | Fixed fee config updated. | | `VolumeBasedFeeSet(address feeRecipient, uint256 basisPoints)` | Volume-based fee config updated. | | `FixedFeePaid(address taker, address collector, uint256 amount)` | Fixed fee paid on a `takeOffer`. | | `VolumeFeePaid(address feePayer, address collector, uint256 amount)` | Volume-based fee paid on a trade. | #### Pausable & AccessManager events From inherited contracts: * `Paused(address account)` / `Unpaused(address account)` from `Pausable`. * `AuthorityUpdated(address authority)` from `AccessManaged` when the AccessManager is changed. These are particularly useful for indexers and monitoring dashboards. ### Error Reference | Error | Typical cause | | ------------------------------------------------------------------- | -------------------------------------------------- | | `InvalidExpiry(uint256 expiry)` | Expiry not acceptable (e.g. in the past). | | `InvalidOfferId(uint256 offerID)` | Referenced offer does not exist. | | `InvalidToken(address token)` | Token not accepted for trading. | | `InvalidTokenTransfer(address token)` | Transfer or freeze/unfreeze failed for this token. | | `LimitsArraySizeExceeded(uint256 arraySize, uint256 maxSize)` | (Used for batched operations, if exposed.) | | `OfferNotCreatedBySender(uint256 offerID, address sender)` | Someone other than the maker tried to cancel. | | `VolumeBasedFeeTooHigh(uint256 basisPoints, uint16 maxBasisPoints)` | Attempt to set volume fee above 100 bps. | | `VolumeFeeExceedsAmount(uint256 volumeFee, uint256 amount)` | Computed volume fee greater than traded amount. | | `ZeroAmount()` | One of the amounts is zero. | | `ZeroAddress()` | Critical address parameter is zero. | You should surface these errors in your dapp for clearer UX (e.g. mapping them to human-readable messages). ### Multicall Support The contract supports **OpenZeppelin Multicall**, allowing you to batch several calls into a single transaction (for example, multiple `takeOffer` operations or a `takeOffer` + off-chain accounting update). This is especially useful for: * Wallets wanting to group multiple fills. * Protocols executing rebalancing strategies that span several offers. ### Integration Tips * Use `TREX()` to ensure you are interacting with the right DinoSecondary instance for a given asset. IDinoSecondary * Index **events** (`OfferCreated`, `OfferPartiallyFilled`, `OfferFilled`, `OfferCancelled`, `OfferPruned`) as your primary source of truth, and reconcile with `getOfferDetails` for on-chain verification. * Never assume offers are contiguous or permanent: always be ready for cancellation, pruning and expiry. * For UX, guide users through approvals (ERC-20) and highlight when the freeze path vs escrow path applies. # T-REX Ledger The compliant reconciliation ledger for Regulated Financial institutions *** ### 1. Concept and Purpose The **T-REX Ledger** is the foundational layer of the ERC-3643 ecosystem — a domain-specific blockchain infrastructure designed to act as the **canonical ledger and book of record** for regulated digital assets. Rather than competing with existing Layer 1 or Layer 2 blockchains, the T-REX Ledger functions as a **trusted financial substrate** where real-world assets, tokenized under ERC-3643, reconcile and settle across chains. Its purpose is to provide: * **Authoritative on-chain recordkeeping** for securities and other regulated financial instruments. * **Seamless interoperability** with multiple chains for liquidity and user accessibility. * **Institutional-grade trust and compliance guarantees**, enforced through an embedded governance and identity framework. *** ### 2. Nature of the T-REX Ledger The T-REX Ledger launches as an **Ethereum Layer 2** built on the **OP Stack**, leveraging Ethereum for security and data availability.\ It integrates **zero-knowledge proofs** for fast and reliable finality, ensuring transaction integrity and scalability. #### Dual Security and Governance Model To combine **public settlement security** and **institutional trust**, the T-REX Ledger introduces a **dual validation architecture**: 1. **Ethereum Anchoring**: all state roots are periodically posted to Ethereum, inheriting its proven decentralization and immutability. 2. **Institutional Proof-of-Authority (PoA) Layer:** a quorum of trusted validators co-sign and attest to key on-chain events. This hybrid approach provides: * Ethereum-level settlement assurance. * Institutional oversight and governance for regulatory confidence. **In summary:** > **T-REX Ledger = Ethereum-anchored rollup (OP Stack) + Institutional PoA validation layer**\ > It merges Ethereum’s security with the governance and trust framework expected in regulated financial infrastructure. *** ### 3. Issuance Model All **canonical asset issuance** occurs on the T-REX Ledger, which functions as the **authoritative chain** for tokenized financial instruments. #### On the T-REX Ledger * Full implementation of **ERC-3643**, including: * Embedded **identity management** * **Claim registries** for KYC/AML and investor eligibility * **Compliance logic** enforced natively on-chain #### On External Chains * **Simplified distribution contracts**, similar to permissioned ERC-20 tokens. * Transferability and permissions are **derived from the compliance logic** of the reference (T-REX) chain. This model ensures: * **The T-REX Ledger holds the “golden record”** of ownership and balances. * External chains serve as **liquidity and accessibility layers** — secondary representations of the canonical assets. *** ### 4. Bridging Mechanism Cross-chain movement follows a **freeze / mint model**, preserving canonical integrity: 1. **Outbound Transfer** * Tokens are **frozen** on the T-REX Ledger. * Equivalent tokens are **minted** on the destination chain. 2. **Inbound Transfer** * External tokens are **burned**. * Frozen tokens on the T-REX Ledger are **unlocked**. 3. **Direct Mint-and-Bridge Flows** * Issuers can mint on T-REX and deliver directly to another chain in a **single transaction**, streamlining initial distribution. 4. **Synchronized Accounting** * Transfers on external chains are **automatically mirrored** on the T-REX Ledger using frozen tokens, ensuring continuous reconciliation. ➡️ **Result:**\ The T-REX Ledger always maintains the **canonical accounting of balances** — no double issuance, no desynchronization. *** ### 5. Book of Record The T-REX Ledger is designed to act as the **regulator-recognized book of record** for legal ownership of tokenized securities. * **Transfer agents, custodians, and regulators** can rely on it as the authoritative register. * External chains are treated as **distribution and liquidity venues**, not legally binding records. This design makes T-REX unique:\ it positions itself as a **compliance and reconciliation layer** for digital assets, **not a competitor** to general-purpose blockchains. *** ### 6. Benefits by Stakeholder #### For Financial Institutions * **Regulatory confidence** through PoA-based validation and Ethereum anchoring. * **Simplified reconciliation** across chains with a single authoritative ledger. * **Interoperability** without compromising compliance. #### For Issuers * **Single issuance point** across all networks. * Automated **compliance enforcement** via ERC-3643. * **Bridging and liquidity** on external chains while maintaining legal control on T-REX. #### For Investors * Transparent and **verifiable ownership** on a regulated chain. * **Inter-chain liquidity** without losing regulatory protection. * Instant, compliant transferability. #### For Builders * Access to **standardized smart contracts and dApps** for issuance, compliance, and bridging. * Participation in an **institutionally backed ecosystem** (via the ERC-3643 Association). * Opportunities to build dApps in the future **T-REX AppStore** : custody tools, marketplaces, compliance modules, etc. *** ### 7. Governance The governance of the T-REX Ledger combines **on-chain transparency** with **institutional oversight**: * **PoA Validators**: Operated by a consortium of regulated and reputable institutions. * **T-REX DAO**: Oversees protocol upgrades, parameter changes, and validator admission. * **ERC-3643 Association**: Maintains open standards, audits, and interoperability guidelines. Together, they ensure: * Accountability to the community and regulators. * Controlled evolution under transparent governance. * Sustainable ecosystem growth aligned with compliance requirements. *** ### 8. Technology Stack | Layer | Component | Description | | ------------------------------- | ---------------------------------- | -------------------------------------------------------------------- | | **Settlement Layer** | **Ethereum (L1)** | Provides anchoring, security, and data availability. | | **Execution Layer** | **T-REX Ledger (OP Stack Rollup)** | Executes ERC-3643 smart contracts and manages canonical issuance. | | **Validation Layer** | **Institutional PoA Quorum** | Trusted institutions co-sign transactions and attest to finality. | | **Bridging Layer** | **Freeze/Mint Protocol** | Handles cross-chain transfers with canonical accounting. | | **Identity & Compliance Layer** | **OnchainID + Claim Registries** | Provides verifiable identity and compliance enforcement. | | **API Layer** | **T-REX Engine** | Developer gateway for issuance, transfer, and compliance operations. | *** ### 9. Future Positioning The T-REX Ledger will **remain domain-specific** — optimized for tokenized financial assets rather than general-purpose computation. Future roadmap: * Expand the **institutional PoA network**. * Launch the **T-REX AppStore** for compliance-native financial applications. * Deepen **interoperability** with major L1/L2s for cross-chain liquidity. * Facilitate FHE integration for **privacy** * Evolve into the **trusted financial substrate** where regulated assets reconcile across all chains. *** ### 10. Privacy & Confidentiality (Optional FHE Layer) #### 10.1 Why add privacy / confidentiality? Public blockchains offer transparency, but that transparency is often a blocker for **large financial institutions** and regulated markets. Some reasons: * **Sensitive amounts**: Firms may not want their transaction volumes, balances, or financial positions exposed publicly. * **Strategic opacity**: For trade execution, hedging, or portfolio adjustments, revealing flows can leak market strategy. * **Regulatory / client confidentiality**: Custodians, asset managers, and clients require privacy guarantees to comply with reporting laws, client privacy rules, and trade secrecy. * **Risk management & segregation**: Masking internal flows or positions can reduce front-running, MEV attacks, or exposure to on-chain arbitrages. By offering a **privacy layer as an option**, T-REX can bridge the best of both worlds: * **Public verifiability and auditability** remain for those who want it. * **Selective confidentiality** for parties or flows that require privacy. That optional privacy makes the T-REX Ledger far more palatable to **major financial institutions** — they can use a public blockchain while still protecting sensitive data. #### 10.2 What technology underpins the privacy option? The privacy layer is built on **Fully Homomorphic Encryption (FHE)**, leveraging ideas pioneered by cryptography projects like **Zama** (in their “Confidential Blockchain Protocol” and fhEVM) to enable computation over encrypted data. Key properties of FHE (as applied here): 1. **Encrypted data at rest and in operation**\ Transaction amounts, addresses (or pseudonyms), and balances can remain encrypted, even while being processed by smart contracts. 2. **Public verifiability of correctness**\ Even though data is encrypted, validators (or proof systems) can **verify that computations were done correctly** (e.g. that balances add up, compliance constraints are met) without seeing the raw values. Zama’s design uses FHE + zero-knowledge proofs to guarantee integrity. 3. **Programmable decryption / access control**\ Smart contracts or compliance modules can define who is permitted to decrypt which data (e.g. a regulator, auditor, or the transacting parties). This is sometimes called **programmable confidentiality**. 4. **Composability and interoperability**\ FHE-based contracts can interoperate with non-confidential ones, enabling mixed workflows (some parts private, others public). 5. **Post-quantum resilience**\ Many FHE schemes are lattice-based, offering resistance against quantum attacks beyond classical cryptography. #### 10.3 How privacy fits into T-REX’s architecture Here’s how the privacy option plugs into the existing T-REX Ledger model: * **Opt-in privacy mode**\ Privacy is **optional**, not mandatory. Issuers or specific transactions/settings can enable confidentiality. * **Encrypted balances & transactions**\ In private mode, account balances and transaction amounts are stored in encrypted form. Only authorized parties (e.g. sender, receiver, regulator) can decrypt. * **Compliance logic on encrypted data**\ Even though values are encrypted, counterparties or compliance modules can enforce rules (e.g. transfer caps, KYC checks) via FHE computation so that the contract can still validate without fully revealing amounts. * **Bridging & canonical integrity** * When bridging out, the encrypted state must align with the canonical (public) representation so auditors / the T-REX Ledger can confirm no discrepancy. * Cross-chain freeze / mint logic will need to work with both encrypted and non-encrypted modes, ensuring that canonical accounting remains consistent even in private mode. * **Access control / audit decryption**\ For audit, regulatory, or legal disclosure, there must be mechanisms (e.g. threshold decryption or key-sharing among trusted parties) for authorized decryption of selected data. #### 10.4 Benefits by stakeholder (with privacy) **Financial Institutions** * Use a **public blockchain** (with Ethereum anchoring) while keeping internal flows and positions confidential. * Protect sensitive data from competitors, on-chain analysis, or front-running. * Satisfy client confidentiality and regulatory privacy mandates. **Issuers of Securities** * Issue tokens transparently but allow **private transfers** or tranche-level privacy (e.g. for high-net-worth investors). * Shield sensitive holdings, distribution patterns, or capital flows. * Maintain compliance but avoid exposing proprietary investment structures. **Investors** * Keep personal balances and transaction history private from public observers. * Enjoy the benefits of regulated, verifiable ownership without full exposure to the blockchain at large. * Selectively share decrypted proofs for audits or compliance only when needed. **Builders / Protocols** * Build **confidential dApps** on top of T-REX that integrate privacy by default (e.g. private settlement layers, auctions, confidential lending). * Leverage standard APIs and smart contract templates that support both encrypted and transparent modes. * Increase adoption by offering privacy-first modules without reinventing cryptography. #### 10.5 Summary & positioning Adding optional transaction confidentiality via FHE gives T-REX a **massive strategic advantage**: * It allows a **public, auditable, anchored blockchain** that also meets **top-tier institutional privacy demands**. * It bridges the gap between **permissioned privacy** (traditionally seen in private blockchains) and **public blockchain integrity**. * It strengthens T-REX’s positioning as the trusted **compliance and reconciliation layer** for regulated assets — offering both transparency *and* confidentiality. In short: **privacy is optional, but powerful** — making T-REX suitable for real-world finance without compromising on blockchain principles. # T-REX Ledger The compliant reconciliation ledger for Regulated Financial institutions *** #### **T-REX Ledger: The Golden Source of Truth** In a multi-chain environment, data synchronization is paramount for maintaining consistency and reliability across diverse blockchain networks. Regulated financial institutions and their issuers require a single, authoritative source of truth to ensure accurate and compliant operations. To address this need, the T-REX network will introduce the T-REX Ledger, the reference chain for RWAs. **Role of the T-REX Ledger** The T-REX reference chain will serve as the golden source of truth for all industry players within the RWA ecosystem. Its primary function is to provide a synchronized and reliable data layer that ensures consistency across multiple blockchains. This chain will not compete with or replace existing chains; instead, it will complement them by adding a crucial synchronization layer. The reference chain will become the data source for regulated transfer agents guaranteeing the legal transfer of ownership. **Key Features:** * **Single Source of Truth**: The T-REX Ledger will act as the definitive registry for asset ownership, providing a unified and authoritative record that all regulated entities can rely upon. This ensures that data is consistent and accurate across the ecosystem. * **Synchronization Layer**: By acting as a synchronization layer, the T-REX Ledger will facilitate seamless data exchange and verification across different blockchains. This interoperability is essential for maintaining the integrity and reliability of financial transactions in a multi-chain environment. * **Compliance and Regulation**: The T-REX Ledger will support regulated financial institutions by providing a transparent and auditable record of asset ownership. This compliance-focused approach ensures that all transactions adhere to regulatory standards, enhancing trust and security within the ecosystem. The introduction of the T-REX Ledger represents a significant step towards creating a more cohesive and reliable multi-chain environment, avoiding silos. By providing a golden source of truth and acting as a synchronization layer, it will enhance the interoperability, compliance, and efficiency of the T-REX ecosystem, benefiting all stakeholders involved. # T-REX Token Powering the T-REX Ecosystem *** At the core of the T-REX DAO is the T-REX token, a utility token designed to drive the ecosystem and facilitate various operations within the protocol. The T-REX token plays a crucial role in ensuring the smooth functioning and growth of the network. ## The Most Promising RWA token T-REX token offers direct exposure to the transition of finance towards tokenized real-world assets (RWAs). * Real, proven, audited technology * Largest Ecosystem of Financial institutions and Web3 players * Concrete token utilities * Long-term vision and clear roadmap {% content-ref url="/pages/CFK6RKfc1SPjjVnSmtvA" %} [T-REX Apps](/t-rex-network/t-rex-apps) {% endcontent-ref %} {% content-ref url="/pages/OmjdGN4F96hj98qIoJ0T" %} [Tokenomics](/t-rex-network/t-rex-token/tokenomics) {% endcontent-ref %} # Token Utilities Don't miss the RWA Great Transition *** ### $TREX powers the RWA infrastructure * **Gas for the T-REX Ledger:** The T-REX token will serve as the gas token for the T-REX Ledger, powering all transactions and operations within this data layer. By using the T-REX token, the ecosystem ensures a streamlined and efficient process for data synchronization and verification, further reinforcing the token's utility and value within the network. * **Ecosystem Governance**: T-REX token holders participate in the governance of the DAO, shaping its evolution to benefit all stakeholders. This collaborative approach ensures that the protocol remains dynamic and responsive to the needs of the community. * **Staking Rewards**: Holders can stake their T-REX tokens to support the network and earn rewards. This mechanism incentivizes long-term holding and active participation, contributing to the ecosystem's stability and growth. **The ecosystem generates revenues** through various means (cf. [Tokenomics](/t-rex-network/t-rex-token/tokenomics)). These revenues are used to accelerate the growth of the ecosystem. . * **Democratize access to RWA**: The T-REX token helps holders to access investment opportunities within the ecosystem. By verifying their identity through on-chain verifiable credentials, investors can participate in compliant and secure token offerings. # Tokenomics Strong Revenue Streams. Clear Community Incentives *** ## Protocol Revenues * **Real-World Asset Backing**: One of the primary revenue models involves backing T-REX tokens with real-world assets (RWA) generating yield and capital gains. By assisting projects in launching their tokenized assets, the DAO can invest in these projects and receive tokenized assets in return. This approach transforms T-REX into a decentralized cooperative for RWA, providing a robust and tangible backing for the T-REX token. * **Utilities Revenue**: The T-REX ecosystem includes various solutions essential for projects utilizing the protocol. Revenue is generated from the usage of these utilities, such as Token Deployment, OnchainID, AssetID, add-on smart contracts for subscriptions, redemptions, capital calls, compliance modules, etc. * **Liquidity Provision**: The DAO will provide liquidity on both decentralized and centralized exchanges, earning revenue as a liquidity provider. This activity supports the ecosystem by ensuring that T-REX tokens are readily available for trading, enhancing market accessibility. ## Token supply TGE: Q2 2026 Total supply: 1,000,000,000 | Class | Quantity | Vesting | | ---------------- | -------- | ----------- | | Contributors[^1] | 40% | 1-36 months | | Ecosystem[^2] | 40% | None | | Liquidity | 20% | None | [^1]: ERC3643 Core Contributors: 20% 10Y Budget for ERC3643 Members: 20% [^2]: Community: 20% Builders: 20% # ERC-3643 protocol The sole EVM Standard for Security tokens and RWAs *** ## Learning center {% embed url="" %} Learning center {% endembed %} *** ## Official Documentation Access the main documentation of the ERC-3643 token protocol. Discover how compliance and controls are applied on-chain for RWAs: {% embed url="" %} ## Official Github Deep dive in the token protocol and access the suite of tools and experimentations made by the ERC3643.org non-profit association: {% embed url="" %} ## Whitepaper of the Protocol Read the original T-REX Whitepaper and discover why the T-REX protocol is a game changer technology for finance: {% embed url="" %} # T-REX Engine The Enterprise-grade ERC-3643 API *** ## Streamlining interaction with ERC-3643 To fully leverage the capabilities of the ERC3643 protocol, an API called the T-REX Engine is introduced. This API serves as a crucial interface for interacting with the Solidity smart contracts that underpin the protocol, offering several key advantages: ### **Facilitating Integration:** The T-REX Engine API simplifies the integration process with the ERC-3643 protocol, making it accessible for both modern frontends and legacy systems used by financial institutions. By providing a standardized way to interact with the smart contracts, the API enables seamless integration, reducing the technical barriers associated with blockchain adoption. ### **Enhancing Data Access:** The API facilitates data access, allowing users to retrieve comprehensive information about transactions, stakeholder activities, asset data, and token lifecycle events. This transparency is essential for monitoring and managing assets within the ERC-3643 ecosystem, ensuring that all stakeholders have a clear view of ongoing activities. ### **Lifecycle Management:** The T-REX Engine API supports the entire lifecycle of tokenized assets, **from issuance to distribution and management**. It provides functions to trigger smart contract operations, enabling users to manage tokens efficiently and securely. This comprehensive support ensures that all aspects of token management are covered, from creation to redemption. ### **Security and Compliance:** The API is secured, audited, and even certified with SOC2 Type 2 certification, ensuring that it meets the highest standards of security and compliance. This certification provides assurance to users, particularly financial institutions, that the API adheres to stringent security protocols, protecting sensitive data and transactions. ### **Commercial Service:** The T-REX Engine is a commercial service provided by [Tokeny.com](/t-rex-network/t-rex-token/tokenomics), offering a direct and efficient way to access the T-REX network. While not mandatory, using the API can significantly accelerate projects by saving months or even years of development time. It provides a robust and reliable framework for interacting with the ERC-3643 protocol, enabling projects to focus on their core business objectives rather than technical integration challenges. # T-REX Community Join the Largest RWA Community ***
ChannelLinkOfficial account
Discord serverhttps://discord.gg/k5B3NdhwQH
Xhttps://x.com/trex_network
Telegramhttps://t.me/+qBi-5cBwzpA5MzA0
# FAQ Transparency is our mantra
What is T-REX?
What types of assets can be tokenized with T-REX?
What makes T-REX different than others RWA protocols?
Who is supporting T-REX?
How to join the RWA Great Transition?
# Glossary *** RWA Onchain Finance T-REX Network, T-REX DAO, T-REX Foundation. T-REX Token T-REX protocol ERC3643 association