> 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/appstore/dino.md). # DINO DINO is the shared distribution and market layer of the T-REX ecosystem: a set of contracts on the T-REX Ledger through which an Issuer offers subscriptions and redemptions, and holders trade with each other, for any asset of the register. This page says what DINO does and how it uses the protocol. DINO is provided by Tokeny. ## What it is | Contract | Role | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | `DinoFactory` | Deploys a `DinoPrimary` and a `DinoSecondary` for a token, with DINO's own roles, fees and permissions set up the same way for every asset. | | `DinoPrimary` | The primary market: Investors subscribe to the asset and redeem it with the Issuer, against payment tokens the Issuer accepts. | | `DinoSecondary` | The secondary market: holders publish offers to buy or sell the asset, and other participants take them, fully or partially. | DINO is not one interface. It is a set of contracts that any Platform, distributor, broker-dealer or wallet integrates. Every interface that integrates `DinoSecondary` for an asset reads and takes the same offers, so liquidity is shared at the level of the contract and not divided between front ends. ## Primary market: subscriptions and redemptions The Issuer, or the parties it delegates to, configures the market of its asset: whether subscriptions and redemptions are open, the minimum and maximum amounts, the payment tokens it accepts and their price feeds, a discount applied to redemptions, and referral fees for distributors. | Operation | What the Investor does | What `DinoPrimary` does, in one transaction | | ------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Subscription | Approves the payment token, then subscribes for an amount. | Checks that subscriptions are open and the amount is within the limits. Sends the payment to the Issuer's address. Delivers the asset to the Investor: by transfer from the Issuer's treasury wallet, or by mint. | | Redemption | Approves the asset token when the tokens return to the treasury, then redeems an amount. | Checks that redemptions are open and the amount is within the limits. Takes the asset back: by transfer to the Issuer's treasury wallet, or by burn. Computes the payment, with the discount when one is set, and pays the Investor from the Issuer's address. | Payment and delivery happen in the same transaction: both succeed, or neither does. A payment token that is not stable against the reference unit of the asset is priced through a price feed set for that payment token. ## Secondary market: offers An offer states the token offered, the token requested, the two amounts and an expiry. One of the two tokens is always the asset the `DinoSecondary` instance was deployed for. | Step | What happens | | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create | The maker publishes the offer. When the maker sells the asset, the offered amount stays in the maker's wallet and is frozen there. When the maker offers a standard ERC-20, such as a payment token, the amount is held in escrow by the contract. | | Take | A taker takes all or part of the offer. The contract computes the counter-amount from the ratio of the offer, releases the corresponding tokens and settles both legs in one transaction. An offer can be taken several times until it is filled. | | Cancel | The maker cancels an active offer. The frozen amount is unfrozen, or the escrow is returned. | | Prune | Anyone can close an offer that has expired, or that the maker no longer covers. The frozen or escrowed amount is released. | > **Why the asset is frozen and not escrowed.** Tokens on offer stay in the wallet of their holder until the trade settles. The register shows the maker as the owner for as long as it is the owner, and the position of each identity stays exact while offers are open. ## How DINO uses the protocol DINO acts on the token on the reference chain, through the token's public functions. Every movement of the asset it triggers is executed by the token, which makes its own checks each time. * **A delivery or a trade by transfer** passes the pause, the freezes, the eligibility of the recipient and the compliance rules. * **A delivery by mint** passes the eligibility of the recipient and the compliance rules. The pause and a freeze on the receiving address do not block a mint. * **A redemption by burn** passes neither gate: the token checks the role of the caller and the balance, and releases frozen tokens when the burn needs them. If a check refuses, the token reverts and the subscription, the redemption or the trade does not happen. DINO adds market logic on top of these checks. It cannot replace them or skip them. Each DINO contract that acts on an asset takes part under its own ONCHAINID of type `SMART_CONTRACT`, bound to that contract and created under a role granted by Network governance. The asset reads this identity when its spender policy requires eligible spenders, and whenever the contract receives the asset. What the contract can do on an asset is what the Issuer and the holders grant it: | DINO does | The protocol requires | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Delivers a subscription from the Issuer's treasury wallet, or takes redeemed tokens back to it | An allowance from the wallet the tokens leave, and acceptance of the contract by the asset's spender policy: see [26 Authorize spenders](/guides/issuer/26.-authorize-spenders.md) | | Delivers a subscription by mint | The `AGENT_MINTER` role in the asset's domain. The recipient passes the checks of [08 Mint a position to an investor](/guides/positions/08.-mint-a-position-to-an-investor.md) | | Takes a redemption by burn | The `AGENT_BURNER` role in the asset's domain. The token asks for no allowance from the holder: see [09 Burn a position](/guides/positions/09.-burn-a-position.md) | | Freezes the amount of an offer in the maker's wallet, and unfreezes it | The `AGENT_PARTIAL_FREEZER` role in the asset's domain: see [13 Freeze and unfreeze an address or a partial balance](/guides/agents/13.-freeze-and-unfreeze-an-address-or-a-partial-balance.md) | | Moves the asset from the seller to the buyer when an offer is taken | A contract moves a holder's tokens with `transferFrom`: an allowance from the seller's wallet, and acceptance of the contract by the asset's spender policy. The frozen amount of the offer is unfrozen first, since `transferFrom` moves the free balance only. The movement then passes the checks of a transfer: see [10 Transfer between investors](/guides/positions/10.-transfer-between-investors.md). The buyer's address must be eligible when the offer is taken, whether the buyer is the taker or the maker. | The Issuer grants these three roles in the asset's domain with the suite's `TREXAccessManager` and can revoke them at any time: see [25 Commission a suite and grant roles](/guides/issuer/25.-commission-a-suite-and-grant-roles.md). When the asset keeps a list of named operators, the Compliance Owner adds the contract to it. > **Trust statement.** An Issuer that connects its asset to DINO grants agent roles to contracts. Within those roles the contracts act without the Issuer's signature, and the token does not limit a role to the participants of DINO. A contract with `AGENT_MINTER` creates supply for any eligible address. A contract with `AGENT_BURNER` burns from any address, with no allowance from the holder, frozen tokens included. A contract with `AGENT_PARTIAL_FREEZER` freezes an amount at any address and unfreezes any frozen amount, including one a Token Agent froze: the token keeps one frozen amount per address. A role is granted in a domain and applies to every token of that domain. The Issuer relies on the code of the DINO contracts and on whoever can configure or upgrade them. The grants are visible in the suite's `TREXAccessManager`. DINO acts on balances on the reference chain. A position that is active on a satellite is recalled before it is offered or redeemed: see [32 Recall a position to the reference chain](/guides/cross-chain/32.-recall-a-position-to-the-reference-chain.md). ## Who uses it | Party | Use | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | Issuer | Runs subscriptions and redemptions for its asset under rules it sets, and gives its holders a market. | | Distributor, broker-dealer, market operator | Distributes assets and brings liquidity on shared contracts, without building its own. | | Platform | Builds the Investor-facing experience on the shared contracts. One integration reaches every asset connected to DINO. | | Investor | Subscribes, redeems and trades through any connected interface, with the same on-chain logic behind each of them. | ## Related applications [T-REX Engine](/appstore/t-rex-engine.md) exposes the DINO contracts through its API. To integrate a contract of your own with an asset, see [Integrate a venue or an application](/build/integrate-a-venue-or-an-application.md). --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.t-rex.network/appstore/dino.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.