> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/t-rex-network/t-rex-apps/dino/dino-primary.md).

# DINO Primary

Dino Primary is the **primary market rail** of the T-REX ecosystem.\
It is a shared smart contract, deployed on the [**T-REX Ledger**](/t-rex-network/t-rex-ledger.md), that standardizes how investors:

* **Subscribe** to new ERC-3643 (T-REX) tokens, and
* **Redeem** those tokens back to the issuer,

with **instant onchain settlement**, **compliance checks**, and a **configurable rule set** controlled by the issuer and its delegates.

Instead of each issuer building its own bespoke subscription and redemption logic, Dino Primary provides a **common infrastructure layer** that any issuer, distributor, broker-dealer or dApp can reuse.

### Key Features

* **Standardized subscription & redemption flows**\
  Unified logic across all Dino-enabled ERC-3643 tokens, with instant settlement onchain.
* **Multiple payment tokens**\
  Issuers can accept several payment tokens (e.g. stablecoins and non-stable tokens) and configure them per asset.
* **Price oracle integration**\
  Dino Primary plugs into price feeds so the contract can compute how many asset tokens correspond to a given payment amount.
* **Per-asset rule configuration**\
  Issuers (or their admins) can configure:
  * Subscription and redemption open/close
  * Minimum and maximum amounts
  * Accepted payment tokens
  * Optional **malus / haircut** on redemptions
  * Referral fees for distributors
* **Built-in compliance**\
  Dino Primary is designed for tokens following the **ERC-3643** standard. It relies on the Identity Registry and token compliance modules to ensure that only verified and eligible investors can subscribe or redeem.
* **Shared infrastructure on the T-REX Ledger**\
  All participants — issuers, distributors, platforms, and investors — share the same contract infrastructure, making integrations repeatable and interoperable.

### Actors & Roles

At a conceptual level, Dino Primary involves:

* **Issuer / Issuer Safe**\
  The party responsible for the asset and the wallet that receives subscription proceeds and pays redemptions.
* **Investors**\
  Wallets holding ERC-3643 tokens (or subscribing for them) that are verified and compliant.
* **Distributors / Platforms / dApps**\
  Front-ends integrating with Dino Primary to offer “Invest” and “Redeem” experiences to end-users.
* **Dino Primary Contract**\
  The onchain logic handling subscriptions and redemptions, enforcing rules, collecting ecosystem fees, and talking to the ERC-3643 token.

Under the hood, Dino Primary uses an [**AccessManager**](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) with separate roles (e.g. admin, token manager, rules manager) so issuers can clearly separate:

* Who can configure payment tokens,
* Who can adjust subscription/redemption rules,
* Who can manage overall administration.

Details of these roles and functions are covered in the *Dino Primary – Admin & Management* subpage.

### Subscription Flow

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

High-level flow:

1. **Configuration by the issuer**
   * The issuer (or its delegates) configures:
     * Subscription open/close status,
     * Min/max subscription amounts,
     * Accepted payment tokens and their price feeds.
2. **Investor eligibility**
   * The investor must:
     * Be registered in the **Identity Registry** (ONCHAINID linked to their wallet),
     * Pass the usual ERC-3643 compliance checks (jurisdiction, investor type, etc.).
3. **Investor action**
   * The investor approves the **payment token** (e.g. stablecoin) for Dino Primary.
   * The investor calls the `subscribe(amount, paymentToken)` function via a dApp or platform.
4. **On-chain processing**
   * Dino Primary:
     * Verifies that subscriptions are open and within configured limits.
     * Verifies the investor’s eligibility and token compliance.
     * Transfers the payment token to the issuer’s safe address.
     * Allocates the ERC-3643 tokens to the investor using one of two approaches:
       * **Preminted treasury**: tokens are transferred from the issuer’s treasury wallet.
       * **On-the-fly mint**: tokens are minted directly to the investor (Dino Primary acts as a minter agent of the token).
5. **Settlement & logging**
   * The transaction settles **atomically** on-chain.
   * A `Subscribed` event is emitted with the relevant details for off-chain systems.

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

### Redemption Flow

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

High-level flow:

1. **Configuration by the issuer**
   * The issuer configures:
     * Whether redemptions are open,
     * Min/max redemption amounts,
     * Accepted payment tokens,
     * Optional **malus** (a penalty or haircut on the redemption price).
2. **Investor eligibility**
   * As with subscriptions, the investor must remain compliant and verified under ERC-3643 rules.
3. **Investor action**
   * Optional *–* The investor approves the **asset token** (ERC-3643) for Dino Primary *–* only applicable if **Preminted treasury** where the tokens need to be transferred back to the Issuer.
   * The investor calls `redeem(amount, paymentToken)` via a dApp.
4. **Onchain processing**
   * Dino Primary:
     * Verifies that redemptions are open and limits are respected.
     * Re-checks investor eligibility and compliance.
     * Handles the ERC-3643 tokens using one of two approaches:
       * **Preminted treasury**: tokens are transferred back to the issuer’s treasury.
       * **Burning**: tokens are burned from the investor (Dino Primary acts as an agent with burn permissions).
     * Calculates the payment amount, optionally applying a **malus** if configured.
     * Transfers the payment token from the issuer’s safe address to the investor.
5. **Settlement & logging**
   * The transaction settles atomically.
   * A `Redeemed` event is emitted with all key parameters.

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

### Payment Tokens & Pricing

Dino Primary supports:

* **Stable payment tokens**\
  Tokens considered stable against the reference asset (e.g. USD), where pricing can be treated as 1:1 or based on simple rules.
* **Non-stable payment tokens**\
  Tokens whose value fluctuates (e.g. other cryptocurrencies). For these, Dino Primary integrates with a **price oracle** implementing [AggregatorV3Interface](https://docs.chain.link/data-feeds/api-reference#aggregatorv3interface) configured per payment token.

This allows issuers to:

* Offer subscriptions/redemptions in several currencies or tokens.
* Keep the asset priced in one reference unit (e.g. NAV in USD) while accepting payments in different tokens.

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

### Compliance & ERC-3643 Integration

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

* Every investor wallet is linked to an **ONCHAINID** in the Identity Registry.
* The ERC-3643 token enforces:
  * KYC/AML status,
  * Jurisdiction rules,
  * Investor categorization (retail/professional, etc.),
  * Any additional custom compliance logic.

When a subscription or redemption is attempted, Dino Primary:

1. Calls into the ERC-3643 token / Identity Registry to confirm:
   * The investor is registered and eligible.
   * The transfer or burn/mint operation is allowed by compliance rules.
2. Executes the token transfer or burn/mint only if all checks pass.

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

### Integration Patterns for Platforms & dApps

Typical integration steps for a platform building on Dino Primary:

1. **Discovery**
   * Fetch Dino Primary configuration for a given token:
     * Subscription and redemption status.
     * Min/max amounts.
     * Accepted payment tokens and, where useful, their price feeds.
2. **Pre-checks**
   * Check that:
     * The investor is onboarded and linked to an ONCHAINID.
     * The wallet is approved in the relevant Identity Registry.
     * The transaction respects compliance rules defined at ERC-3643 level (call `canTransfer(address from, address to, uint256 amount)` on the compliance contract).
     * Any off-chain checks (e.g. investor questionnaire) are completed.
3. **User flows**
   * For subscriptions:
     * Guide user to approve the payment token.
     * Call `subscribe(amount, paymentToken)` and track the emitted event.
   * For redemptions:
     * Guide user to approve the asset token (only if **Preminted treasury**).
     * Call `redeem(amount, paymentToken)` and track the emitted event.
4. **Post-trade processing**
   * Listen to `Subscribed` / `Redeemed` events to:
     * Update portfolio views,
     * Trigger reporting,
     * Synchronize with off-chain systems (e.g. transfer agent, fund admin, custodians).

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

### Related Documentation

For more detailed and technical information, see the subpages:

* [**Dino Primary – Admin & Management**](/t-rex-network/t-rex-apps/dino/dino-primary/admin-and-management.md)\
  Roles, rule configuration, payment token management, fee model.
* [**Dino Primary – Developer Reference**](/t-rex-network/t-rex-apps/dino/dino-primary/developer-reference.md)\
  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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.t-rex.network/t-rex-network/t-rex-apps/dino/dino-primary.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.