# Table of Contents

- [Base Tokens | Makina Docs](#base-tokens-makina-docs)
- [Caliber Accounting | Makina Docs](#caliber-accounting-makina-docs)
- [Flash Loans | Makina Docs](#flash-loans-makina-docs)
- [Harvests | Makina Docs](#harvests-makina-docs)
- [MakinaVM | Makina Docs](#makinavm-makina-docs)
- [Caliber Mailbox | Makina Docs](#caliber-mailbox-makina-docs)
- [Cross-Chain Accounting | Makina Docs](#cross-chain-accounting-makina-docs)
- [Swaps | Makina Docs](#swaps-makina-docs)
- [Overview | Makina Docs](#overview-makina-docs)
- [Positions | Makina Docs](#positions-makina-docs)
- [Liquidity Bridging | Makina Docs](#liquidity-bridging-makina-docs)
- [Operator | Makina Docs](#operator-makina-docs)
- [Overview | Makina Docs](#overview-makina-docs)
- [Permissions and Scopes | Makina Docs](#permissions-and-scopes-makina-docs)
- [Risk Manager | Makina Docs](#risk-manager-makina-docs)
- [Root Update Lifecycle | Makina Docs](#root-update-lifecycle-makina-docs)
- [Safe Security Structure | Makina Docs](#safe-security-structure-makina-docs)
- [Introduction | Makina Docs](#introduction-makina-docs)
- [Security Council | Makina Docs](#security-council-makina-docs)
- [Depositors | Makina Docs](#depositors-makina-docs)
- [Fee Managers | Makina Docs](#fee-managers-makina-docs)
- [Overview | Makina Docs](#overview-makina-docs)
- [Pre-Deposit | Makina Docs](#pre-deposit-makina-docs)
- [Redeemers | Makina Docs](#redeemers-makina-docs)
- [Security Module | Makina Docs](#security-module-makina-docs)
- [Machine Token | Makina Docs](#machine-token-makina-docs)
- [Share Price | Makina Docs](#share-price-makina-docs)
- [Recovery Mode | Makina Docs](#recovery-mode-makina-docs)
- [Oracle Registry | Makina Docs](#oracle-registry-makina-docs)

---

# Base Tokens | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/base-tokens#__docusaurus_skipToContent_fallback)

Base Tokens are ERC20 tokens that can be held directly on the balance of a Caliber.

Each Caliber maintains a set of registered base tokens. In order to be marked as a base token, a valid pricing path must be configured in the [Oracle Registry](https://docs.makina.finance/concepts/oracle-registry)
 so that the token is priceable against the strategy's Accounting Token.

Base tokens should generally be very liquid against the Accounting Token of the Caliber, and relatively low risk. Some Base tokens can be bridged from the Hub Chain, or swapped into locally, on the Caliber's chain.

Base Tokens are accounted for as part of the Caliber AUM through simple balanceOf calls, and pricing against the Accounting Token.

Positions can only be deployed by spending base tokens and closed by withdrawing base tokens. Additionally, swaps can only be made into base tokens and the accounting token. Thus all undeployed assets on the Caliber will always be a combination of base tokens and accounting token.

Calibers perform slippage or loss checks whenever a position is managed or a swap is executed. For positions, the associated accounting instruction returns a list of base token amounts representing the position’s value. The Caliber compares the total value of these tokens before and after execution to ensure that no significant loss is incurred during the operation.

---

# Caliber Accounting | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/caliber-accounting#__docusaurus_skipToContent_fallback)

Each caliber can do a local accounting of all value held including open positions and base tokens held on the Caliber's balance.

The caliber accounting requires all positions to not be stale, i.e. a recent enough value needs to be available for the positions. This requires the operator (or any other entity running a keeper) to execute the accounting script for each position on a continuous basis.

Positions are accounted for every time they are changed. They can also be accounted for at any time permissionlessly by executing the relevant [accounting instruction](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types)
 on the caliber.

Caliber accounting is permissionless and both the Operator and the Makina DAO have a direct incentive to keep position values up to date as their revenue is only distributed once a full accounting cycle is complete.

Base tokens held in the calibers balance can be accounted for by just pricing the token balance against the account token using the registered oracle feed.

The Caliber accounting function is a publicly exposed view function which is queried by the [Wormhole Cross-Chain Queries](https://wormhole.com/products/queries)
 service and published to the Machine's storage on the Hub Chain. See [Cross-Chain Accounting](https://docs.makina.finance/concepts/cross-chain/cross-chain-accounting)
 for more information.

---

# Flash Loans | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/flash-loans#__docusaurus_skipToContent_fallback)

Calibers can take flashloans for additional temporary liquidity during the execution of [Position Management Instructions](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types)
.

The flashloans are taken before executing the instructions to make the extra liquidity available to the Caliber and need to be repaid after the position management instruction is executed.

The flashloan liquidity can be used to open leveraged and looped positions on lending markets, execute complex swaps through protocols or rebalance positions on DEX liquidity pools.

The Caliber interacts with protocols providing flashloans through an external Flashloan Module which can act as an adapter to different flashloan callback interfaces.

---

# Harvests | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/harvests#__docusaurus_skipToContent_fallback)

Some [Positions](https://docs.makina.finance/concepts/caliber/positions)
 may issue reward tokens through various claim contracts. These can be harvested by the Caliber with [Harvest Instructions](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types)
 and transferred onto the Caliber's balance.

Harvesting tokens that are not registered on the Caliber as [Base Tokens](https://docs.makina.finance/concepts/caliber/base-tokens)
 will not increase the Caliber's AUM, as these tokens may not be priceable through oracles. To realise the value as AUM the harvested tokens need to be swapped to base tokens, or registered as base tokens by providing a corresponding oracle price feed.

Harvested tokens can be swapped instantly after being received by passing a swap order to the harvest function on the Caliber, allowing for instant realisation of the value of the harvested tokens.

Operators are incentivised to harvest positions frequently and realise their value quickly to avoid a gap building between the theoretical AUM of the caliber and the realise value. Such gaps can potentially lead to free-riding issues which results in lower performance on the Caliber and thus less fees for the operator.

---

# MakinaVM | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/makina-vm#__docusaurus_skipToContent_fallback)

On this page

Integrating with external protocols traditionally requires writing custom smart contract adapters, an approach that is time-consuming, error-prone, and difficult to maintain.

Makina introduces a new execution model: MakinaVM, a scope-limited, generalized onchain engine designed to execute pre-approved smart contract instructions.

The goal is for Calibers to be highly adaptable while maintaining strong security guarantees, enabling fast and reliable integration with a broad range of external protocols to maximize diversification and capture optimal opportunities.

### Key Benefits of MakinaVM[​](https://docs.makina.finance/concepts/caliber/makina-vm#key-benefits-of-makinavm "Direct link to Key Benefits of MakinaVM")

*   **Pre-approved execution:** Function selectors, target addresses, and selected parameters must be pre-approved. Only the Merkle root is stored onchain, ensuring minimal onchain storage while maintaining strict control.
*   **Efficient updates:** Adding or removing instructions requires only a single Merkle Root update.
*   **Scalability:** Proof size grows logarithmically (log₂(N)) with the number of instructions, ensuring scalability as the instruction set expands.
*   **Transparency & verification:** Anyone can verify the active instruction set by computing the Merkle root locally and comparing it to the one stored in the Caliber contract.

Instructions[​](https://docs.makina.finance/concepts/caliber/makina-vm#instructions "Direct link to Instructions")

-------------------------------------------------------------------------------------------------------------------

Instructions are a core innovation of Makina, offering a highly flexible yet controlled execution model. They define and constrain the Operator's available actions in a given strategy, enabling seamless interaction with a wide array of external smart contracts while maintaining strict operational boundaries.

### Weiroll[​](https://docs.makina.finance/concepts/caliber/makina-vm#weiroll "Direct link to Weiroll")

MakinaVM is built on [Enso Weiroll](https://github.com/EnsoBuild/enso-weiroll)
, an extended implementation of the original [Weiroll](https://github.com/weiroll/weiroll)
 command-chaining framework developed by [Nick Johnson](https://github.com/Arachnid)
, [Dean Eigenmann](https://github.com/decanus)
, and [other](https://github.com/weiroll/weiroll/graphs/contributors)
 open-source contributors. Enso's version enhances Weiroll's capabilities, making it more flexible and suited for advanced execution models.

Weiroll enables stateful multicalls by allowing the output of one call to be used as input for subsequent calls. This makes it possible to chain multiple function calls together, with data passed through each execution step. Moreover, Weiroll supports the generalized execution of any set of interactions across any protocol.

MakinaVM refines this capability by incorporating a Merkle Tree of hashed commands and selected parameters, effectively restricting the scope of executable instructions.

### Merkle Tree Permissioning[​](https://docs.makina.finance/concepts/caliber/makina-vm#merkle-tree-permissioning "Direct link to Merkle Tree Permissioning")

Each Caliber stores the root of a publicly available Merkle Tree containing the full set of allowed instructions. The root can be updated in caliber storage by the Machine's [Risk Manager](https://docs.makina.finance/concepts/governance/risk-manager)
 through a timelock, giving users time to withdraw if they disagree with upcoming changes.

To execute an instruction, the Operator must provide the corresponding Merkle proof. The Caliber hashes data including the instruction's commands (function signatures + target contracts addresses) and its selected parameters (function arguments), and validates the resulting leaf against the stored Merkle root.

Instructions can be validated with fine-grained control, down to specific function arguments. Dynamic arguments, like token amounts, can be excluded from the hash to preserve flexibility while retaining a strong security model.

Once enabled, instructions can be executed arbitrarily by the Operator, within the bounds of the approved set.

### Instruction Types[​](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types "Direct link to Instruction Types")

Instructions are categorized into four types, each serving a distinct operational role:

*   **Accounting**: Computes the current size of a position and updates it in the Caliber's storage.
*   **Management**: Modifies the size of a position. Always paired with an Accounting instruction to reflect the changes introduced.
*   **Harvesting**: Collects rewards from external protocols and transfers them to the Caliber.
*   **Flashloan-Management**: Modifies the size of a position in the context of a flash loan, as part of an outer Management instruction. A Flashloan-Management instruction is always associated with a Management instruction and can only be executed in its scope.

### Integration Flow[​](https://docs.makina.finance/concepts/caliber/makina-vm#integration-flow "Direct link to Integration Flow")

Integrating a new protocol only requires creating the necessary deploy, close, and account instructions and submitting a single governance transaction to whitelist them.

This process enables fast, secure, and scalable integrations across a broad set of protocols without the need for custom adapters.

Instructions are reviewed by the Risk Team and approved through Governance. Over time, a growing repository of reusable Instructions will be available to operators, enabling them to interact with a wide range of external protocols.

It is also expected that protocols seeking to attract capital contribute their own Instructions, promoting a model of self-integration.

See [Root Update Lifecycle](https://docs.makina.finance/concepts/governance/root-update-lifecycle)
 for more details.

*   [Key Benefits of MakinaVM](https://docs.makina.finance/concepts/caliber/makina-vm#key-benefits-of-makinavm)
    
*   [Instructions](https://docs.makina.finance/concepts/caliber/makina-vm#instructions)
    *   [Weiroll](https://docs.makina.finance/concepts/caliber/makina-vm#weiroll)
        
    *   [Merkle Tree Permissioning](https://docs.makina.finance/concepts/caliber/makina-vm#merkle-tree-permissioning)
        
    *   [Instruction Types](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types)
        
    *   [Integration Flow](https://docs.makina.finance/concepts/caliber/makina-vm#integration-flow)

---

# Caliber Mailbox | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#__docusaurus_skipToContent_fallback)

On this page

Deployed alongside each Spoke Caliber, Mailboxes serve as the Machine endpoint from the Caliber’s perspective and abstract away chain-specific logic.

### Liquidity bridging[​](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#liquidity-bridging "Direct link to Liquidity bridging")

Mailboxes control a set of bridge adapters through which assets can be transferred to and from the Hub Machine.

### Access Control[​](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#access-control "Direct link to Access Control")

Similar to machines on the Hub Chain, mailboxes expose to calibers the permissionned addresses involved in their management.

### Accounting data[​](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#accounting-data "Direct link to Accounting data")

Mailboxes exposes a view function that returns detailed accounting data for the Caliber. This function is queried and signed by the Wormhole CCQ network in order to pass the fetched data to the Hub Machine.

![makina cross-chain structure](https://docs.makina.finance/assets/images/makina-cross-chain-27ca2d9532ba49dd0bb3a79e60f19fe1.png)

*   [Liquidity bridging](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#liquidity-bridging)
    
*   [Access Control](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#access-control)
    
*   [Accounting data](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox#accounting-data)

---

# Cross-Chain Accounting | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/cross-chain/cross-chain-accounting#__docusaurus_skipToContent_fallback)

As operators can allocate Machine funds to various Spoke chains, it is crucial to maintain awareness of the accounting from each chain, in order to aggregate it and compute the total Machine AUM.

In order to compute a machine's total AUM, accounting data of each caliber needs to be aggregated. For spoke calibers, the protocol relies on Wormhole Cross-Chain Queries. This technology leverages a network of validators (guardians) to execute cross-chain data retrieval in a pull-based fashion.

Each Spoke Caliber Mailbox exposes a view function returning the detailed AUM of the associated caliber. This data can be retrieved by the Wormhole CCQ network, signed, and then aggregated in the machine contract storage.

Once the machine has fresh accounting data of all involved Spoke chains, this data allows to calculate the total machine AUM.

![cross-chain-accounting](https://docs.makina.finance/assets/images/makina-wh-ccq-4121288a1c06b89ed6a97421c47ab659.png)

---

# Swaps | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/swaps#__docusaurus_skipToContent_fallback)

Calibers can swap any arbitrary token into accounting or [Base Tokens](https://docs.makina.finance/concepts/caliber/base-tokens)
 through a swapper module which can route swaps through external routers or aggregators.

This implies that the accounting token, base tokens and other tokens earned as rewards, incentives, or airdrops can be swapped into other tokens registered in the Caliber and priceable to accounting tokens with oracles through the [Oracle Registry](https://docs.makina.finance/concepts/oracle-registry)
.

The Caliber performs independent slippage checks enforcing that no large losses are taken during swaps by verifying the total value held on the caliber before and after the swap. This adds an additional layer of safety to swapping operation and enables Operators to swap through any atomically executed route, while still allowing for off-chain generated arbitrary calldata, as is commonly used in swap aggregators.

Swapping base tokens is subject to [Cooldown Duration](https://docs.makina.finance/contracts/core/interfaces/ICaliber.sol/interface.ICaliber#cooldownduration)
, transactions attempting to swap any base token before the CooldownDuration has elapsed will revert.

In the case of external unregistered tokens being swapped into accounting or base tokens the balance AUM of the Caliber can only increase.

Direct protocol swaps such as mint/redeem or wrap/unwrap of assets can also be done through Makina's swap infrastructure by enabling custom smart-contracts for those actions as external routers on the swap module.

---

# Overview | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/overview#__docusaurus_skipToContent_fallback)

Calibers are the chain-local execution engines from which assets are deployed. Calibers contain an instance of the [MakinaVM](https://docs.makina.finance/concepts/caliber/makina-vm)
 which execute Instructions for interactions with external DeFi Protocols.

A Caliber is always deployed on the Hub Chain. Additionally, if required, Calibers can also be deployed on Spoke Chains. Calibers are the effective sender of all transactions executed by the Operator. Each Caliber can hold multiple [Positions](https://docs.makina.finance/concepts/caliber/positions)
 and independently account for all positions deployed through it.

Calibers can swap tokens, harvest external rewards from claiming contracts and take flashloans for additional liquidity.

Spoke chain Calibers can receive and send assets from and to the Machine on the Hub Chain through [Mailboxes](https://docs.makina.finance/concepts/cross-chain/caliber-mailbox)
 using Makina's native [Cross-Chain Liquidity](https://docs.makina.finance/concepts/cross-chain/liquidity-bridging)
 infrastructure.

Each Caliber has an Accounting Token and additionally Calibers have a notion of [Base Tokens](https://docs.makina.finance/concepts/caliber/base-tokens)
. The Accounting Token is required to be equivalent or 1:1 redeemable for the Accounting Token of the Machine, and Base Tokens are required to be priceable against the Accounting Token of the Caliber through locally available price oracles stored in the [Oracle Registry](https://docs.makina.finance/concepts/oracle-registry)
.

---

# Positions | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/caliber/positions#__docusaurus_skipToContent_fallback)

On this page

Positions represent base asset deployments made from the Calibers into external protocol.

Operators can open positions on multiple protocols or on the same protocol. Each Position has a unique position ID, all open positions are registered in the Caliber.

Positions can be increased and decreased through [Position Management Instructions](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types)
 sent by the Operator. The value of each Position, needs to be accounted for through an [Accounting Instruction](https://docs.makina.finance/concepts/caliber/makina-vm#instruction-types)
.

Positions can only be increased by deploying [Base Tokens](https://docs.makina.finance/concepts/caliber/base-tokens)
, and they can only be decreased by withdrawing them into base tokens. Accounting Instructions need to also return values denominated in base tokens.

This enables all positions to be ultimately valued in Accounting Tokens, and thus have generalised slippage or loss checks whenever a position is increased or decrease.

Each position has a list of risk attributes defined in the Risk Policy, and thus maximum exposure caps can be set on how large individual or groups of positions can be.

Position modification is subject to [Cooldown Duration](https://docs.makina.finance/contracts/core/interfaces/ICaliber.sol/interface.ICaliber#cooldownduration)
,for a given position and [Command](https://docs.makina.finance/concepts/caliber/makina-vm#instructions)
, transactions attempting to modify identical positions and Commands before the CooldownDuration has elapsed will revert.

Positions are required to have mutual exclusivity on liquidity deployments, two positions can not have overlapping accounting instructions accounting for the same liquidity.

Debt Positions[​](https://docs.makina.finance/concepts/caliber/positions#debt-positions "Direct link to Debt Positions")

-------------------------------------------------------------------------------------------------------------------------

Positions can also be used to represent dept or borrow position in scenarios where assets are borrowed from lending markets.

Debt Positions are accounted for in the negative and subtracted from the total Caliber AUM for purposes of [share price](https://docs.makina.finance/concepts/machine/share-price)
 calculations and risk policy exposure calculations.

Debt positions behave the same as normal positions and are in all matters equivalent to positive value positions excpet that they are stored in the Caliber with a flag marking them as being debt.

*   [Debt Positions](https://docs.makina.finance/concepts/caliber/positions#debt-positions)

---

# Liquidity Bridging | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/cross-chain/liquidity-bridging#__docusaurus_skipToContent_fallback)

The protocol enables bridging of assets between a Hub Machine and Spoke Calibers.

Liquidity transfers rely on external bridge protocols and are facilitated by bridge adapter contract, which are managed by Hub Machines and Spoke Caliber Mailboxes. The protocol includes a dedicated adapter implementation for each supported bridge.

Bridging is a four-step process, executed by the operator, and functions symmetrically in both directions: Hub → Spoke and Spoke → Hub:

1.  Schedule the outgoing transfer on the sender side, which generates a message hash.
2.  Authorize the incoming transfer on the recipient side by registering the message hash.
3.  Send the outgoing transfer through the bridge protocol from the sender side.
4.  Claim the transfer on the recipient side to finalize fund delivery.

token mapping

The protocol assumes that the input and output tokens involved in a bridge transfer are homologous and share the same number of decimals. This assumption relies on the Token Registry, which maintains the mapping between local and equivalent foreign token addresses and must be correctly configured on all chains.

---

# Operator | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/operator#__docusaurus_skipToContent_fallback)

Each strategy has a dedicated Operator responsible for executing strategies to the best of their ability. Operators are granted discretion specifically for executing rebalance actions via Instructions and swaps, as well as initiating cross-chain bridge transfers between Hub and Spoke chains.

The Operator must operate within the boundaries of the Risk Policy, ensuring strict adherence to Risk Policy Caps by never over-allocating funds to any given risk factor. The primary objective is to generate compelling, risk-adjusted returns for Makina users.

At a high level, the Operator has the following responsibilities:

*   Identify new opportunities and submit [Root Updates](https://docs.makina.finance/concepts/governance/root-update-lifecycle)
     for the Risk Manager to review and approve.
*   Execute and maintain their strategies, periodically rebalancing the Portfolio to ensure maximal efficiency and deliver strong, risk-adjusted returns.

The standard operating assumptions on Operators are:

*   Operators are incentivised to maximise performance through performance fees
*   Operators are competent and able to use the provided tooling to effectively

Operators could have their private keys compromised or turn malicious, they could also have software bugs or make operational mistakes, therefore Makina limits trust assumptions on Operators.

The Operator restrictions are:

*   Execution limited to only pre-approved Instructions
*   Swaps allowed only into pre-approved Base Tokens
*   Liquidity Bridging allowed only to pre-approved chains through pre-approved bridges
*   Max loss caps and cooldowns on any position management action
*   Max loss caps and cooldowns on any swap transactions
*   Max loss caps on liquidity bridge transactions

This prevents Operators from willfully or accidentally causing significant losses to a strategy's AUM over a short period, giving the [Security Council](https://docs.makina.finance/concepts/governance/security-council)
 sufficient time to intervene, activate Recovery Mode, and revoke the Operator's ability to execute further actions in the event of deviations.

Active monitoring tooling will be run by the Makina Foundation on all Strategies to detect any unusual behaviour quickly and notify the Security Council.

---

# Overview | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/overview#__docusaurus_skipToContent_fallback)

To provide a comprehensive understanding of the governance system, we will outline the governable components, the entities responsible for their oversight, and the aspects that remain immutable.

---

# Permissions and Scopes | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/permissions-and-scopes#__docusaurus_skipToContent_fallback)

On this page

Protocol-Wide Permissions[​](https://docs.makina.finance/concepts/governance/permissions-and-scopes#protocol-wide-permissions "Direct link to Protocol-Wide Permissions")

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Protocol-wide permissions are covered by roles, managed through an Access Manager contract.

*   **_STRATEGY\_DEPLOYER\_ROLE_**: Grants permission to deploy new strategies to the protocol.
*   **_STRATEGY\_CONFIG\_ROLE_**: Grants permission to assign or update the entities responsible for managing strategies.
*   **_INFRA\_CONFIG\_ROLE_**: Grants permission to configure and maintain shared core contracts, such as registries.

Per-Strategy Permissions[​](https://docs.makina.finance/concepts/governance/permissions-and-scopes#per-strategy-permissions "Direct link to Per-Strategy Permissions")

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Per-strategy permissions are covered by a set of entities, whose addresses are stored in the strategy instances.

*   **_Operator_**: Responsible for day-to-day strategy operations, including position deployments, management, reward harvesting, swaps and transfers across chains. The operator also handles permissioned deposits and redemptions.
*   **_Risk Manager_**: Can update key risk parameters such as: - Merkle Root for allowed Instructions - Loss thresholds - Accounting staleness thresholds - Fee minting frequency - Share minting limits  
    Most of these updates are protected by a timelock mechanism.
*   **_Security Council_**: Monitors activities from operator and Risk Manager:
    *   Can trigger recovery mode in emergency scenarios. When activated, all operator permissions are temporarily transferred to the Security Council.
    *   Can veto updates from Risk Manager (risk parameters + Merkle Root for allowed Instructions).
*   **_Root Guardians_**: Hold veto power over updates to the Merkle Root for allowed Instructions. This root defines authorized operations with external protocols (excluding swaps and bridging), and is critical to the strategy’s security model.

*   [Protocol-Wide Permissions](https://docs.makina.finance/concepts/governance/permissions-and-scopes#protocol-wide-permissions)
    
*   [Per-Strategy Permissions](https://docs.makina.finance/concepts/governance/permissions-and-scopes#per-strategy-permissions)

---

# Risk Manager | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/risk-manager#__docusaurus_skipToContent_fallback)

Along with the Operator, each strategy has a dedicated Risk Manager, whose primary responsibilities include reviewing and submitting new instructions and risk policies, and maintaining the Machine’s risk parameters.

The Risk Manager is responsible for ensuring that the Operator can operate effectively within a secure framework. Maintaining an appropriate balance between flexibility and risk control is key to enabling the Operator to carry out the strategy’s mandate.

All Risk Manager actions must pass through a timelock, during which both the Security Council and the Machine SubDAO hold veto powers. This introduces a layer of trust minimization, ensuring that the Risk Manager cannot apply changes to the strategy atomically or unilaterally.

The Risk Manager has the following responsibilities:

*   Review and verify any [Root Update](https://docs.makina.finance/concepts/governance/root-update-lifecycle)
     requested by the Operator, and then schedule it on the relevant Caliber.
*   Set and adjust all risk parameters for machine and calibers, including max loss caps and cooldowns.
*   Curate the set of [Base Tokens](https://docs.makina.finance/concepts/caliber/base-tokens)
     in each Caliber.
*   Set and adjust the Machine's Risk Policy to ensure compliance with the Mandate.

---

# Root Update Lifecycle | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/root-update-lifecycle#__docusaurus_skipToContent_fallback)

The process for updating the allowed instructions Merkle Root in a specific Caliber will follow a multi-stage approach, consisting of the following steps:

1.  In the public `makina-merkletree` repository, the Operator will submit a PR with the updated root and corresponding instructions. This update will be reviewed by at least two entities: the Security Council and Makina developers.
2.  Pull Request gets merged into main.
3.  After the root is merged into the repository, the Risk Manager retrieves it and submits the transaction to the Caliber, initiating a timelock period.
4.  This action will notify the Security Council and other communication channels like Discord and/or Telegram for further user awareness. Unless vetoed, the new Merkle Root comes into effect at the end of the timelock, and Instructions must then present proofs matching this updated root to be valid for execution.

---

# Safe Security Structure | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/safe-security-structure#__docusaurus_skipToContent_fallback)

All Multisigs within the protocol will adhere to standardized security safeguards:

*   Timelock in owner changes (min: 24h)
*   As a precautionary measure, the Safe implementation will be non-upgradable. This means that once deployed with a specific version (e.g., 1.4.1), it will remain on that version indefinitely.
*   Transactions will not be permissionless; execution will be strictly enforced and limited to the Safe owners leveraging Safe's [Guard](https://github.com/safe-global/safe-smart-account/blob/main/contracts/examples/guards/OnlyOwnersGuard.sol)
    .

In addition to these checks and balances, each owner can utilize an independent simulation engine to simulate transaction payloads in a separate communication channel of their choice (e.g., Telegram, Discord). This ensures independent validation and also enables verification of any root updates, which are critical at the protocol level.

An additional security layer for the Multisigs will be provided by our security partner's product, Hypernative Guardian. During the transaction lifecycle, it can detect malicious activity in the pre-transaction stage and block specific payloads once they reach the blockchain. The Guardian also enables each Multisig to define custom policies, allowing them to block transaction types that fall outside their intended role within the protocol.

This Multisig architecture is designed to prevent sudden ownership changes, allow a sufficient review period, safeguard against unauthorized or malicious implementation upgrades, and restricts the execution of targeted payloads to authorized owners. Given recent incidents related to access control, these measures significantly reduce the attack surface.

---

# Introduction | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/introduction#__docusaurus_skipToContent_fallback)

Makina is an innovative protocol for superior onchain execution. It redefines how smart contract vaults operate by providing a highly agile infrastructure that is used to execute a wide variety of cross-chain strategies: from onchain yield aggregation, to index products, to long-short, delta hedged strategies or any other strategy that can be executed fully onchain.

With Makina users can get access to tokenised assets issued by professionals with full DeFi composability, superior Risk Controls, risk underwriting through a Security Module.

Makina is designed to be fully non-custodial, transparent and trust minimised, providing a secure yet flexible platform on which [Operators](https://docs.makina.finance/concepts/governance/operator)
 with different specialisation and expertise can offer their strategies to onchain users.

Each Strategy is composed of a [Machine](https://docs.makina.finance/concepts/machine/overview)
 deployed on the Hub Chain, and one [Caliber](https://docs.makina.finance/concepts/caliber/overview)
 per supported chain (including the Hub and each Spoke Chain).

*   The Machine manages strategy-wide logic such as handling deposits and withdrawals, calculating share prices, and coordinating cross-chain liquidity bridging.
*   Calibers serve as the execution layer for each chain, enabling operators to perform local actions such as opening and closing positions, harvesting rewards, and swapping tokens.

Upon deployment of a Machine, a mandate for the strategy should be published. The mandate is a high level description of the strategy type and goal, its risk profile, return expectation, opportunity segment and other attributes and charachteristics of the strategy. The mandate will act as a guideline for strategy [Risk Managers](https://docs.makina.finance/concepts/governance/risk-manager)
 and [Operators](https://docs.makina.finance/concepts/governance/operator)
.

---

# Security Council | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/governance/security-council#__docusaurus_skipToContent_fallback)

Besides the Operator and Risk Manager, each strategy is overseen by a dedicated Security Council. Its primary role is to safeguard user funds by providing oversight and emergency intervention capabilities.

Key responsibilities include:

*   **Reviewing Pending Timelock Transactions:** The Security Council reviews all pending timelock transactions submitted by the Risk Manager (e.g., Root updates, risk parameter changes) and may veto any that introduce unacceptable risk to user funds.
*   **Triggering Recovery Mode:** In response to security threats such as hacks, Operator or Risk Manager misbehavior, or funds being at risk, the Security Council can activate Recovery Mode. While in Recovery Mode, the Security Council assumes the Operator’s role until the strategy is stabilized.
*   **Veto Authority:** Outside of Recovery Mode, the Security Council cannot execute actions directly but retains full veto rights over timelocked changes.
*   **Operator Slashing:** When necessary, the Security Council can initiate slashing via the Security Module.

The Security Council acts as a final line of defense, ensuring that neither the Operator nor the Risk Manager can introduce harmful changes without oversight.

---

# Depositors | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/depositors#__docusaurus_skipToContent_fallback)

On this page

The Depositor contract is the entry point through which users deposit funds into a given Machine. Each Machine is linked to a dedicated Depositor instance. The protocol supports multiple Depositor implementations, enabling Machines with different strategies to support different types of deposit flows. A Machine accepts deposits only from its predefined Depositor.

Direct Depositor[​](https://docs.makina.finance/concepts/machine/depositors#direct-depositor "Direct link to Direct Depositor")

--------------------------------------------------------------------------------------------------------------------------------

[DirectDepositor](https://docs.makina.finance/contracts/periphery/depositors/DirectDepositor.sol/contract.DirectDepositor)
 atomically forwards deposited assets to the Machine, and Machine Tokens are minted instantly to the depositor. The contract suports an actionable whitelist, which enables to restrict deposits to KYC-verified participants.

*   [Direct Depositor](https://docs.makina.finance/concepts/machine/depositors#direct-depositor)

---

# Fee Managers | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/fee-managers#__docusaurus_skipToContent_fallback)

On this page

The Fee Manager contract defines how fees are applied to a Machine. Each Machine is linked to a dedicated FeeManager instance. Different strategies may require different fee models, and the protocol supports multiple FeeManager implementations.

Fees can be of two types:

*   Fixed fees: based on assets under management (AUM) and elapsed time.
*   Performance fees: based on strategy performance.

Fees take the form of newly minted [Machine Tokens](https://docs.makina.finance/concepts/machine/machine-token)
, which are distributed to the Operator, [Security Module](https://docs.makina.finance/concepts/machine/security-module)
, and Makina DAO. Since these tokens increase the overall supply without a corresponding increase in AUM, they dilute the share price, effectively socializing fees across all Machine Token holders. Fees are minted and distributed atomically along Machine AUM updates.

Watermark Fee Manager[​](https://docs.makina.finance/concepts/machine/fee-managers#watermark-fee-manager "Direct link to Watermark Fee Manager")

-------------------------------------------------------------------------------------------------------------------------------------------------

See the [WatermarkFeeManager](https://docs.makina.finance/contracts/periphery/fee-managers/WatermarkFeeManager.sol/contract.WatermarkFeeManager)
 contract page for more details.

### Fixed Fee[​](https://docs.makina.finance/concepts/machine/fee-managers#fixed-fee "Direct link to Fixed Fee")

The contracts divides fixed fee into **Security Module fee**, which incentivizes stakes into the Security Module, and **Management fee** which incentivizes the Operator and supports Makina DAO.

The fixed fee is calculated as follows:

FixedFee\=TokenSupply∗feeRatesec∗(currentTimestamp−lastTimestamp);FixedFee = TokenSupply \*feeRate\_{sec} \* (currentTimestamp - lastTimestamp);FixedFee\=TokenSupply∗feeRatesec​∗(currentTimestamp−lastTimestamp);

For example, with a feeRate of 2% annual, a token supply of 1'000'000 and 1 day elapsed:

FixedFee\=1′000′000∗0.02365∗86400∗86400\=54.794FixedFee = 1'000'000 \* \\dfrac{0.02}{365 \* 86400} \* 86400 = 54.794FixedFee\=1′000′000∗365∗864000.02​∗86400\=54.794

The Fixed fee is then split three ways between the Security Module, the Operator and the Makina DAO.

### Performance Fee[​](https://docs.makina.finance/concepts/machine/fee-managers#performance-fee "Direct link to Performance Fee")

Besides fixed fee, performance fee further incentivize the Operator depending on strategy performance, and provides ongoing support to Makina DAO.

The `WatermarkFeeManager` implementation supports a high watermark mechanism ensures performance fee are charged only when the new share price exceeds the stored watermark.

When the new share price is above the watermark, the performance fee is calculated as follows:

PerfFee\=TokenSupply∗(newTokenPrice−prevTokenPricenewTokenPrice)∗perfFeeRatio;PerfFee = TokenSupply \* (\\dfrac{newTokenPrice - prevTokenPrice}{newTokenPrice}) \* perfFeeRatio;PerfFee\=TokenSupply∗(newTokenPricenewTokenPrice−prevTokenPrice​)∗perfFeeRatio;

For example, with a perfFeeRate of 10% annual, a token supply of 1'000'000 and share price increase from 1.00 to 1.01:

PerfFee\=1′000′000∗1.01−1.001.01∗0.1\=1000PerfFee = 1'000'000 \* \\dfrac{1.01-1.00}{ 1.01} \* 0.1 = 1000PerfFee\=1′000′000∗1.011.01−1.00​∗0.1\=1000

The performance fee is then split two ways between the Operator and the Makina DAO.

*   [Watermark Fee Manager](https://docs.makina.finance/concepts/machine/fee-managers#watermark-fee-manager)
    *   [Fixed Fee](https://docs.makina.finance/concepts/machine/fee-managers#fixed-fee)
        
    *   [Performance Fee](https://docs.makina.finance/concepts/machine/fee-managers#performance-fee)

---

# Overview | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/overview#__docusaurus_skipToContent_fallback)

Makina defines the notion of a Machine as a strategy specific vault smart contract. The Machine is the main touch point for users. It handles Deposits and Withdraws, Share Price and Fee Calculations.

Machines are always deployed on the Hub Chain, which can be chosen by the Operator, but for most case is Ethereum Mainnet. Each Machine defines a single Accounting Token which will be the only token that can be deposited and withdrawn by users, and which denominates the share price.

Each Machine issues a Machine Token, an asset who's price depends on the performance of the Machine's strategy. The Operator’s goal and incentive is to always maximise the long-term price appreciation of the Machine Token.

Each Machine is connected to a Caliber on the Hub Chain as well as multiple other Calibers on the Spoke Chains.

Each Machine is required to have [Depositor](https://docs.makina.finance/concepts/machine/depositors)
 and [Redeemer](https://docs.makina.finance/concepts/machine/redeemers)
 contracts as well as a [Fee Manager](https://docs.makina.finance/concepts/machine/fee-managers)
 contract. These contracts may vary in their logic depending on the type of strategy executed and its specific requirements.

Machines are flexible enough to support various types of strategies, from yielding and fixed income strategies to volatile token indexes, Machines can be expanded with diverse manager contracts to best meet the strategie's needs.

---

# Pre-Deposit | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/pre-deposit#__docusaurus_skipToContent_fallback)

Pre-deposits enable strategies to build baseline liquidity prior to launch. This is helpful for bootstrapping, as it allows strategies to start with diversified exposure and efficient allocation across multiple opportunities.

Makina supports a standardised flow for pre-deposits through its Core Factory, providing a secure and efficient way for Operators to gather the liquidty required to launch new strategies.

The [PreDepositVault](https://docs.makina.finance/contracts/core/pre-deposit/PreDepositVault.sol/contract.PreDepositVault)
 contract defines a pre-deposit asset, this can be any yield-bearing token which has an oracle feed against the accounting token and which can later be enabled as a base token.

`PreDepositVault` specifies a pre-deposit asset, typically a yield-bearing token, that:

*   Is priceable against the accounting token through the [Oracle Registry](https://docs.makina.finance/concepts/oracle-registry)
    .
*   Will later be enabled as a base token within the strategy.

Users deposit this pre-deposit token into `PreDepositVault` to earn baseline yield during the pre-deposit phase. The vault’s share price increases in line with the yield accrued by the pre-deposit token.

Importantly, `PreDepositVault` mints the [Shares](https://docs.makina.finance/concepts/machine/machine-token)
 of the future Machine it will eventually migrate into. When the Machine is deployed, there is no need to migrate user balances. Only the minting authority is transferred from the Pre-Deposit Vault to the Machine, enabling a seamless transition into the active strategy.

![makina-pre-deposit](https://docs.makina.finance/assets/images/makina-pre-deposit-f7a7a7bee54cd14f9765b36013417b39.png)

---

# Redeemers | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/redeemers#__docusaurus_skipToContent_fallback)

On this page

The Redeemer contract is the exit point through which users redeem Machine Shares from a given Machine and receive the underlying funds. Each Machine is linked to a dedicated Redeemer instance. The protocol supports multiple Redeemer implementations, allowing Machines with different strategies to handle different types of redemption flows. A Machine accepts redemptions only from its predefined Redeemer.

Given that assets deployed into positions are not liquid, atomic redemptions are not possible.

Redeemers are therefore always expected to be queue contracts which need to be managed and filled by the operator after closing positions to free up the capital required to meet redemption requests. Makina has no control over this process.

AsyncRedeemer[​](https://docs.makina.finance/concepts/machine/redeemers#asyncredeemer "Direct link to AsyncRedeemer")

----------------------------------------------------------------------------------------------------------------------

[AsyncRedeemer](https://docs.makina.finance/contracts/periphery/redeemers/AsyncRedeemer.sol/contract.AsyncRedeemer)
 is an asynchronous ERC-721 Redeem Queue in which Machine tokenholders can request a redemption request. Requests are settled on a First-In First-Out basis, and once settled, users have unlimited time to claim their withdrawn funds.

The Queue implements a three step process.

1.  A user requests a redemption, and locks their shares in the queue. In exchange they receive a non-fungible token representing their request.
2.  The Operator settles the queue against the Machine which transfers the Shares to the Machine where they are instantly burned. In return, Accounting Tokens are sent from the Machine to the Queue contract at the current share price.
3.  The user can claim their withdrawn funds by burning the non-fungible request token in exchange for the strategy's Accounting Token.

The contract suports an actionable whitelist, which enables to restrict redemption requests, as well as asset claiming to KYC-verified participants.

*   [AsyncRedeemer](https://docs.makina.finance/concepts/machine/redeemers#asyncredeemer)

---

# Security Module | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/security-module#__docusaurus_skipToContent_fallback)

On this page

The [Security Module](https://docs.makina.finance/contracts/periphery/security-module/SecurityModule.sol/contract.SecurityModule)
 serves as an insurance reserve, designed to mitigate losses in the event of a shortfall caused by incidents such as hacks, bad debt, or a depeg.

Machine tokenholders can lock their tokens in the Security Module, and get **Security Tokens** in return. In the event of a shortfall, the locked tokens can be burnt to reduce the Machine Token supply and cover losses.

In return, security participants receive enhanced yields, distributed as a portion of the Machine’s minted fee tokens.

### Unstake Cooldown Period[​](https://docs.makina.finance/concepts/machine/security-module#unstake-cooldown-period "Direct link to Unstake Cooldown Period")

A cooldown period for redeeming security tokens prevents users from profiting from boosted yields while retaining the ability to frontrun an expected slashing event in anticipation of losses through an early exit. The Security Council determines the cooldown period, but a minimum of 7 days is recommended.

When initiating a cooldown period, users receive a Receipt NFT in exchange for their security tokens. The cooldown can be cancelled before it reaches maturity, in which case the security tokens are returned to the Receipt NFT holder.

### Max Slashing[​](https://docs.makina.finance/concepts/machine/security-module#max-slashing "Direct link to Max Slashing")

The Security Module enforces a maximum slashing limit, defined by two parameters:

*   a percentage of the Machine Token balance, and
*   a minimum required remaining balance after slashing.

The effective limit is the more restrictive of the two. This guarantees that, in the event of slashing, the amount burnt never exceeds the configured maximum.

*   [Unstake Cooldown Period](https://docs.makina.finance/concepts/machine/security-module#unstake-cooldown-period)
    
*   [Max Slashing](https://docs.makina.finance/concepts/machine/security-module#max-slashing)

---

# Machine Token | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/machine-token#__docusaurus_skipToContent_fallback)

[Machine Tokens](https://docs.makina.finance/contracts/core/machine/MachineShare.sol/contract.MachineShare)
 are tokenized ERC20 representations of the strategy operating on the Machine.

Shares are fully DeFi compatible, and can be acquired in two ways:

*   Minted by depositing Accounting Tokens directly into the Machine
*   Purchased on secondary markets.

The Machine mint and redeems Shares at its current [Share Price](https://docs.makina.finance/concepts/machine/share-price)
. This price is periodically updated based on the total assets the Machine controls, including funds held directly and those managed by [Calibers](https://docs.makina.finance/concepts/caliber/overview)
.

Machine Tokens can be integrated into external protocols such as lending market, where they can provide superior collateral qualities; into DEXs where it can be paired with other assets to provide higher LP returns; or they can simply be held in treasury to benefit from the high risk adjusted return.

Machine Tokens leverage [Wormhole NTT](https://ntt.wormhole.com/)
 for fast and secure cross-chain transfer between Ethereum Mainnet, it's L2s and non-EVM chains such as Solana.

For the official Makina Machine Token bridge visit [https://app.makina.finance/bridge](https://app.makina.finance/bridge)
.

---

# Share Price | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/machine/share-price#__docusaurus_skipToContent_fallback)

The Machine calculates a Share Price at which it mints and redeems Machine Tokens.

The Share Price reflects the total value — denominated in the Accounting Token — of all assets held by the Machine, including those in its Calibers and deployed positions. This represents the Machine’s total assets under management (AUM).

The successful execution of the strategy by the Operator leads to value accrual and increase in AUM, either through earned yield or appreciation of asset prices relative to the Accounting Token.

SharePrice\=AUMShareSupply\\text{SharePrice} = \\dfrac{\\text{AUM}}{\\text{ShareSupply}}SharePrice\=ShareSupplyAUM​

An increase in AUM without corresponding increase in number of shares outstanding leads to an increase in Share Price. The total AUM of the Machine is the sum of any idle assets on the Machine's balance and the local [AUMs of all Calibers](https://docs.makina.finance/concepts/caliber/caliber-accounting)
 connected to the Machine.

Idle assets may be held on the Machine's balance in case new deposits came in that where not yet accounted for, or because they have just been bridged back. Operators may also decide to keep some idle assets as a buffer for withdraws.

AUM\=∑Balanceidle+∑CaliberAUM+∑PendingbridgeAUM = \\sum Balance\_{idle} + \\sum Caliber\_{AUM} + \\sum Pending\_{bridge}AUM\=∑Balanceidle​+∑CaliberAUM​+∑Pendingbridge​

The AUM number's from the Calibers are received by the Machine through the [Cross-Chain Accounting](https://docs.makina.finance/concepts/cross-chain/cross-chain-accounting)
 flow.

Additionally, any pending bridge transfers that are not yet held by the Machine or its Calibers but are currently in transit are included in the AUM. This ensures that no value is lost during the bridging process, which can take up to several days.

---

# Recovery Mode | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/security/recovery-mode#__docusaurus_skipToContent_fallback)

On this page

Recovery Mode can be triggered at the discretion of the [Security Council](https://docs.makina.finance/concepts/governance/security-council)
 to protect Machine vault depositors when any of the following conditions are met:

*   The Operator has been inactive for an extended period
*   The share price exhibits abnormal behavior (e.g., sudden spikes or drops).
*   Suspicious activity is detected that may indicate Operator deviation.

### Effects of Recovery Mode[​](https://docs.makina.finance/concepts/security/recovery-mode#effects-of-recovery-mode "Direct link to Effects of Recovery Mode")

When Recovery Mode is active, all Operator permissions are temporarily transferred to the Security Council, and operator is blocked from executing any actions. Moreover, the following restrictions and permissions are enforced:

*   Caliber:
    *   Positions can only be decreased.
    *   Swaps are limited to conversions toward the accounting token only.
    *   Cross-chain bridge transfers are limited to Spoke → Hub direction.
*   Machine:
    *   New deposits are disabled.
    *   AUM updates are paused.
    *   Bridge Transfers\*\*: Outbound transfers from Hub → Spoke chains are blocked.

### Scope and Exit[​](https://docs.makina.finance/concepts/security/recovery-mode#scope-and-exit "Direct link to Scope and Exit")

Recovery Mode is chain-specific: Each Spoke Caliber must have its Recovery Mode activated independently.

Exiting Recovery Mode is at the discretion of the Security Council, once the system’s state is deemed stable and secure.

*   [Effects of Recovery Mode](https://docs.makina.finance/concepts/security/recovery-mode#effects-of-recovery-mode)
    
*   [Scope and Exit](https://docs.makina.finance/concepts/security/recovery-mode#scope-and-exit)

---

# Oracle Registry | Makina Docs

[Skip to main content](https://docs.makina.finance/concepts/oracle-registry#__docusaurus_skipToContent_fallback)

On this page

The Oracle Registry acts as an aggregator of [Chainlink price feeds](https://docs.chain.link/data-feeds/price-feeds)
, and prices tokens in a reference currency (e.g. USD) using either one or two feed hops. This enables any priceable token to be valued relative to any other.

This component plays a crucial role in the protocol, ensuring accurate pricing of assets within the protocol in order to compute Calibers and Machines AUM.

#### Example: Pricing Token A in Token B[​](https://docs.makina.finance/concepts/oracle-registry#example-pricing-token-a-in-token-b "Direct link to Example: Pricing Token A in Token B")

To determine the price of Token A in terms of Token B, the registry follows these steps:

1.  **Check Token A → Reference Currency:** Given that a direct Chainlink price feed exists from Token A to the reference currency (e.g., USD), the registry uses it.
2.  **Check Token B → Reference Currency (via intermediate):** Given that Token B lacks a direct feed to the reference currency, the registry can be provided with a 2-feeds path: - Token B → Token C - Token C → Reference Currency It combines both feeds to compute Token B’s price in the reference currency.
3.  **Compute Token A → Token B:** With both tokens priced in the reference currency, the final price of Token A in Token B is derived by dividing their reference prices.

### OracleRegistry Usage Scenarios[​](https://docs.makina.finance/concepts/oracle-registry#oracleregistry-usage-scenarios "Direct link to OracleRegistry Usage Scenarios")

The OracleRegistry is specifically involved in the following scenarios:

*   **Pricing Token Balances**: Computes the value of Machine and Caliber token balances relative to the accounting token.
*   **Valuation of Caliber Positions:** Determines the total value of a position held within a Caliber.
*   **Value Loss Checks:** After each Caliber operation (e.g., position management or swaps), the registry is used to verify that value loss remains within acceptable bounds.

The registry is governed by the DAO through a Timelock.

*   [OracleRegistry Usage Scenarios](https://docs.makina.finance/concepts/oracle-registry#oracleregistry-usage-scenarios)

---