The Urgent Need for Standardization:

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

Benefits of Standardizing the Ecosystem

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

Clear Roles and Execution:

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

Interoperability and Compatibility:

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

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

Reduced Complexity:

• Audited Smart contracts: Using an audited and market-proven standard removes technical complexity, eliminating the need for extensive tech due diligence.

• Time and Cost Efficiency: Significant savings in time and cost, as issuers, service providers, and investors can rely on the protocol's credibility and widespread use.

Accessibility and Trust:

• Technology Access: T-REX democratizes access to technology, enabling even small asset owners to leverage tokenization benefits, driving innovation and growth.

• Investor Confidence: Investors gain assurance that their rights are protected without needing to analyze smart contracts, enhancing trust and adoption.

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.

Creating a Coherent Ecosystem

By standardizing with T-REX, we create a more efficient, interoperable, and trustworthy environment for financial asset tokenization, benefiting all stakeholders.

A coherent and interoperable ecosystem is essential for successful asset tokenization at scale. The T-REX protocol aims to provide this standardized framework, leveraging the ERC-3643 suite of smart contracts and the guidelines provided by the ERC3643 Association. By ensuring seamless interaction among all stakeholders, it reduces legal and technical hurdles and enhances the reliability of tokenized assets.

Streamlining interaction with ERC-3643

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

Facilitating Integration:

The T-REX Engine API simplifies the integration process with the ERC-3643 protocol, making it accessible for both modern frontends and legacy systems used by financial institutions. By providing a standardized way to interact with the smart contracts, the API enables seamless integration, reducing the technical barriers associated with blockchain adoption.

Enhancing Data Access:

The API facilitates data access, allowing users to retrieve comprehensive information about transactions, stakeholder activities, asset data, and token lifecycle events. This transparency is essential for monitoring and managing assets within the ERC-3643 ecosystem, ensuring that all stakeholders have a clear view of ongoing activities.

Lifecycle Management:

The T-REX Engine API supports the entire lifecycle of tokenized assets, from issuance to distribution and management. It provides functions to trigger smart contract operations, enabling users to manage tokens efficiently and securely. This comprehensive support ensures that all aspects of token management are covered, from creation to redemption.

Security and Compliance:

The API is secured, audited, and even certified with SOC2 Type 2 certification, ensuring that it meets the highest standards of security and compliance. This certification provides assurance to users, particularly financial institutions, that the API adheres to stringent security protocols, protecting sensitive data and transactions.

Commercial Service:

The T-REX Engine is a commercial service provided by , 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.

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)

The ERC-3643 protocol - code name "T-REX" - is a sophisticated suite of audited smart contracts designed to streamline the tokenization of financial assets. It enables the seamless representation of assets, the data of their underlying assets (documents, price, rating, certifications, etc.), and the legal identification of various stakeholders on the blockchain. Additionally, it facilitates the tracking of all investment activities, including transactions, investments, and redemptions.

Currently, ERC-3643 is the sole standard for tokenized securities recognized by the Ethereum community:

Key Features of T-REX ERC-3643

The T-REX DAO

T-REX operates as a Decentralized Autonomous Organization (DAO), an innovative structure that eliminates traditional shareholders. Instead, token holders become the beneficiaries of the T-REX ecosystem, placing power in the hands of the community.

T-REX Network manages a strategic treasury, allocating budgets to key initiatives such as the ERC3643 Association and various service providers. It also implements grant programs to stimulate the ecosystem, creating a dynamic environment where innovation and collaboration thrive.

ERC3643 Association

The ERC3643 Association is a non-profit organisation consisting of around 140 select members.

These core contributors collaborate to develop open-source tools and solutions for the T-REX ecosystem, establish guidelines, and ensure the open-source protocol continually evolves.

The association's members are actively engaged in various projects, currently focusing on privacy, cross-chain compatibility, decentralized identity, data management, and innovative tools for token management and distribution. All outputs from these working groups and projects are published publicly and made available to the T-REX Ecosystem.

ERC3643 Association receives an annual budget in T-REX tokens from the T-REX DAO. These tokens serve to motivate members to actively contribute to protocol development.

Builders

T-REX Builders specialise in creating and operating products and services compatible with ERC-3643 tokens. They commit to:

• Hold T-REX tokens to demonstrate commitment and alignment with official ERC-3643 tools.

• Exclusively recognize ERC-3643 tokens issued via the official Token Factory.

• Be interoperable and collaborate to create a cohesive and compatible ecosystem.

Discover the vetted Builders of the T-REX Ecosystem:

Community of Investors

The T-REX ecosystem stands out by offering the most extensive selection of standardized tokenized assets, providing investors with unparalleled opportunities. By ensuring that assets are tokenized in full compliance and that smart contracts are robustly secure, T-REX instills confidence in investors. Moreover, the ecosystem processes data related to underlying assets in a standardized and certified manner on the blockchain, adding an extra layer of trust and transparency.

Investors within the T-REX ecosystem enjoy the convenience of reusing their on-chain identity across various assets, enhancing their investment experience. This cohesive and compatible environment creates compelling incentives for investors to join a thriving community focused on tokenized assets, driving growth and innovation in the space.

On-chain Factories

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

2017-2025

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

Learning center

Official Documentation

Dino is the onchain distribution and market infrastructure of the T-REX ecosystem. It provides a shared set of smart contracts that any issuer, distributor, broker-dealer, or dApp builder can plug into to distribute and trade ERC-3643 (T-REX) tokens.

Instead of every project deploying its own isolated subscription forms and OTC order books, Dino runs on a shared infrastructure (the T-REX Ledger). This turns fragmented primary and secondary flows into a common liquidity pool, where all participants benefit from the same rails and network effects.

What Dino Does

At a high level, Dino provides three building blocks:

• DinoFactory – Deploys and wires Dino contracts (Primary & Secondary) for a given ERC-3643 token, with standardized roles, fees, and permissions.

• DinoPrimary – Handles onchain subscription and redemption flows for T-REX tokens in the primary market (investors subscribing to new tokens or redeeming them with the issuer).

• DinoSecondary – Handles onchain trading intents in the secondary market (investors posting offers to buy or sell existing T-REX tokens).

Together, they form a single onchain venue where compliant primary flows and secondary trading can coexist for any ERC-3643 token connected to the T-REX Ledger.

Dino Primary: On-Chain Subscriptions & Redemptions

DinoPrimary is the primary market layer for T-REX tokens:

• Issuers (or their distributors) can open subscription windows and let qualified investors subscribe onchain using approved payment tokens (e.g. stablecoins).

• The same rail can be used for redemptions, allowing investors to sell tokens back to the issuer under predefined rules.

• All flows are compliance-aware, leveraging the ERC-3643 identity and eligibility checks (Identity Registry, ONCHAINID, etc.).

For the user, this can look like a simple “Invest” / “Redeem” button in a dApp or platform UI. Under the hood, all issuers use the same DinoPrimary infrastructure, which:

• Standardizes subscription and redemption logic.

• Applies ecosystem fees in a predictable way.

• Ensures that investor qualification and token compliance are enforced at the contract level.

The result: repeatable, interoperable primary flows for any compliant RWA, instead of one-off bespoke implementations per issuer.

Dino Secondary: Shared Intent-Based Liquidity

DinoSecondary is the secondary market layer:

• Investors can publish offers (intents) to buy or sell a given T-REX token against another token (typically a payment token).

• Other participants can take those offers, fully or partially, enabling peer-to-peer trading.

• Offers are managed onchain with expiry, pruning, and compliance checks built in.

Because DinoSecondary is shared:

• Any broker-dealer, platform, or dApp can plug into the same pool of offers.

• Liquidity doesn’t get siloed inside a single interface, it’s aggregated at the contract level.

• The same fee and compliance framework applies to all trades, simplifying integrations.

This creates a common secondary liquidity network for ERC-3643 tokens, rather than fragmented OTC channels scattered across different systems.

Running on the T-REX Ledger: Shared Infrastructure by Design

Dino contracts are deployed on the T-REX Ledger, which acts as the reference chain for compliance and market infrastructure across the ecosystem.

Because DinoPrimary and DinoSecondary are shared contracts on this common ledger:

• Any compliant ERC-3643 token can attach to the same primary and secondary rails via the DinoFactory.

• Distributors, broker-dealers, custodians, and platforms can integrate once and access all Dino-enabled tokens.

• New apps (e.g. white-label platforms, bespoke institutional portals, wallets, or aggregators) can reuse the same contracts and liquidity instead of rebuilding their own infrastructure.

In other words, Dino is not a single app, it is the onchain market layer that all T-REX-compatible apps can build on.

Who Is Dino For?

Dino is designed to be used by:

• Issuers & Fund Managers Use DinoPrimary to run compliant onchain subscriptions and redemptions for their RWA programs.

• Distributors, Broker-Dealers & Market Operators Plug into DinoPrimary and DinoSecondary to distribute products and provide liquidity without reinventing the rails.

• Platforms & dApp Builders Build investor-facing experiences on top of shared infrastructure, benefiting from common standards, fees, and compliance behavior.

Dino in the T-REX Apps Stack

Within the broader T-REX ecosystem:

• T-REX Engine exposes APIs to interact programmatically with Dino contracts.

• T-REX Platform and dedicated dApps (DINO Primary dApp, DINO Secondary dApp) provide investor-facing UIs on top of these contracts.

• Dino itself is the neutral, shared smart contract layer that all of these applications use for distribution and trading.

The detailed mechanics of primary subscriptions/redemptions and secondary offers/trades are described on the next pages:

• Dino Primary (primary market flows)

• Dino Secondary (secondary market flows)

• Dino Factory (deployment and access control)

Commercial Service

DINO applications are provided by

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.

Key Features

• Standardized subscription & redemption flows Unified logic across all Dino-enabled ERC-3643 tokens, with instant settlement onchain.

• Multiple payment tokens Issuers can accept several payment tokens (e.g. stablecoins and non-stable tokens) and configure them per asset.

• Price oracle integration Dino Primary plugs into price feeds so the contract can compute how many asset tokens correspond to a given payment amount.

Actors & Roles

At a conceptual level, Dino Primary involves:

• Issuer / Issuer Safe The party responsible for the asset and the wallet that receives subscription proceeds and pays redemptions.

• Investors Wallets holding ERC-3643 tokens (or subscribing for them) that are verified and compliant.

• Distributors / Platforms / dApps Front-ends integrating with Dino Primary to offer “Invest” and “Redeem” experiences to end-users.

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.

Subscription Flow

A subscription is when an investor buys ERC-3643 tokens from the issuer, paying with an approved payment token.

High-level flow:

1. Configuration by the issuer

   • The issuer (or its delegates) configures:

     • Subscription open/close status,

From a front-end perspective, this is typically surfaced as a simple “Invest” button with fields for amount and payment token, while all compliance and settlement logic happens within Dino Primary and the ERC-3643 token.

Redemption Flow

A redemption is when an investor sells their ERC-3643 tokens back to the issuer under pre-defined rules.

High-level flow:

1. Configuration by the issuer

   • The issuer configures:

     • Whether redemptions are open,

From the end-user perspective, this is usually exposed as a “Redeem” or “Sell back to issuer” action with clear display of applicable rules and any malus.

Payment Tokens & Pricing

Dino Primary supports:

• Stable payment tokens Tokens considered stable against the reference asset (e.g. USD), where pricing can be treated as 1:1 or based on simple rules.

• Non-stable payment tokens Tokens whose value fluctuates (e.g. other cryptocurrencies). For these, Dino Primary integrates with a price oracle implementing configured per payment token.

This allows issuers to:

• Offer subscriptions/redemptions in several currencies or tokens.

• Keep the asset priced in one reference unit (e.g. NAV in USD) while accepting payments in different tokens.

The configuration and management of payment tokens is described in the Dino Primary – Admin & Management subpage.

Compliance & ERC-3643 Integration

Dino Primary is designed to work with ERC-3643 permissioned tokens:

• Every investor wallet is linked to an ONCHAINID in the Identity Registry.

• The ERC-3643 token enforces:

  • KYC/AML status,

When a subscription or redemption is attempted, Dino Primary:

1. Calls into the ERC-3643 token / Identity Registry to confirm:

   • The investor is registered and eligible.

   • The transfer or burn/mint operation is allowed by compliance rules.

This ensures that every primary market operation is compliance-aware by design, not just at the UI layer.

Integration Patterns for Platforms & dApps

Typical integration steps for a platform building on Dino Primary:

1. Discovery

   • Fetch Dino Primary configuration for a given token:

     • Subscription and redemption status.

Because Dino Primary is a shared contract on the T-REX Ledger, the same integration can be reused across multiple assets, issuers, and distribution channels.

Related Documentation

For more detailed and technical information, see the subpages:

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

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 .

Access Control System

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

Roles

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

Admin Management Settings (ADMIN_ROLE)

Core Configuration Functions

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.

Fee Manager Settings (FEE_MANAGER_ROLE)

Dino Secondary supports three fee layers:

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

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

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

Fee Configuration Functions

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.

Fee System

On top of fixed and volume-based fees, Dino Secondary also participates in the ecosystem fee model.

Ecosystem Operation Fees

For each high-level operation, Dino Secondary multiplies a shared base ecosystem fee by a specific multiplier: DinoSecondary

Ecosystem fees are handled by the T-REX Ecosystem Fee Collector:

• Users must approve the ecosystem fee token for the Fee Collector.

• Dino Secondary calls the Fee Collector with the relevant multiplier when operations occur. DinoSecondary

Combined Fee Flow per takeOffer

When a trade is executed via takeOffer:

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

2. Fixed fee is collected:

   • In fixedFeeToken, from the taker to fixedFeeRecipient

From a UX perspective, you should:

• Preview all three fee layers in your dApp when quoting the trade

• Clearly differentiate protocol (ecosystem) fees from market/platform fees

Fee Introspection Helpers

To make integration easier, Dino Secondary exposes several view functions to introspect fee configuration: DinoSecondary

These allow frontends and off-chain services to:

• Fetch current fee settings

• Display them in UI / legal notices

• Validate that configuration matches expected policies

Multicall Support

Dino Secondary inherits OpenZeppelin’s 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.

Events & Monitoring

The contract emits detailed events for operational and admin actions. DinoSecondary

Dino Secondary–Specific Events

Inherited AccessManaged Events

Typical Operational Lifecycle

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

1. Deployment via DinoFactory

   • DinoFactory deploys Dino Secondary linked to:

     • The ERC-3643 token

Dino Secondary is the shared secondary market rail of the T-REX ecosystem.

It is a smart contract deployed on the T-REX Ledger that lets investors, distributors, and broker-dealers:

• Publish on-chain intents (offers) to buy or sell ERC-3643 (T-REX) tokens

• Partially or fully take existing offers

• Share liquidity across multiple platforms and dApps, instead of fragmenting it into isolated OTC channels

Every offer is created and settled directly onchain, with:

• Built-in compliance integration for ERC-3643

• Freezing of RWA tokens instead of moving them to escrow which helps maintain the integrity of the onchain cap tables at all times

• Configurable fee mechanisms for both the ecosystem and the asset issuer/operator

Dino Secondary is not a single UI. It is the neutral onchain marketplace layer that any T-REX-compatible application can plug into.

Key Features

Intent-Based Trading

• Offer creation – Any investor or participant can publish an offer expressing their intent to:

  • Sell an ERC-3643 token for another token (e.g. stablecoin), or

  • Buy an ERC-3643 token by offering another token.

Partial Fills & Offer States

• Offers can be partially filled multiple times until:

  • Fully filled

  • Cancelled by the creator

Two Token Handling Modes

Dino Secondary supports two ways to handle the asset vs payment tokens:

• Freeze mode for ERC-3643 tokens When the offer is selling the ERC-3643 token:

  • The RWA tokens remain in the seller’s wallet

  • They are frozen using the ERC-3643 token’s built-in freeze mechanism

This design ensures:

• RWA tokens remain tightly coupled with their identity/compliance logic

• Standard ERC-20s are handled with a classic escrow pattern

Compliance-Aware by Design

Dino Secondary is built for ERC-3643 tokens:

• At least one leg of every trade must involve the configured ERC-3643 token for this Dino Secondary instance.

• Transfers of that token are subject to the token’s existing compliance rules:

  • Identity registry checks

Shared Liquidity on the T-REX Ledger

All offers for a given ERC-3643 token are stored in the same contract instance on the T-REX Ledger. That means:

• Any dApp, broker-dealer, or platform integrating Dino Secondary taps into the same pool of offers.

• Liquidity is aggregated at the contract level, not at the UI level.

• New interfaces can appear (white-label platforms, wallets, institutional portals, aggregators) and immediately see and use the existing offer book.

Actors & Roles

At a conceptual level, Dino Secondary involves:

• Offer Creators (Makers) Investors or institutions who post offers to buy or sell the ERC-3643 token.

• Offer Takers Counterparties who accept offers (fully or partially), triggering settlement.

• Issuers / Operators Entities responsible for the ERC-3643 token and the market around it. They benefit from shared liquidity and may configure fees and operational parameters.

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.

Trading Model & Offer Lifecycle

1. Offer Creation

A maker:

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

2. Taking an Offer

A taker:

1. Selects an offer and decides how much to take (can be partial).

2. Approves the appropriate token if needed (e.g. payment token).

3. Calls takeOffer(offerID, amount).

Dino Secondary:

• Validates the offer is still active and not expired

• If the offer is no longer valid, it is automatically pruned and cannot be taken.

• Computes the corresponding counter-amount using the offer’s price ratio.

3. Cancelling an Offer

Makers can cancel their own active offers:

• Call cancelOffer(offerID).

• Dino Secondary:

  • Unfreezes ERC-3643 tokens or releases escrow as needed

4. Pruning Expired or Invalid Offers

Any address can trigger pruning via pruneOffer(offerID):

• If the offer:

  • Has expired, or

  • Is underfunded (e.g. maker moved their frozen tokens away or no longer has enough balance)

Pruning prevents stale or unsafe offers from being executed and keeps the active offer set clean.

Compliance & ERC-3643 Integration

Dino Secondary is designed to align with all compliance guarantees of ERC-3643:

• The ERC-3643 token itself:

  • Validates transfers against its Identity Registry

  • Enforces eligibility rules (KYC/AML, jurisdiction, investor type, etc.)

As a result, secondary market activity remains fully compliant with the same rules as primary issuance and transfers.

Fees & Incentives (High-Level)

Dino Secondary supports multiple fee layers:

• T-REX Ecosystem Fees Collected via the shared Ecosystem Fee Collector, with different multipliers depending on the operation (offer creation, taking, cancellation).

• Asset / Market-Level Fees Configurable by authorized operators (via the FEE_MANAGER_ROLE), including:

  • A fixed fee per trade

Details on how to configure, calculate, and monitor these fees are covered in the page.

Integration Patterns for Platforms & dApps

A typical integration with Dino Secondary follows these steps:

1. Discovery & Display

   • Query the list of open offers for a given ERC-3643 token.

   • Display:

Because Dino Secondary is shared infrastructure on the T-REX Ledger, one integration lets your platform:

• Access all offers for that token

• Co-exist with other platforms and broker-dealers on the same liquidity pool

Dino Secondary in the T-REX Apps Stack

Within the broader T-REX ecosystem:

• DinoPrimary handles compliant subscription & redemption (primary market).

• DinoSecondary handles intent-based secondary trading for the same ERC-3643 tokens.

• DinoFactory deploys both contracts and configures their access control consistently.

Related Documentation

For more details:

• Roles, pausing, fee configuration, and operational best practices.

• Solidity interfaces, function signatures, events, error codes, and concrete integration examples.

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.

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.

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.

Contract Surface

At a high level, the public interface exposed to integrators is:

Core Data Structures

Fee

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

OfferStatus

Offer lifecycle states:

• Active – Offer is live and can be taken.

• Filled – Offer is fully executed.

• Cancelled – Cancelled by creator.

Offer

Represents a single order in the book:

Amounts always keep the original price ratio: partial fills are proportional and update the filledAmount* fields accordingly.

Trading Functions

createOffer

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.

takeOffer

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.

cancelOffer

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.

pruneOffer

Purpose

Clean up offers that are no longer valid, for example:

• Expired offers.

• Offers that became non-compliant.

• Offers where the ERC-3643 leg is no longer funded (maker removed allowance or an agent moved away the frozen balance reserved for the transfer).

Pruning is open to any caller; it updates status to Expired and emits OfferPruned. If tokens had been locked/frozen, they are freed accordingly.

Common errors

• InvalidOfferId(offerID) – no such offer.

Fee Configuration & Getters

setFixedFee

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.

setVolumeBasedFee

Admin-only function to configure the percentage-based fee:

• basisPoints: rate in bps (100 = 1%) applied to the non-ERC-3643 leg of each trade.

• basisPoints is capped at 100; higher values revert with VolumeBasedFeeTooHigh.

Fee getters

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

Read-Only Helpers

TREX

Returns the ERC-3643 token address this DinoSecondary instance is bound to. Every offer must involve this token in at least one leg.

getOfferExpiry

Shortcut to read only the expiry field for a given offer.

getCurrentOfferID

Returns the next offer ID that will be assigned on the next createOffer call (i.e. a counter, not the last valid ID). To iterate over all offers, index from 0 (or 1, depending on deployment conventions) up to getCurrentOfferID() - 1, combined with getOfferDetails and event history.

getOfferDetails

Returns the full Offer struct for the given offerID. Use this for:

• Front-end display of the order book.

• Reconciling with your indexer state.

• Checking status, amounts and timestamps on-chain.

Events

DinoSecondary uses a dedicated events library for consistent logging.

Trading events

Fee events

Pausable & AccessManager events

From inherited contracts:

• Paused(address account) / Unpaused(address account) from Pausable.

• AuthorityUpdated(address authority) from AccessManaged when the AccessManager is changed.

These are particularly useful for indexers and monitoring dashboards.

Error Reference

You should surface these errors in your dapp for clearer UX (e.g. mapping them to human-readable messages).

Multicall Support

The contract supports OpenZeppelin Multicall, allowing you to batch several calls into a single transaction (for example, multiple takeOffer operations or a takeOffer + off-chain accounting update).

This is especially useful for:

• Wallets wanting to group multiple fills.

• Protocols executing rebalancing strategies that span several offers.

Integration Tips

• Use TREX() to ensure you are interacting with the right DinoSecondary instance for a given asset. IDinoSecondary

• Index events (OfferCreated, OfferPartiallyFilled, OfferFilled, OfferCancelled, OfferPruned) as your primary source of truth, and reconcile with

1. Token-Level Enforcement (ERC-3643)

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

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

Access Control System

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.

Roles

Dino Primary defines three logical roles:

How Roles Are Granted

Roles are not granted directly by Dino Primary itself. Instead:

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

2. That AccessManager is responsible for:

   • Attaching permissions to each Dino Primary function selector

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;

Admin Management Settings (ADMIN_ROLE)

Holders of ADMIN_ROLE can manage core configuration of Dino Primary.

Core Admin Functions

Issuer Safe

The issuer safe is the central wallet used for:

• Subscriptions: subscription proceeds (payment tokens) are sent to this address.

• Redemptions: redemption payments (payment tokens) are paid from this address.

Changing the issuer safe:

• Does not affect past transactions,

• But all future fund flows will use the new address.

Preminted vs Non-Preminted Mode

The preminted flag indicates how the ERC-3643 token supply is handled:

• preminted = true

  • The issuer has already minted a supply of tokens into a treasury address.

  • Dino Primary will transfer tokens from that treasury to investors on subscription, and back to treasury on redemption.

Token Manager Settings (TOKEN_MANAGER_ROLE)

Holders of TOKEN_MANAGER_ROLE configure which payment tokens can be used for subscriptions and redemptions, and how they are priced.

Payment Token Management

Dino Primary exposes three management functions:

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

Operational Guidelines

• Only add payment tokens that:

  • Have reliable liquidity and oracle feeds;

  • Are supported by your compliance / risk policies.

Rules Manager Settings (RULES_MANAGER_ROLE)

Holders of RULES_MANAGER_ROLE configure when subscriptions/redemptions are allowed and within which limits, plus the malus applied on redemption.

Subscription Rules

Subscription rules are updated via:

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 & Malus

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.

Fee System

Dino Primary integrates with the T-REX Ecosystem Fee Collector to charge protocol-level fees on top of the asset economics.

Operation Fees

Per design, Dino Primary applies multipliers on a base ecosystem fee: