Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
From a Fragmented Market to a unified Framework
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.
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.
The problem with the other tokenization protocols and blockchains
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.
The Ultimate RWA Ecosystem
ERC-3643
AppStore
AppChain
Utility Token
Community
Developer tools
Standardization enables Mass Adoption
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.
Adopting a common framework like the T-REX ERC3643 protocol brings numerous advantages to the tokenization of financial assets, streamlining processes and enhancing efficiency.
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.
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.
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.
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.
Don't miss the RWA Great Transition
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. ). 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.
Strong Revenue Streams. Clear Community Incentives
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.
TGE: Q1 2026
Total supply: 1,000,000,000
Join the Largest RWA Community
Discord server
X
Telegram
Merging TradFi with DeFi
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.
The interoperability infrastructure for compliant RWAs
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.
When standardization enables mass adoption.
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.
Validation with 20+ regulators in key financial jurisdictions
Create the largest RWA non-profit association: ERC3643.org
T-REX Chain: 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 OnchainID dApp
Release of the AssetID dApp
Release of the DINO dApp
Partnerships with Exchanges
T-REX Token launch
T-REX Chain: Main net of the RWA Reference chain
Tokenization of 10T USD of assets
Reach 1M T-REX token holders exposed to RWAs
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.
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
Contributors
40%
1-36 months
Ecosystem
40%
None
Liquidity
20%
None
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.
The ERC3643 Association is a non-profit organisation consisting of around 140 select members.
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.
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:
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.
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.
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
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:
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:
Read the official documentation from the ERC3643 Association:
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.
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.
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.
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.
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.
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.
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.
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)
DINO applications are provided by
The sole EVM Standard for Security tokens and RWAs
Access the main documentation of the ERC-3643 token protocol. Discover how compliance and controls are applied on-chain for RWAs:
Deep dive in the token protocol and access the suite of tools and experimentations made by the ERC3643.org non-profit association:
Read the original T-REX Whitepaper and discover why the T-REX protocol is a game changer technology for finance:
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.
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.
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.
A complete, secure and scalable set of APIs to interact with ERC-3643 tokens and the T-REX ecosystem.
A turnkey white-label platform to onboard RWA investors, collect their investments, manage portfolio, and access applications compatible with the T-REX ecosystem.
A simple and free decentralized application to verify claims on asset identities.
A simple and free decentralized application to verify claims on stakeholders' identities (Investors, issuers, agents, regulators).
An example of decentralized application connected to the DINO primary market distribution network for compliant security tokens and RWAs.
An example of decentralized application connected to the DINO secondary liquidity network for compliant security tokens and RWAs.
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.
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: [email protected]
A new Era for On-chain Finance
ERC-3643 RWA tokens, with legal guarantees and DeFi interoperability.
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 is the enabler of this fundamental change for finance.
T-REX, the utility token driving the ERC-3643 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.
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.
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
Learn more about the protocol:
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.
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.
Dino Primary is the primary market rail of the T-REX ecosystem. It is a shared smart contract, deployed on the 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.
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.
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
Under the hood, Dino Primary uses an 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.
A subscription is when an investor buys ERC-3643 tokens from the issuer, paying with an approved payment token.
High-level flow:
Configuration by the issuer
The issuer (or its delegates) configures:
Subscription open/close status,
Min/max subscription amounts,
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.
A redemption is when an investor sells their ERC-3643 tokens back to the issuer under pre-defined rules.
High-level flow:
Configuration by the issuer
The issuer configures:
Whether redemptions are open,
Min/max redemption amounts,
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.
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 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.
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,
When a subscription or redemption is attempted, Dino Primary:
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.
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.
Typical integration steps for a platform building on Dino Primary:
Discovery
Fetch Dino Primary configuration for a given token:
Subscription and redemption status.
Min/max amounts.
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.
For more detailed and technical information, see the subpages:
Roles, rule configuration, payment token management, fee model.
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.
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.
Accepted payment tokens and their price feeds.
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.).
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.
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).
Settlement & logging
The transaction settles atomically on-chain.
A Subscribed event is emitted with the relevant details for off-chain systems.
Accepted payment tokens,
Optional malus (a penalty or haircut on the redemption price).
Investor eligibility
As with subscriptions, the investor must remain compliant and verified under ERC-3643 rules.
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.
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.
Settlement & logging
The transaction settles atomically.
A Redeemed event is emitted with all key parameters.
Investor categorization (retail/professional, etc.),
Any additional custom compliance logic.
Accepted payment tokens and, where useful, their price feeds.
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.
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.
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).
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.
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:
Offers can be partially filled multiple times until:
Fully filled
Cancelled by the creator
Pruned after expiry or if conditions are no longer met
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
This design ensures:
RWA tokens remain tightly coupled with their identity/compliance logic
Standard ERC-20s are handled with a classic escrow pattern
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
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.
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
At the admin level, the contract uses an with roles (such as ADMIN_ROLE and FEE_MANAGER_ROLE) to control pausing and fee configuration. Those details are described on the page.
A maker:
Chooses:
Which token they are offering (tokenOut)
Which token they want in return (tokenIn)
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
A taker:
Selects an offer and decides how much to take (can be partial).
Approves the appropriate token if needed (e.g. payment token).
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:
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
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:
Pruning prevents stale or unsafe offers from being executed and keeps the active offer set clean.
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
As a result, secondary market activity remains fully compliant with the same rules as primary issuance and transfers.
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
Details on how to configure, calculate, and monitor these fees are covered in the page.
A typical integration with Dino Secondary follows these steps:
Discovery & Display
Query the list of open offers for a given ERC-3643 token.
Display:
Maker, price, remaining size, expiry, direction (buy/sell).
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
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.
For more details:
Roles, pausing, fee configuration, and operational best practices.
Solidity interfaces, function signatures, events, error codes, and concrete integration examples.
The Enterprise-grade ERC-3643 API
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.
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.
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.
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.
The T-REX Engine is a commercial service provided by Tokeny.com, 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.
The token being offered (tokenOut)
The token requested (tokenIn)
The respective amounts
An expiration time
The contract tracks:
Total offered amount
Filled amount
Remaining amount
Status (Active, Filled, Cancelled, Expired)
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
Freeze/unfreeze controls
If a transfer would violate compliance, the trade simply cannot be executed.
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
Calls createOffer(...) via their preferred dApp or platform.
tokenOutTransfers 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
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.
Emits OfferCancelled and charges the ecosystem fee for cancellation
Dino Secondary releases any frozen/escrowed tokens
Marks the offer as Expired
Emits OfferPruned
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.
A volume-based fee (percentage) capped to protect users
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(...)
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.
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
DINO Secondary dApp (and any other integrated front-ends) provide user-facing UIs on top of this shared contract.
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 page; here we focus on how to call the contract.
Each asset has its own instance of DinoPrimary, typically deployed and initialized via DinoFactory.
DinoPrimary exposes a few public variables:
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
Access control (roles) is enforced by AccessManaged via an contract; see for role mapping.
subscribeDescription
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:
In both cases:
Calculates total cost using a price feed implementing the .
Transfers paymentToken from investor to issuerSafe.
Collects protocol fee via ecosystemFeeCollector.
Reverts if:
Subscriptions are closed (SubscriptionClosed).
amount < minAmount or amount > maxAmount (AmountBelowMinimum / AmountAboveMaximum).
paymentToken
redeemDescription
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:
Then:
Computes payment amount based on NAV / price feed.
Applies redemption malus (haircut) if configured.
Transfers paymentToken from issuerSafe to investor.
Reverts if:
Redemptions are closed (RedemptionClosed).
amount < minAmount or amount > maxAmount (AmountBelowMinimum / AmountAboveMaximum).
paymentToken
These functions do not modify state and allow UIs or off-chain systems to quote amounts without executing the operation.
previewSubscribeWithExactErc3643Returns how much paymentToken is required to subscribe erc3643Amount of the asset.
previewSubscribeWithExactTokenReturns how many ERC-3643 tokens the investor would receive when paying paymentTokenAmount.
previewRedeemWithExactErc3643Returns net payment after applying redemption malus for redeeming erc3643Amount.
previewRedeemWithExactTokenReturns how many ERC-3643 tokens the investor needs to redeem to receive paymentTokenAmount after malus.
These helpers are ideal for front-ends: quote first, then call subscribe / redeem using the same parameters.
Requires TOKEN_MANAGER_ROLE via AccessManager.
addPaymentTokenRegisters a new payment token:
token – ERC-20 used for payments.
priceFeed – 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).
removePaymentTokenRemoves a payment token. It will no longer be accepted for new subscriptions or redemptions.
Reverts if:
Token is not in the approved set (PaymentTokenNotApproved).
updatePaymentTokenUpdates price feed and stability flag for an existing payment token.
Reverts if token is not approved.
getPaymentTokens / getPaymentTokenCountAllow enumerating all approved payment tokens, on top of the approvedPaymentTokens(token) getter.
Requires RULES_MANAGER_ROLE via AccessManager.
updateSubscriptionRulesSets 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).
updateRedemptionRulesSame as subscription rules, plus:
redemptionMalus – in basis points (e.g. 100 = 1%, 500 = 5%) applied as haircut on redemptions.
subscriptionRulesReturns current subscription rule set and whether the window is open at block.timestamp.
redemptionRulesSame for redemptions, including the currently configured malus.
Require ADMIN_ROLE via AccessManager.
updateIssuerSafeUpdates the address that:
Receives subscription proceeds.
Pays redemptions.
Reverts if newIssuerSafe is zero address.
updatePremintedToggles mode:
true – transfer from issuerSafe (treasury).
false – mint/burn via ERC-3643 permissions.
Emits PremintedUpdated.
event IssuerSafeUpdated(address indexed oldIssuerSafe, address indexed newIssuerSafe)
event PremintedUpdated(address indexed updatedBy, bool preminted)
event PaymentTokenAdded(address indexed token, address priceFeed, bool isStable)
Plus inherited:
AuthorityUpdated(address authority) from AccessManaged.
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.
These are meant to be developer-friendly and easily mapped to front-end error messages.
The compliant reconciliation ledger for Regulated Financial institutions
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.
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.
To combine public settlement security and institutional trust, the T-REX Ledger introduces a dual validation architecture:
Ethereum Anchoring: all state roots are periodically posted to Ethereum, inheriting its proven decentralization and immutability.
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.
All canonical asset issuance occurs on the T-REX Ledger, which functions as the authoritative chain for tokenized financial instruments.
Full implementation of ERC-3643, including:
Embedded identity management
Claim registries for KYC/AML and investor eligibility
Compliance logic enforced natively on-chain
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.
Cross-chain movement follows a freeze / mint model, preserving canonical integrity:
Outbound Transfer
Tokens are frozen on the T-REX Ledger.
Equivalent tokens are minted on the destination chain.
Inbound Transfer
➡️ Result: The T-REX Ledger always maintains the canonical accounting of balances — no double issuance, no desynchronization.
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.
Regulatory confidence through PoA-based validation and Ethereum anchoring.
Simplified reconciliation across chains with a single authoritative ledger.
Interoperability without compromising compliance.
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.
Transparent and verifiable ownership on a regulated chain.
Inter-chain liquidity without losing regulatory protection.
Instant, compliant transferability.
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.
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.
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
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.
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.
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):
Encrypted data at rest and in operation Transaction amounts, addresses (or pseudonyms), and balances can remain encrypted, even while being processed by smart contracts.
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.
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.
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.
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.
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.
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)
External tokens are burned.
Frozen tokens on the T-REX Ledger are unlocked.
Direct Mint-and-Bridge Flows
Issuers can mint on T-REX and deliver directly to another chain in a single transaction, streamlining initial distribution.
Synchronized Accounting
Transfers on external chains are automatically mirrored on the T-REX Ledger using frozen tokens, ensuring continuous reconciliation.
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.
Evolve into the trusted financial substrate where regulated assets reconcile across all chains.
Composability and interoperability FHE-based contracts can interoperate with non-confidential ones, enabling mixed workflows (some parts private, others public).
Post-quantum resilience Many FHE schemes are lattice-based, offering resistance against quantum attacks beyond classical cryptography.
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.
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.
DinoPrimaryecosystemFeeCollector() – protocol fee collector.
nonce() – incremented per subscription / redemption; also emitted in events.
approvedPaymentTokens(token) – returns price feed and stability info for a payment token.
Mints amount of ERC-3643 to msg.sender.
Emits Subscribed(nonce, investor, paymentToken, amount, totalCost).
PaymentTokenNotApprovedERC-3643 transfer / mint is not compliant (TransferNotCompliant, InvestorNotQualified).
Price feed issues (InvalidPriceFeed).
Fee collection fails (e.g. missing approval / balance on fee token).
Burns ERC-3643 from msg.sender (DinoPrimary is an authorized agent).
Emits Redeemed(nonce, investor, paymentToken, amount, paymentAmount).
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).
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)
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.
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 { /* ... */ }IERC3643 public erc3643;
address public issuerSafe;
bool public preminted;
IFeeCollector public ecosystemFeeCollector;
uint256 public nonce;
mapping(address => PaymentToken) public approvedPaymentTokens;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;
}function subscribe(
uint256 amount,
address paymentToken
) external nonReentrant returns (uint256 nonce);function redeem(
uint256 amount,
address paymentToken
) external nonReentrant returns (uint256 nonce);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);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);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
);function updateIssuerSafe(address newIssuerSafe) external;function updatePreminted(bool _preminted) external;Introspection helpers, multicall, and events
Suggested operational lifecycle
For function signatures and technical details, see Dino Secondary – Developer Reference.
Dino Secondary uses OpenZeppelin’s AccessManager to enforce fine-grained permissions. Two logical roles are defined: an admin role and a fee manager role.
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
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.
Dino Secondary supports three fee layers:
Fixed fee per takeOffer operation (contract-level, configured here)
Volume-based fee proportional to traded volume (contract-level, configured here)
Ecosystem fee collected by the shared T-REX Ecosystem Fee Collector (configured at ecosystem level)
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.
On top of fixed and volume-based fees, Dino Secondary also participates in the ecosystem fee model.
For each high-level operation, Dino Secondary multiplies a shared base ecosystem fee by a specific multiplier: DinoSecondary
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
When a trade is executed via takeOffer:
Ecosystem fee is collected by the shared Fee Collector (multiplier: 3x).
Fixed fee is collected:
In fixedFeeToken, from the taker to fixedFeeRecipient.
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
To make integration easier, Dino Secondary exposes several view functions to introspect fee configuration: DinoSecondary
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
Dino Secondary inherits OpenZeppelin’s 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.
The contract emits detailed events for operational and admin actions. DinoSecondary
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.
AuthorityUpdated
Emitted when the controlling AccessManager is updated.
Recommendation: index at least OfferCreated, OfferTaken, OfferCancelled, OfferPruned, FixedFeeUpdated, VolumeFeeUpdated, Paused, and Unpaused in your backend or analytics pipeline.
Putting everything together, a typical lifecycle from an admin/operator standpoint looks like this:
Deployment via DinoFactory
DinoFactory deploys Dino Secondary linked to:
The ERC-3643 token
An AccessManager (new or existing)
The ecosystem Fee Collector
Role Assignment
AccessManager admin assigns:
ADMIN_ROLE to issuer / operator multisig
FEE_MANAGER_ROLE
Fee Configuration
FEE_MANAGER_ROLE calls:
setFixedFee to set fixed fee token, amount, and recipient
Production Trading
Users create, take, cancel, and prune offers through integrated dApps and platforms.
Ecosystem, fixed, and volume-based fees are collected automatically.
Operational Controls
In case of incidents or planned maintenance, ADMIN_ROLE can:
pause() trading
Monitoring & Auditing
Off-chain systems monitor:
Fee updates
Pauses/unpauses
setVolumeBasedFee to set bps rate (≤ 100 bps) and recipientunpause() once conditions are safe again
Offer lifecycle events
Data can be used for:
Market surveillance
Compliance & reporting
Revenue accounting
Paused
Emitted when the contract is paused.
Unpaused
Emitted when the contract is unpaused.
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 uses 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.
Dino Primary defines three logical roles:
Roles are not granted directly by Dino Primary itself. Instead:
Dino Primary is deployed and initialized with the address of an AccessManager contract.
That AccessManager is responsible for:
Attaching permissions to each Dino Primary function selector
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
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
ADMIN_ROLE)Holders of ADMIN_ROLE can manage core configuration of Dino Primary.
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.
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,
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.
TOKEN_MANAGER_ROLE)Holders of TOKEN_MANAGER_ROLE configure which payment tokens can be used for subscriptions and redemptions, and how they are priced.
Dino Primary exposes three management functions:
Each payment token is associated with:
token – ERC-20 address of the payment token;
priceFeed – an oracle contract implementing the ;
isStable – boolean indicating whether the token is considered stable vs the pricing currency used for the asset (e.g. NAV in USD).
Only add payment tokens that:
Have reliable liquidity and oracle feeds;
Are supported by your compliance / risk policies.
Removing a payment token:
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 are updated via:
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;
Subscriptions are only accepted when:
dateOpened <= block.timestamp, and
dateClosed == 0 or block.timestamp <= dateClosed, and
minAmount <= amount <= maxAmount.
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.
Redemption rules are updated via:
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:
Dino Primary computes the gross amount owed based on the asset price and quantity.
It applies the malus:
Malus amount = grossAmount * malusBps / 10_000;
Net paid to investor =
This allows the issuer to model:
Exit penalties,
Early redemption haircuts,
Liquidity management fees.
Any change to redemption rules (especially malus) should be clearly disclosed to investors and reflected in legal / regulatory documentation.
Dino Primary integrates with the T-REX Ecosystem Fee Collector to charge protocol-level fees on top of the asset economics.
Per design, Dino Primary applies multipliers on a base ecosystem fee:
The base fee, fee token, and recipient are managed by the ecosystem fee collector, not by the Dino Primary contract itself.
On each subscription or redemption:
Dino Primary calls ecosystemFeeCollector.collectFee(msg.sender, FEE_MULTIPLIER_*).
The user must have:
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.
Dino Primary emits events for all important administrative and economic actions. These can be indexed by back-office systems, analytics, and monitoring tools.
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.).
Inherited from the AccessManaged / AccessManager system:
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.
Putting it all together, a typical lifecycle for a new asset is:
Deployment & Initialization
Dino Primary is deployed and initialized with:
ERC-3643 token address,
Initial issuer safe,
RULES_MANAGER_ROLE to the team in charge of product / risk / compliance.
A separated address (or multisig) for RULES_MANAGER_ROLE to keep configuration changes auditable and controlled.
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.
preminted = falseToken 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.
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.
maxAmount – maximum amount of ERC-3643 tokens that an investor can subscribe in a single transaction.
grossAmount - malusAmountSufficient fee token balance.
RedemptionRulesUpdated
Emitted when redemption rules / malus are changed.
preminted flag,
AccessManager address,
Ecosystem fee collector.
Role Assignment
AccessManager admin assigns:
ADMIN_ROLE to issuer governance / treasury,
TOKEN_MANAGER_ROLE to treasury/ops,
RULES_MANAGER_ROLE to risk/product/compliance.
Payment Token Setup
TOKEN_MANAGER_ROLE adds one or more payment tokens (USD1, USDC, etc.) with price feeds.
Rule Setup
RULES_MANAGER_ROLE sets initial subscription and redemption rules (dates, min/max, malus).
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.
Monitoring
Back-office systems listen to events to track configuration changes and investor activity.
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 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.
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
Subscription Rules
updateSubscriptionRules
RULES_MANAGER_ROLE
Sets subscription period and amount limits.
Redemption Rules
updateRedemptionRules
RULES_MANAGER_ROLE
Sets redemption period, amount limits, and redemption malus percentage.
Subscribe
3x base fee
Fee charged on each subscription transaction
Redeem
3x base fee
Fee charged on each redemption transaction
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.
Subscribed
Emitted on every successful subscription.
Redeemed
Emitted on every successful redemption.
AuthorityUpdated
Emitted when the AccessManager controlling Dino Primary is updated.
Issuer Risk / Product / Compliance
Updates price feed and/or stability status of an existing payment token.
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 page.
At a high level, the public interface exposed to integrators is:
Represents a fee configuration used by DinoSecondary:
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%).
Offer lifecycle states:
Active – Offer is live and can be taken.
Filled – Offer is fully executed.
Cancelled – Cancelled by creator.
Represents a single order in the book:
Amounts always keep the original price ratio: partial fills are proportional and update the filledAmount* fields accordingly.
Purpose
Create a new offer to sell tokenOut for tokenIn at a fixed ratio amountIn / amountOut.
High-level flow
Caller checks prerequisites and approves tokens for DinoSecondary (for the ERC-20 leg).
Contract validates:
amountOut and amountIn are non-zero.
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.
Purpose
Accept an existing offer (partially or fully) and execute the trade.
High-level flow
Validates that:
offerID refers to an existing offer.
Offer is Active and not expired.
amount
Common errors
InvalidOfferId(offerID) – offer does not exist.
ZeroAmount() – taker tries to take 0.
InvalidTokenTransfer(token) – failure in underlying token transfer.
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
Common errors
InvalidOfferId(offerID) – no such offer.
OfferNotCreatedBySender(offerID, sender) – caller is not the original maker.
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.
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.
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.
fixedFee()
feeToken: token used for the fixed fee.
feeAmount: fixed fee amount.
The implementation also provides convenience view functions for the raw recipients (fixedFeeRecipient, volumeFeeRecipient) as documented in the DinoSecondary docs.
Returns the ERC-3643 token address this DinoSecondary instance is bound to. Every offer must involve this token in at least one leg.
Shortcut to read only the expiry field for a given offer.
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.
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.
DinoSecondary uses a dedicated events library for consistent logging.
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.
You should surface these errors in your dapp for clearer UX (e.g. mapping them to human-readable messages).
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.
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.
Expired – Expired based on expiry timestamp and/or pruned.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.
expiry is in the future.At least one leg is the ERC-3643 token bound to this DinoSecondary instance.
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).
Offer struct is stored and a unique offerID is assigned (monotonically increasing).
Ecosystem fee is charged via the T-REX fee collector.
OfferCreated event is emitted.
Computes the proportional amountIn based on original price ratio.
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.
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.
Offer state updated:
filledAmountOut / filledAmountIn updated.
Status set to Filled if fully executed; otherwise remains Active.
Events:
OfferPartiallyFilled if there is remaining liquidity.
OfferFilled if fully executed.
VolumeFeeExceedsAmount(volumeFee, amount) – volume-based fee would be larger than the traded amount. OfferCancelled event is emitted.
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.
OfferPruned(uint256 offerID)
Offer is administratively pruned
offerID
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.
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.
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.
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.
OfferCreated(uint256 offerID, address offerCreator, address tokenOut, uint256 amountOut, address tokenIn, uint256 amountIn, uint256 creationTime, uint256 expiry)
A new offer is created
offerID, maker, tokens and amounts, timestamps
OfferPartiallyFilled(uint256 offerID, uint256 amount, uint256 remainingAmount, address taker)
An offer is filled but liquidity remains
amount filled in this trade, remaining, taker
OfferFilled(uint256 offerID, address taker)
Offer is fully filled
Final taker
OfferCancelled(uint256 offerID)
Maker cancels the offer
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.
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.
offerID
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);
}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 fixedFee() external view returns (Fee memory);
function volumeFee() external view returns (Fee memory);function TREX() external view returns (address);function getOfferExpiry(uint256 offerID) external view returns (uint256);function getCurrentOfferID() external view returns (uint256);function getOfferDetails(uint256 offerID) external view returns (Offer memory);