What T-REX is

T-REX is a neutral, industry-led settlement and compliance layer governed by regulated financial institutions. It is not a competing L2 or a commercial venture, the objective is to provide the underlying infrastructure that allows transfer agents, custodians, CSDs, market infrastructures, and DeFi protocols to transact with full lifecycle control and regulatory oversight.

Why it is needed

FIs have built isolated private chains and stablecoin environments that don’t interoperate which will ultimately constrain adoption and fragment liquidity. Without a shared compliance and identity-based settlement layer, scaling digital markets globally becomes impossible.

Core principles

• Golden-source ledger framework bridging TradFi and DeFi

• Governance via an institutional DAO to ensure neutrality

• Anchored to a public L1 environment (EVM-based) for global interoperability

• Confidentiality via advanced cryptography (e.g., FHE)

• Built on ERC-3643, the institutional compliance standard used by 140+ members

RWAs were limited by tech, not regulation

The digital transformation of finance has introduced tokenization as a means to represent real-world assets on the blockchain. However, current tokenization protocols, particularly permissionless tokens like ERC-20, face significant limitations that hinder their effectiveness and adoption. Most RWA chains and protocols overlook that tokenizing an asset doesn't alter the nature of the underlying assets.

Globally, wherever securities regulations exist, asset tokenization is possible. However, this requires the ability to enforce these securities regulations within a blockchain infrastructure.

Existing Limitations:

• Lack of Compliance Integration: Most existing tokenization protocols do not integrate compliance mechanisms directly on-chain. This oversight leads to regulatory challenges, lack of transparency, and limits the participation of institutional investors who require strict adherence to financial regulations.

• Fragmented Ecosystem: The financial industry is highly fragmented, with various silos operating independently. So far, this fragmentation has been replicated on chain. This is exacerbated by the use of private recording systems and blockchains, which, despite their declining popularity, still contribute to a disjointed landscape. As a result, there is no unified ecosystem where all stakeholders can seamlessly and securely interact.

• Distributor-Level Tokenization: Tokenization often occurs at the distributor level (centralized exchange, bank or broker) rather than at the issuer level. This approach creates multiple ledgers, one for each distributor, leading to inefficiencies and the need for off-chain reconciliation. Without a single, aggregated ledger, the system remains complex and prone to errors.

Market Gaps:

• Compliance and Control: There is a pressing need for tokens that enforce compliance rules directly on-chain. Permissioned tokens, which can only be transferred to eligible investors based on compliance criteria, would provide issuers with the necessary assurances to authorize any application on the blockchain. These tokens also offer guarantees to investors, ensuring that they are the legal holders of the underlying assets, even in cases of wallet hacking or theft.

• Real-World Asset Integration: Current protocols struggle to effectively link real-world assets with their digital representations. This gap limits the potential of blockchain technology in asset management and hampers the adoption of tokenization in traditional finance.

• Unified Registry: The absence of a single registry that aggregates all transfers and investments from various platforms and distributors is a significant drawback. A unified registry would streamline operations, reduce reconciliation efforts, and enhance transparency.

Issues with simple ERC-20 Tokens:

• Transfer capable, but not legal: ERC-20 tokens are technically easy to transfer, but they often represent financial assets that are not freely transferable due to regulatory constraints. This discrepancy creates legal and compliance issues, as the ease of transfer does not align with the regulatory requirements of the underlying assets. These discrepancies undermine investor guarantees. Investors who purchased tokens on the secondary market think they own an asset. However, they do not appear in the legal registry.

• Bearer Instruments: Most countries have regulations against bearer instruments due to anti-money laundering (AML) and taxation rules. Simple ERC-20 tokens, which can be transferred without compliance checks, often fall into this category, making them non-compliant with regulations. Sanctions vary based on the asset's issuing country and the token holder's country, ranging from fines to imprisonment.

The Need for a New Approach:

To address these challenges, the industry requires a new approach that integrates compliance, unifies the ecosystem, and effectively links real-world assets with their blockchain representations.

This approach should focus on creating permissioned tokens that ensure great investor experience and compliance, enabling issuers to confidently authorize blockchain applications. By doing so, the industry can move towards a more cohesive and efficient system that benefits all stakeholders, providing them with the assurance of legal ownership and compliance.

ERC-3643 RWA tokens, with legal guarantees and DeFi interoperability.

Powering Mass Tokenization.

After years of technological development, new regulations, and education worldwide, it is finally time to massively tokenize assets on the blockchain. The Great Transition, where assets get massively tokenized on the blockchain, will occur over the next ten years.

The T-REX ERC-3643 protocol 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.

T-REX Protocol

The ERC-3643 protocol, known as "T-REX," is an advanced set of audited smart contracts designed to simplify the tokenization of financial assets. It allows for the seamless representation of assets and their underlying data, such as documents, prices, ratings, and certifications, as well as the legal identification of stakeholders on the blockchain. T-REX also enables the tracking of all investment activities, including transactions, investments, and redemptions. It is currently the only standard for tokenized securities recognized by the Ethereum community.

The protocol enhances the ERC-20 standard by integrating decentralized identity solutions and control functions. This extends the tokenization process by embedding critical compliance and control mechanisms directly into the cross-chain protocol. It provides a practical solution for linking real-world assets and financial securities to their blockchain representations.

• 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.

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.

The Need for an Interoperable Ecosystem.

Tokenizing financial assets is a complex process due to the intricacies of both finance and blockchain technology. The financial industry involves numerous actors with distinct roles, and the complexity varies based on the type of securities, jurisdictions, and investor types. Additionally, blockchain technology, including smart contracts, is often misunderstood, leading to further complications.

Challenges in the Current Landscape:

• Complexity in Finance and Blockchain: The intricate nature of finance and the technical complexities of blockchain make tokenization projects difficult to execute. This dual complexity results in lengthy legal and technical challenges.

• Educational Gaps: There is a significant need for education to bridge the knowledge gap between traditional finance and blockchain technology.

• Incompatibility of Traditional Systems: Most traditional financial systems are not equipped or compatible with blockchain technology. This incompatibility hinders seamless interaction and integration, further complicating the tokenization process.

Due to these challenges, current tokenization projects often lead to poor quality outcomes. These projects provide limited guarantees to investors and lack interoperability within the value chain, hindering seamless interactions between issuers, distributors, and on-chain applications.

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 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.

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.

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 Urgent Need for Standardization:

To overcome these challenges, market standardization is crucial. A standardized approach to tokenization would streamline the entire process, from issuance and lifecycle management to distribution. This would pave the way for the Great Transition, where most assets are digitized on the blockchain, leading to better management and enhanced liquidity.

Benefits of Standardizing the Ecosystem

Adopting a common framework like the T-REX ERC3643 protocol brings numerous advantages to the tokenization of financial assets, streamlining processes and enhancing efficiency.

Clear Roles and Execution:

• Guidelines and Best Practices: All actors can efficiently execute their roles using established guidelines and best practices, building on the experiences of previous projects and following the official guidelines and solutions provided by the DAO.

Interoperability and Compatibility:

• Single Integration: Service providers, including law firms, fund administrators, exchanges, and distributors, need only one integration to be compatible with all tokens, reducing technical burdens.

• Seamless Interaction: Standardized smart contracts enhance interoperability across the value chain, promoting consistent and compatible interactions.

• 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.

2017-2025

• Create and battle-test the token protocol with 140+ token issuers

• Develop core building blocks: Smart contracts suite, APIs, web interfaces, add-ons

• Validation with 20+ regulators in key financial jurisdictions

• Create the largest RWA non-profit association: ERC3643.org

• T-REX Ledger: Test net of the RWA Reference chain

• Key partnerships with technology providers and asset servicers

• Grant programs for Builders and RWA issuers

• Builders solutions onboarding

• Tokenization of 10T USD of assets

• Reach 1M holders exposed to tokenized RWAs

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: https://eips.ethereum.org/EIPS/eip-3643

Key Features of T-REX ERC-3643

• Multi-chain Protocol: The ERC-3643 protocol can be easily deployed and operated on any EVM-compatible blockchain, ensuring flexibility and broad applicability.

• Efficient Token Issuance: Issuers can deploy tokens in a single transaction while setting compliance and distribution rules. This efficiency simplifies the issuance process and enhances control.

• Data Enrichment: Tokens can be enriched with detailed data using embedded AssetID smart contracts, providing comprehensive information about the underlying assets on the blockchain. This feature enhances transparency, builds investor confidence, and enables advanced DeFi applications.

• Identity Verification: Investors' identities are represented anonymously using verifiable credentials on the blockchain. This ensures compliance while maintaining the confidentiality of investor data. The protocol is using an open DID framework compatible with all KYC solutions and agents.

• Compliance Modules: Additional compliance modules can be linked to the RWA tokens to enforce regulatory requirements directly on-chain. This ensures that all transactions adhere to predefined rules. Most of the time, these compliance modules are used to enforce offering rules, applicable to all investors.

• Centralized Registry: The protocol establishes a centralized but confidential registry on the blockchain, managed by the issuer or authorized agents (Transfer agent, CSD, etc.). This registry serves as a single, transparent source of truth accessible to all distributors and applications, reducing the need for off-chain reconciliation.

• Automated Operations: Rules for managing and transferring tokens are applied automatically and in real-time on the blockchain. This automation enhances efficiency and reduces the risk of errors.

• DeFi Compatibility: Assets tokenized using ERC-3643 are compatible with all decentralized finance (DeFi) applications, opening new opportunities for growth and innovation.

Learn more about the T-REX protocol:

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.

Dino Primary is the primary market rail of the T-REX ecosystem. It is a shared smart contract, deployed on the , 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.

Unlike general-purpose blockchains that rely on simple wallet whitelisting, T-REX enforces compliance directly within the smart contract logic of the asset thanks to the T-REX Protocol (ERC-3643).

• Embedded KYC/AML: Every transfer triggers a real-time check against the OnchainID identity registry.

• Modular Rule Engine: Issuers can program specific restrictions based on jurisdiction, investor type (e.g., Accredited vs. Qualified), holding periods, etc.

On-chain factories are official and ready-to-use smart contracts provided to the T-REX community.

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.

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.

To fully leverage the capabilities of the ERC3643 protocol, an API called the T-REX Engine is introduced. This API serves as a crucial interface for interacting with the Solidity smart contracts that underpin the protocol, offering several key advantages:

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.

Learning center

Official Documentation

Access the main documentation of the ERC-3643 token protocol. Discover how compliance and controls are applied on-chain for RWAs:

Official Github

Deep dive in the token protocol and access the suite of tools and experimentations made by the ERC3643.org non-profit association:

Whitepaper of the Protocol

Read the original T-REX Whitepaper and discover why the T-REX protocol is a game changer technology for finance:

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:

1. Dino Primary is deployed and initialized with the address of an AccessManager contract.

2. That AccessManager is responsible for:

   • Attaching permissions to each Dino Primary function selector

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;

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.

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.

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.

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

Subscriptions are only accepted when:

• dateOpened <= block.timestamp, and

• dateClosed == 0 or block.timestamp <= dateClosed, and

• minAmount <= amount <= maxAmount

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:

1. Dino Primary computes the gross amount owed based on the asset price and quantity.

2. It applies the malus:

   • Malus amount = grossAmount * malusBps / 10_000;

This allows the issuer to model:

• Exit penalties,

• Early redemption haircuts,

• Liquidity management fees.

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:

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:

Putting it all together, a typical lifecycle for a new asset is:

1. Deployment & Initialization

   • Dino Primary is deployed and initialized with:

     • ERC-3643 token address,

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

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

Access control (roles) is enforced by AccessManaged via an contract; see for role mapping.

Description

Subscribes amount of ERC-3643 tokens using paymentToken as consideration.

• For preminted assets:

  • Transfers amount of ERC-3643 from issuerSafe to msg.sender.

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).

Description

Redeems amount of ERC-3643 tokens back to the issuer, and pays the investor in paymentToken.

• For preminted assets:

  • Transfers ERC-3643 from msg.sender back to issuerSafe.

• For non-preminted assets:

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).

These functions do not modify state and allow UIs or off-chain systems to quote amounts without executing the operation.

Returns how much paymentToken is required to subscribe erc3643Amount of the asset.

Returns how many ERC-3643 tokens the investor would receive when paying paymentTokenAmount.

Returns net payment after applying redemption malus for redeeming erc3643Amount.

Returns how many ERC-3643 tokens the investor needs to redeem to receive paymentTokenAmount after malus.

Registers a new payment token:

• token – ERC-20 used for payments.

• priceFeed – for token vs pricing currency.

• isStable

Reverts if:

• token is zero address (ZeroAddress).

• Token already added (PaymentTokenAlreadyAdded).

Removes a payment token. It will no longer be accepted for new subscriptions or redemptions.

Reverts if:

• Token is not in the approved set (PaymentTokenNotApproved).

Updates price feed and stability flag for an existing payment token.

Reverts if token is not approved.

Allow enumerating all approved payment tokens, on top of the approvedPaymentTokens(token) getter.

Sets subscription period and per-tx min/max.

• dateOpened – unix timestamp when subscriptions start.

• dateClosed – unix timestamp when subscriptions end (0 = no end).

• minAmount / maxAmount

Reverts if minAmount > maxAmount (InvalidAmounts).

Same as subscription rules, plus:

• redemptionMalus – in basis points (e.g. 100 = 1%, 500 = 5%) applied as haircut on redemptions.

Returns current subscription rule set and whether the window is open at block.timestamp.

Same for redemptions, including the currently configured malus.

Updates the address that:

• Receives subscription proceeds.

• Pays redemptions.

Reverts if newIssuerSafe is zero address.

Toggles 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.

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.

This page explains how to operate and configure the Dino Secondary contract:

• Access control and roles

• Pausing / unpausing trading

• Fee configuration (fixed fees, volume-based fees, ecosystem fees)

• Introspection helpers, multicall, and events

• Suggested operational lifecycle

For function signatures and technical details, see .

Dino Secondary uses OpenZeppelin’s to enforce fine-grained permissions. Two logical roles are defined: an admin role and a fee manager role.

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

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:

1. Fixed fee per takeOffer operation (contract-level, configured here)

2. Volume-based fee proportional to traded volume (contract-level, configured here)

3. Ecosystem fee collected by the shared T-REX Ecosystem Fee Collector (configured at ecosystem level)

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).

The fixed fee configuration typically includes:

• fixedFeeToken – ERC-20 address;

• fixedFeeAmount – amount charged per takeOffer;

• fixedFeeRecipient

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%).

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

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:

1. Ecosystem fee is collected by the shared Fee Collector (multiplier: 3x).

2. Fixed fee is collected:

   • In fixedFeeToken, from the taker to fixedFeeRecipient

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

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 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.

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

Putting everything together, a typical lifecycle from an admin/operator standpoint looks like this:

1. Deployment via DinoFactory

   • DinoFactory deploys Dino Secondary linked to:

     • The ERC-3643 token

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

1. Caller checks prerequisites and approves tokens for DinoSecondary (for the ERC-20 leg).

2. 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

1. Validates that:

   • offerID refers to an existing offer.

   • Offer is Active and not expired.

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.

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

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

1. Concept and Purpose

The T-REX Ledger is the foundational layer of the ERC-3643 ecosystem — a domain-specific blockchain infrastructure designed to act as the canonical ledger and book of record for regulated digital assets.

Rather than competing with existing Layer 1 or Layer 2 blockchains, the T-REX Ledger functions as a trusted financial substrate where real-world assets, tokenized under ERC-3643, reconcile and settle across chains.

Its purpose is to provide:

• Authoritative on-chain recordkeeping for securities and other regulated financial instruments.

• Seamless interoperability with multiple chains for liquidity and user accessibility.

• Institutional-grade trust and compliance guarantees, enforced through an embedded governance and identity framework.

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:

1. Ethereum Anchoring: all state roots are periodically posted to Ethereum, inheriting its proven decentralization and immutability.

2. Institutional Proof-of-Authority (PoA) Layer: a quorum of trusted validators co-sign and attest to key on-chain events.

This hybrid approach provides:

• Ethereum-level settlement assurance.

• Institutional oversight and governance for regulatory confidence.

In summary:

T-REX Ledger = Ethereum-anchored rollup (OP Stack) + Institutional PoA validation layer It merges Ethereum’s security with the governance and trust framework expected in regulated financial infrastructure.

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

• 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:

1. Outbound Transfer

   • Tokens are frozen on the T-REX Ledger.

   • Equivalent tokens are minted on the destination chain.

➡️ 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.