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.

Access Control System

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

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.

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.

Typical usage:

• Incident response (oracle problem, compliance issue, exploit suspicion)

• Coordinated protocol upgrade or parameter change that temporarily requires halting trading.

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

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

Recommendation: index at least OfferCreated, OfferTaken, OfferCancelled, OfferPruned, FixedFeeUpdated, VolumeFeeUpdated, Paused, and Unpaused in your backend or analytics pipeline.

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