High Level Architecture

Use the API

For most integrations, interact with Boros through the REST API and SDK rather than calling contracts directly. The API handles calldata encoding, settlement, and transaction submission. The contract details below are provided as an architectural reference.

Core Contracts

graph TD
    Router --> MarketHub
    MarketHub --> Market-1
    MarketHub --> Market-2
    MarketHub --> Market-3
    MarketHub --> ...
    MarketHub --> Market-n

Router authenticates and forwards user operations to MarketHub.

MarketHub receives user operations from Router, forwards them to the correct market contract, settles fees/payment, and checks that accounts fulfill the margin requirements.

Market executes user operations from MarketHub, then returns payment amount and data for margin checking.

Router

Router is the gateway to the Boros protocol. Its main functionality is authentication and authorization. Transactions can be sent to Router in two ways:

• Direct call where msg.sender is used as user address
• Agent call where user signs messages of desired operations
  • Only available to Pendle's permissioned relayers
  • Accessed through the Boros SDK

MarketHub

MarketHub is the market coordinator and risk manager of Boros. MarketHub holds user deposits and keeps track of users in the system and the markets that they have entered. Users are identified by MarketAcc, a custom type made of:

• user EVM address
• subaccountID
  • Every user has up to 256 subaccounts, though only subaccount 0 is available for direct calls
• tokenId
  • Every collateral token has a specific ID inside Boros. A given MarketAcc can only interact with markets of that collateral token.
• marketId
  • For an isolated-margin account, this is the marketId of the market that this account operates on.
  • For a cross-margin account, this is a special value CROSS, equal to $2^{24}-1$.

An account can enter a single market, if it is isolated, or multiple markets, if it is CROSS. Every market represents a different interest rate swap type: different token, different maturity, different reference rate. However, every market entered by a given account must share the same collateral token.

After each user operation, MarketHub checks that accounts fulfill the margin requirements.

Market

Boros markets are deployed as separate contracts. Markets are differentiated by their descriptors:

- bool isIsolatedOnly
- TokenId tokenId
- MarketId marketId
- uint32 maturity
- uint8 tickStep
- uint16 iTickThresh
- uint32 latestFTime

Market provides an on-chain central limit order book, as well as over-the-counter (OTC) trading. For each user, market keeps track of position size and list of orders. When an order is filled, or an OTC trade is made, the position size is updated accordingly, and the fixed interest is paid upfront. Variable interest payments are paid on a fixed time period; the payment amount is determined by the accrual of the variable interest since last update, which is reported on-chain via an oracle.

AMM

Automated Market Makers (AMM) provide continuous liquidity alongside the order book. In Boros, AMMs are like normal accounts: they don't have any special permissions except that they can perform OTC trades with users when requested. Router ensures optimal liquidity routing between AMMs and order book for best swap rate.

More details about AMM can be found in the whitepaper.

Supporting Contracts

FIndex Oracle

Each market has an associated FIndex Oracle that provides the floating rate data used in periodic settlement. The oracle reports the cumulative floating index and fee index, which are packed into the FIndex type. Oracle updates trigger settlement calculations for all positions in the market. The oracle address is configured per market and can be queried via getMarketConfig().

Deposit Box

Deposit Boxes are deterministic per-user contracts created by the DepositBoxFactory. They serve as intermediary wallets for receiving cross-chain deposits and performing token swaps (via external DEX routers) before depositing into Boros. Funds in Deposit Boxes are managed by Pendle's backend — users do not interact with them directly. The factory computes a deterministic address from (root, boxId) so senders can pre-calculate the deposit target.

Bot Infrastructure

Pendle operates permissioned bots that perform automated risk management on behalf of the protocol. These bots can affect user positions and orders:

• Liquidation Bot: Liquidates accounts whose health ratio drops to 1.0 or below
• Force-Cancel Bot: Cancels open orders for accounts approaching liquidation, or orders with rates that deviate too far from the mark rate (see Risk Management Actions)
• CLO Bot: Toggles markets into Close-Only mode when open interest approaches risk limits

Users should monitor their order status and account health, especially during volatile market conditions, as these bots may modify open orders or trigger liquidations.

Token Decimals

Internally, Boros uses 18-decimals fixed point for all numerical values, including position size, payment, fees, etc.

When depositing ERC20 tokens of non-18 decimals, the amount will be scaled up. Similarly, when withdrawing, the amount will be scaled down.

Tokens with decimals greater than 18 are not supported.