# 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**](https://docs.t-rex.network/t-rex-network/t-rex-ledger), that standardizes how investors:

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

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

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

### Key Features

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

### Actors & Roles

At a conceptual level, Dino Primary involves:

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

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

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

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

### Subscription Flow

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

High-level flow:

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

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

### Redemption Flow

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

High-level flow:

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

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

### Payment Tokens & Pricing

Dino Primary supports:

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

This allows issuers to:

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

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

### Compliance & ERC-3643 Integration

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

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

When a subscription or redemption is attempted, Dino Primary:

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

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

### Integration Patterns for Platforms & dApps

Typical integration steps for a platform building on Dino Primary:

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

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

### Related Documentation

For more detailed and technical information, see the subpages:

* [**Dino Primary – Admin & Management**](https://docs.t-rex.network/t-rex-network/t-rex-apps/dino/dino-primary/admin-and-management)\
  Roles, rule configuration, payment token management, fee model.
* [**Dino Primary – Developer Reference**](https://docs.t-rex.network/t-rex-network/t-rex-apps/dino/dino-primary/developer-reference)\
  Solidity interfaces, function signatures, events, error codes, and integration examples.

These pages are where you can expose the content from your existing `DinoPrimary.md` and the actual contract interface, while keeping this page focused on the conceptual behavior and business logic.