RealFi deploys reserve capital into a diversified portfolio of real-world assets including U.S. Treasuries, money market funds, investment grade CLO ETFs, floating-rate corporate notes and private credit. The RealFi treasury reconciles borrower repayments off-chain, then mints new USDrf on-chain to reflect realized profits and distributes it to sUSDrf holders through discrete weekly staking epochs, so each sUSDrf becomes redeemable for progressively more USDrf. The remainder of the income is allocated to a configurable treasury address. sUSDrf is the risk-absorbing layer and takes portfolio losses before USDrf holders are affected.

RealFi issues USDrf, a reserve-backed digital dollar, and sUSDrf, a non-rebasing staked token received by staking USDrf. USDrf is backed 1:1 by a reserve portfolio anchored by a liquidity buffer of U.S. Treasury bills and tokenized money market funds, supplemented by liquid floating-rate credit and short-tenor, senior-secured private credit. Cardano is the canonical chain for supply accounting, and a burn-and-mint bridge extends USDrf and sUSDrf to EVM networks.

RealFi is a stablecoin ecosystem built on Cardano. USDrf and sUSDrf are issued by separate British Virgin Islands business companies, while the protocol technology and its oversight are governed by Cayman Islands foundation companies.

website

twitter

discord

telegram

Stablecoin issuers

RealFi

# Asset senders (daily) methodology

## 1. Overview

Asset senders (daily) is calculated as the number of unique addresses that initiate asset transfers within a fixed 24-hour window. Daily activity is measured from 00:00 UTC to 23:59 UTC for each tracked asset. Active transactors are isolated from passive recipients by identifying only the sending addresses of transactions. This metric is utilized to evaluate the daily active user base and transaction utility of tokenized assets across multiple blockchain networks.

## 2. Data sources

- **EVM chain events**: ERC-20 `Transfer` events, covering EVM-compatible chains (Ethereum, Arbitrum, Base, Polygon, Optimism, and others)
- **Solana instructions**: Token transfer instructions, covering Solana
- **Aptos, Cardano, Stellar Classic, and Sui events**: Token withdraw events, covering Aptos, Cardano, Stellar, and Sui
- **Near, Algorand, Injective, Ripple, and Stellar Soroban events**: Token transfer events, covering Near, Algorand, Injective, Ripple, and Stellar
- **Polkadot Asset Hub events**: `Transferred` events from the `assets` pallet, covering Polkadot Asset Hub
- **Asset metadata**: Token addresses and chain configurations

## 3. Step-by-step calculation

### Component A: Extract sender addresses

- **Purpose**: Identify and extract the unique sending addresses for each asset transfer across all supported chains.
- **Logic**: On EVM-compatible chains, sending addresses are extracted from the `from` field of ERC-20 `Transfer` events, excluding the zero address to filter out mint transactions. On Solana, sending addresses are extracted from the authority address field of token transfer instructions. On Aptos, Cardano, Stellar Classic, and Sui, sending addresses are identified from the account address field of token withdraw events. On Near, Algorand, Injective, and Stellar Soroban, sending addresses are extracted from the sender address field of token transfer events, with null addresses excluded. On Ripple, sending addresses are extracted from token transfer events where the transfer value is negative. On Polkadot Asset Hub, sending addresses are extracted from the event data of `Transferred` events emitted by the `assets` pallet.
- **Key fields**: `timestamp` (block timestamp truncated to daily grain), `token_address` (the contract or asset identifier), `sender_address` (the address initiating the transfer)

### Component B: Consolidate and deduplicate sender data

- **Purpose**: Aggregate sender addresses across all chains and prepare the dataset for daily unique counting.
- **Logic**: Sender records from all individual chains are consolidated into a unified dataset. For each asset on each chain, the sending addresses are grouped by day. To prevent double-counting, duplicate sender addresses for the same asset on the same chain within the same 24-hour window are removed.
- **Key fields**: `timestamp` (daily timestamp), `chain_id` (blockchain identifier), `token_address` (asset address), `sender_address` (unique sending address)

### Component C: Final aggregation

- **Purpose**: Calculate the final daily active sender count per asset and per chain.
- **Logic**: The consolidated dataset is aggregated to compute the daily active senders. Unique sending addresses are counted for each asset on a daily basis, both at the individual chain level and aggregated across all chains for multi-chain assets. If no transfer activity is recorded for a tracked asset on a given day, the daily sender count is filled with zero values.
- **Key fields**: `timestamp` (daily timestamp), `chain_id` (blockchain identifier), `token_address` (asset address), `asset_dau` (daily active senders count)

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

Unique asset senders over a fixed 24-hour window.

RealFi

Asset senders (daily)

Asset senders (daily)

Competitive landscape