> 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-secondary/admin-and-management.md).

# Admin & Management

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 – Developer Reference**](/t-rex-network/t-rex-apps/dino/dino-secondary/developer-reference.md).

### Access Control System

Dino Secondary uses OpenZeppelin’s [**AccessManager**](https://docs.openzeppelin.com/contracts/5.x/api/access#AccessManager) to enforce fine-grained permissions. Two logical roles are defined: an **admin** role and a **fee manager** role.

#### Roles

| Role               | Value | Description                | Typical Holder(s)                      |
| ------------------ | ----- | -------------------------- | -------------------------------------- |
| `ADMIN_ROLE`       | `0`   | Global administrative role | Issuer / Operator multisig, governance |
| `FEE_MANAGER_ROLE` | `3`   | Fee configuration role     | Market operator, platform / treasury   |

**`ADMIN_ROLE`** can:

* Pause / unpause the contract (emergency control)
* Generally manage admin-level functions and (via AccessManager) other roles / mappings

**`FEE_MANAGER_ROLE`** can:

* Configure **fixed fee** parameters
* Configure **volume-based fee** parameters DinoSecondary

{% hint style="info" %}
Dino Factory can either:

* Deploy a new AccessManager and wire Dino Primary & Dino Secondary to it; or
* Reuse an existing AccessManager shared across multiple assets.\
  For a given token, **Dino Primary and Dino Secondary must share the same AccessManager** so roles and UX are consistent.
  {% endhint %}

### Admin Management Settings (`ADMIN_ROLE`)

#### Core Configuration Functions

| Setting          | Function    | Role         | Description                                                                           |
| ---------------- | ----------- | ------------ | ------------------------------------------------------------------------------------- |
| Pause Contract   | `pause()`   | `ADMIN_ROLE` | Pauses all trading operations: offers cannot be created, taken, cancelled, or pruned. |
| Unpause Contract | `unpause()` | `ADMIN_ROLE` | Resumes normal trading operations.                                                    |

When paused:

* `createOffer`, `takeOffer`, `cancelOffer`, `pruneOffer`, and similar trade functions will revert.
* Admin and fee configuration functions remain usable so operators can resolve issues before unpausing.

{% hint style="info" %}
**Typical usage:**

* Incident response (oracle problem, compliance issue, exploit suspicion)
* Coordinated protocol upgrade or parameter change that temporarily requires halting trading.
  {% endhint %}

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

| Setting          | Function            | Role               | Description                                     |
| ---------------- | ------------------- | ------------------ | ----------------------------------------------- |
| Fixed Fee        | `setFixedFee`       | `FEE_MANAGER_ROLE` | Sets the fixed fee per `takeOffer` transaction. |
| Volume-Based Fee | `setVolumeBasedFee` | `FEE_MANAGER_ROLE` | Sets the percentage-based fee (capped at 1%).   |

**Fixed Fee**

* **Purpose:** Cover operational / platform costs on each trade.
* **Charged:** On every `takeOffer` transaction.
* **Paid in:** A configurable ERC-20 token (e.g. stablecoin).
* **Recipient:** Configurable address (e.g. market operator, platform, or issuer). DinoSecondary

The fixed fee configuration typically includes:

* `fixedFeeToken` – ERC-20 address;
* `fixedFeeAmount` – amount charged per `takeOffer`;
* `fixedFeeRecipient` – beneficiary address.

**Volume-Based Fee**

* **Purpose:** Align incentives with transaction volume (e.g. % fee for the marketplace / issuer).
* **Charged on:** The **non-ERC-3643 leg** of the trade (the payment token side).
* **Rate:** Expressed in **basis points** (100 = 1%).
* **Cap:** Maximum **100 bps** (1%) enforced by the contract.
* **Recipient:** Configurable address, usually marketplace or issuer. DinoSecondary

Dino Secondary ensures the volume-based fee cannot exceed the 1% cap, protecting users from excessive fee configuration.

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

| Operation    | Ecosystem Fee Multiplier | Description                              |
| ------------ | ------------------------ | ---------------------------------------- |
| Create Offer | `3x` base fee            | Payable for creating a trading offer     |
| Take Offer   | `3x` base fee            | Payable for executing a trading offer    |
| Cancel Offer | `1x` base fee            | Payable for cancelling an existing offer |

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

* Users must **approve** the ecosystem fee token for the Fee Collector.
* Dino Secondary calls the Fee Collector with the relevant multiplier when operations occur. DinoSecondary

#### 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`.
3. **Volume-based fee** is:
   * Calculated on the **non-ERC-3643 leg** of the trade
   * Deducted and sent to `volumeFeeRecipient`.

From a UX perspective, you should:

* **Preview** all three fee layers in your dApp when quoting the trade
* Clearly differentiate protocol (ecosystem) fees from market/platform fees

### Fee Introspection Helpers

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

| Function               | Description                                                 |
| ---------------------- | ----------------------------------------------------------- |
| `fixedFee()`           | Returns fixed fee configuration (token, amount, collector). |
| `volumeFee()`          | Returns volume-based fee rate in basis points.              |
| `fixedFeeRecipient()`  | Returns the fixed fee recipient address.                    |
| `volumeFeeRecipient()` | Returns the volume-based fee recipient address.             |

These allow frontends and off-chain services to:

* Fetch current fee settings
* Display them in UI / legal notices
* Validate that configuration matches expected policies

### Multicall Support

Dino Secondary inherits OpenZeppelin’s [**Multicall**](https://docs.openzeppelin.com/contracts/5.x/utilities#multicall) functionality.&#x20;

This allows batching multiple calls into a **single transaction**, for example:

* Multiple `createOffer` calls in a single transaction to create a grid of offers.
* Multiple `takeOffer` calls on different offers in a single transaction to process a large transaction that requires fulfilling several Offers at once.
* Multiple `cancelOffer` calls on different offers in a single transaction.
* Multiple `pruneOffer` calls on different invalid offers to process garbage collection in a single transaction.

Benefits:

* Gas efficiency (one base transaction cost, many actions)
* Better UX (“Confirm once to execute multiple steps”)

From the front-end side, you simply encode several calls into a single multicall transaction.

### Events & Monitoring

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

#### Dino Secondary–Specific Events

| Event              | Description                                          |
| ------------------ | ---------------------------------------------------- |
| `OfferCreated`     | Emitted when a new offer is created.                 |
| `OfferTaken`       | Emitted when an offer is executed (full/partial).    |
| `OfferCancelled`   | Emitted when an offer is cancelled by creator.       |
| `OfferPruned`      | Emitted when an offer is pruned (expired/invalid).   |
| `FixedFeeUpdated`  | Emitted when fixed fee configuration changes.        |
| `VolumeFeeUpdated` | Emitted when volume-based fee configuration changes. |
| `Paused`           | Emitted when the contract is paused.                 |
| `Unpaused`         | Emitted when the contract is unpaused.               |

#### Inherited AccessManaged Events

| Event              | Description                                            |
| ------------------ | ------------------------------------------------------ |
| `AuthorityUpdated` | Emitted when the controlling AccessManager is updated. |

{% hint style="success" %}
**Recommendation:** index at least `OfferCreated`, `OfferTaken`, `OfferCancelled`, `OfferPruned`, `FixedFeeUpdated`, `VolumeFeeUpdated`, `Paused`, and `Unpaused` in your backend or analytics pipeline.
{% endhint %}

### 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
     * An AccessManager (new or existing)
     * The ecosystem Fee Collector
2. **Role Assignment**
   * AccessManager admin assigns:
     * `ADMIN_ROLE` to issuer / operator multisig
     * `FEE_MANAGER_ROLE` to the team managing fees
3. **Fee Configuration**
   * `FEE_MANAGER_ROLE` calls:
     * `setFixedFee` to set fixed fee token, amount, and recipient
     * `setVolumeBasedFee` to set bps rate (≤ 100 bps) and recipient
4. **Production Trading**
   * Users create, take, cancel, and prune offers through integrated dApps and platforms.
   * Ecosystem, fixed, and volume-based fees are collected automatically.
5. **Operational Controls**
   * In case of incidents or planned maintenance, `ADMIN_ROLE` can:
     * `pause()` trading
     * Adjust configurations (e.g. fee parameters)
     * `unpause()` once conditions are safe again
6. **Monitoring & Auditing**
   * Off-chain systems monitor:
     * Fee updates
     * Pauses/unpauses
     * Offer lifecycle events
   * Data can be used for:
     * Market surveillance
     * Compliance & reporting
     * Revenue accounting


---

# 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-secondary/admin-and-management.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.
