The protocol operates through smart contracts that analyze market conditions every minute and automatically rebalance deposits across different lending pools to optimize returns. Users deposit USDC/USDT to receive CRT tokens that appreciate in value as yield accrues to the vault, with funds diversified across multiple protocols to reduce single points of failure and enable programmatic responses to market events.

DefiCarrot offers a yield-bearing token (CRT) that automatically optimizes stablecoin yields across multiple Solana lending protocols including Kamino and MarginFi. The platform continuously monitors and rebalances funds between the top 5 lending protocols to capture the highest available rates for USDC and USDT deposits, providing users with automated yield generation without manual protocol management.

DefiCarrot is a decentralized finance protocol built on the Solana blockchain that provides automated yield optimization for stablecoin deposits. The platform operates as a yield aggregator that simplifies DeFi lending through a single token interface.

twitter

website

github

discord

telegram

Real-world asset (RWA) issuers

DefiCarrot

# DEX trading volume methodology

## 1. Overview

DEX trading volume is the total value of trades involving a specific asset executed on decentralized exchanges, broken out by the exchange and product where the trade was executed (venue). Integrated venues include Uniswap, Aerodrome, PancakeSwap, and Fluid, among others, with coverage expanding as more are added.

## 2. Data sources

- **EVM chain events**: Swap and trade events from decentralized exchange contracts, covering EVM-compatible chains (Ethereum, Arbitrum, Base, Polygon, Optimism, and others)
- **Solana instructions**: Swap and trade instructions from decentralized exchange programs, covering Solana
- **Hyperliquid native spot**: Spot trading data from Hyperliquid
- **Asset metadata**: Token addresses and decimal precision
- **External data**: End-of-day price feeds

## 3. Step-by-step calculation

### Component A: Extract trade events and instructions

- **Purpose**: Retrieve raw trade data from decentralized exchange contracts, programs, and native spot feeds.
- **Logic**: On EVM-compatible chains, swap and trade events are parsed from decentralized exchange contracts. On Solana, swap and trade instructions are parsed from decentralized exchange programs. For each trade, the raw amounts of both traded tokens (the token sold and the token bought) are extracted along with the pool address, chain, and product identifier. For Hyperliquid, native spot trading volume is retrieved directly.
- **Key fields**: `amount_0` (raw quantity of first token), `amount_1` (raw quantity of second token), `token_address_0` (address of first token), `token_address_1` (address of second token), `timestamp` (block timestamp), `trading_volume` (raw trading volume for native spot)

### Component B: Normalize amounts and apply valuation

- **Purpose**: Normalize token quantities and calculate the USD value of the trade.
- **Logic**: Raw token amounts are normalized by decimal precision retrieved from asset metadata. Normalized amounts are multiplied by end-of-day price feeds from the price pipeline. To mitigate wash trading and mispricing, a conservative valuation is typically applied where the total trading volume of the trade is determined by taking the lesser USD value of the two legs (the token sold and the token bought). However, for trades involving exactly one tokenized stock, the valuation is determined solely by the tokenized-stock leg to prevent mispricing from unpriced counterparties. Hyperliquid native spot trading volume is retrieved pre-valued and is not subject to this valuation logic.
- **Key fields**: `trading_volume` (calculated USD value of the trade), `token_address_0` (address of first token), `token_address_1` (address of second token)

### Component C: Resolve trade legs and final aggregation

- **Purpose**: Attribute trading volume to each individual asset and aggregate by venue.
- **Logic**: Each trade is typically split into two distinct legs to represent both sides of the transaction, where one leg is categorized as a sell for the token sold by the trader, and the other leg is categorized as a buy for the token bought by the trader. Hyperliquid native spot trading volume is excluded from this split as it is retrieved pre-split by trade direction. The trading volume is then aggregated by summing the USD values across trade directions, assets, chains, and venues.
- **Key fields**: `trade_direction` (direction of the trade leg), `token_address` (resolved token address), `trading_volume` (aggregated USD volume)

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Value of trades involving the asset on decentralized exchanges, counted on both sides of each trade, broken out per venue.

DefiCarrot

DEX trading volume

DEX trading volume

Competitive landscape

Venue breakdown